What is Quality Assurance and 10 reasons why You should Practice it

Do you know what happens when the user isn’t satisfied with your product?

According to a survey done by TechBeacon on mobile app users:

• 80% of the respondents said they would only attempt to use a problematic app three times or less;
• 53% uninstalled or removed a mobile app with severe issues like crashes, freezes or errors;
• 55% hold the app responsible for performance issues.

These numbers show that without quality assurance and testing, your end users will likely give up on you and your product, no matter what idea stands behind it.

Good news is, there's never too late to adopt Quality Assurance as a constant practice and you're in the right place to learn more about it.

The conveyor belt or Software Development Lifecycle

In the world of developing a product, whether it is a machine, a soap or software, there are several roles or stages of the development lifecycle. Usually, you start with some sort of research to find out if your solution exists or not on the market and if so, what you can do to bring something more to the table.

Then you start to develop a prototype, a first-stage product that has the core features you wish for, but it isn’t the best you can make.

All the while, the testers or - as they are more affectionately known - Quality Assurance Engineers are asking questions, investigating, gathering feedback, all so you can transform that into business intelligence and improve your product.

What I wrote above is an oversimplification of the process, but it’s a foundation for my point in this article. You have different roles that oversee these different stages. In the software development world, you have Project Managers, Architects, Business Analysts, Developers and also Quality Assurance Engineers.

We all know, more or less, what the first four roles are doing. But there is still some fog surrounding the fifth, the Mighty Software Tester.

Read why and how we're constantly updating our product development skills, here: How Startup Weekend Schools Us in Product Development.

So what is Quality Assurance?

Merriam Webster Dictionary defines Quality Assurance as “a program for the systematic monitoring and evaluation of the various aspects of a project, service, or facility to ensure that standards of quality are being met”.

In a factory, these are the people who look at each product being built on the assembly line and compare it with an ideal product or some sort of specifications. They also test those products in different mediums, against different factors and see if there are any ways in which the customer will break that product.

In the software development lifecycle, a Quality Assurance Tester does pretty much the same thing but with some major differences.  

They take your ideal product, usually contained in some documents, acceptance criteria or even just an idea, and assure that the outcome is the desired one. They also help you shape your product by asking a lot of questions, taking notes, investigating and providing some metrics of quality. They are (or at least, they should be) involved in every step of the development life cycle, from the idea to the MVP.

Why can’t the developer just develop the ideal product?

Because the developer has a very specific focus: the code he is working on at the moment.

In an ideal world, a developer would build code taking into account every aspect of the software, thinking about every business logic, every use case. But in the real world, where your software is more than a few methods big, that is impossible.

Sure, an application that searches from a database, that has maybe 3-4 tables, for a specific entry does not need a dedicated Tester. Although some would argue that it does. But for the sake of the argument, let’s say that the developer has investigated every scenario possible and they have covered all those scenarios in his code. Nothing can go wrong. No need for Quality Assurance, because the developer has built the code in such a way that there is no scenario in which that search method will fail.

But now, let’s just say that the product is Uber, a car-sharing application that has a myriad of features.

You have a huge database, with lots of tables, with stored procedures, with several methods for each action of the application, with different layers, with a frontend that has to look and feel a certain way. How do you expect a team of 1500 developers (in 2016, they scaled their business to 6000 employees, 2000 of which are engineers.) to develop in such a way that they take into consideration how each and every component of the app will communicate?

You don’t. Of course, they have product owners, project managers and business analysts that list all the ways a specific feature must work. But it’s the tester's job to see the bigger picture and scrutinise each and every detail so that nothing is left to chance. I noted below how a tester takes this into account when they do this job:

10 Reasons Why

If you still aren’t convinced that Quality Assurance Testing is for you, here are 10 more reasons that might change your mind:

1. All big software companies (Facebook, Google, Uber) have QA departments. Meaning that there is a big turnover for having a dedicated team for quality assurance.
2. Investing in testing means investing in the quality of your product.
3. Testing takes up about 40% of development time. Having a dedicated team/person to do that instead of a developer or a PM means that the developer and PM can focus on their responsibilities only.
4. Earlier testing means lower development cost. A QA specialist will keep the product in good conditions and prevent issues that can delay delivery.
5. There’s a difference between a developer and a tester mindset. A developer’s job is to build. Their main target is to resolve a task by the means of the code. A tester focuses on checking and challenging this code.
6. A developer is responsible for the code, while a tester takes care of the business logic and puts themselves into users' shoes. Developers usually make more assumptions and think about the solution, whereas testers think about value for the customer.
7. Every bug can cost money in production. Put $ value on a bug. Some bugs, like cosmetics, probably won’t be so valuable. But failing to protect a user’s identity throughout security holes might cost you some millions.
8. The Pareto Principle (in testing) states that 80% of bugs come from 20% of the application. A tester will know which part of your application is that 20%. This is one of the fundamental Testing Principles.
9. Testing is necessary due to the fact that it provides a measure of the current quality of the product.
10. Overall, testing makes sure that the clients’ needs, project specifications and requirements are kept in check.

With these reasons in mind I invite you to take a look at your project, product or team and see where you can involve a tester as early as possible in the process. Take notes on the way the processes change and what improvements you see. Because I assure you, pun intended, that there will be improvements.

If you need more reasons why you should be testing your product, more info on what is quality assurance, or you just want to talk about anything testing-related you can reach me at [email protected]