Testing no-dojo session 5 - agile testing part 1

Last Friday we had a discussion with developers about whether our team was doing Agile. Developers claimed that according to a 10-question quiz which was supposed to help people check their Agility, our team matched "yes" to over 6 of these 10 questions. Therefore our team was an Agile Team, especially with the 0 document part. That was true, they did not provide any document to testers in the past 4 years.

But for what I knew about Agile, it was about practices and principles.
So I asked:"what was the practices and principles we had in our team?"
"0 document", developers answered.
"Any other one?"
"We release fast."
"Any other one?"
"Oh, and we do not follow process. That's quite enough. We match the major spirit of Agile."

I didn't continue my challenge, because I knew Agile only from several infoq videos. I chose not to discuss something I didn't quite understand. So the discussion ended.

This week while we were scheduling our dojo, Qia suggested 1 video lecture on agile testing. She got confused with the discussion, and wanted to know what Agile was, and how Agile we were doing in our team.

So we started our session with the lecture - Agile Testing by Elisabeth. In the beginning, Elisabeth introduced how she met XP, and got herself involved in her first Agile/XP project. With her former experience in a tradition team, she made a comparison between the 2 teams.

Then she started introducing Agile including 4 major methodologies: XP/Scrum/Lean Development/Crystal. She claimed that most people considered Agile was all about chaos, but a real XP team was quite disciplined.
* developer work with customer to come up automated acceptance testing - as a replacement of specification
* developer write unit test before they start coding - as design document
* developer commit code only after they pass their unit testing

Then she moved on to testing in Agile Team, how testing diffed between traditional team and agile team.
* plan for iteration
* instead of being the last line of defense, become team support

We ended up in the middle of the lecture and started discussion. We focused on 2 major questions
* are we agile
* how could we apply it

We all knew that developers refused to do unit-testing. "We tried, but it really slowed us down." They said. The schedule they referred here was called "development cycle", it counted from the day developers started coding till the day they released the package to testers. Without unit testing, developer could release the package in shorter time.

But hey, without unit testing, testers would find more bugs, need more time to investigate, more time to file it, more back and forth for developers to fix bug and release again and again. Developers knew that but they simply didn't care. Because after the day they released package, "testing cycle" started. Why developers should give a damn about how long it would take. The longer testing cycle took, the worse testers looked. Everyone loved developers, because they always beat the schedule. Everyone hated testers, because they always got beaten!

After the complain, I still found something I could do - become team support. So I went back my seat, found out the bug list for the latest release, and went through all the bugs 1 by 1. Among all 16 bugs, I found 5 bugs could be avoided if I could give comments to developers before code commit. So I sent out mail with the evidence. 30 minutes later I got a confirm from developers that from now on I would be invited in the code review. That was not exactly what I hoped for. But at least I would not need to file those not-so-smart bugs any more.

BTW, Elisabeth mentioned Mary in the section of lean development. Mary is one of my favorite speakers among all infoq speakers. The ideas she has on Lean development and Deliberate Practice lights my way in darkness. I would encourage everyone who considers software engineering as craftsmanship to watch her series on infoq.