The TMD Sprint Code Review Process

Using the TMD Code Review Process creates strong Development Team integration with the Architect Team and the QA Team by using the Agile “One Team” philosophy for fostering creative cooperation.

This Code Review process unifies the commitment of delivering Sprint User Story Points to QA with the fewest possible development issues.

The process creates an environment that fosters the QA Team to spend the Business Team’s money on real bug and performance testing.

The QA Team’s effort is directed toward discovery of issues that were not found in the integration test suite, the QA Objective, as the “Happy and Sad Tests“.

This process enables the QA Team’s daily activity to concentrate on real world code issues and not playing the “Gotcha” game with the Development Team.

The QA Objective 

Let us start this discussion with an understanding of the real goal of Development Code Quality and QA Testing:

Quality Business Solutions that Controls

… The Cost of Delivery and Maintenance

…… Over the Software Development Life Cycle

The TMD term “QA Objective” refers to the QA Team Test Suite that exercises the Sprint Feature Story Scenarios developed as the code base.

The QA Objective ensures that the Development Review Certification process meets the Business Team’s User Story Acceptance Criteria for all delivered code.  

The QA Objective supports the Sprint concept of “Definition of Done“.

The Sprint Task Completion Criteria 

The Agile Sprint Scrum Master is responsible for ensuring that the QA Objective has truly has been met.

A formal Definition of Done and the acceptance specification of Conditions of Satisfaction should be defined by the Business Team and used as the criteria for development completion of Story Points.

There is a relationship between these two important concepts.

Definition of Done (DoD) – An agreed-upon set of criteria that must be met before any product backlog item is considered done.

Conditions of Satisfaction (CoS) – An agreed-upon set of criteria that is specific to a given product backlog item that defines what must be met for that product backlog item to be considered completed.

The “Definition Of Done” is a

… Set of “Conditions of Satisfaction” applied

…… To Every User Story Product Backlog Item

The QA Objective,
when defined in compliance withe DoD and CoS,
certifies that the Sprint backlog item will meet
the Business User Story Acceptance Criteria

The Review Process

The TMD Review process certifies that a Sprint backlog item has complied with the Ubiquitous Language for all Namespace, Assemblies, Classes, Methods, Data Transfer Objects and other Software Entities.

… The Certified Business User Story Delivered Concrete Code will Always be

…… Described by the Ubiquitous Language’s Lexicon of Terms

… And becomes a Backlog Item Selected as a Sprint Refactoring Task anytime

…… The Business Domain Definitions are Changed and Updated by the Lexicon Master

The process guarantees that automated Unit and Integration Test Suites have been certified as demonstrating the defined Feature Acceptance Criteria as defined by the Business User Story Acceptance Criteria.

The tightly integrated environment of cooperation between the Development Team and the QA Team, through the QA Objective, ensures that the delivered code base for QA testing will not waste their time on bug issues that should have been resolved by the Development Team.

IMPORTANT

Delivery of the QA Objective to the Development Team’s
Integration Developer during the Integration phase
will significantly reduce the “Bug Report Noise”
within the Bug Tracking System

The TMD Code Review Process has Three Phases:

1. The Design Review

This review is held before any development activities begin and after the Design Statement of Work has been created from the SOW Template Document. 

The Sprint Teams with their representatives meet and complete the SOW for the selected Spring backlog item. 

The QA Representative delivers the defined acceptance criteria as the abstraction for the QA Objective.

2. The Development Review

This review is held during the Sprint iteration for the code base developed using true Unit Tests.

All external dependencies mocked for this review. 

The developer’s code base is reviewed using the Developer’s Unit Test Suite within the Development environment. 

A representative from the QA Team can be a member of this review to ensure that the understanding of the QA Objective from the Design Review is correct. 

The QA representative leaves the review with a clear direction of the QA Objective delivery criteria. 

This understanding must be based on the concrete representation of the code base as demonstrated during the Development Code Review. 

This understanding should refine the abstracted QA Objective understanding received after the Sprint backlog item’s Design Review.

3. The Code Integration Review

This review is held before the developed code base is released to the QA Team as the QA Objective certification. 

The QA Team delivers to the Integration Developer the finalized QA Objective as the “Road Map for Success”. 

The code base is tested in the QA environment but not released to the QA Team until the Integration Review is completed and certified as a successfully integrated backlog item. 

The certification criterion for the Integration Review code is QA Objective Test Suite. 

The Integration Review Lead certifies the passing code base. 

It is now ready for delivery to the QA Team. 

The Integration Review Lead notifies the QA Team that the backlog item has met the QA Objective and is ready for testing.

In Conclusion

The TMD Code Review 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 Agile Methodologies.

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

The preeminent objective of the Code Review process
is to deliver to the QA Team developed code
that has been pre-tested for compliance
with the Business Team’s Success Criteria
as defined by the QA Objective

This objective creates an environment where the QA Team can efficiently concentrate on finding issues that the developers had not thought of during the development activities.

IMPORTANT

The definition of success for the QA Team is NOT to find as many “Bugs” as possible.

The definition of success for the QA Team is to spend as little time as possible locating issues that should have been found by the Development Process.

The definition of success for the QA Team is to spend its time in exhaustive testing of a working code base to locate obscure issues before the Production release.

… The Concept of Giving the Developers the Test Suite

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

… Violates the Primary Responsibility of the QA Team

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

Wisdom Pearl # 106 – Continuous Poor Results

If You Do What You Have Always Done

… Then You’ll Get What You Have Always Got

…… Better Manage Your Results