If you read my previous post, you know I help test a product on iteration 80. This product has few automated regression tests (we are working to change that). Currently, my test team faces regression testing armed with nothing more than their brains, their hands, and a big ticking clock.
Each 4 week iteration provides us with a little less than a week to spend regression testing. If you can relate to my situation, you may be interested in two painless practices we have adopted to better handle our ever increasing challenge of regression testing.
- Group Regression Test Planning – We get the devs, BAs, and testers into a room and spend an hour brainstorming, to determine the top priority regression test areas of focus. We scan through the iteration's changes and draw on each other’s knowledge to create a draft of what will become the priority “1” tests or areas of focus. This occurs on a shared MS Excel regression test list spreadsheet. The prior iteration’s regression tests drop in priority...and so on.
- Group Regression Test Sessions – We fill a large bowl with chocolate and invite the BAs and devs to join the testers in our classroom for two 3-hour sessions of group regression testing. All participants track their progress on the shared regression test list and we tackle it as a team. The team approach also occasionally shakes out multi-user-scenario-bugs, since our product is heavily dependent on user locking.
Our approach is not to complete a set amount of regression tests before we ship. Instead, we complete as many tests as we can, within the time provided. The prioritized test list makes this possible and shields us from things outside of our control.
Is anyone else doing regression testing with mostly manual testing? How do you pull it off?
2 comments:
Subscribe to:
Post Comments (Atom)
RSS
My team does regression testing in almost exactly the same manner. Which usually involves our 4-5 core team members, bribed with free food, manually testing core functionality and features in a three day testing sprint (over the past three iterations it's been a Thursday, Friday and Saturday).
The reason we manually test in this manner is due to the nature of our software: most results require interaction, or at least need to be observed. Because of this, reviewing the results from automated testing would take just about the same amount of time. For this reason I've started calling it "Hisenburg software."
We start with a priority list and a complete list of tests to perform, and dive right in. Having everyone in the same room, collaborating, troubleshooting and performing multi-user tests makes any regression testing go much faster.
It also helps that we have joined the work study program at a local college (with a good engineering school) and so we have two very capable part-time work-study members on the team. Teaching while performing regression testing allows us to see what a user might see, and brings usability to the surface when it otherwise would not.
In general, our regression testing is not done manually, nor in a group format.
But, I have used that approach for specific situations in the past.
Here are a few cases:
http://strazzere.blogspot.com/2010/04/organizing-test-fest.html
http://strazzere.blogspot.com/2010/04/automation-assisted-test-fest.html