Working as a tester in an Agile Project

It is common knowledge that shifting to an agile approach will affect the tester’s role. If you’re a tester who is used to working in a more traditional approach, you can feel some concern about working in an Agile project because it will operate in a different way than what you’re used to.

There is no need to panic, but it is useful to know how you can leverage your testing skills in an Agile way so that you bring a lot to the table with your testing skills, while taking the most advantage of the team around you.

In this series of articles we’ll be demonstrating the main differences in the tester’s role between the traditional model of development, and agile development. In this article we’ll cover basic differences, but we have also spoken of Requirements Management in Agile Projects, Test Documentation in Agile Projects and Automated Testing and how each of these affect your role as a tester.

The Differences between Agile and traditional work

There are no sharp, well defined boundaries between what constitutes Agile and what is the traditional work. Of course, all agile projects work a bit differently to each other according to their conditions.

In some cases, testing cannot be automated, perhaps because of lack of resources or due to technical complications. In other situations, conventional requirements are used, for example in the form of use cases.

In agile development, there often is less time for test planning and a less strict separation between those who work with requirements, testing and development.

Here are some of the differences that are often mentioned when talking about Agile work.

What about dynamic roles and levels of testing?

Agile is famously a great proponent of more dynamic roles in the organization, instead of subscribing to the more traditional developer vs tester label. This is also reflected in the levels of testing carried out, which is good knowledge to keep in mind.

In Agile work the whole team is engaged working towards the goal, that is ‘working software’. This means that developers are testing in much greater extent than usual and that both developers and testers are involved in specifying requirements.

Often testers in agile projects are responsible for ensuring that testing is done in a good manner. Both the testers and developers provide project management or product owner with metrics on system quality.

Test levels are more tightly integrated when working agile. The boundary between the system and acceptance testing is thin. Often developers do all of the low level testing, corresponding to component testing (unit testing/module testing) and integration testing, while system tests are performed by developers and testers together.

These tests often include elements of requirements design using prototypes and usability tests. Acceptance testing is commonly conducted in the form of demos for the product owner. These demos will only take about half an hour when the team shows what that developed so that the product owner may accept that the system is developed according to its requirements.

The differences between traditional and agile work provide an opportunity for testers to work more hand in hand with requirements specialists, developers and others in the team.

Take advantage of your testing skills – remember that in an Agile team you have an important role in transferring knowledge about testing to the entire team and your work will be appreciated because if done well, it will save the whole time headaches and embarrassments in future, as well as contribute to the end goal, that of working software.