Even a cursory look online you will net lots of opinion and research telling you why software development is so much more predictable and efficient with proper software quality assurance (SQA), yet almost every small software shop decides SQA is one of the roles they can do without.
Why might this be? Studies and experience have long shown us the value of including quality controls throughout the process after-all; yet we continue to pretend we are the exception to the rule. I think this is because of two things:
- Focus on features – Projects are heavily focused on the features and functions of the software, usually from a software development frame of mind, not on the quality of those features
- We assume (close to) perfection – we are special, and any problems we have, we and our team will be able to resolve trivialy, therefore can save on testing
Let’s dig in to these assumptions.
Focus on Feature Development
Application development projects always start with what you are building, and this focuses on the features – the development portion of the effort. It is rare to have quality control on the mind of the project sponsor or project manager, and this focus accidentally overlooks the need to include quality assurance. You will commonly see a section in the project plan for testing and validation somewhere near the end of each project or for each release, but somehow this often doesn’t make it into the resource plan until pain is felt. This isn’t a purposeful oversight, but simply an unintended consequence of the single-minded focus on delivery of features. The usual focus begins once the software quality is found to be lacking, at which point the cost of resolving is much higher.
Good quality assurance has a completely different mindset than feature development. The best QAs think like an auditor, tracking what we agreed we are trying to accomplish, and making sure we did; delivering both the specifically mentioned features as well as the non-functional requirements which make the difference between the software we love and recommend to our friends, and the software we tolerate (until something better comes along).
In my career, I’ve now worked closely with hundreds of IT professionals. Of those who were working on the cool new projects, almost all thought their team was better than all others. This hubris might lead to the self-fulfilling confidence needed to get the project through, but also leads to glaring oversights and assumptions. Also, highly confident teams tend to unintentionally create situations which require team and individual heroism.
This isn’t done on purpose, and in fact, one could argue they were avoiding over-engineering in areas where they felt they could personally mitigate risk. Nonetheless, only 1/3rd of all projects succeed when measured as being on time, on budget, and accomplishing what they set out to do. It’s hard not to draw the conclusion that we overestimate our individual and collective ability to pull it all together when needed. It is for this reason so many have moved to project management methodologies which account for chaos. According to one survey, Agile projects have more than double the success rate, which is an impressive result, and likely explains its continued adoption. This doesn’t address the root of the problem, but rather is an attempt to work around our human tendencies. Alternately, proper Quality Assurance can help remove this lack without having to rework your entire project management methodology.
Why do you think QA is so often overlooked? Leave a comment below.