Thursday 23 February 2012

Everybody should test.

We have the professional tester who is trying to make an overview of all aspects of software and create their own plan. The tester plays the ears and eyes for all. But with interchanging information and views, a lot of information is lost, simply because of communication between people is always distorted. Everybody translates their ideas to their own perspective on the world, and the tester or test team will also do that.

So everybody should test. What do I mean exactly with “Everybody”? At least I mean all IT people should test. Test their own work, test their colleagues work and not be afraid to make and recognize errors we all make. As we are human beings and humans make mistakes.

The software developer that creates software is the best person to review code and test the smallest units of software. This is because he or she knows the code, knows how programming patterns work and knows how to program some automated checks for this level.

The user tests the way he or she likes to work, she knows what the daily work is, how customers are satisfied, how the process works with information from a phone call, email and how the digital shopping cart is handled in their line of business. She knows the domain of their business and she talks the talk of it.

The designer translated the wishes and demands of the user into a new IT system, or upgrade and should be aware of the product risks that are also introduced with introducing this new software. The risks can be (partially) mitigated by writing these mitigations already in design documentation.

The functional owner of the software can be right in the middle and keep communication open, up and running between the business people and the technical people.
The support engineer can search for possible risks in the new system. Can we support it later on, has it got enough monitoring and logs, can we easily fix things or change the software by configuring it via a configuration file or settings in the software? Is it extendable and compatible with other tools we use? Because this is his focus area, the support engineer is the guy (or girl) that can check this. And also she has the power of knowledge of issues from the past in her incident system. Issues from the past could arise again with new releases.

Conclusion
This are some ideas about testing by everyone. If we in IT (and it is a big and differentiated world) all test our own concerns and views on a new product the quality control could be better than the way we do it nowadays.

So testers, let’s help our colleagues, we are not learning to test at school, but we have the experience and knowledge to upgrade testing to the next level, as part of the daily IT job.