The problem at large
The quality of early stage code is felt to be a concern by many engineering managers that I talk to. In my numerous consulting assignments, I have noticed that many issues found by QA folks seem to be ones that do not require the expertise of a specialist tester, compromising the effectiveness of ‘system test’ resulting in avoidable customer issues.
Great quality code is not the result of intense system testing, it is result of well structured filtration of issues from the early stages. A compromised ‘unit test’ puts unnecessary strain on the QA folks who seem to be compelled to go after these issues at the expense of system test.
Developers on the other hand do not deliberately write bad code, it is just that accidents happen. Accidents seem to happen due to brute force push of unit testing without it being simple and practical, and developers already short of time are unable to adhere to a heavyweight process. The other fallacy seems to the over dependence on automated unit tests as the saviour without paying attention to test cases. Also the incorrect notion of unit testing as being only white-box oriented with a skew towards code coverage results in ineffective tests that are introverted. Lastly the sheer emphasis of dynamic testing as the only method to uncover defects is possibly overwhelming, when easier static methods of uncovering issues could have been employed.
Business/economic impact
The impact of leakage of issues from early stage is not irritating, but serious enough. Issues reported by customers that are early stage simple issue like poor validation of inputs, results in significant drop of confidence in the customer. The QA folks focus on these issues result in their job of system validation being poor, resulting in field issues related to end-to-end flows and sometimes attributes being compromised.
Also the incorrect focus of a specialist QA results in insufficient time for doing things that can make system test more effective and efficient like automation of end-to-end flows, focus on non-functional requirements, revising the test strategy/approach and sharpening with knowledge gained every cycle.
Yes, this age old problem is boring. Don’t force your developers to more unit testing to solve the problem. Ask them to do it smartly by doing less. If you are keen to know how, check out the e-book listed below.
SaveSave