Whenever the topic of quality assurance (QA) over a project is brought to a conversation, testing is the first thing to come to most people’s minds. QA actually goes far beyond just testing code. In any case, being test centric can become more effective from the standpoint of QA at the project level if we expand our view of testing by taking the following five considerations:
- Test the software development process. A fundamental part of continuous improvement is to mature the software development process, whether or not you are using an agile or lean methodology. If you plan a development strategy and stick to it instead of adjusting it to become more effective over time and to follow the actual project needs, then the quality of the product or service and the performance of the stakeholders will suffer. Does the infrastructure count with continuous integration? Is the software delivered to the customer frequently and continuously (good), or as a whole at the end of the product’s lifecycle (poor)?
- Test the use of the application. This has to do with the perceptual integrity of the product in terms of how easily and rapidly the user gets productive with it, and it applies to new and to seasoned users. Is the application easy to use or does it require a steep learning curve? Does the application make sense, or does it confuse the user?
- Test the results of using the application. This also has to do with the perceptual integrity of the product, but from the standpoint of how useful it actually is to the user. That is, how much productivity is increased. Is the application actually useful or is it making life more difficult for the customer? Is it adding value or being a diversion? Does its use result in frequent mistakes by the customer — mistakes which are, in reality, not user mistakes but usability failures?
- Test the software developed. This has to do with the conceptual integrity of the product. Is it being implemented using design patterns? Is the code being continuously refactored? Is test code implemented and executed before (great), during (good), or after (poor) the features are coded?
- Test the data used by the application. What if everything in the project works great except that the data doesn’t make sense at all or, even worse, the data is corrupted? Good data warehousing and handling are extremely important but, unfortunately, little is done to test the data compared with code testing.
All five considerations should be tested keeping in mind the agile-testing quadrants; that is, consider the business, technology, product, and team perspectives. This requires a good combination of test tools, test automation, manual testing, and a lot of customer interaction. It does not mean that the enterprise has to invest vast amounts of capital in QA, but it does mean that good quality doesn’t come free. However, good quality pays for itself in the long run by significantly reducing technical debt. As much as possible, customers or users should be involved in testing the product, since they are the product’s target.