Plan-Driven Testing fails with Agile Developers
There were two situations today in the office that opened my eyes. I finally understand why it is so hard to form a team of plan-driven testers and agile developers.
Our daily scrum meeting went fine today. Our iteration progress is back in parallel with the ideal burndown after a 2 days upward drift.
After the meeting a tester came to me and said, „it’s really annoying to notice in the daily scrum that some stories are ready for testing. Why don’t the developers write me an email?“
SM: „What’s your problem? You just got the information a few minutes ago in the meeting. What could we improve to help you?“
Tester: „I don’t know. I just don’t like to wait for answers. The developers do not react on my postings in the bug tracking system. Therefore the testing crew is in waiting mode.“
SM: „Have you asked the developers?“
Tester: „What do you mean?“
SM: „Whom did you give a phone call? Did you talk to a developer directly?“
Tester: „No, they know that they have to write me an email.“
SM: „OK, obviously we have to improve something here.“
I stopped the discussion. And I am very curious if this issue will be mentioned by the tester in the next retrospective.
Later in the afternoon I went to the test lab. I met another tester there and asked, „Have you seen all the fixed bugs in the bug tracking system? There’s lots of stuff ready for testing.“
Tester: „Oh, no I didn’t take a look.“
SM: „You could start to look right now.“
Tester: „‚Err, no first I need the bug list.“
SM: „What do you mean? Just take a look at the bug tracking system to get that list.“
Tester: „No, one of the other testers is responsible to create an Excel sheet with the bug list. Then we can coordinate who is testing which bug when and how long.“
SM: „Yeah, OK, I understand.“
I stopped again. And this time I was sure that this issue will be mentioned in the next retrospective: testing has to be agilized much more!
Imagine to have a detailed iteration task board which gets updated every morning in the daily scrum by the whole team. Everyone knows, what’s going on, and everyone is up-to-date. But simply having actual knowledge of status is not enough for the testers – they want to be informed explicitely by email. Then one of the testers takes a look at the stories „ready for testing“ and maybe takes a look at the bug tracking system. The bug tracking system is already one redundant system too much but for the testers even this is not enough. One tester copies all important information out of this system into a new list. For what sake? Simply to fall back to old habits and have a plannable list of things one can assign people to and give each an effort estimation.
If the next retrospective meeting would not be within the next 3 days, I for sure had raised my voice today. But I’m sure the team will see and mention these issues on its own. The next retrospective will be exciting!