The Lifecycle of Agile Testing

Over these years we have moved our approach of development from the Waterfall model to the Agile Methodology. The Agile model provides an iterative and incremental building approach for software development that helps teams deliver value to the customer faster and provide scope for quicker changes to the software rather than building the software once for all and delivering it to the customer with less scope and adaptability towards change. The testing practice followed in the agile methodology is known as Agile Testing. Agile testing starts at the start of the project and includes a continuous testing approach all throughout the iterations until the delivery to the end customer, unlike the Waterfall model where it is a phase.

To get access to all the newly posted articles

Subscribe Now!

Please select "I agree to get email updates" option.

Get Widget

In this article, I will be referring more towards the lifecycle of testing involved into Agile. Please Note the article would be inferencing words from the agile world. Since I may not be defining them here, hence an explanation of those have been provided via source links.

When to Begin?

As part of an agile team, before kickstart of any testing activities, it’s important to understand the release plan and planned user stories across the sprints in a release. A storyteller[a document enlisting the features or modules to be implemented in the upcoming releases] will be provided by the product owner which would be compiled into multiple epics and users stories. All user stories are distributed among sprints based on their priority, business needs and team capacity by the product owner. Post awareness on the release plan and features, the first building block of testing activity starts with a test plan.

Test Plan:

A test plan is created for each release and needs to be updated post every release. The main purpose of creating the test plan before the start of a release is to outline the scope, test approach, entry and exit criteria for the release. The exit criteria become the acceptance criteria for the release to be pushed to UAT and approved by the product owner.
For details on how to create a test plan, please refer my article Test Plan

Sprint Planning

The next phase of testing activity starts in sprint planning. The team sits together to discuss the efforts involved across the planned user stories in a sprint and any dependencies involved in terms of development or testing. The team coordinate together to achieve the required velocity of the sprint. Efforts across a user story are defined via story points, which are the efforts involved in both development and testing. Therefore during sprint planning estimation across user stories for the testing efforts are provided. On how to perform test estimation please refer my article Test Estimation[The article emphasizes test estimation to be done across modules, the same can be extended across user stories.]. Please note story points across user stories always follow Fibonacci series[1,2,3,5,8]

Post sprint planning, work allocation across the sprint is designed, wherein the testers involved in the project are assigned user stories in the sprint for test case creation and execution

Implementation and Execution

The next testing activity involved in agile is the creation of test cases across the assigned user stories. Post creation of user stories, peer review is performed. This activity provides a two-way value wherein the other QA gets awareness across the feature(user story) and helps to provide inputs for better test coverage. All test cases created in the test management tool must be linked across the stories. This helps to ensure all stories have the required test cases across them. For a better quality of deliverables, developers can view the test cases across the story and ensure on an overview that the code handles the scenarios enlisted, This helps to ensure a smaller cycle and lesser bugs across the story. Basically a quick delivery. Please note, as a good plan rule, all test cases should be created when the stories are under development. Once the stories are ready for testing, only execution across the story should be the left out task. This helps speed up the agile process. Creating test cases post the stories are ready for testing, just adds on the time for the closure of the story.
Post creation of test cases, once stories are ready for testing, the test cases created should be executed across it. Another good practice while execution is to ensure, the assigned tester who created the test cases should not be executing them. The reason behind it is, the person would just execute the test cases and won’t explore the further area via Ad-hoc testing. Since as per him all test cases across the features have been written and he could not think more out of it. But a person who is executing the test cases may come across more pointers and may perform ad-hoc testing also. In an agile environment, ad-hoc testing plays an important role due to the shrinking testing cycles available. During execution, all testing types should be implemented be it functional, UI, usability, cross-browser etc. You can refer to my article on how to ace your execution skills for it.
All bugs encountered across stories should be logged in the bug management tool and linked with user stories as well as test cases. A triage meeting is conducted to propose a plan for the bugs logged and their fix. Post the bugs are fixed, they are retested across the stories and closed

Sprint closure activities

Once all the bugs linked to the stories and test cases are retested and closed, the user stories are also closed and are made ready for the product owner to be accepted. A sprint review is performed demonstrating the deliverables of the sprint. If any story within a sprint does not gets closed due to outstanding bugs or development work pending, those get overflow to the next sprint. It is vital to understand a story is considered a deliverable only post testing activities are closed and not just with mere development work completion. A defect analysis report will be created post every sprint. On details on how to create one, please refer my article Defect Analysis Report. This report can also be created once post the release rather than across each sprint end. A sprint retrospective meeting would be conducted to discuss what went good, bad and what should be done to ensure better productivity of the next sprint.

Regression

Post all sprints closure in a release, regression testing will be performed. A regression suite would be created from the test cases of the features planned in the release along with the impacted test cases of the previous releases. The regression suite would be approved by the product owner. Based on the approval, a regression estimate would be prepared before kick-starting regression that would outline the time required to complete off regression.
Daily status emails would be shared with the stakeholders highlighting the execution status and the number of bugs encountered. Depending upon the number of bugs and complexity of business involved, the regression may be divided into multiple cycles. Retesting across the bugs would also be performed in those cycles. Post regression completion a sign-off report would be created and shared with the stakeholders. If required a cumulative defect analysis report for all sprints will be also shared along with it.

Release activities

