Bloggo back to the blog
Agile Testing Days in Berlin (Wednesday) ; self-certification-->
I didn’t post yet about Tuesday because I had prioritized preparing my presentation for Wednesday.
Michael Bolton kicked off the day telling us testers to get out of the QA business. After all, Quality depends upon your point of view.
Quality is value to some person(s)
– Jerry Wineberg
-James Bach and Michael Bolton
If you complain that you need requirements documents before you can test; you’re not really testing, you’re checking.
In the agile world, there is a big focus on automated checking. We don’t just test for repeatability, but also adaptability, value, and threats to value. That cannot be scripted.
Testing is exploring. Michael proceeded with an analogy of testers as investigative reporters, and CSI lab assistants. Those lab assitants do work closely with the police, but they’re not running the show.
An example of an airline with a tight budget: we wanted to go with a skilled pilot.. but they’re so darned expensive…
Our specialty is to help other people not to be fooled.
During the question stage, Michael Bolton recounted a disaster in 1957: IBM set up an independant test team; before then, testers we co-located with programmers!
After this, Gojko Adzic stole the show with something that should have been a keynote as well.
Gojko had transformed his “Top 10 reasons why people fail with ATDD, and how to avoid them” into a presentation that was told in <irony mode> the whole time. He pretended to be from the fictitious ‘Global Agile Qualification Board’, explaining how testing should be performed.
For example, if someone was co-locating testers and developers, that would be a clear violation of:
Question 7.a.3 : independant team, preferably at a +12 hour time difference to avoid interference.
In fact, the term offshore was shown as a good place to put your test team: at sea, on an oil rig.
Our error rates have dropped…
Question 8.b.1: Never give away what you test, otherwise developers will write the system to pass the tests.
Using open source tools
Of course that was cheating: develeopers were helping in automating.
Question 10.c.2 Ideally use tools with licensing costs that prohibit developers from accessing tests to ensure isolation.
Hiring people with experience
Question 1: certifications are a good replacement for experience.
A few minutes later, during the break, Jose Diaz came up to the group where Gojko was talking. Jose congratulated Gojko on his memorable performance, and said they should talk about a keynote next year.
Later still, Stuart Reid would be up: “Agile Testing Certification; How could that be useful?”
He started with a disclaimer, and talked at length about the rationale, and the money floating around in a new scheme of certification of individuals and accreditation of trainers and course material.
The genie is already out of the bottle. If the community doesn’t come up with a solution, maybe forming a (true) nonprofit organisation, then someone else will step in and launch a commercial certification.
The curriculum and the length of the course was appearantly still open for debate. The idea was to have some agile intro first, before the agile testing topics could be covered. (That rang a bell, that’s what we’ve been doing for years now.)
There were some good points made, but not enough to make me stay in the room. In the Speaker’s Lounge, I witnesssed the last few moments of a session about Patterns.
My own presentation
At the start of the conference, my own presentation was far from complete. I had skipped the improvisation theatre the night before. Because I was close to the end of the day, I had decided to get to the point quickly, and explain most of my view in the first 20 minutes. After that, I would proceed to show my attempts to put things in practice.
Initially, only 15 people were with me in the room. Soon, that number rose to about 35, phew! Interesting enough, Elisabeth Hendrickson had joined in the back of the room. She had given me inspritation with her keynote the year before. The concept she had introduced was “collective test ownership”; my title was “Implementing collective test ownership”.
Essentially, my points were simple. If you want it to work, to treat all your test ideas and test code as regular code, and to maintain them as a team, you will have to operate in a cross-functional manner. Testers and programmers will not become fully interchangable and they never will be. Teams will have to make working agreements, in order to learn from eachother, and to be able to pick up where another has left off. Employers will have to create career paths for tester/programmers, and send them to conferences. Teams will have to refactor their tests.
For illustration, I sketched out 1 recent and 1 current project. Both projects had problems, and were not quite doing ATDD the way I would have them to. (Later, on the twitter feed [ #agiletd ], I saw the statement reappear: “ATDD is not an optional practice”.) Before the teams and the customers(!) would be ready to incorporate more aspects of collective test ownership, many other small steps had to be taken. Hence my advice to take away impediments for doing ATDD first.
During the question stage, I realized that I hadn’t highlighted the benefits. When something goes wrong, then your investment should pay off, in having a team of generalizing specialists. Collective test ownership implies that if one person calls in sick on Tuesday, another team member will take over and do their work – even if that involves testing. At a time like that, it’s very, very convenient if your coding standards and naming conventions cover your testware as well as any other piece of code. Haven’t we all had the experience, that testware from another person was hard to find, hard to comprehend, or hard to get it to work on your machine?
At the Oktoberfest (!) dinner, something memorable happened. Maybe I should even say historic. I was handed a piece of paper by the initiator, Elisabeth Hendrickson. People were reading and copying. The text was a powerful statement:
WE ARE A COMMUNITY OF PROFESSIONALS.
WE ARE DEDICATED TO OUR OWN
CONTINUING EDUCATION AND
TAKE RESPONSIBILITY FOR OUR
CAREERS. WE SUPPORT EACH OTHER
IN LEARNING AND ADVANCING OUR
CRAFT. WE CERTIFY OURSELVES.