Agile Testing Days 2010 – Day 3 (Lederhosen and Certified Self-Certifiers)

Agile Testing Days 2010 – Day 3 (Lederhosen and Certified Self-Certifiers)

Advertisements

October 6

Wednesday. Michael Bolton warmed up the audience with the keynote performance How am I supposed to live without you?Testers: Get Out of the Quality Assurance Business!“, and proved once again that he’s a hard act to follow. He immediately came out of the closet saying that he’s an Agile skeptic and stated what “being Agile” means to him:

  • Adhering to the Agile Manifesto
  • “Be able to move quickly and easily” (cf the definition in the Oxford English Dictionary)
  • De-emphasizing testing for repeatability
  • Re-emphasizing testing for adaptability
  • For testers, focusing on testing skills
  • Focusing on not being fooled

Michael then defined quality as “Value to some person(s) who matter” (© Weinberg, Bach, Bolton) and said that decisions about quality are always political and emotional, and taken by people who actually have the power to make these important decisions. A little bit later, the main message of the talk jumped right at us and bit us in the face:

If you are a tester, do *you* hire the programmers? Fix problems in the code? Design the product? Allocate staff? Set the company’s strategic direction? Allocate training budgets? Set the schedule? Decide on raises? Control the budget in any way? Negotiate customer contracts? Actually choose the development model? Set the product scope? Do you decide which bugs to fix, or write the code yourself?

Did you answer “No” to most of them? Then you will probably agree that it is simply impossible to “assure” quality. But no worries – it is not our job to assure quality. What we *can* do is test, and make sure we’re damn good at it. Testing in the sense of a sapient activity, providing information with the intent of *informing* a decision, not *taking* the decision. Not to be confused with checking, which mainly aims at confirming existing beliefs. Checking is automatable and non-sapient.

Michael Bolton shifted into a higher gear, and claimed that “acceptance tests” are examples, and that examples aren’t really tests. They are checks, not tests. Acceptance tests don’t tell us when we’re done, but they do tell us that we’re not finished when they fail. They should in fact be called “rejection checks”.

I looked around me. Usually, at this point in a presentation and at this time of day, people are dozing off. Even the biggest barflies were wide awake now. He ended with a set of statements that almost read like some kind of Tester’s Manifesto:

We’re not here to enforce The Law.
We are neither judge nor jury.
We’re here to add value, not collect taxes.
We’re here to be a service to the project, not an obstacle. 

I got out of the room early and skipped the Q&A part, since my presentation was up next. Apparently the Q&A got a bit out of hand (I suspect the A was probably more to blame than the Q), because the auditorium doors swung open 15 minutes late. In hindsight, I was lucky that I even had an audience; in a parallel track, Gojko Adzic was delivering one hell of a performance (a stand-up comedy routine, I was told) for an overly packed room. 

No stand-up comedy in my room, but an honest “inexperience report” called “A lucky shot at Agile?“. I had ditched Powerpoint one week earlier and decided to go for Prezi, the so much nicer alternative. Of course, this was a bit of a risk, but I think it turned out fine. The presentation went well, and I received some good and heartwarming feedback which really made the rest of my day. 

In case you are interested, here’s A lucky shot at agile – prezi.

<Shameless_plug>In case you’re interested in the full story, Eurostar conferences has released my paper on the subject in an ebook-format – available for free – here </Shameless_plug>

I stayed in the room to attend Anko Tijman‘s talk “Mitigating Agile Testing Pitfalls“. Anko’s talk revolved around five pitfalls that threaten agile teams, and what we can do to mitigate them:

  1. Not testing with the customer. We can mitigate this risk by building a relationship, building trust.
  2. Not testing as a team. Teams are collectively responsible for the quality of the product. Share knowledge not only with your testers, but with the whole team. Work on a collaborative definition of done, tackle risks.
  3. Unbalanced test strategy. Teams sometimes focus too much on unit tests or acceptance tests, postpone other test activities to the next phase. This in turn can lead to a lack of feedback. To overcome this, put more detail in Definition of Done, schedule knowledge sessions, share content on a wiki.
  4. Requirements are too vague/ambiguous. Collaboration is the key in overcoming this pitfall. Communicate!
  5. Tools. Focus only on tools that add value to the team and that support the practices of the team. Decide as a team which tools to use and which not.

By then it was time for lunch, which is always a good occasion to mingle with other testers, discuss and have some fun. And to ravage that German buffet, of course. I had the impression that everyone was eagerly anticipating the keynote that would follow, which was Stuart Reid with “Agile Testing Certification – How Could That Be Useful“. It became clear that he wasn’t exactly going to preach for his own parish.

And a controversial talk it was. Twitter servers were moaning as Stuart’s quotes and graphic interpretations thereof were launched into #AgileTD cyberspace. Strangely enough, the infamous twitter fail whale was nowhere to be seen, which surprised me since the whole auditorium was filled with bug magnets. Stuart Reid started off by stating that it is only a matter of time before a qualification for agile testing is proposed and launched, whether we like it or not. He continued to say that if we want our industry as a whole to improve, we should exert our influence to help create a certification scheme we can truly benefit from. Fair enough. But what followed next confused me.

