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.)
  

Tester Reputation Cheats

How well do you know your testers? There are several tester stunts I have been tempted to pull (and sometimes have). The act of testing is difficult to monitor so it is easy for testers to spoof productivity. If you catch yourself doing these…don’t.

• Whenever team members stop by your desk, make sure you have a GUI automation test running on one of your boxes. It looks really cool and gives the appearance that you are an awesome tester (they’ll never know it’s just a looping record/playback test with no verifications).
• Your manager needs to see test cases. How about just copying the requirements into something called a test case?
• You didn’t stumble upon that bug (yes you did). It came from a carefully planned test.
• There is no evidence of what tests you executed because you kept track of them locally (not really). You will upload the tests to the repository when you have time (yeah, right).
• You didn’t forget to log that bug your dev is asking about (yes you did). You are still reducing the repro steps down to the bare minimum due to some variables that may be related.
• You didn’t forget to execute those tests (yes you did), you choose not to execute them because you performed a risk assessment matrix resulting in a lower priority for said tests.
• When running performance tests using your wrist watch, record time span values out to the millisecond. It appears more accurate.
• Does your manager review your test cases or just see how many you have written? If it’s the later, find the copy/past option in your test case repository and change one value (e.g., now pass in “John”, now pass in “Pat”, now pass in “Jill” etc.). Dude, you just wrote 30 test cases! It looks great on the metrics summary page.
• If you’re lost at the Feature Walkthrough meeting, periodically raise your hand and ask if there are any “ility” requirements (e.g., Scalability, Usability, Compatibility, etc.)…it just sounds cool to ask.
• You don’t have a clue how this feature is supposed to work. If you wait long enough, another tester will take care of it.