The role of testers in Agile product development

What I like about Agile is that it gives the development team to really understand the product and what I like about the testing process in Agile is that it emphasizes the communication between testers and other team members. Last year, together with Olga we gained our ISTQB Agile tester certificates and that was the time the inspiration for that article arose.

Testing in Agile

In Agile the whole team is responsible for QA, so testers and developers need to work closely together. The agile approach focuses on communications and collaboration. Developers and testers should cooperate to set user stories before starting work on the coding and testing of any feature.

Agile development is often driven by tests so developers write the test but sometimes also testers write code - automation test. When the development of an application is underway, programmers write code and agile testers should be testing. So it is important to start the testing process as soon as possible.

In Agile development, the definition of done is important. It has to be standardized and understood among the team when work on user story is done and the team can focus on developing the next part of the code. To consider that story is done, the user story needs to pass the acceptance criteria - this includes testing and validating the acceptance criteria.

Tester/QA role: Start functionality and integration tests as soon as developers finish working on them. Report bugs when they appear. After the release of fixes, retesting functionality and application.

What are the differences between testing in traditional and agile approaches?

Every QA engineer or software tester knows that there are some significant differences between work in agile oriented projects and the traditional ones. Testing activities, with no doubts, are inseparably associated with coding, and they should look different on different software development stages. For traditional projects, with a not agile approach, like model V where the execution of processes happens sequentially in a V-shape, for every development phase, there is an analogous testing phase.

The traditional testing depends mostly on documentation. On the contrary, gathering all the requirements, testing, development happens linearly in the Agile, it all occurs iteratively with light documentation. The team members collaborate closely with each other with the testing first approach with writing automated unit tests before the functionalities are coded.

Understanding the principles of the Agile Manifesto, knowledge of Scrum ceremonies

Let's take a look at the beginning of the Agile Manifesto:

Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan

Individuals and interaction

Agile development is more concentrated on people. The team is composed of individuals building software to perform specific functions. In Agile, work is more effective thanks to constant communication and cooperation, as opposed to relying on processes and tools. Thanks to this approach, the team can work faster, react to challenges or changes and testers can report bugs early.

Working Software

Nowadays, for most of the clients, the delivery time of working software is more important than overly detailed documentation. The Agile approach fits in perfectly with these requirements because the development team can deliver tested parts of the application faster and get more precise feedback from clients, and the application itself will hit the market quicker.

Customer Collaboration

During Agile development collaboration with clients, it’s crucial to maintain regular communication, so teams can get feedback systematically. When customers see some issues with the software, thanks to close cooperation with the team, including testers, it is easier and faster to identify the source of the problem and assess whether the application’s behaviour results from an error or earlier assumptions. It accelerates the changes implementation process. 

Responding to Change

In the modern world, business, law, competition, technologies, customer preferences and other factors have a significant impact on the project and its goals. These factors change dynamically, which means that the team should react quickly and communicate with the client about these changes. As a result, it is often necessary to make a lot of modifications to the projects, and each of these adjustments should be tested before they reach the customer and the production.

To work in accordance with the Manifesto, the team must keep the scrum ceremonies, which consist of:

• Sprint Planning: meeting during which work for the next sprint is planned. The team chooses from the product backlog what task they will make in the next sprint, depending on priority and time consuming, in terms of coding and testing. 
• Daily Scrum: This is a standup meeting, a 15-minute meeting during which the team shares what has been done, what they are planning to do and whether there is any trouble in performing the feature.
• Sprint Review: Meeting with the client, where the team presents the progress of their work, both in terms of development and testing.
• Sprint Retrospective: A meeting at which team members analyze their work, its effectiveness and refine to improve the quality of work.

Tester/QA role: Bugs reporting, reporting deficiencies in requirements. Listing to what extent the application has been tested and where bugs or problems occur.

Whole team approach

When we take a closer look at team members that will work with us during the development of the product, we can see that each of them has not only specific knowledge but also different skills. But they all have one thing in common - they are there ensure the product success. That means, more or less, that the product quality is everyone’s responsibility in the Agile approach. It means that testing is not only a tester’s thing. 

