Testers in development teams

Introduction

For this blog post I’m going to talk about my experiences as a tester in a development team working to “scrum” which is an agile development methodology. I write this as someone who has worked to more traditional waterfall style processes prior to working in scrum and as someone who has worked for several years within scrum. I’ve also worked to a “kanban” model too but I won’t cover the pros and cons of the other methodologies here. The goal is to hopefully help someone in a similar situation to me have a clearer idea of how they can fit as a tester into scrum.

I’m going to assume you know the basics of how scrum works but if you are new or unsure about it, please have a read of the wikipedia article first:

https://en.wikipedia.org/wiki/Scrum_(software_development)

I would also add that my thoughts on this topic are from the view of an agile project, where speed is absolutely key. Most of these thoughts would possibly not apply to a project where speed is not desired, though I feel the role of a tester and the skills they use are the same no matter the situation.

Should a development team include a tester?

I’m going to start by tackling this first. You may notice in the link above that there is no distinction between team members in a scrum development team. A common view that I have come across before is that testing should be a process external to development. There are some that feel that testers shouldn’t become too close technically with the system they are testing because they may make some conscious or subconscious assumptions, because of their heightened insight. There is a fear that testers would lose their ability to think like an end user and would think too much like a developer.

For me, this is nonsense, I consider it my job to be aware of end users and to think beyond what I know or see. I have found it to be faster and more efficient in general to work as closely as I can with developers and I have built a much better rapport with them. This has meant that the levels of trust and understanding are much higher and developers see the value in testing. As soon as testers and testing are perceived to be a separate process, I have found the two communicate less and become more frustrated with each other.

In scrum this is crucial as you don’t have the time to waste with the traditional methods. This means that a tester cannot sit outside of development and only test pieces of work when they are complete. This would lead to development work being completed in a sprint, defects being found after a sprint and then the development work having to be revisited in a new sprint. This is obviously not an efficient way of working.

So for me, a tester must sit within a sprint team and be considered part of the development team. While their skills and role is different to a developer, they are an important contributor to considering a piece of work “done”. It is also important to realise that developers are capable of contributing to the test effort. While automation tests do not replace manual exploratory testing, they are very useful for taking the heavy load of more focused tests. Developers can be an alternative resource for constructing automation scripts, expanding upon their unit and integration tests with more advanced Selenium UI tests for example.  Testers should view themselves as being responsible for improving the quality of the work and not as an executor of tests. If tests can be easily automated by developers, then it doesn’t always have to be the tester who creates and executes the automation.

Developers can also provide assistance and help with setting up more intricate or complex tests, reproducing problems and also providing more technical explanations about how the system functions. This can be an invaluable source of information if you have little documentation or wider business knowledge about the system (though it should not be relied upon on its own).

At the same time, a tester can do more than simply test work as it is completed. In some cases, it is possible and very useful to test pieces of work while they are still being developed. Working in close collaboration with the developer, a tester can provide quick and effective feedback on the work and really focus the developer on producing quality work. The tester can also continue to perform preparation activities such as gathering any additional information, ensuring they have the appropriate tools and environments or planning their testing.

I personally feel a tester doesn’t just bring an ability to exploratory test, but also to gather knowledge, critically challenge designs and re-focus a team on what is important to deliver. These skills are best put to practice before the sprint even begins through to finishing the work, rather than after the work has been completed - where it is too late to really reap the benefits of these skills.

Summary

• In Scrum, testers are most effective when they are part of a team of developers.
• A collaborating team is far more productive than separated focused individuals in short time periods.
• Developers can contribute to developing and supporting automation testing.
• Testers should actively ensure they are not becoming too close to a system and are aware of external areas to the team - such as end users, other systems, business concerns, legal requirements, etc.