Daily Posts

There is a lot that goes into building a great team,

IMHO hiring the ‘right’ people and then giving them freedom are key ingredients.

The ‘right’ people may not be just highly skilled, but also have the right attitude and social skills.

Giving freedom is even harder part. But remember, your building a great team to ‘think’ and give you solutions, not so you tell them what to do.

Giving freedom not only leads to good decisions, but also increases ownership in the team

When they are taking decision, then they try their best to make it a success – if you decide on their behalf, there’s less ownership.

And all of that leads to good quality. Ultimately quality is not something you paint on top – it’s the way you build software determines the quality.

#RedefiningSoftwareQuality #AgileTransformation #TeamBuilding #Hiring

“Default to open” (from how google works by Eric Schmidt)

Many of us designing platforms, gathering information / insights, generating product documentation, source code – the default state is to keep it all secure location

Then we start thinking about giving access on ‘need basis’ and ask people of ‘evidence’ why they need access

At first this may seem like common sense and harmless, but before you know you have all sorts of things under lock and key

Different project source codes, product documentation, analysis, features being developed, CI pipeline test results… and the list goes on

This stifles progress and engineers to do their job well, most of their time then is spent ‘unblocking’ themselves.

The default setting to EVERYTHING should be ‘OPEN’, not ‘CLOSED’.

Engineers in your teams are not hired to do dummy jobs like building walls, they are hired to THINK

And if you want to help them take good decisions, they need to be exposed to first hand information / stats & figures.

To have true autonomy, you should have free flow of information.

#RedefiningSoftwareQuality #AgileTransformation #Transformation

Today I learned positivity has a special place in ‘being’ agile.

Unless your team does not have a positive vibe, they wouldn’t be able to self-organize and be productive.

From my personal experience, when I’m feeling down my productivity starts to dwindle.

For many of us, we are driven by our past experiences and most of us don’t expect really great things at work. We’re just waiting to find something negative and start with our rant.

If we treat “The past as a place of reference, not a place of residence” [1] things would be a lot better.

“The past is a place of learning, not a place of living” [1] – live in the present with a positive attitude!

#AgileTransformation #Positivity

Flakiness kills automation..

The worst team I’ve seen, their scripts flakiness was around 70 – 80% !

With that kind of failure rate, looking at the reports was impossible, so instead they saved ‘error’ messages from the AUT separately and look only at those

That was an extreme, but more than often I see teams having inadequate details in their reports

I’m happy to see over years reporting libraries have improved, still sometimes come across teams not doing it well.

Further on automation test reports in the linked article (first comment)

#TestAutomation #TestReport

Crystallize your target state, but plan for only few weeks ahead..

The mistake I’ve made in the past is to plan every step of the way on how to reach the target state.

Being agile, to me, means have a very clear picture of where you want to go but only plan the steps you’ll take in the next few sprints.

We’re bad at planning and cannot predict very well, so plan just enough.

For this to work, management and the team need a little faith.

You’ll get there, but by taking small steps in the right direction and course correcting, not by planning every step of the way’.

#RedefiningSoftwareQuality #AgileTransformation #Agile

Should tester’s learn programming? And is it just for automation?

IMHO, every software engineer should be able to program, and it’s not just for automation,

Rather the ability to understand production code and how the control flow works across the tech stack.

Not everyone has to be a wiz at the whole architecture, but not completely clueless either –

IMHO the justification of: “I test just like the user, hence I have no need of knowing how the product technically works” is extremely wrong

Every software engineer should have the capability to look at code and make sense out of it.

#RedefiningSoftwareQuality #TechnologicalExcellence #Automation #Transformation

Most common calculation of Automation ROI:

Savings = Manual execution time * no. of times expected to run

Except, this doesn’t give any real value..

These tests we are calculating under time ‘saved’, mostly never get tested!

A lot of times testers just try to fit in whatever they can in the given time duration, and many of these tests just cannot be done

The real value of automation is the quick feedback you get

Instead of regression issues being reported weeks later, devs get instant feedback and takes a lot less to fix the issue.

Automation does save effort, but not in the way we usually calculate it.

Details on this and other ROI calculation aspects in the linked blog post

Don’t write code just good enough for releasing today,

But so it’s usable & maintainable a year later.

There are quite a few short cuts teams take under the pretense of Agile, this is one of them

Agile does not mean to release work which will have to be redone again, or with tech debt

Smaller release cycles never meant bad quality, and yes bad coding practice IS bad code quality

#RedefiningSoftwareQuality #Programming #CodeQuality

Job Seekers, Here’s what I call a “Unicorn employee”:

1. Hands on technical skills

• Has sufficient technical background and exposure to the job that needs to be done.
• Ability to demonstrate that knowledge

2. Is a Natural leader

