Introduction

Being agile means having the ability to adapt to the ways your team or organization work, and to make constant improvements. Agile is a set of values and principles. Agile will not explicitly tell you what to do, instead these values and principles helps you and your team to decide what you should do. Agile Process is being rapidly adopted in the software industry to improve their efficiency. In this article, we will see how to perform Testing using Agile Methodology.

Manifesto for Agile Software Development

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

That is, while there is value in the items on the right, we value the items on the left more.

There are several ways, teams can use to follow these values and principles. One of those methodologies is SCRUM.

Scrum

Scrum is an Agile framework within which people can address complex adaptive problems, while productively and creatively delivering products of the highest possible value. Scrum is a simple framework that facilitates effective collaboration of team on complex products.

Roles in Scrum:

There are mainly 3 roles in a Scrum Team.

• Product Owner: Product owner’s responsibility is to give directions to the team and help them build the best product possible. Agile product owner can be considered as the decision maker who knows the market and the customer, so that he can make the right decisions regarding the product
• Scrum Master   : A scrum master is the facilitator for an agile development team.The Scrum master helps the team in removing obstacles if any, and helps the team to stay focused to reach their goal .
• The Team: A cross functional team of developers, testers etc. who are self-organising and help each other for completing the sprint successfully.

Scrum Events:

• Sprint: A sprint is a set period when a scrum team works to complete/ready for review a set amount of work. Sprints are at the very heart of scrum and agile methodologies. The duration of a sprint is determined by the scrum master, the team’s facilitator, and manager of the Scrum framework.
• Sprint Planning: The work to be performed in a sprint is planned in sprint planning. This plan is created by the collaborative work of the entire Scrum Team.
• Daily Scrum: Daily scrum is a 15-minute meeting for the team to synchronise activities and let the team know if they are held up in any work.
• Sprint Review: Sprint review is held at the end of the sprint to inspect the work done in the sprint completed.
• Sprint Retrospective: In this, the team will retrospect on the sprint completed and plan for improvements that can be done in the upcoming sprints.

Scrum Artifacts:

• Product Backlog: Product Backlog is an ordered list of everything that is known to be needed in the product. It is the single source of requirements for any changes to be made to the product.
• Sprint Backlog: Sprint Backlog is the set of Product Backlog items selected for the Sprint, plus a plan for delivering the product Increment and realizing the Sprint Goal.
• Increment: Increment is the sum of all the Product Backlog items completed during a Sprint and the value of the increments of all previous Sprints.

User stories, Acceptance criteria and Definition of Done

In the software development industry, the word ‘Requirement’ defines what is our goal and what the customers exactly need and what will make the company to increase its business. The term ‘requirement’ has different names in different project methodologies. In Waterfall, it is referred to as ‘Requirement/Specification Document’, in Agile, it is referred to as ‘Epic’, ‘User Story’.

• User Story:

A user story is usually the simplest descriptions of possible requirements for any functionality or feature told from the perspective of the person who desires the new capability, usually a user or customer of the system. User stories provide an excellent way to define your product with clarity. Properly written user stories provide a solid basis for communication and collaboration — focusing on what matters most to the user.

User stories should be associated with pre-defined acceptance criteria.

• Acceptance criteria:

An acceptance criterion is a set of accepted conditions or business rules which the functionality or feature should satisfy and meet, to be accepted by the Product Owner/Stakeholders. Acceptance criteria is used to identify the boundaries of a user story and what needs to be done for the story to be considered complete. This could also include any tests that need to be done to verify a user story.

The User story defines the requirement for any functionality or feature while the Acceptance Criteria defines the ‘Definition of done’ for the user story or the requirement.

• Definition of Done:

A feature is either done or not done, a sprint is either done or not done. So, what does “done” mean? Definition of Done is a shared understanding of expectations that the increment must live up to in order to be releasable into production. It is a list of valued added activities to be completed that ensure a high level of quality.

• Use Case:

Consider a Test case as below:

As a signed-in user, he/she should be able to comment on a blog post, o that the user can get feedback on issues. Acceptance criteria in this case will be:

