I remember reading a post by a Microsoft employee saying that even with Microsoft’s huge resources many wished-for functionalities in core software aren’t developed because budgets need to end somewhere. Likewise in quality testing, there’s a limit to how much you can actually test for - both in terms of resources but also in terms of time.
Keith Vanden Eynden has written quite a technical article about best practice - How can you possibly test modern software fully? (Reg Developer):
The common assumption about software testing is that “more is better”, and testing all the possible states and variable combinations guarantees you will find all the bugs.In the real world, however, there is not enough time or enough testers to test every combination of every variable. Not all bugs will be found, making quality assurance a risk management discipline. How can you validate that your product is ready to ship within reasonable time and cost parameters? In other words, how can you manage the risk of not testing everything? One solution is to use structured testing methodologies, supported by proper tools, which help you quantifiably manage this risk.
Practically speaking, the role of quality assurance is to reduce the risk of these bugs ending up in the final product. Software complexity puts a huge burden on QA teams, which are typically much smaller than the development teams writing the software (it’s even worse if there isn’t a QA team and developers take on the role part time). It is also very easy for one developer to write a small amount of code that requires a significant amount of testing to ensure it functions properly in all situations.
0 comments ↓
There are no comments yet...Kick things off by filling out the form below.
Leave a Comment