Product Quality Defined by the QA Objective

The Agile Process Preeminent Responsibility

The preeminent responsibility of the Agile process is to Deliver Product to the Business Team’s Stakeholders on a recurring basis.

This cycle is defined in the Modern Developer’s Agile Methodology Daily Activities.

… Demo is every other Tuesday at 10:00 AM

…… The Second Day of the Current Sprint

At 10:00 Am on the second day of the new Sprint the Demonstration environment presents that latest product for the Business Team to view.

The Business Demonstration Presentation Agenda:

1. Demonstrate the Developed, QA Certified and Delivered Business User Stories

2. Seek Validation that the Business Acceptance Criteria has, in fact, been met

3. Query for any changes to the deliverables that the Business Team now understands as required that may have not been clear before the development of the last Sprint User Stories

4. identify Issues or Bugs that were missed during the Development and Quality Assurance process

5. Collect the Business Team’s Consensus information that will be discussed at the 2:00 PM Sprint Retrospective later that day

What is the QA Objective?

The QA Objective is the complete Testing Suite, Test Use Cases and Test Data that the QA Team will be using to validate their understanding of the Definition of Done for the Code Under Test.

… The QA Objective is delivered to the Development Team

…… During the Code Integration Phase of Development

This process gives the Development Team the responsibility of ensuring that the QA Team will spend their time finding issues that neither team has thought about when the Test Criteria was created.

The Code Integration Review certifies the QA Objective
BEFORE the QA Team Receives the Code for Validation

This process frees the QA Team from wasting the Client’s time and money playing the “Gotcha” game.

…The QA Process is not about “Finding Bugs”

…… It is About Delivery “Bug Free Code”

… QA Objective is “Certifying Quality”

…… Before the QA Team Receives the Code

The preeminent responsibility of the Quality Assurance Process is to validate that the Business User Story Acceptance Criteria has been understood and achieved.

The QA Objective is the concept of the Development Team and the QA Team working as a “Synergistic Collective” to accomplish the preeminent responsibility of the Agile Process: Deliver Quality Product to the Stakeholders.

The Code Quality Assurance process is a structured balance of Team Cooperation and Defined Processes.

The goal, as always, is to reduce the Cost of Software Development through the use of the Agile Methodology.

The “One Team” philosophy of Agile is expanded in the Development Code Review process to prevent issues related to the traditional adversarial relationship between the Development Team and the QA Team.

Both the QA Team and the Development Team
are on the “Same Side” of the proverbial “Net”

What the QA Object strives to prevent is competition to find Bugs. QA Testers should never be “Graded” on how many Bugs they can find!

… The Concept of Giving the Developers the Test Suite

…… Is like Giving a Student the Answers to a Test

… Violates the Preeminent Responsibility of the QA Team

…… Efficient Use of QA Resources for the Business Team’s Acceptance Criteria

The Sprint: The QA Objective as a User Story

The Code Quality Assurance Process has three development-centric reviews:

1. The Design Review

2. The Development Review

3. The Integration Review

The Integration Code Review uses the QA Objective as the criteria for certifying that the code base is ready for QA Testing.

The QA Objective is created to validate that the Business User Story has been met.

The QA Objective triggers the creation of a Technology Feature Story with Feature Task Criteria that meets the User Story Acceptance Criteria defined by the Business Team.

When the Integration Code Review is completed the code Feature Step Tests are moved from a RED “To Do” state to a passing GREEN state.

The Task Estimations for the “Level of Estimated Effort” required for the QA Testing Process Scenarios are added to the QA Testing Process Scenarios in the same fashion as the Code Scenarios.

The QA Testing Process Scenarios are RED until the
QA Team certifies that the “Definition of Done”
for the Business User Story under test has been met.

A GREEN display on the Web Report
indicates Business User Story completion.

Final Thoughts: The QA Objective

Once again, the objective of the Development Integration Code Review process is to deliver to the QA Team developed code that has been pre-tested for compliance with the Business Team’s Acceptance Criteria.

The criteria are defined by the QA Objective: The QA Testing Suite of Tests, Use Cases and Test Data.

The “Product” delivered in Software Development is complied and script code along with supporting files such as images, XML, Style sheets and other file types.

Like any other product manufactured, a quality control process must be in place to protect the Customer.

The QA Team ensures that the product performs as expected by the Customer. This is the result of the Code Quality process.

Code quality must be validated throughout Code Development and certified with the QA Team’s processes.

The QA Objective
Unifies the Commitment of Delivering
Quality Code to the QA Team
with the Fewest Possible Development Bugs and Issues

Wisdom Pearl # 113 – Understanding Success

Have a Crystal Clear Understanding of Your Destination

… Or Your Might Drive Right By It