• info@helpingtesters.com
  • helpingtesters

How to provide Agile Testing Estimates in Projects

August 1, 2017
Agile Testing, Agile meaning, scrum testing

Agile testing estimation is done in every iteration. At the start of each sprint, features are picked from the product backlog, groomed, estimated and added to the sprint backlog. But how are the estimates provided? How can the team members know which feature is complex than the other and would require more efforts and man-hours? In this post, we would talk about the agile testing estimation process and how team members evaluate the complexity of a task i.e. be a good agile tester.

How is Agile Testing Estimation Done

Testing in Agile is generally done early in the sprint. Before estimating any feature, the product backlog items are properly ordered on the basis of their priority and business needs.

  • Grooming the features – Features from the product backlog are properly groomed so that any ambiguity and uncertainty regarding the feature is removed. During this phase, developer and QA can contact the client and clear any doubts regarding the items. Once grooming is done, the team members are well aware of the feature and are able to evaluate the complexity and the amount of effort required to build and test the feature.
  • Sprint planning meeting – During the sprint planning meeting the actual estimates are provided. In this meeting developers and QA sit together and discuss the features that are to be delivered in the current sprint. During the grooming stage, features can even be assigned to a particular developer/ QA pair, so that they can take ownership of the item and follow up till it is demoed to the client. In the sprint planning meeting, every feature’s complexity is compared with a base story. A base story/ feature can be some pre-decided feature which takes 1 days work or 6 hours to build and test. The agile testing estimation is given in terms of story points as well.
  • Planning Poker – The estimated range is normally a Fibonacci series. That means a story’s or feature’s story point or complexity can be 1, 2, 3, 5, 8, 13, etc. The planning poker is an Agile estimation technique and is normally part of the sprint planning meeting. Once the sprint items are groomed, the base story has been decided, the owner of the feature or agile testing deliverable explains it to every other team member. Based on every team member’s understanding, everyone provided story point to the feature. Note, the story point provided must be part of a Fibonacci series and the story point is decided by comparing the feature with the base story. While providing estimates each team member selects a card with a Fibonacci number (from the series), from the planning poker deck and raises it. In this way, every team member decides complexity which is unbiased and based on the individual’s understanding of the project. Once every team member puts forward their estimated story point, the story point which is provided by the maximum number of team members is assigned to the feature. Every team member has the right to question the story point provided by any other member as well.

A similar process is followed for agile testing estimation as well. Such practice improves the business understanding among the team members and brings clarity about the agile testing complexity. It is suggested that estimation shouldn’t take up more than 10% of development or testing time. If any conflict arises during testing estimation, test lead or project manager can pitch in to resolve such issues.

Which Agile Testing Items are Estimated

All the agile testing activities that would be performed on the different features would be estimated. Some of the major points that should be considered while performing testing estimation for a particular feature/ story or task are:

  • Test Case/ Scenario writing – For proper agile testing estimation, you must take into account the time required to create test cases and scenarios. These scenarios have to be properly documented and shared with developers before they start development so that they can be aware of the edge cases and negative scenarios way ahead of development.
  • Pair testing – Pair testing is done when a dev and QA owner sit together to test a feature on the developer’s local machine. This is a primary check which ensures early defect detection and prevents tracking of defects into production or staging server. If such practice is not prevalent for your current Agile project, then you can neglect pair testing while giving the testing estimation.
  • Manual testing – Manual testing tends to take up the major chunk of time. So it is one of the major estimation criteria. It is generally performed on the staging server and is the most important parameter that decides the task’s complexity and effort required.
  • Creating automation scripts – Agile testing estimation for automation in agile should also be done, even if that it means doing it separately and not within the feature’s scope. Generally, automation scripts are prepared for features which were delivered and tested in the previous sprint. Estimation would take into consideration the flow complexity and the amount of coding and logic that needs to be added to the existing framework. Read to identify Is Automation worth in Agile.
  • Performance testing or other testing deliverables – If your project demands to perform various types of performance testing, they should be discussed in the sprint planning meeting. During estimation, you must take into account the number of users, volume of data and the resources required to accomplish it. Other than performance, other types of testing items like security, API, and database testing items can be discussed and estimated.
  • Ad-hoc testing tasks – There are numerous other items that testers devote their time to. During every sprint, few QA members are generally involved in deployments, refactoring automation and performance scripts, modifying test cases and scenarios after change requests. Apart from these core testing items, QA team members are also involved in various planning meetings and client calls. Such things should also be considered while providing the testing estimation.

Which items should be picked first for Agile testing?

After QA sprint planning meeting, the testing team gets the sprint items that need to be worked on. But the question arises, which item should be taken up first? Should we target the items which have higher complexity so that we can deliver the most complex items by the end of the sprint or take up the easily testable items so that most items can be tested early in the sprint? Well, the solution lies in effectively planning the approach for the sprint items

  • The first priority should be given to the creation of test cases and test scenarios of every sprint items. This will let the developers get a clear picture of the edge scenarios specific to each product.
  • Then as development commences, the QA team should focus on the creation of automation scripts which were delivered in the past sprint. While creating the scripts the priority would be provided to those scripts which have more business value and requires less effort to create.
  • Now as the development team finishes development the phase of pair testing would start. So to answer the question, which features would be picked first, the answer would be the ones which are delivered early by the developers. Yes, this does create a dependency on how swiftly developers develop the features, and as of now, there is no way to dodge this dependency.
  • Most QA teams spent half of their sprint creating test cases and writing automation scripts from the past sprints while the second half of the sprint is used to test the developed features and perform other forms of testing.
  • In worst cases if the feature delivery occurs at the end of the current sprint and QA is unable to test the items, then the sign-off is postponed and the untested features are marked under slipped items.

NOTE – Even if some items are pair tested but not verified on the staging server, they should be considered as slippages and not be part of the sprint sign-off items.

Conclusion

  • Testing estimation should be done after the feature has been groomed properly.
  • All team members should be present during the sprint planning meeting and the estimation of each item would be based on a pre-decided bases story.
  • Estimation is done using planning poker and each team member’s estimate is based on their own understanding.
  • Testing estimation is based on the different testing techniques and processes that are needed for the successful completion of the sprint items.

 

About the author

arindam bandyopadhyay author

Arindam Bandyopadhyay is an automation tester with over 5 years of experience in software testing. While during the day he juggles between Eclipse and spreadsheets, at night he lets his fingers do the talking as he writes about anything and everything his paradoxical mind desires.

Leave a Reply

Your email address will not be published.