As a software quality engineer, you may have encountered situations where you're assigned a project that isn’t tested or is midway through development.
This article outlines practical strategies for implementing quality assurance in such projects, drawing from my hands-on experience as a QA engineer who has successfully tackled untested projects.
Let's begin with the first strategy.
Start by identifying the business-critical areas of your application where testing is most needed. You can consult domain experts like business analysts or product owners on your project team for guidance.
You can also implement risk-based testing to assess potential issues across various application components, focusing on key business features. Start with a thorough risk assessment that weighs both the likelihood and impact of various risks tied to application functions.
Create a risk matrix to visually prioritize these risks by mapping them to specific application features. Then you can start designing test scenarios and test cases focusing on those critical features. This strategy helps you to efficiently utilize your testing efforts, increase software quality and minimize the likelihood of having major production bugs.
When I joined an e-commerce project with a huge backlog of support tickets, I analyzed them and identified the key areas where users encountered the most problems. By implementing a risk-based testing approach I prioritized high-impact areas and designed test cases targeting those features.
This proactive approach reduced the incoming support tickets by over 60% within a few months.
Set up a dedicated environment for testing, separate from the development environment where developers add new features. You can use containerization tools like Docker to ensure consistency between development, testing, and live environments.
This setup allows for quick configuration and scaling while replicating the live environment including current and planned features. It’s also imperative that you choose based on your project needs. For instance, if you need to automate web application tests, you may choose Selenium, Playwright, or Cypress by considering cross-browser support and team familiarity.
For microservices-based projects, consider using REST Assured, Playwright, or Postman to build individual test suites for each microservice. Also, you can build test suites to test the integration between multiple microservices.
In my e-commerce project, I chose Selenium to automate E2E tests considering cross-browser support, long-term maintainability, and team skill sets. Additionally, I used REST Assured to automate API tests since it works well with Selenium to create test prerequisites.
Create a feature list and work with your business analyst or product owner to classify them as Critical, High, Medium, or Low priority. Based on that list, you can derive tests and prioritize using the same business priority. You can automate critical tests first as they form your smoke test suite for each build.
This prevents critical bugs from reaching production. Gradually, you can automate high and medium-priority tests when time permits. Add these to your regression suite, which runs after the smoke tests on final builds.
This approach helps to provide fast feedback on the builds as the automated tests can be integrated into the CI pipeline and triggered for every build. By following this strategy, I was able to stabilize critical features such as Checkout and product search in the e-commerce project making our customers happy.
Quality assurance thrives on teamwork. Encourage open communication between QA engineers and developers. This helps everyone understand the project goals and objectives and how they can help make it successful. Make it easier for developers and QA engineers to discuss ideas and concerns by introducing collaboration tools like Slack and JIRA for real-time updates and issue tracking.
Include the QA engineer at the early stage of the development to share the QA feedback on new feature designs. This early involvement, involving the QA in daily stand-ups and solution discussions, helps spot potential issues before they grow. Creating a culture where developers appreciate QA insights minimizes the resistance.
In my project, this strategy facilitated a strong relationship between developers and QA engineers which kept everyone on the same page regarding project requirements and ensured a smooth development process.
Set metrics such as bug counts, test coverage, and support ticket counts to measure your QA efforts. This helps to understand what’s working well and what needs improvements. Track bug counts by business priority to identify critical features you might have missed during testing. Evaluate test coverage to ensure critical features are thoroughly tested.
You can create a requirement traceability matrix to map your test cases with the business features that effectively visualize the test coverage. Regularly review and update that matrix to ensure sufficient test coverage and monitor counts to identify user pain points.
It is also important that you conduct regular retrospectives to collect qualitative feedback from your team members. Additionally, conduct regular retrospectives to collect qualitative feedback from your team members to understand the challenges and successes. This strategy helped my project by addressing challenges, strengthening our QA strategy, and creating a continuous improvement culture that led to an increase in the overall quality of our e-commerce application.+
With these strategies, you can turn any untested projects into stable projects.