Skip to main content

Agile Testing

Agile testing is a software testing practice that follows the principles of agile software development.

What is agile testing methodology?

Agile testing is a ‘testing methodology’, that follows principles of Agile software development.This methodology promotes continuous increments and iteration in both, development and testing, throughout the software development life cycle of the project.

In simple terms, in this methodology the software to be tested( or developed ) is split into small modules.

  • Each module is treated as a small software project. That means, each module has the requirements analysis, design, implementation and testing phases.
  • These modules are prioritized. Based on priorities each module is taken up for completion.
  • Prioritization is done by the customer. Hence, most important functionalities  given high priority.
  • Customer can change the priority queue as and when he wants.
  • Each module is delivered to the customer in ‘ready-to-use’ state.
  • Again next module in the priority queue is taken up for developing and testing.
  • The process will continue till the complete system is achieved.

As module period is 1 to 4 weeks time. As a result the Customer satisfaction is achieved by rapid delivery of useful software.

You will learn more about modules in the lesson- module.  As the definition of the first term might be used in the 5th term, reading of lessons in sequence is recommended.

Agile testing terminology

Agile methodology has its own terminology. For example:- the daily meetings are called as ‘Scrum meetings’ and there is no team lead but there is a ‘Scrum master’.

Its always recommended and professional for any test engineer when moving into ‘Agile testing’ methodology project to learn and understand what these words are and understand them.

Here we are referring to those words as ‘Agile testing terminology’. This is a list of the words that are used when we are testing a project in ‘Agile testing methodology’. I have tried my best to cover all the the terms.  This list will be always a live one. I will keep appending and adding new terms that I come across during my testing and I will also keep adding more examples to make definitions easily understandable. But, I am open for comments and suggestions. If you find any term missing you are welcome to comment.
Stake holders

Agile testing

teamwork

    • Agile testing is the testing methodology that follows principles of Agile software development.

  • This methodology promotes continuous iteration of both development and testing throughout the software development life cycle of the project.

Stake holders

  • Actual meaning of Stake holders is: All the people who potentially get affected with the development of the product. E.g.:- product funder, managers, developers, testers, users etc.
  • But here in agile process, Stake holder is a company or a person who funds the project
  • If we are developing our own product to sell, then end users, who buy our product, is a customer and is the stake holder.
  • If a company or a person has hired us to develop a product for them, then the stake holder is this company or the person who is funding the development of the product.
  • Basically, Stake holder =customer=client

Sprint

sprint

  • Sprint is the term for iteration.
  • A sprint is a period when the dev and testing team works together to produce the next increment of the finished product.
  • Each new feature when delivered to the customer it is in ready to use state.
  • Each sprint normally is of 1 to 4 weeks.
  • The time period of the Sprint is discussed and decided by the team.
  • Once this Sprint duration is decided it should not be changed.
  • Each sprint should build a potentially shippable product increment.

Iteration

iteration

Iteration is a period, when the development and testing team works together to produce the next increment of the finished product

Scrum

teamwork

  • Scrum is the most widely used agile development
  • The main focus of this methodology is to manage the tasks within a team in the product development environment.
  • Here the size of the team is below 10 members. Normally the team size is 3 to 9.
  • In Scrum whenever we are referring to team it is dev and testing together.
  • Sometimes there may not be a separate testing team as such, and then the development team becomes cross functional doing analysis, design, develop, test, technical communication, document, etc. by themselves. It is comprised of short iterations, called sprints.

Scrum master

  • The Scrum master is not a Team Lead or a Project Lead but his role is that of a Team facilitator.
  • Scrum master is responsible for smooth sailing of the project.
  • He sets up team meetings and mainly removes obstacles that hinder the team in progressing towards its goal which is delivering the quality product on time.

Stand up / Daily Meeting/Scrum meetings

scrumeetings

The Stand-up meeting is one of the most important activities in Agile based approach. These are short and precise meetings where the teams along with the scrum master sits for a 15 – 30 minute period to discuss the daily

Frame work

A software framework is a universal, reusable software environment that provides particular functionality as part of a larger software platform to facilitate development of software applications, products and solutions. (Definition taken from internet)

It’s something like music melodies, where you have notes and you can replace any words in that melodies to make songs. E.g. “Do re me fa so la” is an example of a frame work which can be replaced by words by any user in his own language.

Scrum Product Backlog

Product-Backlog

 

  • In Agile methodology the requirements are prioritized, based on the importance of the feature to be delivered and added to a STACK.
  • This STACK is known as PRODUCT BACKLOG
  • This prioritization, re-prioritization of the requirements (existing and new) is done by the project stake holders (product owner).
  • The highest priority requirements are implemented first by developing and tested accordingly.
  • Product Backlog consists of prioritized stacked features, requirements,bug fixes.
  • As and when new requirements come, they are prioritized too and added to the stack in the appropriate place.
  • The work to be done for a SPRINT is taken from Product Backlogs.
  • The Features are expressed in the form of user stories- short, simple descriptions of the functionality from users perspective.
  • Coming to bug fixes and a new feature are also described similar to features
  • Scrum Product backlog grows and changes with the development of the product based on the product, its end users or its customers.
  • The end product of each Sprint (when delivered to the stake holder) should be potentially shippable
  • The next Sprint begins when the team chooses another chunk of the product backlog and starts working on it.
  • The cycle repeats until all the items in the product backlog have been completed and the product is completely ready.
  • The prioritization is done based on the importance of the features. The Scrum frame work ensures that the most valuable work has been completed in the early stages itself.

User Stories

Usually, Software requirements are specified in the business perspective rather than the software or user perspective.

