Verification in Agile, Part 1
Verification in Agile, Part 1
It can be tough to decide what a product needs to be successful. Agile gives teams an improved way of defining product requirements via Sprints.
Join the DZone community and get the full member experience.Join For Free
Discover how you can take agile development to the next level with low-code.
Are we making the product right? Are we correctly building the solution? Failure to answer these questions positively throughout development can result in delivering a defective solution. Failure to verify the solution at each level of construction can result in costly, thrown-away work and backtracking to redesign, rewrite specifications, or redevelop solution components.
Yes, we verify each and every user story and the product is verified in chunks toward the solution's deployment. Agile teams do a little of everything, rather than doing all of one thing at a time.
Just as the approved vision and the scope report is the baseline for the solution, the approved Solution Design (SD) is the baseline for what is required of the solution to satisfy the business need. Through traceability to the business requirements in the Solution Design Document , the designers verify that each business requirement will be met through technical specifications.
Verification occurs when the solution is compared to the specifications to ensure that the solution is built according to those specifications.
The Validation Strategy:
The BA is accountable for leading and managing the validation strategy. Strategy Management includes a follow-up on defects found in the Solution Design Document and placing a check in the features which is driven towards User Story chunks to schedule revalidation when necessary. When the findings are significantly different than expected, the schedule may be affected, either positively or negatively.
Upon approval of the vision and scope report, the BA begins to develop the Solution Design Document and building the Epic, which is broken into User Stories with pieces of information hidden inside the Acceptance Criteria.
The strategy is driven by project and solution risk. The likelihood of defects are less in an agile mode of working.
The type of project is new to the organization: It is more likely that all requirements will not be identified or that they may be improperly defined. In Agile, we have the luxury of defining the requirements in chunks and thus taking as many Sprints as necessary to get the desired end product.
- A new category of users will be interfacing with the system: It is more difficult to predict the expectations and usability requirements of these users. However, in Agile, the probability of creating a bad UI/UX is lower, as the product is built in pieces and in layers. We as a tester, by placing a testing phase in the end users mode, can sort out the solution to an extent.
- There are a large number of requirements: More requirements mean more chances for miscommunication, inconsistencies, or misinterpretation. Agile helps to reduce these problems, as the requirements are broken into pieces to make life easy.
- Stakeholders are not confident in the information they provide: If operational management, business users, or marketing personnel are not confident in their knowledge and understanding of the need and what is required to meet the need, the information they provide is less reliable. This state is never going to happen in Agile, as the stakeholders can change/modify in intervals of Sprints.
Opinions expressed by DZone contributors are their own.