Testers have no place in a Scrum team…

… Unless we breakaway from the traditional way in which software gets developed and more importantly the role the test engineer plays within the team.

The shift-left approach has moved testers closer to the development teams however very little has changed and in most situations, it has worsen the experience for everyone involved.

Two smells that makes me suspicious of something wrong going on:

1. Coders and Testers both estimate effort using story points separately for a given piece of work (let’s say an user story). Both estimates are then somehow computed resulting in a final estimate, which tends to be inflated by design.
2. There’s a step called “Awaiting Testing” and /or “Test In progress” in their workflow.

What’s the problem with these?

From these two smells it becomes apparent that for the coder, quality becomes an afterthought and a sole responsibility of the tester to find whatever defects so that they can fix them in the future (if ever found).

For the tester their objective is to work hard to find ways to break the code, log defects and send them back to the coders for fixing.

The mindset of the waterfall model is still intact, the only difference though, is that now coders feel miserable because they feel the pressure to fix defects faster (and potentially introducing more defects) and find themselves hostages of the tester because they serve as the gatekeepers to DONE.

As for the testers, they feel equally miserable because they tend to feel the pressure at the end of the sprint when all the work flows into “Awaiting Testing” in the last day of the sprint.

Finally the product owner starts to get annoyed at having to wait till the last minute of the sprint, to learn if that given sprint has any chances to be salvaged.

The issues however, do not end here.

Teams where effort for building and effort for testing is estimated independently observe serious issues underneath.

1. Quality is usually not a team game or a shared responsibility.
2. Automation is almost inexistent.
3. Lead and cycle times are extremely long.
4. Cutting corners (like skipping tests) is a accepted way to move forward for the sake of speed.
5. Low quality stuff gets released.
6. Unsatisfied users and customers.

STOP

… Estimating testing effort separately and instead get test engineers to work with the rest of the development team to collaborate and support testing activity as something that is inherent part of the process of developing software.

The true shift, less QC and more QA for the tester

To make the most of shift-left, it will require also a shift in mindset, for testers it will mean that their role will be doing less Quality Control (QC) activities, such as finding defects in code that has already been written but doing more of Quality Assurance (QA), focusing in activities that prevent defects to be introduced in the very first place.

For coders it will mean that it becomes part of their responsibility to ensure that quality is something that is inherent since the very beginning.

Three aspects to consider

Collaboration

Testers and Coders must come out of their own bubbles and start working together, from refinement, through out planning and design, development and release of the features. When work is getting refined and while coders are thinking about the happy path of a certain feature, the test engineer can be thinking about negative scenarios such as, incorrect input, incorrect steps that the user may take and other exception scenarios.

As time goes by, this mentality gets naturally spread within the team and coders will start evolving their ability to think proactively in negative scenarios.

Pair Programming is also a great way to make the test engineer to work closely with the coder as the software gets done, having the coder to write tests for scenarios that the test engineer thought about, will eliminate the need to having a “ready for testing / testing” or similar column and therefore eliminating a handover that impacts cycle time and getting to DONE sooner.

Automation

It’s nearly impossible to go faster if every time a thing is added/removed from the code, the tester needs to manually run all their test scenarios to verify what worked yesterday still works today.

Automation is imperative to make the most of this approach.

And testers and coders must both learn how to write and maintain suites of automated tests. Actually I’d strongly advise that those who are more likely to break the tests should also be the ones who fix them — the coders.

Nowadays there are tons of test automation tools, some require no coding (or very little) at all, and others require coding skills, which requires test engineers to upskill and learn new skills where as before they didn’t require as much.

Continuous Integration / Continuous Delivery

Scrum teams are effective when they create one or multiple increments of DONE, it’s not even expected teams to wait for the sprint to finish for them to be able to deploy or even to release to users.

This is only possible when having the different types (see picture below) of test directly embedded in the CI/CD pipeline, leading to a sharp decrease of manual testing.

Continuous means “very often”, for some teams this may be several times a day or just once a day (at a minimum), the moment a coder integrates, the the code should be tested to ensure problems haven’t been introduced, and if they have, then they should be quickly fixed or reverted, this to make a point that testing is also a continuous activity, not something that happens after a large batch of changes have been done. The test engineer plays an important role into helping the rest of the team expanding on the several tests that can be done at the stage on integration and delivery.

Although there may be an initial cost to up-skill, adopt tools and make mistakes (and learn from them), in the long run teams that have the test engineer working in the way I have described here are more likely to be high-performant, to feel a strong sense of trust within the team and to enjoy the benefits of software that performs well that make happy users and customers.

Back to you

What are your thoughts? Let me know in the comments below.

✍ Check my other articles

• Is Jira anti-agile? You have a bigger problem

• What every Scrum Master should know about success

👋 About me

I am a Scrum Master and Agile Coach, born in Portugal, with Indian origins and currently living in the UK.

I love to coach teams and individuals and get my learnings at the coalface.

Find me at:

🔗 https://linktr.ee/wilsongovindji