• Mostly ends up leading people
• Ability to rally people behind a cause, not through authority, but by motivating them

3. Can communicate

• Ability to express themselves clearly to engineers and senior management (two very different set of skills)

I know, as engineers we dislike too much talking, or leading people.

From employers perspective: at certain level you need people with these skills, and are extremely rare to find

Unlike unicorns, these people do exist. so:

Become them, search for them, hire them and look after them , they are the drivers of your company.

#RedefiningSoftwareQuality #Hiring #JobSearch #CareerAdvice

“Testing IS a technical skill”, if there is no code involved, does not mean it’s not technical..

There are two extremes, one says testing is a mystical unique art which you are born with, either you have it or not

The other extreme says it’s not really a skill, it’s more of a chore you do, no learning required

IMHO both ends of the spectrum are wrong, it’s a technical skill which MUST be LEARNED and EXPERIENCED in (I call this #TestingAcumen).

So, if your a developer and will be involved in testing activities: testing is a skill you have to LEARN and PRACTICE, you don’t just wing it.

And for testers, more than half of them I meet are horrible at testing. If you’r a tester, just having ‘tester’ in the title does not mean you might be good at testing.

Testing is not an innate gift you were born with. It’s again a skill you have to lean & practice.

I’m all for agile transformation, that’s what I do on a daily basis, but not building your team’s testing skill and hoping your CI/CD is going to do some AutoMagic is a fallacy..

#RedefiningSoftwareQuality #QualityTransformation #Testing #AgileTransformation #DevOps #ContinuousTesting

For teams operating in DevOps ways of working, test code needed to be written sometimes can be as much as production code itself.

Still having someone to build and advise on test code architecture & automation seems like an alien concept to many teams.

I’ll be talking about our transformation journey and developing this role at the #TestLeadershipCongress 2020

Event link

What would be the most effective test automation KPI?

Few candidates in my opinion:

• % (Flaky scripts / total scripts)
• UI tests vs API tests ratio
• % stories with automated tests for the acceptance criteria (BDD / ATDD)
• % (Tests running in CI / total tests)

What others can you think of?

#TestAutomation #Testing #KPIs

There is a lot of good content out there on writing good use stories,

• Here are few things I try to look out for:
• Example mapping / Three amigo sessions – VITAL. This will crystallize your acceptance criteria and pointers for tests
• Ensure the business objective & value is clear
• Try to assign business value points when possible
• Estimate relative to other work – Scrum poker helps
• Definition of Done – Automation scripts, especially on services layer should be a part

The list can surely be longer, with these actions you should be able to write decent user stories resulting in highest value features delivered quickest.

#RedefiningSoftwareQuality #Agile #UserStories #Automation

Complex problems necessarily don’t require a complex solution..

Often a simple simple solutions work best

This is crucial to understand as a programmer, we often love to over-complicate things

This doesn’t just take more time to implement, but way more time to upkeep and maintain.

#RedefiningSoftwareQuality #Programming #AlgorithmDesign

“A problem well stated is half solved”

If we use that in the context of shift left:

Half of testing is really asking questions and re-hashing the problem statement properly BEFORE coding is complete.

#RedefiningSoftwareQuality #ShiftLeft #AgileTesting

Agile does NOT mean no documentation, most teams run into this trap.

It ‘values’ interactions over documentation – so interact with people then document the decisions from the interaction.

For instance, defining service contracts – white board the points, producers and consumers discuss what’s needed,

And after decision is made, then ‘document’ it.

#RedefiningSoftwareQuality #Agile #Testing

Coding a feature is not the bigger problem –

It’s everything ‘around’ that development is what’s hard:

Effort that goes into:
– Making sure we’re building the right thing,
– Adequate testing of what’s developed
– Automated checks to test the functionality across tech stack
– Infrastructure to support development and testing
– Automating deployment across environments
– Observability & alerts to detect any anomalies

So you see, it’s not just ‘writing production code’ anymore. To be truly agile and having DevOps practices there is a lot more that has to be done.

#RedefiningSoftwareQuality #Transformation #DevOps #ContinuousTesting

Automation training doesn’t start with learning automation tools,

It start with learning testing fundamentals!

Learn what to test, where in the tech stack to test and how to test.

Next we can talk about what to automate, where and how.

The unfortunate part of many folks lerning automation – their training starts and ends with Selenium

And I say this all the time, you cannot pick a worse place than Selenium with Java to begin with.

Nothing against Selenium or Java, brilliant library & language but that’s not the starting point.

Most people feel what they lack is automation skills, unfortunately often engineers lack “Testing skills”.

If that’s not fixed, you’ll get garbage in and garbage out.

#RedefiningSoftwareQuality #Testing #Automation #TestAutomation #ContinuousTesting

Some background to ‘flattening the structure’

In the industrial revolution and mass manufacturing era, companies operated with lots of workers doing remedial tasks.

We had hundreds of people doing atomic jobs and funneling up progress & information up the ladder.

After information consolidating across many hierarchical structures, ‘management’ took decisions and sent instructions down the corporate ladder

In the internet age, we don’t have much remedial work left in many places & the speed of operation has phenomenally increased

Workers have been replaced with ‘knowledge workers’

OR ‘Smart creatives’ who are tech savvy, business savvy and are closest to the ground reality

Therefore decisions should not be made at the top, rather by the engineers closest to the situation

Which renders no need to ‘manage’ people and take decisions for engineers, rather just ’empower’ the engineers to take decisions.

Hence the necessity of flatter org hierarchies and Servant leadership

#Transformation #AgileTransformation

#ServantLeadership

Which language for automation – Java or JavaScript?

There is NO silver bullet answer and it might not even be these two (Python or Ruby)

Here’s what I have used historically:

• Browser automation : Javascipt
• Interacting with the DOM is easier,
• Using AUT exposed methods is easy
• Scripting languages quicker to write and lesser code
• Popular tools: WebDriver, Cypress, NightWatch

Services automation: Java (Where prod code is in Java)

• Same language as production code – critical for component tests
• More options for mocks
• Can reuse prod code (e.g. POJOs)
• Extensive community support
• Popular tools: RestAssured, WebTestClient

Again, no silver bullet answer – need to consider various factors to decide for your team.

#TestAutomation #Testing #Programming

Planning you PIs (Program Increments) is crucial (One PI typically spans for 6 sprints).

While planning architectural road maps for quality initiatives across different teams, I’ve noticed a couple of blind spots:

1. Planning for feature deliveries and enablers / architecture road map are very different, planning them both the same way does not work.

2. Test and learn – I am the planning type, plan so extensively and as soon as the rubber hits the road, all plans go up in the air. Have a long term vision, but how to get there is fluid – plan that for just ONE PI

3. Prioritizing enabler features. Depending on what your structure is, getting tech debt prioritized can be the toughest job. Try to get an agreement around that.

DevOps is a mindset change.. BUT

Also requires a hell lot of enablers:

CI/CD:

• CI tool in place (Jenkins, TeamCity..) with hooks to SCM, to creating environments, build & deploy the product, run the tests, and quality gates
• You may need multiple pipelines

Environments:

• Capability to spin up environments (Docker / OpenShift / Cloud..) on demand with desired configurations & tear them down

Static analysis:

• E.g. SonarQube or any other static analysis

Test data:

• Mocks / stubs for tests running on lower levels (unit / component)
• Synthetic data generation on demand
• Data creation and clean up routines

Test Automation:

• Unit tests, component tests
• API tests, contract tests, UI tests

…to mention just a few high level enablers.

The best part – engineers and product owners need to have confidence in all this.

So if you want to transform the way you release your product, have a plan for both:

• mindset change and how to develop all the enablers you need
• INCREMENTALLY (waterfall like DevOps is of no use..)

#RedefiningSoftwareQuality #Transformation #DevOps

Documenting your APIs behavior / contract on a confluence page enough for building common understanding?

In my experience, these pages often remain as static pages. The code keeps changing and the documentation does not.

I prefer using swagger to document workings of the API and use that as a reference.

This way you have a living document and no need to keep updating a static page.

Oh, and just to add, functional & contract tests are going to ensure if your building your services properly.

#RedefiningSoftwareQuality #TestAutomation #APIs #Swagger

A key area to consider while working on automation frameworks:

Complexity vs configurability.. and their inverse relation

To support more and more features, and make a solution scalable you’d want it to be more configurable

However as you make it configurable, it is bound to become more complex.

Sure using design patterns will ‘reduce’ the complexity, but inevitably will become complex as you make it configurable

There’s a balance you want to maintain between the two.

E.g. using libraries like cypress & robot you’d be able to create tests very quickly, but you loose control on certain configurability aspects, if you can live with them these are great

So it’s going to depend on your situation, But the principle remains..

#RedefiningSoftwareQuality #TestAutomation #AutomationArchitecture

Hiring for automation engineers / looking for a position?

Here is my list most important skills you consider / learn:

1. Programming aptitude. Can think and design algorithms, language does not matter.

2. Testing Acumen. Practical experience of developing and using heuristics & identifying risks.

3. Attitude. Enjoys solving problems.

4. Automation exposure. Have an understanding of typical pitfalls in automation frameworks and how to fix them.

Importan point: Don’t necessarily look for someone / stick to any one langauge / tool. Technology is bound to change.

#RedefiningSoftwareQuality #TestAutomation #Hiring