But User stories are the descriptions of a software feature or functionality from an end-user perspective.

User stories are actually like stories, as if a person is telling you what he wants. They are narrative texts which describe the interaction between a user and the system and what the output the user expects from the system with that action/command.
Agile methodology does not insist on fully documented requirement adhering to the rules. But here the documentation is only secondary.
The template has 3 parts:
  1. Title:-The title is only a name of the user story or short references to the user story and it will be about 3 to 10 words.
  2. Description:- We can say the Description is the body of the user story.
  3. Acceptance criteria:- The end behavior of the functionality or the system being developed is described here

Difference between Product-Backlog and Sprint-Backlog

Product Backlog

1. The Product Backlog is a prioritized list of all the features, functionalities, bug fixes etc. that are needed in the final product of the project.

2.   In the beginning of the project the customer describes the final product in simple, non-technical language.

3. The Product Backlog is never frozen. It can be changed when ever the stake holder wishes. The modules can be added and also re-organized. All the requirements, change requests in the project are also included in it in it.

4. There is only one Product Backlog for the entire Project

5. The product owner is the owner of the Product Backlog. He is the only responsible person to add, prioritize, re-prioritize, maintain modules/items.

6. The Product Backlog consists many Sprints. Each Sprint in-turn has Sprint Backlogs. Each Sprint Backlog will have many User Stories. Each User Story is divided into tasks. And the tasks are estimated in hours

7. Product Backlog is based on the discussion among all the owner, stakeholder.

 

 

Sprint Backlog

1.The sprint backlog is a list of user stories, and identified tasks to be completed during the sprint. Sometimes the bug fixes are also included in to the Sprint Backlog. These are taken by the Scrum team from the Product Backlog based on their priority.

2.A Sprint Backlog is created in the Planning phase of every Sprint. These are also described in simple, non-technical language

3.The user stories in the Sprint Backlog cannot be added or removed during the Sprint. Once the Sprint Planning is done they are frozen. This is delivered as a fully complete increment.

4.For every planned Sprint there is a Sprint backlog

5.The Sprint Backlog is property of the Development and Testing Tea

6.Tasks of the Sprint Backlog are estimated in Hours

7. Sprint Backlog is dependent totally on Product Backlog

Real Examples:-Ramayana is an example of EPIC. And its chapters are all user stories.

We can even take ‘Harry Potter’ as an example of epic and

‘Chapter 1: The Boy Who Lived’ is one of the User stories.

Epic in Agile Methodology

In Agile methodology an Epic  comprises of 5-10 user stories. Hence, it can not be completed in a weeks time. It might take a full sprint to complete. In simple words we can call an epic as a BIG USER STORY which had to be sliced into many smaller user stories so they can fit into a sprint.

Example:-

Epic:-User should be able to EDIT a word document

User stories1:

Priority:2

User should be able to DELETE text

—————————————————

User stories2:

Priority:1

User should be able to Add text

———————————————

User stories3:

Priority:3

User should be able to COPY and PASTE text

Fail-fast

Say you are going on a vacation by your car and there was a ‘y’ junction where you had to go ‘straight’. You went ‘straight'(left). After traveling for 30 miles you realize that you have taken wrong road. You should have taken ‘Straight-right’. Oh!

If only you would have checked if it was ‘straight-left’ or ‘straight-right’ before taking the diversion…or…at least after 10 miles…or at least after 15miles :(

Yes, its better to fail-fast if we are going in the wrong path rather than wait till the wrong end product is ready.

Start working on the project, pause to verify and take an early feedback at certain intervals. Go ahead if you are doing good, else FAIL FAST if its totally wrong direction. This way we are stopping the project when its going in the wrong path. Hence, saving economically and time

What happens in Scrum Frame work

teamwork

  • A Product backlog is a prioritized wish list created by the Product owner or the customer or Stake Holder.
  • Product Backlog consists of prioritized stacked
    • features
    • requirements
    • bug fixes.

A Scrum team and its product owner begin by writing down everything they can think of for agile backlog prioritization

This Scrum product backlog grows and changes with the development of the product based on the product, its end users or its customers.

  • During sprint planning, The team pulls a small chunk from the top of the sprint backlog, and decides how to implement those pieces.
  • The team in the Sprint time (usually two to four weeks) completes its work
  • The Scrum Master keeps the team focused on its goal.
  • Daily Scrum meetings are held to assess Sprint progress.
  • The end product of each Sprint (when delivered to the stake holder) should be potentially shippable
  • The next Sprint begins when the team chooses another chunk of the product backlog and starts working on it.
  • The cycle repeats until all the items in the product backlog have been completed and the product is completely ready.
  • The prioritization is done based on the importance of the features. The Scrum frame work ensures that the most valuable work has been completed in the early stages itself.

Sprint Backlog

The sprint backlog is a list of user stories, and identified tasks to be completed during the sprint. Sometimes the bug fixes are also included in to the Sprint Backlog. These are taken by the Scrum team from the Product Backlog based on their priority.

2.A Sprint Backlog is created in the Planning phase of every Sprint. These are also described in simple, non-technical language

3.The user stories in the Sprint Backlog cannot be added or removed during the Sprint. Once the Sprint Planning is done they are frozen. This is delivered as a fully complete increment.

4.For every planned Sprint there is a Sprint backlog

5.The Sprint Backlog is property of the Development and Testing Tea

6.Tasks of the Sprint Backlog are estimated in Hours

7. Sprint Backlog is dependent totally on Product Backlog

Related Agile testing Articles
How testing fits in agile environment

Common challenges experienced by manual testers in agile teams