Implementing Quality Assurance in production
Key takeaways:
1. Map out what needs to be tested
2. Define the priorities
3. Create an appropriate QA strategy
Implementing Quality Assurance (QA) is critical to ensure that products are reliable, user-friendly, and meet customer expectations.
The “testing early, test often” ideal, while quite relevant, cannot always be applied.
For small startups, adding a QA team may not be feasible in the early stages, but it’s still important to implement QA processes whenever possible to ensure that the product is fit for use and that it meets the requirements. Many projects may start without a dedicated QA team, or may encounter unexpected delays that push QA implementation to later stages in the Software Development Lifecycle (SDLC).
Furthermore, taking over legacy code that does not have tests may also require that QA is implemented on a code that is already in production. Legacy code often presents challenges when changes are made, particularly when migrating to a new platform or environment. Adding QA for this type of code can help to identify any potential issues and to mitigate the risk of disruptions to the system’s functionality.
While implementing QA so late in the SDLC (on a system that has already gone to production) raises the costs of fixing a defect and may seem daunting, it’s still possible to achieve a successful outcome.
On this article, we detail how we tackled this challenge at On2 to ensure our success.
1. Map out the system — define what needs to be tested and how thoroughly
Before you begin the QA process, it’s important to conduct a comprehensive assessment of the product and its requirements. This step will help ensure that the QA process is efficient and effective.
When requirements are properly documented, the QA team can use the documentation to create a comprehensive test plan and to ensure that all necessary tests will be performed. In some cases, however, organizations may not have the requirements in a document such as a Software Requirements Specification (SRS) — or it may also be the case that the documentation has become outdated during the development process.
Reviewing existing development documentation, reviewing the code that has been implemented, observing user behavior, gathering feedback from stakeholders, and analyzing system logs are all actions that can provide valuable insight into the requirements and the expected functionalities. They help to understand the system and to identify all areas that will need testing.
2. Listen to the stakeholders (and your team) — define the priorities
When implementing QA in a system that is already in production, it’s important to prioritize the parts of the system that are more critical. These parts may be customer-facing, or they may be internal systems that are critical to the functioning of the product.
Some of the factors that may be considered:
- Customer impact: Customer-facing parts of the system are often more critical and have more urgency in testing, as they directly impact the customer experience. Stakeholders can provide valuable insight into the customer needs and expectations, helping the QA team to prioritize the parts of the system that are most critical to the customer experience. They can also provide feedback on the product, helping the QA team to identify any potential issues and improve the overall quality of the product.
- Business impact: Parts of the system that are critical to the functioning of the business should also be prioritized, as they may have a significant impact on the overall success of the product.
- Urgency: Parts of the system that are experiencing issues or need to be updated to meet changing business requirements should also be prioritized. Developers can provide valuable input to identify anything that is constantly failing or places where more than one bug has been found. In a case of Defect clustering, it’s highly probable that more defects will be found nearby and this part is prime for being prioritized on testing.
It is also valuable to listen to your team members and gather their feedback on the product. They are the ones who are most familiar with the product, and they know how the product is expected to behave. They may also be able to identify potential issues and technical debits that may cause issues, things that may not be obvious to someone who is not familiar with the system.
3. Create an appropriate QA strategy
Creating a QA strategy that is appropriate to the time and resources that you have is critical to the success of your QA process. The strategy should take into account the size and complexity of the product, as well as the available resources.
If you have limited resources, it may be necessary to prioritize the most critical tests and focus on these first. Limitations may also help you to define the tools you will use for testing.
Some questions to be asked during the development of a QA strategy:
- How much time will be needed to set up the testing environment?
- How long it will take for your team to create the test cases, to run the tests, to automatize them when appropriate?
- How much training will your team need to learn the testing tools and processes in order to be effective?
The strategy does not have to be a fixed plan, it’s important to have regular reviews and updates to the strategy as the product — and the team — evolves and changes. Continuously monitoring and updating the QA process will help to ensure it will remain meeting its goals.
In Conclusion
Implementing Quality Assurance (QA) is crucial to deliver quality products. Although implementing QA throughout the entire Software Development Life Cycle (SDLC) is ideal, it is still possible to successfully incorporate QA processes in a project that already is in production. By conducting a comprehensive assessment of the product, prioritizing the most critical parts of the system, and developing a tailored QA strategy that considers available resources, it’s possible to achieve positive results.
