Get your QA Process Off the Ground

In our previous post, The Case for QA in Agile, we stressed the importance of QA for startups. It’s now time to talk about how to actually implement the QA process. QA is not just about superficially testing an application or making sure that the features are validated and verified. Rather, it’s about defining a robust process and building a test-driven culture within one’s team/organization.

The Best Laid Plans

To begin with, you should consider bringing in a QA leader — even before you begin the development of your product. A lot of companies/teams procrastinate, waiting till they’re midway through their development cycle and start finding issues on their products. Sometimes, quality concerns begin to get addressed only once clients start complaining. Neither of these are desirable situations, as the person testing the application needs to catch up with all the work that’s been done before while also keeping track of ongoing and new features. It’s simply not tenable.

Having a dedicated QA leader, on the other hand, brings a different perspective to the table and helps the team identify a roadmap. They also help in flagging potential issues and steer the team towards the right tools to ensure the specific project or product will succeed. By starting with a clear strategy for how you plan to test, everyone knows what to expect (and when).

It’s important for the QA individual to get in early and understand the application design and architecture. This allows them to have context early on. Once this is done, you then want to create a high-level test plan for your product and think about all the test scenarios and potential edge cases. You also need to start thinking about the tools you’ll need and start getting them setup. Oftentimes, some additional time and effort needs to be spent to get the testing team familiarized with these tools.

It’s especially important to think about the non-functional requirements which may not have been brought up by the stakeholders or clients in the initial discussions. Is it an enterprise web application used by 100,000 people? If so, you might need to think through your load-testing plan. You need to think about accessibility and be familiar with WCAG standards to ensure that the application is fully adopted and is easier to use by people who have disabilities or specific impairments. Is this a product that you’ll be supporting for the next few years? You now need to plan for automation of regression tests. Is it a marketing or ecommerce site with a lot of slick animations and specific colour notes for branding? Plan out your VQC and cross-browser testing agenda carefully. Is this a product that’ll be launched in multiple regions? Time to think about localization testing. Last but not the least, vulnerability assessment and penetration testing needs to be a part of test plan.

Agile teams aren’t known for comprehensive documentation, but a test plan can help serve as a form of minimal documentation. This is enormously helpful when teams change and the product evolves. Modern test management tools also allow you to integrate with automated test frameworks, helping you track product health over time. At Myplanet, we use Testrail for documenting test scenarios and test suites. It helps the team indirectly when they need to go back and review implemented business logic. Its great reporting features allow us to track project metrics over time and identify defect clusters and unstable functionality.

Execution Strategy

After doing most of the planning work including product discovery, tool identification, and writing a high level test plan, it’s important to do the execution right. Be sure to capture meaningful, detailed acceptance criteria.

What you’re aiming for is defect prevention over defect identification, and the best way to get there is to have acceptance criteria that sets a high bar. This ensures that anything that passes has been properly vetted before it goes through a formal review. Stomp out bugs before they ever hatch. Acceptance criteria is usually defined by the product owner while collaborating with the lead developer and QA.

Once the acceptance criteria is defined and a user story has been coded, it should be peer reviewed. Peer review is a great way to get the feature tested by a fellow team member before deploying it to the integration environment. In this case, a developer on the team would be testing the feature in isolation and ensure the functionality works. This is to catch any bugs early on to reduce the cost of production.

After the peer review process, it’s important to have the feature code reviewed by a senior developer on the team to ensure there are no security flaws and the code is optimized. After a number of these checks have passed, the code can be integrated and deployed to a test environment where the user story can be more formally tested against the acceptance criteria/business requirements. This is usually done by the business experts (i.e. product owner or QA on the team). As well, localization, performance benchmarks, and accessibility are some areas that need more technical expertise and do well with a dedicated QA expert.

It’s also important to get the UX/Creative Lead involved at this point and have the feature tested from a visual standpoint. Since your visual designers are experts in this area, they may help you in catching things that would be missed otherwise. We define this as part of vQC and is a part of regular sprint workflow.

After all the checks and resolving bugs has happened, the user story can be deployed to staging/production environment depending on the kind of product (i.e. brand new or existing). This is also a good point to get automated tests written for the features as the feature is stable and all the scenarios and edge cases have been tested manually for the first time.

All Together Now

In sprint, QA is something that needs to be practiced by all the team members and not just limited to the test/QA analyst. As mentioned earlier, it’s more about creating a test-first culture in the organization or product team. When we have team members thinking about potential issues and edge cases before hand, there is a higher chance of success and delivering a robust product.

At Myplanet, we also encourage a high level of collaboration between developers, product strategists, designers, and testers to ensure the application is reviewed from all standpoints. Designers have access to the test suites so they can provide feedback on user flows being tested. Testers work very closely with developers to identify root causes of issues and then explore other areas that might be affected. And product strategists work with testers to understand the impact of an issue on the end user and look into possible ways of refining the original user requirement.

The QA process can seem daunting or overwhelming — especially when you only bring it into a project part-way through. But when you set a project up for QA success from the start, ensuring the whole team knows the plan the whole way through, you create a much easier, more manageable workflow and ensure a more successful product build with fewer issues to resolve at every stage. Whether you have a dedicated QA lead for each project or not, getting in the habit of establishing a test-driven culture requires just three things: a good plan, a commitment to executing that plan, and a team that helps each other out.


Thanks for reading. Be sure to 👏 and share!