Quality Assurance (QA) is not only a process, but a person, who must know the application top to bottom. Because QA and the Product Manager are the only people who read every task and every user story, a QA is second-to-none in understanding the application. The difference between the QA engineer and the Product Manager, is that QA not only knows the theoretical side of the requirements, but is also the person who first tests the new functionality and assesses its productivity.
Product Managers usually do not have time for this (and frankly, it is not their job), so it is very important to understand why the system works this way, why the client needs certain functionality, and whether it fulfills the quality standards by the end of development.
"It is very important to understand why the system works this way, why the client needs certain functionality, and whether it fulfills its purpose at the end of development."
In contrast, developers are usually only familiar with the portions of the application they were actively working on. That is, if you have a team of eight developers, each of them would only know an eighth of the application extremely well. QA, on the other hand, should be thoroughly familiar with the application and be the go-to expert for questions on functionality across the application.
It is very important to always remember who your users are. When QA is testing an application, it is easy to forget that your target audience may differ from you in many criteria: they may be older or younger, be good or bad with modern technology, use your application constantly or visit it for the first time. To cover as many possible scenarios as possible, you need to try to think out of the box. You never know how an end-user will attempt to use the application, which can lead to big problems within the system.
QA, as stated in paragraph #1, should know the application better than anyone else on the team. This means that QA also has a greater understanding of the objectives of the application and the target audience than anyone, perhaps even including the client.
In this case, QA should not just check the application for bugs, but also suggest ideas on how to make the application more convenient and easier for the end-user. The QA should decide when test automation is required or when manual testing is better suited for the task.
The key to understanding the application and its goals is communication. Whether it is communication with the client, discussion of the new task with the developer, or brainstorming with the Product Manager, QA should not be afraid to speak, share opinions, and ask questions.
While perhaps the most boring part of the QA work, documentation is certainly not the least important! You will be grateful for well-documented flows, bugs, test cases, and properly written test plans during regression testing or when someone needs instructions for using the application.
The key to effective documentation is to make sure that it is always up-to-date. As soon as the requirements for functionality have changed, the documentation should be updated immediately to ensure consistency.
As you can see, Quality Assurance is a crucial, albeit oft overlooked, role in every project. A quality software QA Analyst and process can make or break the rollout of any product. Following these rules will ensure your rollout is a celebration of great accomplishments rather than a rush to put out fires caused by unforeseen bugs and a poor user experience. We'll help you get your native app all the way through production. Contact Ventive today!