In this session we are going to cover agile requirements gathering, their importance in developing quality software, and how you as a QA engineer can make an impact.
Follow the Agile journey for Success
Our XBOTalk 7 part series we will address AGILE and the Key Solutions to the most common Software Development Pain Points related to Software Quality. By the end of this 7-part series you’ll understand:
✅ Agile Requirements Gathering
✅ Agile Sizing (Epic / Story / Task)
✅ Testing Manual vs. Automation
What makes a good candidate for automation?
✅ Test Asset Management (highlighting Jira Plug In)
Organization in to groups
✅ Automation Script writing
✅ What is a quality gate, and how to use
The art of defining clear agile requirements.
First, let’s discuss the problem in that there are many challenges of converting a business concept to a viable software product. This can only occur through defining clear requirements. One most common pain points voiced within the software community is the frustration caused by requirements which are not fully defined, or are modified as the development process progresses.
Agile requirements gathering
An Agile requirement gathering starts vague and is refined and becomes more as it progresses from concept, to Epic, to Story, to Task. One of the weaknesses of Waterfall is that the majority of the work to refine the requirements is done during the design stage, and adjustments needed later in the cycle are expensive and create development delays. Our discussion will focus on the Agile process of refining requirements through iterations.
Quality needs to be built into the requirement development process from conception through delivery. One of the key considerations when constructing a requirement is how it will be tested. If the requirement covers new functionality for an existing application, dependencies need to be identified to be placed in testing tasks.
Illustration of Agile requirements gathering
To understand how to take a requirement from concept to delivering a usable product that meets a user’s needs, we’ll use the analogy of building a house.
Using that analogy, there are potentially seven groups involved in creating, implementing, testing, and deploying a requirement, prior to it being put into production. Let’s talk about the role of each group:
#End users – (Homeowners)
The group who uses the product once it is in production, the expert on whether the product is what they need, and able to contribute valuable feedback on improvements.
End users provide exploratory testing. As they use the product, they report functionality that does not work as they expect it to work or suggest improvements after they have used the product. They test the product from the perspective of how they want to use it.
#Client – (Real-estate developer)
This group pulls the vision together to offer the product to the end users.
Clients provide user acceptance testing. This group of users understands how the product should work, test with this understanding in mind, and test with predetermined standards, which ties back to the agile requirements gathering.
#Business Analysts – (Realtor)
They act as the liaison between the client, and potentially the end users, to move from concept to requirements. This group is the first line of defense on clear agile requirements gathering, and they need to ask specific questions:
Who will be using the product?
What does the final product look like?
Are there any risks which need to be mitigated?
Are there any dependencies?
Business analysts test the requirement from a perspective of how they interpreted the requirement should work, build tests as the requirement is being finalized to test their understanding.
#Software Engineer – (Construction Crew)
Pulls the product together into a cohesive deliverable, and builds the complete product. In terms of the house analogy, think of the components which go into creating a house such as foundation, frame, infrastructure, internal and external walls, windows, doors, and roof.
The software engineer will build unit tests to prove that they are building to the requirements specified for each component.
Tests the build for compliance to requirements, verifies the dependencies, product works as expected, verifies messages, visual and performance aspects of build are acceptable to client and end users. Using the house analogy, think of verification of hurricane straps to attach the roof to the foundation, the plumbing is attached to the input and output, the electricity works as expected, all light switches and electrical outlets are live.
Let’s turn our focus to how to identify a well-formed requirement in agile.
Comparing the good and the bad of agile requirements gathering
The most common complaint about agile requirements gathering is that requirements are changed, that they are not specific enough, or are open to interpretation. Let’s work through examples to show the difference between a well-defined set of requirements and requirements which will lead to confusion. Continuing with the house example let’s look at 3 sets of requirements, then examine what is good or bad about each set:
#Requirement gathering set one:
Need a two-story house, with 3 bedrooms, 2 bathrooms
Analysis: Wide open to interpretation, end-users could be envisioning one style of house, and the team builds their very interpretation of the requirement. In Agile terms, this could be the back of the napkin level of requirements definition.
#Requirement set two:
Two-story brick house
One Master Bedroom, with ensuite bathroom, and walk in closet
Two standard Bedrooms with a bathroom between
Stairs from center of the house to second floor
Analysis: In this set of requirements, there is more guidance, but it’s still very open to interpretation. In this case the team can still choose the style of the house, and there is no definition about the layout of the first floor, window requirements, or clear vision of the final product. In Agile requirements gathering terms this may be the level the team gets to during a quarterly planning session.
#Requirement set three:
Two story brick house, built in a traditional style
Five windows in the front wall
Solid front door painted blue
Six step stoop to front door
5 rooms – Living room, Dining room, ½ Bathroom, Kitchen, Study
Stairs from first floor to second floor
Hallway connecting rooms, and landing for the stairs
Walk in closet
Two standard bedrooms
Full bathroom, connecting the standard bedrooms
Drop down stars from attic to hall
Analysis: The basic structure of the house is well specified, the team can start on the project, the details for each room will be specified as the project progresses through the agile retrospective and planning ceremonies. One of the keys to successful requirements is to understand how much detail the requirements need for the team to start a project, and how to add details and stories during the planning sessions.
Key to solid agile requirements gathering
The key to solid requirements is asking for the correct level of detail. Once the initial requirements are specified, the team needs to evaluate them for completeness, identify dependencies, and a delivery order. Most organizations want to deliver a minimum viable product first, which means prioritizing delivery according to user wants and needs. A strong requirement has clear acceptance criteria. Acceptance criteria is used to build test cases. And both need to answer at least one of the Why, What, When, How questions:
Why are we working on this project?
What do we hope to accomplish by completing this project (sprint/build)?
What do we need to accomplish in terms of resources, software, or hardware?
What are the dependencies?
What are the risks?
What is the logical order for the requirements?
When does the project (sprint/build) need to be delivered?
When will the resources be available?
How will the project (sprint/build) be approached in terms of Epics, Stories, and Tasks?
Agile requirements from a Software testing point of view
From a software testing point of view, testing in Agile needs to start early in the requirements phase by determining if the requirements are testable. QA engineers typically review requirements examining for clarity and completeness, and also give feedback to product managers for requirements that don’t meet these criteria. With clear, complete, and accurate requirements, QA engineers are then able to test criteria for pass/fail that help developers understand the “Definition of Done” for the requirement.
The problem is that in order to do review and provide feedback on requirements requires more than just button pushing of an existing system. Rather, QA engineers have to think from an end-user point of view on what would be acceptable to the user in executing or using the particular function being developed. This requires thinking outside the normal ‘tester’ box, along with domain knowledge of the application.
You Discover the features and functions of loan applications that are important to loan application software testing….
BY JIMMY FLORENT
XBOSOFT manages it all
Now you know one of the key advantages of XBOSoft. We’re not just software testers pushing buttons. We are domain experts in various disciplines with accumulated knowledge that you can take advantage of in thoroughly testing your software from start (agile requirements gathering) to final delivery to your end users. Please reach out to XBOSoft with questions or to request support from our talented team of experts.
In the next XBOTalk episode, we will explore Agile Sizing, where you’ll learn how to identify Agile Epics, Stories, Tasks, and Spikes, using an Agile Sizing approach.
XBOSoft offers a unique blend of agile testing expertise for companies that are either currently in waterfall and converting their development methodologies to Agile, as well as those with various hybrid and popular Agile testing methodologies such as Scrum and Kanban.
You want 100% automation, right? Discover why you might think wrong. Deciding between manual testing vs. automation testing can seem like a cornelian dilemma. At least, that’s how it transpires when dealing with many of our clients.