Testing is seen as an important activity. There is lot of focus on improving testing and the coverage of testing. More and more people are working testing products and creating test cases. These activities, do improve the product quality a bit, but it isn't really a way forward.
Testing is a wide subject, and I'm talking especially on the cases were testing and product creation are seen as separate activities. There might even be separate test teams and separate product teams. Product teams do test to some extend, but the main responsibilities are given to test team. This is the big problem of testing. Separate testing should only be about knowing the risk level of releasing, not about increasing the product quality.
The aim should be to decrease the amount of testing and increasing the the product quality during the product creation. In the long run, the thing that matters is the product creation quality, not testing quality. Of course some of the product creation quality comes from testing, but this is not separate testing, but assuring the quality while creating something.
I don't believe any organization can get rid of testing. Some amount of testing is always necessary to know the risk level of releasing. Amount of testing needed should be analyzed thinking the costs and effects of fault in product release. In some businesses fault could mean bankrupt, in others, few annoyed customers. This analysis should tell the amount and scope of needed separate testing.
Testing and product creation should work together to ensure quality of the product. Organizations need to learn to build good quality products from the start. Every error should be analyzed and corrective actions should be made. Unfortunately this is utopia in most of the companies. Errors found in testing are seen as normal way to ensure quality. In the long run this will start hurting organizations and cause more and more errors.
The only way forward, is for management to start taking errors seriously. Especially having an eye on why the errors have been introduced in the first place, not why the errors were not caught in testing. Blame is often put to testing, even though it's an activity that shouldn't be done separately at all.
Written by +Henri Hämäläinen
Thinking very clean as well: developing is waste, since there are ALWAYS bugs in a code, right? :)
ReplyDeleteIF you have own development teams, then it makes sense to integrate/hire (professional) testers into the teams.. especially if developers attitude is with separate test teams is "we do not care on quality, since there is different team who takes care on it".
But, in some cases, I have seen separate testing team is not an bad option at all. E.g. when we have bought some project (development) from vendor X and we used vendor Y to test it. So, why I'm glad to pay extra, get extra management for separate test team? Simply because some (big) vendors in Finland are cheating and hiding information (which is really weird). Just think failed IT projects in public sector.. almost every week there are horror stories with vendor names. Maybe it is todays business logic; win contract with lowest price, forgot professional testing and charge more for founds bugs (as "new features")?
There are already studies on root-causes of the bugs: one of them (by James Martin) says that 56% of the bugs is caused by bad/missing requirements. So, we should accept incomplete requirement documents and do more exploratory testing to cover more information on the product. And that is again one example, where testing BRINGS value.
Thanks for many good points. To the first point, development definitely can be waste. For many companies it might be better to remove stuff instead of adding stuff to bring more value to the customers.
ReplyDeleteMy point was more about that separate testing is mainly knowing and reducing risks. That said, I would never try to run a larger SW project without some level of separate testing.
The buying SW from Vendors is really complicated and definitely good testing team lowers the risk. It still doesn't mean that it wouldn't be waste, because the SW could have been done better at the first time.
Testing is an interesting topic. I just wanted to raise the thoughts that not always increase in testing resources do good for organization. Sometimes reduction could make the difference.