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:
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.
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.
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.
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:
If you still aren’t convinced that Quality Assurance Testing is for you, here are 10 more reasons that might change your mind:
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 alexandra.varro@around25.com