The world we live in today is largely dictated by the software we use in our everyday lives, from Tweeting profanities at Donald Trump, to paying those bills online; software is everywhere and all of it will have been put through some form of Software Quality Assurance.
At secondary school in my very first Design & Technology lesson, I remember being told that everything that we use from the chairs we sit on to the pens we write with, each of them started off as a design. As a child I guess you don’t really think much about manufacturing processes, but this realisation that every object in the classroom had undergone this entire process starting with just a design blew my mind. So why am I telling you this? Well because it was something I had overlooked at the time, quite possibly the same way you might be overlooking the Quality Assurance that goes into the software you use daily.
For those of you reading who are unfamiliar with what Software Quality Assurance is (often referred to as SQA or QA) in essence, it is multiple processes carried out during the software development cycle to help ensure that: (A) the software functions as intended, (B) is free from vulnerabilities, and (C) conforms to requirements, standards and procedures.
Is Software Quality Assurance important?
Well, let’s start by going through some of the key reasons as to why we at 1minus1 believe Software Quality Assurance is an absolute must when developing software.
1. Reduces Risk
If you had to board one of the following two airplanes which would you choose? The first airplane has had all of it’s internal flight software fully tested whilst the second airplane however, has had no testing carried out on it’s internal flight software. You would choose the first airplane, right? That’s because the first airplane poses the least risk of failure. Albeit that’s a rather extreme analogy it can still be applied to the software we use daily. We’ve all encountered websites that don’t load correctly and applications freezing midway through usage, it’s infuriating and when those defects persist it’s likely more and more users will cease to use them. This can be detrimental for the software owners as it could lead to loss of revenue. Reducing the risk of the software not fulfilling what it’s built to do not only installs confidence in the development team but it also increases the software’s reliability, resulting in greater consumer satisfaction which naturally leads to repeat usage.
2. Increases Quality
The clue is in the name really…while finding defects is a large part of Software Quality Assurance it is not the sole purpose. It is just as important to test through the software with the end user in mind – can they easily access the menu? Is the text legible? Can the user navigate around fluently? This feedback during the development cycle is invaluable in raising the quality of the software. SQA also has a positive impact on the skill level and quality of the development team. One example of this could be that the QA department report several defects which occur on an older version of Internet Explorer, if some members of the development team don’t have experience with Internet Explorer they are then put in a position where they need to expand their knowledge in order to resolve the defects reported; subsequently improving their skill level in that area. Often when a commonly occurring defect is fixed the development team will then utilise that knowledge to prevent it from occurring again in future projects, this doesn’t just improve the build quality of that project but it also reduces the time spent reporting that defect again; which takes us nicely onto our final reason.
3. Reduces Cost
I know what you’re thinking, how does spending money on hiring a QA Tester or paying for a QA Service reduce costs? Well to put it simply, time is money and carrying out Software Quality Assurance throughout the development cycle reduces the maintenance time spent on the software after release. Maintenance refers to any corrections and modifications made to the software that may be discovered only after release. Implementing stringent SQA procedures during the development cycle helps identify more errors before the software is released resulting in an overall reduction of the life cycle cost. Likewise, if you don’t do any testing, how much will it cost to manage and fix all of the bugs found by end users? Those bugs found may ultimately result in loss of sales for a client, have a negative impact on the reputation of the team who built the software or could even damage the end users consuming the software.
What impacts would not having a QA department have on 1minus1?
We have briefly touched on some of the implications that could arise if SQA is not carried out, but I want to take you through how we at 1minus1 would be directly affected by not having SQA in place.
I presume that even with no QA department the great overseers here at 1minus1 wouldn’t let anything go out the door without it being somewhat tested. This would mean that the work and procedures usually carried out by the QA department would fall onto other members of the team resulting in an increased workload for those tasked with it. Increasing anyone’s workload will have a negative impact on their primary role within the company simply because they will have less time dedicated solely to that role, so quality in those areas would likely decrease.
One of the benefits of having a QA department is the experience and knowledge that they bring to the company, which ultimately pays dividends in the amount of defects discovered and reported. Losing that experience would reduce the amount of defects discovered and reported resulting in more defects being shipped. As stated during the ‘Reduces Cost’ section, shipping software without proper testing could have a negative impact on the client, consumer and the reputation of the company responsible for the software. The latter I believe would be the most damaging to 1minus1 as it could result in loss of current and potential business.
Whilst the team in charge of looking after SQA might be doing their best at reporting and logging any defects found, the format and detail in which a QA department would deliver would likely not be met. This again will be down to the fact the team would not have the luxury of time on their side to further investigate the defects. As a result of this any defects reported may not contain sufficient information for the developer to fix first time so the ticket would likely be assigned back to the reporter starting the investigation/reporting process all over again. I think you can see the running theme here, more time = more money. Over time costs would rise for 1minus1 as we spend longer fire fighting defects reported by clients and consumers and if a drop in quality has any impact on current and potential business, well we all know how that will end for us. I hope this article has given you a brief insight into why we believe SQA and quality in general is important when developing software.