A while back, I was working with a team on a new mobile app for some really big names. A demo of a functional prototype was slated to hold with the prospective clients in just a few days. The project manager felt that being ‘just’ a demo, there wasn’t any need for a quality assurance (QA) test as it would only delay the whole process. So within the short time, the app was ready and tested by the developers only. When the sales manager who was going to pitch the app to the clients got to the venue, she noticed the app kept crashing randomly while trying to launch the app on her own device. She also noticed that upon attempting to log in as the test user, the app logged in as another user! She was confused, worried and surprised! This was an app she had tested at the office while preparing for the presentation. She later had no choice but to use her slides containing screenshots and did the demo with the menus she managed to access amidst the unstable behavior of the app.
When she got back, the QA team was able to investigate the issue and discovered that the reason for the random crash was the epileptic internet on her device. They observed that the app crashed whenever the user was trying to launch the app with poor or no internet connection. It happened that failed attempts to launch the app was not handled by the developer. While the reason for seeing information for another user was because there was another app on the device that was sharing the same resource as the demo app. The QA team went on to explain that a negative testing and ‘attempting to break the software’ was one of the major tasks performed by the QA while testing. The issues would have been detected before the demo only if they had done software testing. Based on this report from the QA team, the project manager insisted on always getting a go ahead from the QA team henceforth before showcasing a software to the clients.
With my short experience in Software Quality Assurance (SQA) field, I have come to understand that SQA means different things to different people in the IT world. To developers, SQA analysts are perceived as bullies; people who are out to downplay their hard work and sleepless nights while raising bugs. QAs are seen as destructive and are usually excited when they find faults! While PMs sometimes think that the SQA is not compulsory and that the SQA process is just another bottleneck that tends to slows down the development process causing the team not to meet the proposed deadline. And the Business Analysts often sees the SQA process as an addendum event to the project for raising bugs and ensuring they are fixed and so it should wait till the end of the project.
Many others even believe that it’s possible to eliminate all software bugs and defects within a set period, therefore concluding that quality assurance is a pretty easy task and can be done by anyone. One can go on and on about the many misconceptions many individuals have about SQA but that’s not the focus of this article. Sometimes, people wonder if there is even need for QA. What do they really do? Why can’t the developer even test his work? What’s the importance of the QA process in the Software Development Life Cycle?
For clarity sake, software quality assurance (SQA) is aimed at achieving and maintaining the highest level of software quality possible and also to create product confidence through the questioning and evaluation of the software in prevention of undesirable outcomes. This can be done using many activities, only one of which is software testing.
When it comes to SQA, there are two main areas of focus, which are Functional QA and Structural QA. Functional QA involves ensuring functional requirements and relevant documents are correct and that the basic functionalities, business logic/rules works as designed or expected. For Structural QA, other non-functional aspects such as accessibility, usability, security of the software are considered so as to confirm that there is adherence to the initial architectural specification and industry standards.
The QA Process is a very important one that helps to discover defects through software testing so as to prevent the user from encountering problems and having unsatisfactory experiences. Through quality assurance analysis, the software development team can learn about the reliability of the software and ensure that product works as expected. More so, QA helps in reducing the cost of defect fixing especially when the QA process is initiated at the beginning during the functional requirements gathering. Thus, it saves money and time that would have been spent fixing issues that arise from non-compliance to industry-based, functional and quality requirements/checklists.