Stuart Reid stated that “the certification genie is out of the bottle” – what started as a good intention has spiralled out of control, and there’s no way back. This sounded like nothing more than a public dismissal of ISTQB to me, coming from one of the founding fathers. He proceeded to give an overview of the typical money flows in such a certification scheme, which was pretty enlightening. At one point, Stuart even managed to upset Elisabeth Hendrickson by stating that “it’s not because you are teaching Agile, that the training itself has to be Agile”. The movie clip of that very moment will live long and prosper on the internet. The whole “if you can’t beat them, join them”-idea bothered me too, as if there are no alternatives. Instead of focusing on certifications, we could try to educate employers, starting right at the top level. Certification programs exist mainly because employers don’t really know what qualities define a good tester. For them, a certification is merely a tool to quickly filter incoming resumes. Anyway, I think it’s good that Stuart initiated the debate, which would continue the rest of the conference.

The room was buzzing afterwards. Nothing better than some good old controversy to get the afternoon started. David Evans calmed things down again with “Hitting a Moving Target – Fixing Quality on Unfixed Scope“. He had some great visuals to support a thoughtful story. Some heavily tweeted quotes here:

  • QA in Agile shouldn’t be Quality Assurance but rather Questions and Answers
  • The product of testing is confidence (to which Michael Bolton quickly added that the product of testing is actually the demolition of false confidence).
  • Acceptance Test Driven Development (ATDD) slows down development just as passengers slow down a bus. We should measure the right thing.

Then it was Markus Gärtner‘s moment to shine in the spotlights. He presented “Alternative Paths for Self-Education in Software Testing“. During the last year, I got to know Markus as a passionate professional, dedicated to learning and advancing the craft. An overly active and ever-blogging guy that may have found the secret of the 27-hour-day. He opened with the question “who is in charge of your career?” Is it your boss? Your employer? Your family? Your teachers from high school? Well, none of that. It’s YOU. If you find yourself unemployed a year from now, everything you do now is contributing to you being employed quickly again.

Markus listed several ways of learning and self-improvement:

  • Books:
  • Courses
  • Buccaneer Scholaring, a way of taking your education in your own hands, based on the book Secrets of a Buccaneer Scholar by James Bach
  • Testing challenges – challenges to and by the Testing Community
  • Testing Dojos – principles: collaboration in a safe environment, deliberate practice. Usually consists of a mission which allows the testers to practice their testing and learning. Can happen with observers or facilitators, can be a good occasion to practice pair testing too.
  • Weekend Testing – A few hours of testing + debriefing in the weekend  according to a charter or a mission. I participated in a couple of European weekend sessions, and I must say: great learnings indeed. 
  • The Miagi-Do School of Software Testing, a school founded by software craftsman Matt Heusser. It’s a zero profit school where people can improve their skills, learn from others and share knowledge, using a belt system like in martial arts. They are not widely advertised – as Markus said: the first challenge is finding them.  

Janet Gregory‘s closing keynote fitted nicely in Markus’ theme, since it was all “About Learning“. It was an inspiring talk, about congruence in learning, the importance of learning, the curiosity of children – how their unspoiled curiosity makes them natural testers. She also related the learning to the agile principles. She managed to tie in neatly with Rob Lamberts presentation about structures and creativity. A safe environment helps you to learn. She referred to trust as an important element in team safety. A blame culture will work counterproductive. No-one will learn anything.

After all this theory about learning, we were all yearning for some hands-on practice. The Diaz & Hilterscheid gang gave us the opportunity to practice that typically German custom called Oktoberfest. Just like last year, they dressed up in Lederhosen (I’m actually getting used to the look of José in Lederhosen, go figure) and started serving plenty of local food and one-liter glasses of beer. There was live music as well, which added to a fun Bayerisches athmosphere. The evening culminated in some vivid discussions of the burning issues of the day. Well, actually there was only one burning issue: certification. Elisabeth Hendrickson was determined to get everyone mobilised for a worthy cause and whipped out her iPad on which she had written some kind of self-certification manifesto. Someone threw a pile of index cards on the table. Elisabeth was on fire and started handing them out everywhere. “If you agree with it, copy it. If you don’t, don’t”. Index cards on tables. Pens. Beer. Lots of people copying index card after index card till their fingers went in a cramp. That night witnessed the birth of a community of certified self-certifyers, all of them proudly carrying the message:

We are a community of professionals.
We are dedicated to our own continuing education
and take responsibility for our careers.
We support advancing in learning and advancing our craft.
We certify ourselves.

Some people took the discussions to the hotel bar, while others decided to dance the night away. I think I even spotted some genuine limbo-ing on the dancefloor. Someone ought to tell these testers about risk…

To be continued… Day 4

2 thoughts on “Agile Testing Days 2010 – Day 3 (Lederhosen and Certified Self-Certifiers)”

  1. Thanks for the summary.
    It seems to me now, that we’re in the business of supporting informed decisions in more than one way: Apart from the obvious one in providing information to support a business decision to go — or not go — to production, there’s we are also the ones who can support an informed decision about how to hire testers for a given team and product.
    A decision not only based or certificates, CVs and an interview with the hiring manager, but based on other criteria (we [yet] need to find/develop).

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s