We had a problem. As a test team, we had two conflicting goals. We needed to develop new automated regression tests, and we needed to work with developers and product owners at the beginning of the sprint. Before introducing automation hour, we didn’t do either well.
We develop software in four-week sprints. In QA, our goal is for everyone to develop automated tests – we don’t want automation to be a specialized skill.
Before we introduced automation hour, we found ourselves working on our backlog of automation projects after one sprint was completed – during weeks one and two of the following sprint. When we focused on automation at the beginning of a sprint, we missed out on the planning and requirements discussions with programmers and product owners. When we did become involved with the sprint work, we were behind and didn’t know the project well. Weeks three and four were full-on testing efforts and our work on automation stopped. We were never in sync with the developers.
About a year ago, we started automation hour. Automation hour is one shared hour a day that everyone on the QA team sets aside to work on automation. We now work on automation during all four weeks of the sprint, even the hectic third and forth weeks of the sprint. During weeks one and two, we limit our time on automation work to the hour, and this gives and encourages us to find ways to involve ourselves more fully in the opening days and weeks of the sprint, long before anything is ready to test. We are able to follow automation hour during weeks three and four because we spread out our automation work evenly throughout the sprint.
Automation hour has freed us to focus on the broader aspects of agile testing while continuing to grow our automated test coverage.
Automation hour has freed us to focus on the broader aspects of agile testing while continuing to grow our automated test coverage.
No comments:
Post a Comment