Social

Follow me on Twitter

Pulling the covers on regression testing

Well not quite, but making it more the teams responsibility….

There has been something bothering me about the way we do regression testing and I want to try something a bit scary.

We release every 2 weeks. Scrum teams test their own features on our CI environment, we then branch to test and regression test the whole site. This is split into areas, and each scrum team gets an area to look after. The scrum teams like to test other peoples work for 2 reasons:

its nice to checkout what the other teams are doing.

the other teams act as a safety net for teams own feature testing.

This makes me a bit uncomfortable.
Its forcing us to not be responsible for the quality of our own work. As the QA team organise regression testing this is seen as the last point of call, which sends the message that feature testing isn’t as important.

Wikipedia says

‘Regression testing is a type of software testing that seeks to uncover new software bugs, or regressions, in existing functional and non-functional areas of a system after changes such as enhancements, patches or configuration changes, have been made to them.’

We still have a need for regression testing, but what I want to address is the ownership of quality.

I have been throwing around conversations with the developers to ask them how they would feel about regression testing their own work. The initial reaction is intense fear, but following some reasoning its now just fear.

My plan is that is everyone shares the testing, we will work out a better way to do it, automate some (I mean more) tests and be a lot happier. We will tackle knowledge sharing by pairing more.

I still have a lot of work still do to so I will blog my journey of making the real responsibility for quality to be everyones.