Allgemein WWW

QuickLinks for November 2010

Here a quick list of articles I´ve read during the last month:


Ahas on „Regression Testing with an Agile Mindset“

I´ve read a pretty interesting article about Regression Testing with an Agile Mindset, found via the GoogleReader commendations of Ralph Miarka who is an agile coach at our company.

Here are my „Ahas“ on that article:

  • Realize the difference between functional tests and regression tests to avoid common pitfalls
  • At the end of each sprint product owner should not only accept new features, but the overall functionality of the software
  • Zero bug tolerance pay off on the long term, so it is better to reduce the scope (regarding new features) then accept (regression-) bugs
  • Regression tests need to be maintained/ adapted over time
  • Regression tests provide safety net, so team can focus on new functionalities during the sprint
  • Fast feedback is needed, therefor regression tests should be automated
  • Regression test suite != sum(Functional test suites)
    • product owner defines the functionality to be tested within the regression tests
    • updating a regression test is part of the user story (so it needs to be considered when estimating)

Book Study Group: “Agile Testing”, Chapter 4

For personel interest I decided to read chapter 4 „Team Logistics“ of Agile Testing, before we decided to do so in the book study group, here is my outcome:

  • 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
  • Physical logistics
    • -> Co-location of all team members!
    • support communication of distributed teams (phone, webcam, instant messaging, …)
  • Resources
    • 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 (!)
  • Hiring an agile tester
  • 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
      • communication
      • feedback

Rubber Ducking

While reading chapter 18 of „Agile Testing“ the term „rubber ducking“ was mentioned.


Book Study Group: “Agile Testing”, Chapter 18

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:


Book Study Group: “Agile Testing”, Chapter 21

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.

Book Learning

Book Study Group: „Agile Testing“

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.


Tester and programming skills

Why should (agile) testers have programming skills? They are testers, not programmers. Why to know how to code, if it isn’t your job to do so?


Responsibility for your learning (?)

Since I’ve heared Maruks Gärtner’s talk about self education at #agileTD I’m thinking about two things mostly:


def intialize

Yesterday & the day before I had the chance to visit the Agile Testing Days in Berlin, thanks to my employer Agfa Healthcare who send me there and paid the fee, thanks! 🙂
I setup this blog because of a talk of Markus Gärtner (Blog: http://blog.shino.de/, Twitter: @mgaertne) who recommended to write a (private or public) journal about the things you´ve learned to get feedback about it from others and I think also to re-think before writing it down, which might improve learning as well. To be honest – I am thinking about that for a while now, but what me kept from it are mainly the following concerns: Is it interesting for others what I´m writing about? Is my english good enough for others to be readable? Maybe it´s wrong what I´m writing? etc.? But what I didn´t consider yet was „How do I benefit from that?“, but after Markus talk I at least know, that my own learning benefits from it, and I think that´s worth a try! 😉 So, here we go, and thanks a lot to Markus!
These days I´m mostly interested in testing, agile, integration & -ility testing in an agile environment and being a teamlead of a „classical integration test team“ and a „classical test manager“, finding my role/ position in an agile organisation and how to support developers (programmers AND everybody else developing our product) best. Furthermore I’m doing functional GUI test automation and scripting with Ruby.
I´m very courius about how this will evolve and how I (and you!) can benefit from this!