How to start regression testing from zero?

I´m thinking about how to solve the following task: You´re joining an (agile) team as a tester and you´re the one being responsible to do the (automated) regression testing. No structured regression tests have been done before, (nearly) no tests (test cases, automated test scripts, etc.) are existing. What you have are the user stories + acceptance criteria from previous sprints and the (user-)documentation as far as it exists. Maybe some other docs too, but that´s not the point.

So it is your task to start regression testing for the old functionality as well as doing the testing for the stuff that is under development at the moment. Since development is ongoing, you somehow need to split up your time between this two main tasks, but how?

I see two possibilities:

  1. Don´t care about the actual ongoing development, just start building up a regression test suite from the very beginning of the product on. Iterate over the user stories + acceptance criterias from the very beginning on, discuss with the product owner which ones are needed as basis for tests, and which ones may have become obsolete or changed.
    As soon as you´re reached the actual sprint, start to keep up your role as tester in the team by testing what is under development at the moment and updating the regression test suite.

    you learn about all the product´s feature from the very beginning
    you know about the „development history“ of the product
    regression test suite is build up as fast as possible

  2. Work as tester in the team by testing what is under development at the moment, but with reduced capacity. For the rest of the time work on builing up the regression tests. Do so until you´ve created all the regression tests up to the actual ongoing sprint.

    tester is available for testing actual stuff under being under development right on from the start
    tester is working as closely as he could(/should?) together with the team from the very beginning on.

Disadvantages for both proposals: Just invert the advantages of the other proposal. 😉

What should be done indepently from what solution is been chosen:

  • Regression tests should be automated, why and how is explained at other places, e.g. in the Agile Testing book or in the article Regression Testing with an Agile Mindset.
  • The task of adding regression test should be estimated in any case. It’s a reoccuring task and because of this it has value to estimate this task(s) from the very beginning on to learn how to do right estimations on this.

What do you think about this?
Did I miss a possibility or (dis)advantages of the explained possibilities?

Interesting article on Starting Test Automation for a Legacy Project which is imho closely related to what I have written: You can’t start test automation without having a clear concept on how to start regression testing. The article gives some good ideas on how to start for both.


Christmas goes Scrum

Nice story, unfortunately in german only: Weihnachten nach Scrum Manier

Via Thomas Nesges on Facebook


Kanban Christmas Story

Find a nice Kanban Christimas Story by Arne Roock and Henning Wolf at agile-it: Santa Claus Has Everything Wrapped Up Now.

Via @ipreuss on yammer

Allgemein WWW

Testing is like Heavy Metal

#testing is like heavy metal. Doom, death’n destruction, speed’n torture’n beautiful ladies dancing half naked around.no!last is imagination

Source: @teemuvesala

Book Learning Programming

Programming Skills

Not only Ruby is a great programming/ scripting language to do your daily jobs or to automate your testing tasks, also Perl is.
Find a free (GNU Free Documentation Licence) Perl training as HTML or PDF on the homepage of Greg London

Also Python is a great language, and a lot of free books & tutorials are existing to learn it, e.g. Learn Python The Hard Way by Zed A. Shaw, which can be downloaded as PDF. But please be aware that this is a book for absolute programming beginners!

Via http://www.schockwellenreiter.de/

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: