Quantity or Quality.

It seems the QA testing team is the one interested party in agile scrum that tends to get a little neglected. Nobody disputes the necessity or indeed the importance of testing the new code, however in my experience, our testing team have received the least amount of training and support to change to this new methodology.

In our project, we are very lucky in that the vast majority of our testers have been with us for many months, they are familiar with our application, have met some of our users and are therefore very well equipped in understanding what we need the system to do. Each of our scrum teams have their own QA resources that are involved in the discussions around each story. Of course, in agile, testing happens much sooner in the development cycle which has certainly helped us in mitigating risk before going to production.

However, I am personally not quite convinced that we haven’t shifted our focus ever so slightly away from the quality of our QA. It’s not that we are finding more defects now or that the team are putting in less effort to trouble shoot everything. But to me it seems that we have taken away some of the focus off QA, as it no longer functions in its own testing cycle. Where before, everybody on the project team was 100% focused on QA and bug fixing for several weeks, now that the process is built in the scrum cycle, it really is predominantly the testing team that are in charge of QA.

Is that a problem? Frankly, I am not quite sure… Based on our recent experience, I get the impression that there are ever so slightly more defects that we are surprised with when going to production. It’s not that we would have fixed every single defect prior to go-live previously, but I do think that we usually  found them beforehand and were able to mitigate that risk by communicating with our user community.

So, I do ask myself the question: Is the constant push for production ready code at the end of every sprint putting too much focus on quantity at the expense of quality?