AutomationAutomated: Evolution of V Model in Agile

AutomationAutomated: Evolution of V Model in Agile:                                  As we are moving towards Agile [ even PMP is adapting to Agile on 2021], we tend think Waterfall model, V m...

Evolution of V Model in Agile

                                 As we are moving towards Agile [ even PMP is adapting to Agile on 2021], we tend think Waterfall model, V model as stone age methodologies.  But as I work more and more on Agile I couldn't shake the feeling of similarity on V model. Especially from a QA / Tester  point of view. 

 

Traditional V model

V Model

 

 Verification is the comparison of software to its technical specification. This effort is typically led by a systems analyst.
 Validation is the comparison of software to its business requirements. This effort is typically led by a business analyst.

Left side of the traditional “V” portrays various upfront and comprehensive business and technical documents.

Right side mirrors the corresponding levels of testing. 

Top-down, the testing levels are satisfaction assessment, acceptance testing, user testing, system testing, integration testing, and unit testing. 

The top 3 levels provide validation while the lower 3 verification.

 

Agile V Model

Agile V Model

 

Left Side of the agile “V”

1. Business Need – states the business direction in the form of cost savings, revenue increase, conformance to laws, industrial standards, or an executive edict

2. With a statement of business need, the stakeholders scope the Product Vision of the solution by creating a list of prioritized software features. Led by a business analyst, the stakeholders attend a facilitation session where they brainstorm ideas, construct AS-IS and TO-BE models, conduct a gap analysis, and finally rank the product features of the software solution along with their benefits. Note the stakeholders most likely also identify associated process improvements.

3. Together with the stakeholders, the agile team elaborates on the Product Features via user stories consisting of conversations and matching test confirmations with constraints (business rules) and environmental conditions (e.g., system performance, capacity, usability, security, etc.). The team then estimates the work required for each feature in story points for velocity planning. Velocity is the average of story points a team can address in an iteration

4. For each iteration, the agile team breaks down selected product features into Functional Tasks (e.g., input, store, retrieve, calculate, transmit, print, etc.) and estimates the work required in hours. This is called commitment-driven iterative planning

Right Side of the Agile “V”

As in the traditional V-Model, the right side of the “V” mirrors the progressive definition side with matching testing levels. Again starting at the top:

1. Business Case Assessment consists of economic indicators that confirm that benefits stated in the Business Need are realized.

These indicators range from payback period, benefit-cost ratio (BCR), return on investment (ROI), net present value (NPV), to internal rate of return (IRR). Note benefits need to be on a feature basis since the product owner will approve features incrementally. This allows the product owner to update the business case as soon as the benefits are realized. This is a real economic benefit of the agile approach; the quicker the features are moved to production, the higher the NPV. Note if the business case is motivated by a conformance issue, the benefits are in the compliance rather than economics.

In the traditional V-Model, the matching test level of Business Need is a satisfaction assessment rather than a business case assessment. The satisfaction assessment is typically a user survey providing solution feedback such as solution errors, enhancements and lessons learned. Due to the continuous involvement of the product users in agile, the satisfaction assessment is redundant.

2. Product Owner Testing is when upon reviewing completed features of the current release/iteration, the owner of the solution decides if the quality of the Product Vision features are “fit for use” for an incremental move to production. This is in contrast to the traditional V-Model where the quality definition of “conformance to written and approved requirements” is applied by the product owner using the formal Business Requirements Document (BRD).

3. Regression Testing, also known as continuous integration testing or automated testing, is a suite or series of testing to ensure all acceptance criteria for developed features are still working (no errors). This level of testing also includes solution environmental conditions as stated in the Product Features.

4. Test-Driven Development (TDD) is the 

1) development of functional tests prior to coding, 2) coding, 3) test execution and 4) refactoring of the Functional Tasks; see the process model in Figure 3. Refactoring is “cleaning” up code for efficiency and/or maintainability (yes, documentation), not adding or changing tasks; sometimes referred to as technical debt.

SUMMARY 

Like the traditional V-Model, the proposed V-Model for agile development testing highlights both validation and verification. Although, by nature, the agile V-Model is simpler (fewer test levels), it is just as thorough. The agile V-Model maintains and truly enhances the test-driven development concept. And most important, it completes the test life cycle with the business case assessment.