Peace is a lie, there are only bugs
Bugs are everywhere. They hide in deployment templates, they obscure themselves with complex code conditions, and they even live in places that at first glance seem cosmetic. Finding those bugs is what brings testers joy. Their brain is wired differently than implementation developers. They find pleasure in bringing the house of cards down. And yet, they strive towards the same thing.
It might seem trivial, but it is very important that this is well understood. If testers feel that their bug reporting is not taken seriously, it can quickly become demotivating. The same is true for when testers become gatekeepers or bottlenecks. Being a ‘tester’ does not mean that you should write ‘all the tests’: it means that you are responsible for coming up with ‘good tests’. Good tests expose bugs.
Through test failures, I gain victory
Tests are meant to fail. Acknowledging this is the beginning of writing good tests in the first place. Bad tests that fail will show you at best that there is something wrong with the product, better tests that fail will show you the ‘something’ that went wrong, good tests that fail will show you what we expect and what we got instead from the product.
Unfortunately, it is often the reaction to blame the test for the problem instead of the product. This could mean that the team has no trust in or sees the benefit of testing. Tests, and especially integration-like tests, are often not written in a stable manner, which might be the cause of this mentality.
This is also a problem of language, since in this case the tests are not seen as part of the software, meaning they never receive the same love. Tests are meant to fail: that is their purpose. Only failing tests will bring you victory.
Through suitability my chains are broken
Good testers go beyond the software functionality and make assertions on the suitability of the product. Test tools are always a couple of years behind software development tools. It seems that test-first is not only lacking in teams, but also with vendors. With the help of test tools, things get quickly automated, randomized, a.k.a. ignored — which is a good thing. It means that brain space is left to think about higher concepts like usability and suitability.
This is related to how acceptance tests work, only that the tester goes beyond those defined stories and makes deduced assumptions. Testers will ask questions, a lot of them. Questions that might have never come up at the design table. Continuously asking those questions is what makes Quality Assurance. It is not about gatekeepers or code police, it is about guiding the software throughout as part of the development process.
Test-driven development should guide development through the unit-testing processes, so that testers can focus on testing products against their suitability and usability.
Conclusion
There is beauty in seeing the world through a tester’s lens, but just like Light Side users, they only see the Dark.
Thanks for reading!
Stijn
Subscribe to our RSS feed