Software testers or QA specialists should do that on a deeper level, they are the professionals, and it is understandable, but developers should take care of tests as well. They should e.g. write unit tests, and the testers should perform tests of different types and levels. It means that they can e.g. perform API tests, add e2e tests on the UI layer, check the performance and so on. The more bugs on different levels will be found, the less problem there might be in the future.

Skills to create a user story

User stories are created to collect requirements from the perspective of developers, testers and business analysts. User stories contain functional and non-functional properties. They should also include acceptance criteria for features and are co-created by the whole team, including the tester or verified by tester members of the team. During the process of creating/verifying user stories, testers use their own experience and knowledge from the previous projects to create user stories for new projects.

Thanks to the unique perspective of testers, they can find missing details or non-functional requirements and ask the right people for details that are missing. When we create a user story it's important to focus on the user perspective and have well-defined functionality, without technical and implementation details, of your product using 'plain English' - which is understandable for the technical and non-technical side of the team. When a team is creating user stories together, they can use the INVEST technique to define user story. INVEST stands for:

• Independent
• Negotiable
• Valuable
• Estimable
• Small
• Testable

The user story is a combination of 3 elements:

• Cards - physical (or digital) media describing the story: requirements, priority, criticality, estimation, acceptance criteria.
• Conversation - an explanation of how the software will be used. It can be in a verbal form, where developers, testers and business representatives exchange stories, opinions and experiments while discussing the story.
• Confirmation - acceptance criteria, confirming that the story has been completed. AC will be met when tests covering the happy path and sad path are performed.

A user story example: As a cinema client, I want to see a movie repertoire for a given day.
Acceptance criteria: 

• See a thumbnail of each movie.
• Click to display the movie description.
• See details of each movie (age restrictions, language, movie display hours).
• Search for the movie.
• Change a date.
• Make a reservation/buy a ticket for the screening.

Tester/QA role: Find missing or non-functional details. In the process of testing, checking if AC has been met. Creating Test Cases based on User Stories

What is the role of a tester in the release and iteration planning in Agile methodology?

We all know that release and iteration planning is an indispensable part of Agile methodology. The indisputable fact is that the QA specialist or software tester should be involved in those activities. When it comes to release planning, we usually organize it during the sprint 0. What is the purpose of these actions? To plan the release, to define the goal and features, to write the acceptance criteria and, what is the most important for every QA specialist, to set the test strategy and test approach and planning. So as a QA, we should co-write, with other team members, the acceptance criteria and user stories to make them understandable for others. We should create test cases against those user stories. If we find any risk during the release planning, we should inform the entire team.

Iteration planning is different. The team decides which story should be put in the sprint. All team members, including QA specialist, should ask as many questions as possible to understand the story entirely. The user stories should be divided into testing tasks with the estimation from the QA about the amount of work that is needed. As you can see, the cooperation between all team members is crucial also on that stage.

What is Exploratory Testing in Agile?

Exploratory testing is a style of testing based on the experience of the tester and human intuition. Because exploratory testing is a less structured and specified process than traditional testing and gives a tester personal freedom, but also a responsibility to rely on his skills and knowledge. During the whole process of exploratory testing, the tester (him)herself designs and executes the test and tries to find unforeseen problems with the software which wouldn't be found during traditional testing within the case of test scripts saved in advance. Both activities are performed simultaneously.

This style of testing insists on reflecting the user experience when using the application. Also, tests are more adaptable to changes because they do not rely on the test plan created at the beginning of the project and the plan that should be tested is selected on an ongoing basis and responds to changes in the project.

So-called heuristics (rules on how to perform tests and evaluate their results) are helpful in performing tests:

• CRUD (create, read, update / replace, delete)
• various configuration
• interruption (eg log out, close the app, restart, refresh)
• limits

It's important that the tester documents the process of the test.  Here are some examples of information included in the test documentation:

