QA testing can be confusing to anyone who doesn’t work in tech – and even many who do. For those who are unaware of what QA testing entails, the vague concept might be “looking for problems in a website or app.” But there are many different phases of QA testing. Some of them happen before a product is even ready to test!

Read on to find out more about the different phases of manual QA testing.

The Design PhaseQA Testing Design Phase

One of the first steps that QA can help with is the design phase. This might seem surprising, as QA testers aren’t exactly known for being graphic designers. But testers can provide valuable insight into user experience issues with design.

If QA can anticipate design and user interface issues before development begins, the team will save money, time, and effort.

Test Cases

Once the team knows what the new features and design will be, QA can start writing test cases. Each test case describes a behavior that should happen when a user interacts with a section of the app or website. Sometimes testers have to write test cases without requirements or input from the rest of the team. But when QA has time to write these scenarios ahead of time, it can help ensure that every path is tested. Learn more in our article, What Are QA Test Cases?

Planning & Prioritizing

So QA has helped hone the design, and written out test cases to prepare for testing. Now it’s time to plan and prioritize. When developers go over their estimates, the testing timeline is often shortened. With this in mind, it’s helpful to map out the most important flows to test. Software testers can do this by ranking test cases in order of priority, or even making a simple list of the most crucial sections to check.

Software Testing PhasesSmoke Testing

Smoke testing comes from the phrase, “when there’s smoke, there’s fire.” When QA doesn’t have time to do a deep dive, testers can engage in basic tests of major features, otherwise known as smoke testing.

This often happens right before or after a release. But it’s also an important first step once a new version is ready for testing. That way, QA can tell developers right away if there are major bugs in any obvious path. Learn more in our article, What is Smoke Testing?

Testing

Once QA determines that a build is at least usable, the real testing can begin. This is the phase that QA is best known for. Testers will go through as many sections of the software as possible, looking for any and all potential bugs. Even if a mobile app or website seems pretty simple, there are many different devices/browsers/scenarios that users could encounter problems in. Learn more about Cross Browser Testing and Best Practices for QA Testing.

Writing Bug Reports

The “bug reports” phase weaves in and out of many other parts of the QA process. QA can report a bug from the second testers get access to a build, all the way until the launch. A “bug” can be anything from a minor different in text color (compared to the expected design) to a major crash. Bug reports need to be detailed and in-depth, so product managers can properly prioritize them – and even more importantly, so developers can understand exactly how to fix them. Learn more about Best Practices for Reporting Bugs.Bug Reports Phase

Testing Bug Fixes

After bugs are reported, they usually need to be fixed. (We say “usually” because sometimes product managers choose not to prioritize certain minor bugs. Learn more in our article, How to Prioritize Bug Fixes.)

Once bugs are fixed, developers will create a new version and update the bug report tickets (for example in Jira). When QA sees that bug reports are marked as fixed, it’s time to re-test the issues. Sometimes developers think a problem is fixed, but it may still be happening. This doesn’t even mean that a developer is at fault. It’s QA’s role to make sure that the developers’ fix works across different devices and scenarios.

Regression Testing

Once developers have fixed every known bug, they create a version known as a “release candidate.” This means that it’s a candidate for releasing to customers – as long as QA doesn’t find any new bugs in it. This is where regression testing comes in. Sometimes when developers change one area of code (for example, to fix a certain bug), it can cause a different function to no longer work. Regression testing means re-testing any and all areas of the app or site, looking for anything that may no longer work as expected. Learn more in our Guide to Regression Testing.

Post-Launch Testing

When a release candidate is approved by QA, it’s time to let it out in the wild! Once it’s live, QA will then do a round of testing immediately after launch. This will help ensure that all of the new changes are working in the production environment. If there are any issues, QA can report them right away, so the changes can be reverted before they affect too many real users.

Rinse and Repeat

The software development life cycle is exactly that — a cycle. The second a new version is launched, the engineering team is already preparing for the next one! In an Agile QA process, the phases of QA testing never truly end.

Need Help with the Different Phases of QA Testing?

Mindful QA provides software testing services and consulting, and we’re regularly featured in “Best QA Companies” lists.