FizzBuzz Quiz TDD Process

The TDD process for the FizzBuzz Quiz may seem like a total overkill for such a simple solution. It is the fact that it is a simple solution that makes it such a great candidate to demonstrate the TDD paradigm.

Regardless of the complexity of a given business case, that requires a software solution, the steps to ensure success are the same. A clear understanding of the definition of success is critical for a successful result. Everyone involved must see, hear and feel the solution in the same way for the outcome to be deemed a success.

The Development Process Steps:

1. Create a Business User Story in the Project Management Tool – The Business Stakeholders

2. Create a Lexicon of Terms (LOT) for the User Story as the Ubiquitous Language in the Project Management Tool – Stakeholders, Product Owner and Architects

3. Using the User Story create the User Story Acceptance Criteria in the Project Management Tool –  Stakeholders, Subject Matter Experts (SME) and Product Owner

4. Create the Project Solution for the User Story with the Test Assembly in the defined Folder Structure in Visual Studio IDE – Architects

5. Using the User Story and Acceptance Criteria create the Acceptance Test Driven Development (ATDD) Feature File using Behavior Driven Development (BDD) with SpecFlow – Architects with SMEs and Product Owner input

6. Create the BDD SpecFlow Steps Files using the Gherkin Language format of Given/When/Then to map the User Story Acceptance Criteria to the Gherkin formatted Scenarios – Architects

7. Certify that the BDD Acceptance Scenarios, as Web Posted YELLOW Inconclusive Tests State, meet the User Story Acceptance Criteria using a Web Browser – Stakeholders, SMEs, Product Owner, Scrum Master and Quality Assurance Team (QA Team)

8. After the BDD defined Scenarios has been Certified as acceptable mappings to the Acceptance Criteria in the Business User Story move the YELLOW Inconclusive State to the RED “Not Implemented Yet” State. Assert to “true == false” – Architects, Developer, Product Owner, Scrum Master and QA Team

9. Using the Scenarios in the BDD SpecFlow Steps Files to create all TDD Single Unit of Work Unit Tests as a Failing RED Test. Assert to “true == false” – Developer and Scrum Master

10. Using the TDD defined process of create ALL concrete solution Software Entities inside the Test Class file that contains the current Single Responsibility Method you are validating correct functionality. When the Tests pass this are your GREEN Tests – Developer and Scrum Master

11. After all the defined BDD Scenarios have been mapped to TDD GREEN Tests then Refactor all the Tests to comply with the Modern Developer’s Best Practices Principles, Design Patterns and Code Standards. These are your TDD YELLOW Refactoring Tests. Run the complete Test Suite for validation of compliance state after the refactoring of the GREEN code to YELLOW – Developer and Scrum Master

12. Use Move Refactoring to move your Concrete solution code from the TDD environment to the Solution Project assembly created for the User Story Business Case. This move will set the Namespace by Folder Structure, Dependency References and all Access Modifiers. Run the complete Test Suite to validate the Code Move was successful – Developer and Scrum Master

13. Moving back to the BDD SpecFlow Steps Test Files, use the Test Code within the Unit Tests to complete the ATDD Tests. The Gherkin language will direct you to the applicable Unit Test code to create the ATDD GREEN Tests – Developer and Scrum Master

14. Validate that ALL ATDD and TDD tests within the Test Suite now run as GREEN Successful Tests – Developer. Srum Master and QA Team

15. Validate the Posted Web ATDD Status of all mapped User Story Acceptance Criteria tests are displaying a GREEN passing Development status – Architects, Product Owner, Developer, Scrum Master and QA Team

16. Certify that the Solution Performs as Required in all Deployment Platforms – QA Team

17. Notify All Interested Parties to View the ATDD Web page Status Report informing all of the Team members of the Completion of the Business User Story Development Request – Stakeholders, SMEs. Product Owner, Architects, Developer, Srum Master  and QA Team

18. Request your Bonuses from the Boss for a Job Exceptionally Well Done – All Team Member and the Big Dogs

If You Can’t Measure It …

…… You Can’t Manage It!

The ATDD process, using BDD, puts the  “Teeth” into the Business User Stories that reside in passive Project Management Tools such as Rally for Agile, MS Project or even Excel. The mapping of the User Story Acceptance criteria to Web-based real-time reports, that can be integrated into a Continuous Integration architecture, enables the Client to Measure the current state of the solution. This process produces the information required to Manage the Total Cost of Ownership (TCO) of a Business Case developed solution over the Software Development Life Cycle (SDLC.