• Test coverage - what data were used, what was tested.
• Notes from the assessment - eg. if the system is stable, found defects, what steps should be taken and a list of ideas what to test next
• Problems, queries and anomalies - unexpected behaviours, application restrictions
• Real behaviour - notes form the actual system behaviour in the form of a description and video, screenshots of data files generated by the application

Pros and cons of Exploratory Testing

Like all of the solutions, Exploratory Testing has its advantages, but also disadvantages. Here we pointed out some of them: 

Pros of Exploratory Testing

• Test time is reduced because the process doesn't require specialized preparation and it depends mostly on experience, skills and creativity of the tester. 
• Testing the app as it will be used by the target user- tester is imitating the behaviour of the final user.
• Finding usability and UI issues and bugs.

Cons of Exploratory Testing:

• Insufficient experience of the tester.
• Lack of documentation for reference.
• Critical bugs can be still overlooked.

Tester/QA role: Testing the application as it would be used by the target user. Reporting bugs and signalling problems with the application

When do the tests begin?

When the UI/UX process is started, it's possible to begin the testing process. Testers can check if all elements were taken into consideration and if they have been included in mockups and designs. Sometimes the development team gets a design from a client or the UI/UX process starts earlier than coding and testing. In those cases, testers should get familiar with mockups and designs. Again the tester should test the design for all elements of the application and if any components are nor missing. If a user can use an application when logged out and when the user is logged in, the tester should make sure that the different views are designed.

Tester/QA role: Verifying that all application components have been included. During testing, verification of the compliance of the appearance of the application with the design.

Test levels

When we think about test levels, the first terms that come to our minds are unit, integration, system and acceptance tests. But, what is essential in the Agile model, test levels can overlap each other, e.g. unit tests written by developers and acceptance verification tests that are written by QA specialists and test the user stories acceptance criteria. We have already mentioned the iterations during which the user stories are being developed, tested and delivered. For each user story test activities are performed, including already mentioned unit tests and acceptance verification & validation tests. Another important thing is performing regression tests both on unit and acceptance levels. This means often re-running already created automated tests. In some Agile projects, QA specialists also perform system tests.

Testing techniques in Agile

Test-Driven Development (TDD)

As Marcin said in his article, everybody at least heard about test-driven development. TDD became popular thanks to one of the types of agile software development which is Extreme Programming. But now it is widely used in other Agile methodologies. To cut a long story short, test-driven development is a process used where the requirements are turned into test cases, the code is written after that to make the tests pass eventually.

What are the steps in the test-driven development cycle?

• Add a test
• Run the test - it should fail because the code for the functionality is not written yet
• Write the code and run the test again - now the test should pass
• Refactor the code after the test is passed, to be sure it will work after refactoring, rerun the test
• Repeat this whole process for every new feature

Behaviour-driven Development (BDD)

Behaviour-driven development (BDD) approach to develop a new application improves communication between members of the development team, business analysts and clients. Scenarios are written in a special format called Gherkin Given/ When/ Then syntax. These scenarios hold information on how a feature should behave in different information with various input parameters. Because scenarios are written in a specific way, they are understandable by technical and non-technical members of the team and clients. Scenarios written in this way constitute documentation of the application being developed and can be the foundation for automated tests 

Scenario: Registered user successfully logged in to the app. Given User has registered account.
When User enters user's credential
And User clicks submit login form.
Then User is logged in.
And User is redirected to Homepage.

Acceptance Testing Driven-Development (ATDD)

Acceptance Testing Driven-Development is a development methodology that helps to communicate by all people involved in the product development: customers, developers, UX/UI designers, QA specialists etc. Thanks to that the team gets well-designed requirements that everybody knows and that helps to be on the same page. Every team member helps to define acceptance criteria. With this approach acceptance tests are written before developers write a single line of code.
 
Thanks to Agile methodology and its testing approach, the early detection of bugs is easier and can be performed much faster than in the traditional approach like Waterfall. Moreover, the whole team has in mind that it is quality-oriented and the power of three (developer, software tester and business representatives) works on the same feature discussing, asking questions and trying to think about the project not only from their point of view. Agile is about people and communication and it helps us to avoid any communication problems that may occur in a different approach.