There has been a significant shift to agile development recently that has made every IT specialist revise his work priorities and working style. It is applicable to testers as well because they also have come across the necessity to adapt to the changing conditions of an agile environment.
If you have ever thought of some kind of agile manifesto for testers, here you can find the issues it would probably include.
1. Bug advocacy is more preferable than bug counts
It is meaningless to count individual bugs or those in the whole project unless the most important of them are getting fixed. Useful measurements related to bug count can help on condition that they are utilized in the appropriate context. Bug counts themselves have no direct influence on customers. However testers are often much more motivated by the number of bugs they are logging rather than the number of those important bugs they’ve detected, reported, advocated and managed to use in order to fix the product before it went outdoors.
2. Testable software is more preferable than exhaustive requirements documentation
Sense we sell software products rather than requirements documentation to the customers, and provided that this documentation usually conveys a false sense about testability, it’s much more important for agile testers to focus on testable software. It is more efficient to test the software by requirements found from collaborating with your team and interacting with customers than to do the same applying the previously documented requirements. In this way you have greater chances to provide better feedback on your software, while requirements documents are, at their best, the result of trying to print out some tacit knowledge. At worst, these are outdated and have no touch with customer preferences. On the other hand, planning without absolute commitment to requirements documentation also leaves room for discovering some omissions.
3. Measuring product success is more preferable than measuring process success
We can often see some obsession with the process itself in software development companies. However it is in fact absurd since looking at the process too much we can lose the right measurements. There is evidence that at times wonderful processes result in terrible products, and vice versa. From the customer’s point of view, that is the most referred to in testing, the process itself is unimportant and he’ll prefer product quality over process quality at any time. Thus, it’s also no use fearing a bad fame while having problems with some product. It’s essential to learn from them and strive to just do better. And if you fail to deliver a high-quality product, he won’t care about your well-organized testing process.
4. Team collaboration is more preferable than departmental independence
As practice shows claims about the testing team working better when it’s independent, don’t fare well in an agile environment. Often testing done is insufficient as QA specialists being at odds with the rest of the team end up serving as just the process police. Since software programs are sometimes too complex, software testing represents a challenging intellectual practice in which more collaboration and more testing is required. In case of the product’s failure the responsibility for it should be also shared among the whole development team.
Following the above guidelines can ensure the success of your agile testing team and your products.
Check out our related articles: