What do you do when you have less than too little testing effort for a huge agile developmentteam? Can you turn out high quality product with so limited testing efforts?
Part of the answer lies in using your team's strengths to your advantage and use the dev skills to do testing. What if you could do it without boring the developers to do "much of" manual testing but could set the expectations clearer that they are accountable for the quality? Test driven development is the key in such cases.
Here:
1. Test cases are written before the code is written
2. Simultaneous regression test suite is getting developed as you write the code and this will bring down the cost of quality.
3. Integration with continuous integration system will ensure that regression suite is being run as frequently as possible to bring out regressions in related areas.
How you could approach this:
1. Select a unit test tool which goes well with your programming environment.
2. Complete the required setups to properly integrate it with your dev and build environment.
3. Start developing the intended program features by:
- First write a unit test for the feature to be developed. Run and verify the suite for failed TCs and this unit test will fail.
- Develop the feature inline with the assumptions made in test case. Run and verify the suite to see if the test case passes.
- Repeat the iterations as you fine tune the code and develop new modules.
In its simplicity, this is what the process is all about. However, there are dangers too: Unit test suite remain as one of the least reviewed dev artifact till date. The quality of the unit test suite often goes under monitored for the simple reason that quality manager, accountable for quality, often is not accountable for the exhaustiveness of unit test cases. Example of what this could lead into is that :
- many of regression scenarios become irrelevant over a period of time. Eg: instead of consuming real time data, the unit tests do have hardcoded data (this is criminal violation of quality principles in most cases). This will return false positives and will not bring out the regressions.
- Unit tests might not be exhaustive. Al branches or all decisions / loops couldn't have been covered. Many integration dependencies might not be covered.
As an end result it happens that unit tests are run just for the sake for meeting KPIs and lose actual purpose. When things are done for the heck for meeting KPIs, i call it the KPI syndrome and is the most dangerous risk to the quality and to the continuous improvement pillars of lean.
