Quality Assurance, the SINAPTIA way

In a previous post, we discussed how we approach new challenges, such as testing an application on a serverless architecture. But we haven’t yet discussed our Quality Assurance process in detail. In this post, we’ll explain the different steps involved in our Quality Assurance process.

First steps

When onboarding a project, our job as QA engineers is to fully understand the nature of the project we will be testing. Understanding the purpose of the system, its users, its processes, and the domain concepts and rules is key to success in assuring the quality of a software product. It’s impossible to design and deliver effective tests without this knowledge.

Once knowledge has been acquired, the next step is to define the testing scope. For example, here are some typical questions we ask:

• What are the target devices (eg. desktop, mobile)? If we’ll be targeting desktop, which browsers? If we’ll be targeting mobile devices, which operating system?
• Is accessibility important for this project? If it is, which accessibility standards will be used?

Then we define the scope of work: in this phase, we analyze and decide which testing strategies and tools we’ll use. Particularly, we need to define which testing strategy is a better fit for the project (automated, manual, or both), define the testing technical stack (which testing framework, continuous integration server), and define the workflow with the development team (this is fundamental to get it right from the very beginning).

Once the scope of work has been defined, it’s time to think about the Test Plan. The Test Plan is the set of test suites that will be executed to validate the functionality. To create an effective Test Plan, one must be very familiar with the application, and the best way to familiarize with the application is to perform manual tests. Only after familiarizing with the application, one can automate the tests. It’s extremely important, for us, to manually use the application and understand every little detail. Manual testing can’t be avoided. On the contrary, it’s necessary.

It’s important to note that the Test Plan may change from sprint to sprint as features are being developed.

Working side by side with developers

The process we follow integrates seamlessly with the development workflow. We always use the same ticket management system and like to have direct and fluid communication with the rest of the team, whether the development team is ours or it’s our clients’.

For the testing to be effective, we verify each feature in an isolated environment (using a dedicated QA environment, or testing apps deployed for each new code branch). We not only check that the code conforms to the specification but also that nothing else breaks. Automated test suites come in super handy for this. We also check the features in different browsers and mobile devices to ensure every little detail is working according to our previously defined testing scope.

When a bug is detected during testing, it’s important to follow a systematic process to report it. It’s important to give a detailed description of the bug, specifying the steps to reproduce it and screenshots or videos to help the developer reproduce it.

Working side by side with developers is the way to a successful QA process.

QA Automation

QA automation is really important once manual QA has been performed extensively. Manually testing the same flows over and over could be tiresome and time-consuming. Automated tests save time and allow QA engineers to focus on other tasks. They’re also faster and more accurate, as people are prone to make mistakes, especially when tired or stressed.

However, the only way of defining accurate, effective automated tests is by manually testing the application. You can’t do automation without manual testing.

Working side by side with users

All software has bugs. Sometimes they appear after extensive QA (manual or automated). They are often found by users. And more often than not they don’t know how to reproduce them. That’s when a QA engineer’s expertise shines. Frequently, QA engineers have more and fresher knowledge than users and even the developers themselves, so using that knowledge they can discover broken paths that would take a long time to unveil to other people, and determine whether what the user reported is a bug or not.

QA engineers are a key part of the development and maintenance processes.

Conclusion

We talk a lot about manual QA because without it you can’t do QA automation. With manual QA, not only do we gain experience with the application to design and deliver effective tests, but also we gain knowledge to help the application’s users and development team.

We believe that our QA process is effective in many ways: developers trust they’re delivering code that works properly and users have someone who holds their back.