A bunch of us participated in three days of “Agile Boot Camp”. Speaker/Agile Coach/President of DavisBase, Steve Davis came and attempted to enlighten our department by teaching us what Agile development is all about. My department has been practicing its own flavor of Agile development for about four years but many of us have felt it’s time to adopt more Agile ideals. For starters, QA is still one iteration behind dev.
For me, the class was mostly info I had heard before. I hoped to collaborate with others and help them grasp new ideas. I was frustrated about 50% of the time as I watched many of my higher level team members look up from their Blackberrys and iPhones throughout the class to say, “Right, Steve, but that’s not the way we do things here”. Sigh.
Nevertheless. Here are some of the tidbits and ideas I wrote on the back of my tent card. Many of these are related to my new role as QA Manager.
- Make my testers feel like they are part of the solution. Give them missions and get out of the way. Don’t assign specific tester tasks. Let them work for their team. I will say “I did not hire you to please me. I hired you to please your team”.
- If the above is true, what is my role as a QA Manager? To mentor, teach, and figure out how to make my test team the best team there is.
- Assign each of my testers to a permanent dev team instead of bouncing them between teams. Locate each tester with their dev team. The longer they are a team, the more likely they will develop a cadence (natural rhythm). The cadence will allow them to stop worrying about process and concentrate on what they do best…testing!
- Get the hardest tests done first.
- Write the high level tests during the Feature walkthrough.
- Writing user stories. Don’t get too far ahead on capturing detail. If you do, you are approaching the waterfall methodology.
- If you are not going to have enough time to test, bring that up in your daily scrum ASAP so others can help.
- Daily scrum. Stop looking at the lead or scrum master as you report. Look at your team members. Your report is for them.
- Don’t wait until the end of the iteration to get anxious. Rally around the goal from day 2. Keep the energy high.
- Eric Idea: Post test status inside bathroom.
- Eric Idea: Testers evaluate each other. (this may not work if they don’t work together.)
I’ll report back later in the year with updates on how we’re doing.
RSS
I find sitting near my developers invaluable. I don't know how many times I've overheard a conversation that either directly affected something I was testing or scenarios where I was able to help shed light into the context of such and such feature. In the list above that has got to be one of the easiest items to implement for what you get in return. (The "you" could be at an engineer level and at the organizational level)
Getting the hardest tests done first is great advice.
It would be interesting to be a fly on the wall in these organizations that claim to be agile shops. I'm curious how requirements are created, especially external ones, and how their QA reconcile "writing the high level tests during feature walk through"
My experience is that a jira email shows up in my inbox and I don't deal with even thinking about how I'll test it until it comes time to testing it (maybe I process some ideas during lunch, on my drive home but no serious work).
I'm really interested in hearing about your findings when it comes to testing in an Agile environment. I love the concept, and I want to be able to make it work, but I can't help but think that Agile is somewhat antithetical to QA process. Of course, this could just be a limitation in my ability to adapt to Agility.
In general, though, QA and Dev sitting together and working together as a team is imperative. I've worked for too many companies who have contrived a physical and cultural divide between QA and Dev that has done nothing but hinder testing and project development.
Eric...first of all thanks for sharing your experience
I like your idea:
"Eric Idea: Testers evaluate each other. (this may not work if they don’t work together.)"
pre-req: both members work with an open mind to work together
Idea of testers evaluating each other has many positives
1. competition to do better
2. accountability
3. fun, energy
In Agile, this idea can work wonders..because you need to maintain pace along with other teams.
I would be interested in knowing how youve done