What is a test strategy? What is the role of a test strategy in the overall QA process? How is a test strategy different for larger software projects (e.g. Salesforce) vs. smaller projects? These are some of the questions that organizations face while implementing testing strategies. Let’s look at how we can leverage best practices to build a robust testing strategy that supports both large and small scale projects.
Test Strategy and the Role
Test strategy is a plan to assess the quality of any product that is developed. It is a fairly static, high-level document derived from the business requirements specification document.
The purpose of a test strategy is to define standards for the overall QA processes, activities on a particular project and standards for other documents such as the test plan, test case creation, bug reporting, quality metrics, etc. It also specifies any challenges that can be faced while testing an application.
Components of Test Strategy
A good test strategy is very specific and practical. The test strategy document can have many components varying from one project to another, depending on the business needs. Clearly define components for structural QA processes and activities. These components should be well discussed and reviewed with the business before finalizing the test strategy of a project. Below are the commonly used components in test strategy:
- Testing Techniques (Both Automated and Manual)
- Entrance Criteria
- Exit Criteria
- Test Plan
- Test Case Creation
- Test Execution
- Test Deliverables
- Testing tools
- Types of Testing (Includes performance, security testing)
- Assumptions and Risks
- Defect Reporting
- Roles and Responsibilities
- Test Environments
- QA Metrics
- Go/No Go Meetings
For Larger, Long-Term Projects
Large-scale projects usually have a long duration, a larger group of team members, enhanced budget and higher task complexity. Most large-scale projects have a formal phase called analysis or discovery, when requirements are reviewed and finalized. This phase is when the QA team prepares test strategy documentation for the entire process. There will be many formal review meetings with the business to go through the strategy document. The document will be subjected to many changes based on the review meetings.
Once finalized, the test strategy will not change very often unless an important task needs to be considered by the QA team and the business. The QA team will be an integral part of analysis, design, daily check-ins, and any other decision making/change meetings that may affect the QA activities.
In my experience, you can enhance the test strategy document by adding other components including information regarding:
- Release-based testing vs. Sprint-based testing,
- security testing by analyzing the security needs of the project,
- Defect Lifecycle in different Test environments,
- Calculated QA metrics,
- Test Summary per Sprint and Release, etc.
The test plan will be part of the test strategy for large projects. It is a critical component that focuses on:
- Scope description for the features
- Testing approach
- Testing schedule
- Resources participating/required in tests for a testing phase or a cycle.
The testing cycle varies from project to project. While some projects have testing cycles along with the development cycle, some have testing cycles after. So, the test plans are prepared to satisfy the above needs and will be a part of the test strategy for large projects.
The Testing Process for Long-Term Projects
The application is tested in various test environments. A more formal approach is created to approve builds in different test environments. A QA Coordinator is responsible for accepting the code into test environments from dev environments, conducting smoke tests every time a new build deploys to the test environments. Team members receive formal acceptance of the build via emails. The QA team identifies bugs and assigns to Product Owner (rather than instead developers). The Product Owner will then analyze if the bugs are truly bugs or enhancements. Users are invited to test the application based on the Release, and the UAT Coordinator trains the users on the important features for the release.
Test Automation Engineers who are part of the QA team, help automate manual test execution. Engineers work with developers or manual QA people to automate smoke testing processes, major regression scenarios, and any necessary end-end test cases. There are a wide variety of testing frameworks available in the market today. Again, it depends on the project needs to choose an automated testing process tool and framework.
The final step before moving implemented code into production is a Go/No Go Meeting. Do not ignore the decision to go live in production (or not). The QA team provides a test summary which contains a list of all outstanding unresolved defects, test status, and any associated risks by releasing the product/code to production. Discuss all outstanding issues before deciding to push to production.
For Short-Term Projects
Considering the budget, time and resources, most of the formalities are avoidable in small projects. There will be an analysis phase for any size project, but the QA team does not need to prepare a formal test strategy document. Do define a master test plan to use as source of reference for QA activities. Embed major components of the test strategy in the master test plan. Sometimes the budget may not support even the master test plan creation. For such projects, have a structured QA process agreed upon with the team members. Have a QA resource assigned to the project who can handle all the test case execution. Involve more team members in understanding the business requirements. Identify various kinds of tests needed for the project, such as performance testing and security testing. Usability testing is also critical to success. In this instance, limit the test artifacts only to create and manage test cases around the different kinds of tests identified.
The Testing Process for Short-Term Projects
Focus more time on exploratory testing rather than planning. Focus on testing as early as possible. Plan for at least one regression testing per testing cycle. Report bugs and make sure they are assigned to a developer. Participate in daily check-ins to know the status of features and bugs. Make sure to retest bugs. The cost for automating the testing process will be high, so limit automation to end–end test cases or avoid the creation of test automation framework. Provide feedback to the team on the quality of the application on a regular basis.
Quality is the number one goal. Whether it is a small or a large-scale project, never ignore quality. Having a structured QA process is the key. The best practice is to set-up a QA process that has minimal maintenance and is risk-free. Be detail-oriented. Collaborate well with the team and enjoy the work that’s being carried out.
The Build phase poses unexpected challenges and difficult questions. In other words, we love it! This is where we thrive. During the Build phase(s), we’ll work side by side with you to answer (and ask!) questions, architect solutions, configure Salesforce, develop code, troubleshoot and share the occasional beer. Our definition of done includes automated QA, or QE, using tools like Selenium. Let’s talk!