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.
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.
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.
2 Antworten auf „How to start regression testing from zero?“
Could you elaborate more on the difference between the testing during development and automated regression tests? Aren’t all testing artifacts, such as unit tests, automated UI tests, test cases, etc., by default part of the regression test suite for subsequent development interations?
A third option could be to make a short sprint/iteration cycle with the team with focus on test coverage. So the team is challanged and also made responsible to create a base regression coverage for what they produced in the past. Testing should not be the exclusive domain of a dedicated tester.
Thx Sven, for your kind feedback.
I will quote the Regression Testing with an Agile Mindset article to answer your first question:
Your proposal means something like a „quality sprint“, where the whole team is working on creating the regression suite?
Anyway, I like the idea of involving the whole team in doing that.
Of course, testing should not be the responsibility of one single person, but if the rest of team lacks specific testing skills, it will be the „tester“´s task to train the team on that.