“User is in a role of signed-in user. When user opens the page with a specific blog post, then the system shows the “Comments” section below the blog post with the list of comments added by other user and the system shows the “Add a Comment” field in the top of the “Comments” section. When the user fills in the “Add a Comment” field with their comment and the user clicks the “Submit” button, then the system saves their comment. The system shows user’s comment in the top of the “Comments” section. The system shows user’s username and profile picture on the left side of their comment and the system shows “Remove” and “Edit” icons opposite their comment”.

Agile Testing

Testing the software, following the Agile principles of software development is called as Agile Testing. In Agile, testing is not a separate activity; the whole team (developers, testers etc.) work together to attain a high-quality software which satisfies all the specifications required. In an Agile project, Software Testers and other quality analysts are involved in planning and requirement analysis so that any flaws can be removed as early as possible. Automation is the key aspect of Agile Testing. If everything is to be done manually, it would be very difficult to keep up with the development plan. Testers along with the other members of their team will decide on which tests to be automated. At the end of each sprint, testers will run the test cases in development environment so that developers can fix them. Any defects found is fixed based on priority. Component/Unit testing is also done by the developers to find any early defects.

Testing is an important part of every phase of Agile software development and quality is constantly checked and assured by continuous feedback from the stakeholders. Agile as opposed to waterfall model, is a very flexible, adaptable and faster process of software development.

Agile Test Strategy

QA is an important part of Agile process. So, it is important to understand how test strategy is created in Scrum process.

If you’re an Agile tester, then start of each sprint begins with the question of what to do with the user stories. In Sprint planning, sprint backlog is created with the user stories picked up from the product backlog for implementation in that particular sprint.

In Sprint planning, the Testers should,

• Determine the testability of the user stories selected for the sprint
• Create acceptance tests
• Define test levels
• Identify test automation

Testers update the test plan with the estimates for testing effort and duration in the sprint. This ensures provision of time for required testing during the time-boxed sprints and accountability of the testing effort.

When a sprint begins, as the developers carry on story analysis for design and implementation, testers perform test analysis for the stories in the sprint backlog. The task of tester in this phase is to,

• Write test cases
• Unit tests are performed (By developers)
• Integration and Interface tests are performed (By developers)
• Functional testing of the new feature by testers,
• Execution of Tests by Engineers
• Automation of new functional test cases
• Perform non-functional tests.
• Regression tests are done to make sure other modules are not affected by the changes. This may not be necessary for every sprint; the frequency will be determined by the team depending on the project.
• Collaborate with the team to review the stories and test cases.

Testing of a feature is successful, only if the acceptance criteria defined is met for each user story. This is reviewed in Sprint review. Then the feature is released when the exit criteria is met and all necessary activities like Definition of Done, documentation of user guide are completed.

In Sprint retrospective, the improvements and changes that can be adopted in future sprints are discussed. For example, if the time given for testing was not enough in a given sprint, then it is important to let the team know of this in the retrospective. The team can then decide to increase the testing time from next sprint onward which will help finish testing of the feature on time and within the sprint.

Writing test cases using Acceptance Criteria

Acceptance criteria determine when a User Story works as planned and when developer can mark the User Story as ‘done’.  Because each Scrum team has its own Definition of Done to assess when a User Story has been completed, it is a good practice for testers to begin writing test cases from acceptance criteria. Many times, while writing test cases, a tester will come across a case that requires changes to be made to acceptance criteria, which can lead to requirement changes and greater quality.

Testing if the feature is incomplete at the end of a sprint

A sprint is considered complete when the QA activities are successfully completed for the user stories. Every sprint need not have a release. A release may take several sprints of work. The main criteria of a release is to deliver business value to the customer. The team decides on the sprint length with release planning as an input. So, it is possible that in a sprint, an incomplete feature may be the end result, which will be completed in future sprints. Now the question for testers is, how do you test an incomplete feature?

Testers will still have a role in this situation. Depending on what part of the feature is complete, testing can be done in different ways. Testers can test it at component and unit level. If the feature is incomplete at the end of sprint, testing cannot be done in end to end perspective. Testers can limit their testing to story or interface level. We can also do exploratory testing when the feature is not complete. During refinement, it is important to trigger the development team to know the breakdown of stories, so that the testers can plan what to test to prevent the issues coming up.