Post a release closure, the build is deployed to the UAT environment and is made ready for few users to perform user acceptance testing. After deploying the release to UAT, a smoke is performed by the alpha testers and post smoke success, the release is given to the beta testers who test the build before signing off from there end to be shipped to production. Around a  week time may be provided for beta testers to complete off testing. Once testing is completed, the build is been deployed to production and is made ready for end users to be tested after performing a round of smoke by the alpha testers. Any bugs encountered during UAT or production release would be logged and provided quick fixes if possible or a point release would be planned for the issues raised.
During this time other members of the testing team would be performing root cause analysis across the bugs raised in UAT or production.
 

Getting Ready for the next release

Post completion of the release, the team would prepare themselves for the next release, which would involve going through the storytellers encapsulating the features planned up for the release. Any business clarifications or issues would be raised and cleared during this phase.
The below image highlights the testing cycle and deliverables followed in the agile environment:
The lifecycle of Testing in Agile
Closing the article with the below quotes, showcasing the agile practice:
 
“Learn from yesterday, live for today, hope for tomorrow. The important thing is not to stop questioning.”– Albert Einstein
 
As agile organizations, teams and team members, we must constantly question what could be better in order to continually improve.
Author: Sadhvi Singh
 



  •  
  •  
  •  
  •  
  •  

21 Thoughts to “The Lifecycle of Agile Testing”

  1. realistic and simple agile explanation.Thanks!

  2. Thanks for jolting it down all at one place ….

  3. Superb job….?

    What is UserStory here? Can someone explain

  4. Thanks
    Userstory are small functional units which together makes up an epic(parent story). For example, lets say their is a functionality as user should be able to login to the application. This would becomes an epic, corresponding user stories to this would be user should be able to login via facebook, user should be able to login via login form etc. So small functional units that are deliverable and actionable item from end user perspective becomes user stories.Anything which is not a deliverable task from an end user perspective is not a user story.

  5. Post creation of user stories.
    Madam can you explain a little bit on this..
    Article is really good and helpful .

  6. I did not understood your question. Could you please elaborate it?

  7. @Unknown: Post creation of User Stories, They are been placed in Product backlog by product owner. PO owns the work to create the User Stories based on the funneling technique. Inputs to PO is given by Stake holders, BA's, Competitors Analysis based on Good to have features.

    Hope this makes more informative to you. IF you are looking for any other case – Do explain your point. So that we can revert and provide more insights.

  8. Agile explained so beautifully… nice article. Agile is indeed gaining widespread popularity across the globe. Agile’s focus on continuous testing has given rise to the need for test automation and today we have new age test automation tools like QARA Test that has made software testing simpler and more efficient than ever before. Click to explore the tool: https://www.qaratest.com/

  9. @Sadhvi Singh: what is the main difference/gain in what you have described in this article with a waterfall implementaton ? I might have missed it, but for me this sounded like a mini-waterfall within an agile sprint. When one does code and the other does testing … for me it's at most hybrid method and not Agile.
    Appreciate if you can clarify in case I got it wrong.
    Tks

  10. thanks for the explanation. Just to add a more simplistic view, post user creation, as mentioned above, they go to the backlog where those are planned on sprint basis and priority basis to the business by the product owner. Once done, they are labelled into different release and sprints and sprint planning gets kicked off.Let me know if this suffice to your query?

  11. @Rosangela Fritscher Santos Apologies for the delayed revert.Thanks for this constructive query.
    So I have been into this waterfall model for close to 2 years.Before I answer how different does it sound from waterfall model and the gain we get from it, I just want to talk about something related to agile. So lately I attended an amazing agile session.So when we say agile, what does it mean? Does it mean following a set standard process laid down by agile like waterfall model? the answer is no, agile in itself means the agility to imbibe any process one needs for its software development methodology. The only requirements it talks about to be agile-scrum owned is:
    -> "Iterative incremental approach", if one is following that it means its following agile methodology.
    ->Secondly and importantly, to be scrum owned if we follow processes like sprint planning, sprint review, sprint retrospective, poker planning.We are in true sense scrum owned. Those are the essentials of agile-scrum.
    When I say what difference we withhold from waterfall model are the presence of numerous activities mentioned above which are not carried in waterfall model.From a testing perspective, in case of waterfall model, we get involved in testing at a very later stage and the end result is deliverable in one go to the end customer. In agile we are working in terms of iteration with testing going in parallel right from the requirement analysis stage.In waterfall model we work majorly as independent teams towards the delivery of the whole project but in agile we all work in unison as a team for each sprint and release.Each smaller unit is rigorously tested across releases and delivered.
    I hope it answers the major difference between the two methodology and how different it sounds from waterfall method.

  12. Sujatha Sadhasivam

    Hi Sadhvi,

    I am in to business testing no IT or development involved. Can you suggest how to setup Agile for this ?

  13. Regnum Digital Alliance is a Digital Marketing Agency that offer SEO services, SMM services,QA testing, social media marketing,Google Adword and PPC management.

  14. what is fantastic post? this is so chock full of useful information I cannot wait to dig deep and start utilizing the resource give me.your exuberance is refreshing.
    Portal Development
    Travel portal development
    Travel white label
    Travel Portal Solution
    B2C Travel Portal
    B2B Travel Portal
    Flight Booking API System
    Flight api integration

Leave a Comment