Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
Full Integration
After working in this way on different Scrum teams, I felt I could add feedback more quickly during development, so I began informally working directly with a developer during a Sprint for a couple of hours a week. Sometimes I tested something on which the developer was working; at other times, I provided a second opinion on a design. This setup provided even earlier feedback to the developer and helped me be more effective in earlier Sprints, where there wasn't yet much of a product to test.
Eventually, I moved on to a project with very experienced agile developers who were using Scrum. At this point, I was ready for full integration; as a tester, I would work side by side with the developers throughout the entire project. We agreed to work as closely together as possible, since I wanted to learn more about test-driven development, and they wanted to learn more about conventional software testing.
When we started out with a Product Backlog, the lead developer began repeating a mantra I would hear throughout the project: "Is this testable?" He wanted to be sure that whatever was developed was something I could test. This strategy forced me to be more involved in the planning discussions instead of waiting until I could look at the software. I was also asked to provide documentation on testing from Sprint to Sprint, rather than providing test plan documentation just prior to the testing and debugging Sprint near the end of the project. We weren't working on a "big design up front" project, and our Sprints were shortened to two weeks instead of four weeks long, so I was a bit reluctant to create what I thought might be wasteful documentation. However, the project stakeholders needed the information. I worked out a short two-page testing strategy document based on the information from the Sprint Backlog for each Sprint. The template included the Sprint goal, the features that would be developed, and an initial risk assessment and corresponding test techniques we would use to mitigate those risks. I drew much from James Bach's articles for my test planning:
As I began to fill in the details of the document, it surprised me to find that the first Sprint goal we had brainstormed wasn't testable. It was too vague; in spite of us thinking hard about testability in our Sprint planning meeting, we had come up with something that was not testable. I talked to the Scrum Master and the lead developer, and we rewrote it. I had a couple of use cases already, so I plugged those in and found they were also vague. Despite all our planning discussions, it was only when the goals were committed to paper from a testing perspective that we found the problems. In the end, documenting our testing efforts provided more coherent design documentation and Sprint Backlogs. And later, when we added more testers, we were able to divide tasks and focus testing efforts much more easily.
Our focus was on speedy communication, as well as logging and fixing defects quickly in each Sprint. We deferred some defects for later Sprints, but we tried to keep that find/fix/verify feedback loop as tight as possible. A typical day involved pulling and installing a build for the testing team, running and developing automated tests, and executing manual tests. We would execute tests, verify bugs, and spend time talking to developers about emerging designs, test ideas, and areas to test. We designed automated tests to detect changes, so we could quickly find out if there were changes in the software to worry about. Manual testing was unscripted, focused on risk, with new features tested first and changed areas (revealed by the automated tests) tested second.
Testing in this new way was enjoyable. I was testing on working software sooner and closely collaborating with developers to provide instant feedback on development work or to help with test idea generation. With developers, I was as likely to be working on test problems as design considerations, usability concerns, or tracking down bugs. To facilitate testing quickly, I developed scripts that automated parts of the application that I had already tested thoroughly. I could run these to get to an area in the application very quickly, and then take over and do exploratory testing manually.
We still retained the final testing Sprint to do complete end-to-end testing on the final product. Because of the thorough testing of the features from Sprint to Sprint, there were few surprises in this effort other than system integration problems.