Over the last two years, I have been working on a model of “Testing Collaboration”, where the responsibility of testing is shared and quality focus is at the heart of feature development.
Before discussing the 5 stages it is worth noting that Customer feedback should be encouraged and can be received at any point in the process. The same principle applies to feedback from Internal staff.
- Workshop
Running a workshop at the initial stage of feature development can be highly beneficial. If possible find volunteers outside the engineering department that are representative of the end user or even better still, actual end users.
Thoroughly discuss the problem that needs to solved, and only then discuss possible solutions.
Once a solution has been agreed upon, then develop scenarios to guide the team.
BDD,User Story Mapping or similar approaches can be used at this stage if you wish.
If you use analytics, this is the phase to consider what success looks like.
2. Pairing/mobbing
During the implementation phase focus on pairing/mobbing.
Close collaboration at this stage ensures better decisions are made and that the team is aligned with the scenarios agreed in the workshop stage.
Testing and development are performed in tandem, issues uncovered are immediately resolved.
Often a feature may take several weeks or months to complete, thus its good to push code to production frequently.
For example, you can Dark launch using Toggles in place for the UI and have backward compatibility on the APIs and databases changes. This opens up the opportunity to test in Production.
3. “Team Walkthrough”
Once the team is satisfied that the feature has been implemented and tested, this is a great time for a “Team Walkthrough” prior to the Bug Bash.
Attendees typically include the team members e.g developers, testers, UX and product managers.
The focus of the Walkthrough is to ensure that the team is satisfied with the implementation of the scenarios and walk through any other scenarios that any team member can propose.
A benefit of the walkthrough is that the team can decide if its ready to be consumed by a wider audience, firstly the bug bash and then real users.
Additionally, everyone is on the same page in relation to what the feature does and any possible limitations.
4. Bug Bash
Typically a week before release to Beta Customers, run a Bug Bash.
The Bug Bash gives those outside the team(e.g sales, customer support etc.) an opportunity to test the software. Often people from different disciplines will uncover issues that the team may not have considered.
Dogfooding is a complementary strategy at this phase.
If you wish to learn more about Bug Bashing, check out my Bug Bash blogs Bug Bash – Give it a bash and Guidelines for running a Bug Bash.
5. Beta Customers
Often you may not wish to roll out the new feature/feature update to all customers.
Perhaps you wish to roll out to a small percentage of customers to gather feedback and ensure that you haven’t introduced an issue that would affect all your customers.
It is also an opportunity to gain feedback from real users, conduct A/B testing and evaluate the analytics.
Benefits of the 5 stage model
- Testers can influence at each stage and have an equal contribution to other disciplines such as UX, Product Management and Developers.
- Sharing decision making about when the team feels comfortable about releasing the feature.
- Shared responsibility for quality, not only is shared amongst the team, but it is also shared amongst the wider company.
- The principles of Communication and Collaboration are supported throughout the 5 stages, for example, it easy for everyone in the company to know the status of any feature.
- Provide a supportive Environment for Exploratory Testing.
- Early feedback helps ensure that feature are likely to be succesful.
Leave a Reply