Also, Regression Testing is a very important aspect of the Agile testing process. We do not want any feature to affect the working of already existing functionalities. So, regression tests have to be performed every sprint to make sure the changes made in that sprint does not affect already existing functionalities of the product. Automated regression tests are run in continuous integration.

Agile Test Automation Strategy

Automation is a key part of Agile testing process. Below is the Automation Test Pyramid that is followed in Agile.

• Automated Unit Tests:

Test Automation starts at the unit level. Unit tests should be written by developers for any new feature that is developed. These Unit Tests form the foundation of a larger automation practice that spans all the way up to the System GUI Tests. It is the responsibility of the developers to ensure that for every new feature that is developed, a set of coherent and solid Unit Tests are written to prove that the code works as intended and meets the requirements.

• Automated Component, Integration/API Tests:

Component tests help in testing each component of a feature or product before doing integration testing. While Unit Tests are based on testing the functions within a class, Integration Tests form the next level up from Unit Tests to test the classes that collectively make up the component to deliver a piece of functionality. These tests are executed only when the Unit Tests have run and passed.

• Automated System level/ End to end Tests:

After unit, component and integration testing, System level testing of the software is done. Consider that the product is an online shopping website. Once the building of website is complete, it is important to test end-to-end functionalities of the website. This includes testing to make sure all user interfaces on the website work as expected, the website is able to fetch desired data from the database and most importantly the user information is encrypted and secure. End to end testing will also include API testing if the website accesses some third party applications. System level testing is where you test the product with the point of users. This is a very important step and will help analyze the usability of the product along with its functionalities.

Agile Testing methods

There are various agile testing methods. Some of them are,

• Behaviour Driven Development (BDD)

Behaviour Driven Development improves communication among project stake holders, so that all members correctly understand each feature before the development process starts. There is continuous example-based communication between the developers, testers, and business analysts. These examples are called scenarios which are written in a special format. The scenario holds information on how a given feature should behave in different situations with different input parameters. These are called executable specifications as it comprises of both specification and inputs to the automated tests.

• Acceptance Test Driven Development (ATDD)

It focuses on involving team members with different perspective such as the customer, developer, and tester. The three people’s meetings are held to formulate acceptance tests incorporating perspectives of the customer development and testing. So, the customer is focused on the problem that is to be solved. The development is focused on how the problem will be solved whereas the testing is focused on what could go wrong. The acceptance tests are representation of the user’s point of view and it describes how the system will function. It also helps to verify that the system’s function as it is supposed to. In some instances, acceptance tests are automated.

• Exploratory Testing

In this type of testing the test design and test execution phase go hand in hand. The exploratory testing emphases working software over comprehensive documentation. The individuals and interactions are more important than the process and tools. So, the customer collaboration holds greater value than the contract negotiation. Exploratory testing is more adaptable to changes as well. The testers identify the functionality of an application by exploring the application and try to learn the application and design and execute the test plans according to their findings. So, the process goes like these, first you learned then you design the tests and execute that particular tests and finally you analyze the test results.

Advantages of Agile Testing:

• This testing helps in saving a lot of Time and Money.

Unlike the conventional process, in Agile development and testing are performed simultaneously. In addition, critical problems could be found and solved in the initial stage ultimately, saving a lot of time in the development as well as testing phase. It is a test driven approach so the focus remains on producing an excellent well performing application. This will in turn save money to the client avoiding any problems to arise at the end or during product launch.

• Facilitates better communication between developers and testers.

Agile testing enables collaboration and consistent communication between the development and testing teams. As a result, complex issues are prevented or solved quickly.

• It is Flexible and highly Adaptable to changes.
• Consistent Sprints help fasten the Testing Process with great Results.

Consistent sprints mean consistent improvement. Each iteration follows a certain working code that allows the testers to work efficiently. The objective is to create user stories and identify bugs present in the codes so that they can be resolved and smooth performance of the application can be ensured.

• It provides a way for receiving a regular feedback from the end user.

Summary

Agile testing involves testing as early as possible in the software development life cycle. It demands high customer involvement and testing feature as soon as it becomes available. Extensive regression testing can be done to make sure that the bugs are fixed and tested. Importantly communication between the teams makes agile testing process a success.

Contact us at sales@brainbox.consulting for more information and we would be happy to assist you with testing related services.