There are some big changes happening on my test team. I’ve written before about how we changed the way we performed testing when I moved my desk into the team room. At the time, I was the only tester working on the project, and the product manager was only involved at a high level. The overall process was fairly simple:
- The product manager created a basic roadmap of features to be addressed.
- The lead developer wrote and managed development of the user stories and assigned work (including defect fixes) to developers.
- I tested user stories and defect fixes, working with the lead developer whenever I had a question.
- The lead developer and I reviewed test results and determined whether stories were complete or needed additional work.
Spearheading a new way of working was exciting, but I wasn’t sure how it would scale when we had more testers working in the team room.
Get TestRail FREE for 30 days!
Changes to the Team Require Fresh Thought
We now have three testers on the test team. Our new project is fairly large, and it will require everyone on the development and test team to work together. Should we all work directly with the lead developer, as I had? On the last project where that created a bottleneck, I was the only tester. Three testers working exclusively with the lead developer would be completely unsustainable.
That’s not the only difference between this project and the last one. There’s also a lot more work to get done on this project. We are creating the first phase of a website that will eventually replace our flagship product, which requires at least six weeks for regression testing alone. We will be rebuilding the features of that product from the ground up. If we have to stop and meet with the lead developer before and after every single story while he’s trying to manage the development work, we’ll never finish.
Finally, as I’ve mentioned before, we have a new product manager. Our previous product manager participated in guiding features at a high level; she wasn’t interested in getting deep into individual stories. Our new product manager seems much more interested in developing the user stories and features in detail. He would prefer to collaborate with the lead developer to write acceptance criteria instead of participating from a distance.
Join 34,000 subscribers and receive carefully researched and popular article on software testing and QA. Top resources on becoming a better tester, learning new tools and building a team.
New Challenges Lead to a New Development Process
Based on the changing situation, we’ve decided on a development process that includes the product manager and reduces the amount of individual attention we need from the lead developer to carry out our testing.
1. Stories are written by the product manager and lead developer, and they create acceptance criteria together
At the moment, the test team is not included in the acceptance criteria discussions. As the project continues, we’ll monitor whether we might improve the initial quality of stories by asking to be included in those discussions, but the focus at this time is on allowing the lead developer and product manager to build their working relationship as they carry out this task.
2. Multiple testers work in the development team room to test stories and defects
There were physical constraints to adding three desks to the development team room, so most of the time, two testers will work in the team room. I’ve encouraged the other two testers to take those seats so they can benefit from the relationship-building that I experienced on the last project. I plan to pair with them on a regular basis, so we will sometimes have all three testers working in the development team room.
Testers also will work with developers on questions about the implementation and with the product manager on questions about the stories. This means that rather than all questions being directed to a single individual, our questions will be spread across the development team and the product manager.
We hope this will reduce the chances of experiencing a bottleneck. It also gives the product manager more say in the development cycle as we ask questions that drive out new stories and defect reports.
3. Review overall test results with the product manager
Instead of reviewing test results on a story-by-story basis, we will inform the product manager of the status of stories using a test report that gives the overall status of testing, and call out specific items of interest to the product manager. We hope that by including the product manager in our conversations as we test the stories, his understanding of the product and how it has been tested will be sufficient.
This is our initial plan for managing the testing in our current situation. We’ve included much of what we learned when I worked in the development room during our last project, but we will continue to adjust as the project proceeds and we search for process improvements and identify mistakes.
I’m eager to start working in a new way and discover even better ways of working together as a unified test and development team with our new partner, the product manager.
This is a guest posting by Carol Brands. Carol is a Software Tester at DNV GL Software. Originally from New Orleans, she is now based in Oregon and has lived there for about 13 years. Carol is also a volunteer at the Association for Software Testing.
Test Automation – Anywhere, Anytime
