Quality assurance (QA) is one of the most important aspects of software development, but the complexity of the process is often misunderstood. Jesus Borrego at Red Eye debunks some of the myths
Myth 1: There is no need for testing
No testing will only lead to no bugs being detected, but that doesn’t mean they don’t exist; only that there was no one to see them in the first place and raise the issue with the developers, allowing them to remedy them.
Paying attention to the quality of the final product is key. Websites that don’t work are a turn off and occasionally users may mock these flaws via social media which can damage the reputation of your product or brand. This should be considered when considering a QA department or process because most issues will be left undetected without rigorous testing.
Myth 2: QA is the same as testing
It is important that we differentiate between QA and testing, as they are fundamentally different things and testing is only one part of the QA process.
High quality standards require the entire development teams’ involvement. A good quality assurance process will include the engagement of everyone from the start – from specifications, processes and briefs through to coding. Quality should be something that everybody takes responsibility for. The entire development team should be boasting a more collaborative approach and it should be built on a foundation of excellent communication.
If QA is left until the end of the process, major issues can potentially be left in the system until the later stages of a project. It is always cheaper and less time-consuming to fix bugs early on, rather than doing it towards the end of the development cycle, when they are possibly part of a more deep-seated code and not as fresh in the developer’s minds.
Myth 3: You can catch all bugs
No matter how experienced your developers are, their code will always contain bugs; there is no software without bugs. Software development is not like Pokemon. Unfortunately there is no QA ball that can catch all the bugs! In light of this, expectations need to be managed. There will always be a list of ‘known issues’ that are accepted because the overall level of the software quality is high, but it is important that everybody understands this and agrees what an acceptable level of defects is. In the end, the most important part is to guarantee high quality on your final product, and you will not be able to do that without QA.
Myth 4: Testing is easy
One big misconception I came across when I was testing video games in my early career was that testing a game was basically playing for eight hours a day! Even though some of the work bears resemblance with actual play, QA tasks require a broad perspective of the project, and need a deep understanding of both the development process and the business goals and standards required.
QA testers are usually underrated but bring a lot of value to projects. With different backgrounds, they have a general idea of what may create issues in the early stages of projects as well as having a solid understanding of how things are built so they can provide the feedback crucial to solve the defects. They keep a constant communication with the rest of the team and disciplines to enforce their deep knowledge of test techniques and their enthusiasm for quality. They are, commonly, a jack-of-all-trades.
Myth 5: QA adds unnecessary cost and time to a project
An undiscovered bug left on the project disallowing users to buy a product or a badly implemented search function meaning users can’t find the product on your site will lead to your project losing money or worse, users. It can tarnish the reputation of a brand, damage profitability and push clients away. If a user can find the same object/service without the hassle of a website with bugs, why would they come back to yours? The attention span of a customer and the time dedicated to a task is shorter every year. Quality Assurance is really not a luxury but a key to a project’s success.
Myth 6: Automation vs manual
Automation consists of a server running a set of automated actions on different devices/browsers. Automation can reduce the need for repetitive manual testing, but it means we would always be applying the same inputs. Users are not machines and generally tend to use random and unpredictable responses. Whatever you think the users won’t be doing, they will be!
There is a joke that QA experts use to define these scenarios: “A QA engineer walks into a bar. Orders a beer. Orders 0 beers. Orders 999999999 beers. Orders a lizard. Orders -1 beers. Orders a sfdeljknesv.” All those behaviours are behaviours users undertake and need to be taken into consideration.
If your project requires repetitive inputs, automation might be the solution for you but for small projects or projects where users can have different behaviours or inputs, exploratory testing will still be the best solution. Ultimately, the most effective solution will be the combination of both, automated and manual testing.