daily post

From waterfall style having extensive documentation for each SDLC phase till the Extreme programming / SCRUM with very basics like user stories

I must add here, when teams say we’re going ‘Agile’, so don’t need anything except for user stories, that does not make me happy

Too much we run into problems of maintaining them,

Too little, and as soon as one or two key people leave their position, everyone is in trouble

It should be enough to sustain development, and keep the process lean enough

I guess everyone would agree on all the aforementioned, the problem is “Striking the right balance”..

I’d like to propose the following as a yard stick:

– Anyone wishing to understand any part of the code should not have the need to hunt down people to understand. Sufficient commenting and coding practices should be used

– Anyone wishing to learn about how the system should behave in a certain scenario, can find that info without bugging every single developer.

For application domain, one can utilize user stories, gherkin feature files (BDD), mind maps, test cases, client specifications

For code understanding, code documentation, commenting, coding practices, architecture documents

Thoughts?
#QsDaily #RedefiningSoftwareQuality

Make sure to follow the “Pillars of Automation Framework Design”

Unfortunately most teams start with UI automation

Which is the toughest and has the lowest return

Nonetheless it is important, so best to do it right

The 4 Pillars are:

• Maintainability
• Reusability
• Scalability
• Robustness

Description of those here:

#TheAutomationBlogBook #TestAutomation

It’s one which is most scarce – TIME – and the successful know that

It cannot be created or borrowed

Every person has 24 hours, and once they pass, they will NEVER RETURN

The trick is utilize your time in the best possible place you can

Ideally we should do stuff only which we MUST do ourselves

DELEGATE anything else that can be done by someone else

This will take disciple, planning and a burning desire to head towards your goals

PS.
This is important for testers and software development teams too

References:
“The art of self-discipline” by Brian Tracy
“The Millionaire booklet” by Grant Cardone

A #QsEpisode in which @Jim Hazen shares names of few automation experts over the years

I was familiar with most recent ones, but folks from back in the day I did not know of

Quite a few people have been contributing over the past many yers

Teaching tricks of the trade and their experiences

You either learn by experiencing it yourself or by learning from someone elses experience

It’s best not to reinvent the wheel and learn from those who have seen it before

Here’s the segment of the talk around this topic:

P.S.
This is not a conclusive list. Just few names recalled at that time.

Jim Hazen shares the story behind the term he is famous for “AutoMagic”

He was kind enough to spend some time talking about automation and it’s history

Instead of uploading the whole 2 hour long talk as one video, I’ll be creating topic wise smaller ones

If you are not introduced to Jim or the term “AutoMagic”, you would want to listen to this:

Stuck with processing red tape to get things done?

Here’s one way how I went around it

I was seeing a major lacking in our code coverage for a safety critical device

The only way to test it was through white box testing, having entrenched silos it was not an easy sell

Instead of selling upfront, we went covert to build a case first

Implement and generated results from the intrusive testing technique,

Once we had a business case opened it up to management and

The miracle happened, despite it seeming impossible to institutionalize, the evidence of its necessity was evident

And since then have tried this few more times with excellent results..

Give it a try next time, I’d be eager to know how it went..

Remember Web front end development 15 years ago, and what has WordPress and other platforms done to it today?

The same might happen with CI processes through tools like Jenkins

The number of tools providing integrations to Jenkins is getting insane

Which is a really good thing, CI and Continuous testing is becoming way important

And getting hooks in there is not as smooth yet, but we can surely get there, probably in the near future

It might feel complex if setting up Jenkins is not approached the right way

Here’s a short guide to the very basic setup and brief description on it’s moving parts:

IMHO – Lessons learned and the relationships you built.

We might have supported financial needs while being on that job

But the lessons we learned through our experiences are far more important

And even more are the relationships we built

On that note, I’d like to thank a team member of mine who just moved on..

Thank you @Arslan for your efforts and your contribution towards the team

I truly wish you all the success and hopefully

You had great experiences with us because I’m sure we build great relationships..

One area I see neglected a lot is code complexity

I was fortunate to have worked for safety critical devices early on and learn some valuable lessons

One of which is code complexity (nested conditions)

When your code goes beyond a certain complexity level it becomes hard to have a deterministic result

More than often, I’ve seen a single area of code made too ccrammed and complex leading to problems all over

Spread out your conditions, instead of going deep vertically, try to go horizontal in your control flow

More on common UI problems causing flakiness:

https://goo.gl/tSGm8A

Try changing things around you or yourself?

The kind of life you are living is not because of the people around you

It’s because of how you feel about and react to life

The people, events, opportunities we see around us are a manifestation

Manifestion of our thoughts and expectations

So to change your surrounding, change your thoughts and manifest the change you want to see

Think and become the change you want to be

Credits:
How to be a badass by Jensen Shero