During the Agile Testing All-Star webinar, our panelists answered key questions about the best ways to overcome key Agile testing challenges. Agile testers need to conduct their testing with the same speed and flexibility found in Agile development. It’s critical that teams be able to respond to changing requirements quickly, efficiently and effectively.
Lisa Crispin answers 3 questions posed by our Agile Testing Challenges: Overcoming Quality, Process and Team Issues webinar attendees in her own words.
Q: Any ideas on how to increase visibility of the test results for the whole team (mainly developers)
Lisa: Continuous Integration tools provide good visuals of test results and the history of each run of each suite. These can be wired to devices such as an ambient orb or stoplight in the team area, or projected on a big monitor on the wall of the team area. Simple visuals such as a calendar color-coded each day, red if the build failed all day, yellow if it failed some, green if it passed all day, can be effective. Experiment with different ideas to find what works for your team.
Q: As our company has moved to Agile, our QA team has encountered situations where the Scrum master wants to dictate the process to determine what and when a bug can be entered. As the QA manager, I maintain that is not an Agile approach, and QA should be allowed to enter issues as they feel necessary. It’s up to the product owner (along with team) to prioritize. What do you think? How does QA balance its role with trying to cooperate with what the Scrum master desires?
Lisa: If your company is doing Scrum, your teams need to learn how to self-organize. The ScrumMaster can help facilitate that process, but should not try to impose practices. Each development team should experiment with different ways to approach their bug reporting. As the QA practice leader, you and the testers in your testing community of practice can provide your own experience about good ways to handle defects, but others on the team have a valid point of view and experiences as well. The ScrumMaster’s only job is to help facilitate retrospectives and discussions on this issue, and help the team remove obstacles or get resources. For example, maybe the team decides to try color-coding bug cards on the Scrum board, the ScrumMaster should obtain the colored cards and make sure everyone follows the agreed procedure for putting the cards on the board and making sure they get addressed.
Q: How do we differentiate between the developer and the QA role? How do we deal with the overlap and manage the hand off?
Lisa: I heard Jeff Patton speak recently at the Mile High Agile Conference. He likes the term “positions” rather than “roles.” He likened it to a sports team. For example, say you’re playing football. You’re the kicker, and you just kicked off, and the runner from the other team is about to go by you because everybody else missed him. You don’t stop and say, ”Well, I’m the kicker. It’s not my role to tackle this person.”
We all have to wear different hats at different times. We shouldn’t get too hung up on whose role is it to do what. We all have to jump in and make that a team responsibility.
When I hear the word “hand-off,” I cringe a little bit, because hopefully we’re collaborating. The testers are helping the developers write the acceptance tests up front, and the tests that guide development, and working in small iterations. They’re writing tests, writing code, doing testing, doing the exploratory testing, writing more tests.
That should be something that just goes on in tiny little iterations until the story is done, and all the activities are finished. On my teams, because it’s such a testing-intensive application that we have four developers and three testers, the developers will often take on testing task cards because we’ve got to get that story done.
Just last sprint, we were very busy with testing. One developer did all the manual testing for one of our stories. We had a mind map of post-test cases to carry out, which he followed. And he also did a really great job of exploratory testing because he’s had a lot of experience in the past eight years.
So really it’s about making it a team problem—we’ve got this testing to do. In terms of overlapping and unit tests, people are talking about automated test. They don’t want to repeat what’s testing, yet the unit test did—I don’t really find that to be much of a problem. Unit testing is so different from testing at higher levels. If there’s a tiny bit of overlap, it’s not necessarily a bad thing.
If you missed the live event, catch the On-demand recording at your leisure. Enjoy!
Photo credit: flickkerphotos