The initial statement of Anko Tijman (@agiletesternl) in his talks was, that agile testing is about migitating the risk, therefor a test strategy should focus on risks in
- business acceptance
In this talk Lisa Crispin (@lisacrispin) and Janet Gregory (@janetgregoryca) presented some major issues they learned about since they published their book Agile Testing some years ago.
These topics are:
- Feature Acceptance
- Test Automation
- Large Organisations with Multiple Teams
- Distributed Teams
- Continous Learning
From monday to wednesday I had the chance to visit the Agile Testing Days in Potsdam. It was an awesome event: I met a lot of interesting people (delegates, speakers & tutors), had many interesting conversations, met former colleagues, listened to amazing talks, and learned a lot. Far too much to wrap everything up in one blog posting. Therefor I will use this article to list up all the articles about the Agile Testing Days 2011 (#agileTD), the list will be updated as a add articles, so drop in from while to while, or subscribe to the RSS-feed:
- Agile Testing and Test Management, Johanna Rothmann
- What Testers and Developers Can Learn From Each Other, David Evans
- Do agile teams have wider awareness fields?, Rob Lambert
- Who do You Trust? Beware of Your Brain, Linda Rising
- Product Management using Effect Mapping, Gojko Adzic
- Appendix A: Lessons Learned since Agile Testing Was Published, Lisa Crispin & Janet Gregory
- A Balanced Test Strategy Strengthens the Team, Anko Tijman
- Testing your Organization, Andreas Schliep
- Five key challenges for agile testers tomorrow, Gojko Adzic
Short notice: I will participate at the German Agile Testing and Exploratory (GATE) Workshop 2011 on October 1st & 2nd in Hamburg, Germany. My topics will be „Shared responsibility for quality vs. separate QA teams“.
Other guys participating so far: Markus Gärtner, Maik Nogens, Meike Mertsch, Eusebiu Blindu & Sven Finsterwalder.
More info available on the GATE homepage: www.gate-workshop.de.
I´m looking forward to have a productive weekend full of learning and insights with these guys!
- Team Structure communication is critical!
- Independent QA teams
- lead to division between programmers & testers
- are inefficient
- structures & reasons should be changed
- testers as learning CoP, QA managers as „leader“/ „teachers“
- Integration of testers into an agile project
- testers (also) need training -> critical/ crucial
- programmers need training on testing (skills)
- pairing of programmers & testers
- improves communication
- is efficient
- only 1 budget/ schedule
- -> how does this fit into a big organization with multiple scrum teams and multiple independeent QA-teams?
- testing as part of the DoD
- testers are full fledged team members (use retrospective to improve)
- testing tasks are as important as all other tasks (use retrospective to improve)
- new definition of QA & development managers to be found
- Agile project teams
- cross-functional, but „whole team effort“
- build team depending on project´s needs <- refactor as needed
- tester´s CoP, driven by QA manager
- Independent QA teams
- Physical logistics
- -> Co-location of all team members!
- support communication of distributed teams (phone, webcam, instant messaging, …)
- tester-developer ratio
it depends… on
- complexity of the AUT
- skillset of the tester
- used tools
- -> number of test taks taken by programmers (?)
- focus on skills instead of ratio
- use retrospectives to find out if hiring a tester would solve the problem (!)
- tester-developer ratio
- Hiring an agile tester
- Very similiar article online: http://lisacrispin.com/downloads/HiringAgileTester.pdf
- most important: does person fit into team
- „hire for attitude“ (not skills)
- Building a team
- self-organizing team: team can identify & solve problems on their own -> best progress
- involving other teams: bring teams together, so they can learn from each other
- performance and rewards
- measuring & rating individual performance risks undermining team collaboration
- good performance shouldn´t be victimized if team doesn´t perform well
- don´t blame the tester if a bug gets discovered in production
- set goals which
- serve business
- increase profibility
- make customers happy
- -> generalized(?): which add value?
- celebrate success
- What can you do?
- get team principles from chapter 2 to work
During our latest book study group session some of the members of the group stated that they aren’t interested in reading the whole book, since they would not benefit from every chapter. So we decided to read the (at first sight) most interesting (looking) chapters first and then see how to go on.
So as next chapter to study and discuss, we decided on „Chapter 18, Coding and Testing“.
First of all, I have to admit, that from the title I would have expected a more technical content; I expected to see things like examples of code and unit tests, see automated tests and stuff like this, but this wasn’t the case, and at the beginning I was a bit surprised. 😉
But here we go, my notes & summary on the chapter:
For some strange reason I can´t follow (without having talked to anyone yet) the book study group decided to study chapter 21 for this week´s session. Chapter 21 has the headline „Key success factors“ and is more or less a summary of all the chapters before. Seven key success factors are given, here my notes/ remarks to this.
Things in “ are quoted directly from the book, normal text is my abstract, and things marked by an arrow ‚->‘ are my comments on something.
Two weeks ago, at work we had the kick-off-session for a „Book Study Group“.
In a former „book swashing session“ facilitated by Deborah Preuss and Sebastian Lang, it came out that we want to start with „Agile Testing: A Practical Guide for Testers and Agile Teams“ by Lisa Crispin & Janet Gregory or with „Clean Code: A Handbook of Agile Software Craftsmanship“ by Robert C. Martin.