3Cs drive agile development. They are collaboration, coordination, and communication. Agile is an ideal example of close teamwork to generate exceptional value for the customer.
Nothing significant occurs in agile without these 3Cs, including test planning and automation.
Agile is also customer-centric. Deliverables are defined as distinct features and functions that the end customer sees value in, instead of counting an abstract technical artifact or a piece of code as a deliverable.
A story or user story helps understand agile and its associated processes in this context. This blog will explain user stories and how they tie into testing. Further, we’ll explore how a base story helps estimate test automation efforts and how those estimates can be validated.
What is a User Story?
A user story is a plain-English explanation of what a customer expects from a software deliverable or feature. The story outlines what to develop, what value it adds, and what to test. It is usually recorded in plain language so that all stakeholders, even non-technical personnel, can understand the end objectives. With agile stories, teams can focus on what matters most – the customer.
A story comprises another set of Cs–card, conversation, and confirmation.
· The card describes in a few lines the end-user role, what actions are to be performed, and why these actions are necessary. User stories often point to flow diagrams, calculations, and logic to clarify the design aspects that will meet the objective on the card.
· A conversation is a meeting between all the relevant stakeholders to discuss, among other things, how to build the right solution to deliver the objective on the card. It also includes the definition of done, i.e., how to confirm if the feature can deliver value to the end-user.
· Finally, confirmation is the acceptance test that validates whether the story meets its intended purpose based on the previous definition of done.
How do Stories tie into Testing?
Testers, especially senior testers and test analysts, are part of the story conversations that we discussed earlier. They use these 3Cs – cards, conversation, and confirmation – to understand the solution and write the test requirements and design early in the sprint.
Since agile is a collaboration and communication-intensive process, testers can refine these tests as each sprint progresses.
How to Estimate the Testing Effort? What is a Base Story?
To understand the estimation processes in agile, you need to identify base stories. Base stories provide clarity and streamline development efforts to deliver maximum value to the customer. A minimum of two base stories are chosen, but a few are the norm.
What do base stories do in Agile? They are closely related to user stories. Simply put, base stories form the basic measuring units used to estimate the efforts related to other user stories.
Even though it is an approximate measurement, it is a subjective approach that works well. Another point to keep in mind is that this is a collaborative task, i.e., all the team members need to work closely together to identify the base story and related measurements.
For instance, after brainstorming with the team, you concluded that the story being discussed takes twice the testing effort compared to the base story. So, the new user story will require 20 hours of testing. Some user stories that may be less complex will require lesser effort to test.
Also, break up the estimates by the test types—unit, integration, system tests, etc. Not all tests run on a story can be automated. The testing estimates should be done separately for each type of test. In this way, the automation tests are easy to identify and estimate effort-wise.
For automation testing, choose base stories that were validated using automated tests. So, your estimation effort will be easier and simpler to manage.
Validating the Estimates
Predictably, there may be a variation in the estimates. Say 4 testers were involved in estimating the testing effort for a story. Tester 1 estimated 12 hours, Tester 2 said 9 hours, Tester 3 arrived at 10 hours, and Tester 4 about 7 hours.
One approach is to take the nearest two estimates. In this example, estimates of Testers 2 and 3 are close to each other. Since it’s better to take the higher estimate for any contingencies (leave, attrition, etc.), you can take the final estimate as 10 hours.
The other approach is to calculate the average of all the presented estimates. It’s always a good idea to add extra time to make up for unwarranted issues down the line.
The base stories approach is the most common estimation method for development and testing efforts in Agile.
Agile adoption around the world is at an all-time high, with over 92% of organizations using agile methodology up to some extent. And test automation forms the backbone of agile. A no-code test automation solution like Avo Assure can provide critical testing support to agile and DevOps workflows in organizations. Avo Assure possesses robust features such as intuitive, visualized reporting, parallel testing, cross-platform testing, record and playback options, test history management, and pre-built keyword libraries. It even helped a leading US-based financial institution achieve 100% test automation and deliver their updated loan management platform 2x faster.
If you are looking for a test automation solution to support your agile efforts, then book a demo with us today.
