Here a quick list of articles I´ve read during the last month:
Monat: Dezember 2010
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:
- 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.Advantages
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 - 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.
Advantages
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?
[Update]
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.
#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
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!