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).
Perfection Myth
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.
Scott, nice article. You make some great points
I think that an unstated assumption in many small shops is that Developers are expected to output flawless code from the beginning and Quality issues should be easily detected (as you say) and resolved on their own time (ie. no cost to the company or their clients / customers)
Of course, this is not realistic given the quick turnaround times these developers are expected to meet, so the Developer’s family and health pays the price and ultimately puts the company at a competitive disadvantage when they experience higher costs of turnover than their competitors and damage to their company’s brand equity as a result of quality issues
It’s really in a company’s best interest to be educated on the value of QA/Test, so kudos to you for writing this article 🙂
Thanks Omar. I agree, too often project teams are putting in insane amounts of overtime near the end of the project in large part due to the expectations of perfection, and their attempt to achieve it against all odds. The process runs so much smoother from start to finish if issues are addressed early.
Scott,
It’s harder to plan and execute than it is to simply react. A little structure can pay huge dividends in terms of the quality of the end-user experience, and having someone operate from a different perspective from an engineer or project manager is valuable.
As far as schedule compression goes, ‘Testing’ is only one tool in the SQA realm, just like schedules and requirements are. One cannot ‘test in’ a high level of quality at the tail-end of the process. It’s a false economy to cut the QA components of a project at all stages, even within Agile teams.
Danny – Thanks for the comments. I completely agree, having focus on quality in the project from the start is crucial, in particular, someone with a completely different mindset and focus. Doing so adds overall predictability and efficiency, and as Omar has mentioned, likely leads to happier teams who get to go home on time more often.
As for my use of the word ‘testing’ rather than ‘quality,’ I was attempting to show that was the extent of the quality assurance commonly included in the project. I’m betting we are on the same page there too.