What "Software Testing By The Book" Is?

7th of November.

In some days I decide to go and have lunch on my own. Usually, I pick a small table to enjoy my lunch, putting my cell phone away and focusing on my thoughts and the people entering and leaving the restaurant.

There are cases when people around me are engaged in conversations, and naturally, when hearing some triggering words (software, developer, tester, work, etc.), I put my thoughts on pause and start listening to theirs. Why do I do that? Because I'm trying to find myself in their stories.

So, today's characters were two ladies, working as software testers, talking about their job and complaining about the lack of processes, or the poor ones they need to follow and about all the fuzzy decisions that were taken and are affecting their work. The conclusion was they were feeling they are in the wrong working place, and it's time to start looking for another job where

"software testing to be done by the book".

Well, this phrase kept repeating in my mind as an echo.

Inevitably made me think "what software testing made by the book means?". And the following came into my mind.

🍎Clear specifications and clear acceptance criteria

We do not deal with lack of specifications and we have well-defined acceptance criteria on which we can create our manual and automated test scripts. Change requests? Not much. Everything is clear from the very beginning.

🍋Enough time for testing - testing effort never rushed by deadlines and by development delays

While working in an Agile world, our work is split in equal increments of time and at the end of these increments (Sprints), we deliver a good piece of implemented and tested code. We, as testers, don't suffer from time pressure imposed by deadlines and we always get the code for testing in time before the delivery.

🍈Tester's voice always heard in the team

We are part of all the discussions - grooming, planning, 3 amigos and our voice is heard and listen. Our suggestions are always taken into account and also our estimations.

🍇Good balance between manual and automation

Manual test cases are written to cover the acceptance criteria, to reveal other scenarios that derive from acceptance criteria, to cover edge cases and negative testing. We have automated scripts to ensure a good coverage for all the manual test cases that we have created. We also have clear reporting, so at any time any of the team members or stakeholders know the state of the system under test.

🍊Good and stable automation framework

And enough time allocated to automation testing, of course. Flaky tests? Well, in the software testing made by the book, flaky tests are something you just heard of, but never seen, right?

All the testers have a deep understanding of why we automate, how we do it, have a good understanding of all the tools used to create the automated tests.

🍉There are always user stories to test and no dead time

Dead time, what's that? We always have something to work on and our pipeline contains tasks that can be picked by any of the testers. We have a well-developed plan within our team so that is a continuous flow between developers and testers in delivering a user story.

🍌A clear strategy for the testing process

All our adopted processes are well documented and the testers are all aware of them. Communication is good within our team.

🍐Automated tests are running in a CI

We never create automated suits and run them manually on our local machine or on different servers, but we integrate them in a Continuous Integration pipeline.

🍒Automation testing is part of the Definition of Done

For every user story that we deliver we ensure its quality by doing both manual and automated tests to cover all the scenarios derived from the acceptance criteria. We end up having good coverage for our tests.

Conclusion

All the above is a utopia.     

We usually work in imperfect environments, dealing with lack of specifications, not enough time for testing, bad decisions took with regards to automation, flaky tests, bad communication and so on.

But there is hope.

GIVEN you accept that your process is not perfect

WHEN your testing is not made by the book

THEN work on defining what "by the book" means to your context

AND create discipline

AND have the courage to challenge things

Or, if you are lucky enough to be part of such a perfect world, where all the above are not on the "things to be improved" list, congrats! 👏

Photo credit: Ben White on Unsplash