Agile and the product quality

Product quality

• Product quality is defined by :
  • Acceptance criteria
  • Continuous integration
  • Definition of done
  • Escaped defects
  • Project charter
  • Test, Test Driven Development (TDD) / Test First Development (TFD)
  • Frequent verification and validation

Acceptance criteria

• The acceptance criteria doesn’t be too vague (remember the T of INVEST for defining good User Stories) and cannot be easily tested. [The Art of Agile Development. James Shore.]
  • Acceptance criteria is typically defined in tandem with User Story definition during release planning; however, acceptance criteria can also be defined during iteration planning once a story has been picked for the iteration.
  • The one steadfast rule is that acceptance criteria must be defined before development begins.
  • Like agile planning, the definition of acceptance criteria is constantly evolving as the conversation with the Product Owner matures.
  • [The Art of Agile Development. James Shore.]
• During release planning, acceptance criteria are typically recorded on the backs of User Story cards.
  • Agile team testers will use this acceptance criteria in their verification tests.
  • [The Art of Agile Development. James Shore.]
• Acceptance test criteria should be written at the last Responsible Moment while Velocity, Product Backlog and release length are essential input for release planning.

Continuous integration (CI)

• The eXtreme Programming (XP) principle of Continuous Integration (CI) is that code is integrated into the full code base as soon as it is built, tested, and completed.
  • Once integrated, the code base and therefore the entire system is built and tested.
  • Continuous Integration (CI) is just one principle of eXtreme Programming (XP) that promotes rapid delivery of software and the early detection of integration defects.
  • [The Art of Agile Development. James Shore.]
• An eXtreme Programming (XP) project typically integrates code at least once per day. [The Art of Agile Development. James Shore.]
• Being continuously integrated theoretically means having a working product ready to ship at any time. [The Art of Agile Development. James Shore.]

Definition of done

• A cornerstone of the Scrum framework in agile is to ‘always have a product that you could theoretically ship,’ it is important for the team and Product Owner to have a Definition of Done (DoD) or what criteria is necessary to consider user features or functionality in a state of finality. [Coaching Agile Teams. Lyssa Adkins.]

Escaped defects

• An escaped defect is a software defect that is not found by the development or testing team and later found by an end-user. [Agile Software Development: The Cooperative Game – 2nd Edition. Alistair Cockburn.]

Project charter

• A project charter provides a brief overview of product functionality and serves as a guide for testers performing exploratory testing. [Lean-Agile Software Development: Achieving Enterprise Agility. Alan Shalloway, Guy Beaver, James R. Trott.]

Test, test-driven development (TDD) / test first development (TFD)

• Regular Exploratory Testing is encouraged to improve product quality.
  • Typically, Exploratory Testing is performed on completed product software to test the system design for any bugs and to identify any new features that may add value to the customer.
  • Exploratory Testing should cover what a developer is unable to anticipate through the course of normal Unit Testing (UT).
  • A project charter is often used as a general overview of the product that exploratory testers use for testing guidance.
  • [The Art of Agile Development. James Shore.]
• The commit build process includes both Unit Testing (UT) and Integration Testing. [The Art of Agile Development. James Shore.]
• In eXtreme Programming (XP) all testing are automated, the only manual Testing, an XP team may perform is the Exploratory Testing.
• See Test Driven Development (TDD) and Test First Development (TFD)

Testing and ATDD

• Acceptance Test Driven Development (ATDD) is similar to Test Driven Development (TDD) in that it requires programmers to create tests first before any product code.
  • The tests in Acceptance Test Driven Development (ATDD) are aimed at confirming features/behaviors that the intended software will have.
  • The iterative cycle of Acceptance Test Driven Development (ATDD) with its four steps can be remembered as the four Ds : 1) Discuss, 2) Distill, 3) Develop, and 4) Demo.
    • 1) Discuss:
      • The agile team and customer or business stakeholder discuss a User Story in detail.
      • Talking about the expected behaviors the User Story should have and what it should not.
    • 2) Distill :
      • The Developers takes those items learned from the discussion and distills them into tests that will verify and validate those behaviors.
      • The distillation process is where the entire team should have a good understanding of what « done » (or completed, see Definition of Done (DoD)) means for a User Story.
      • That is, what the acceptance criteria are.
    • 3) Develop :
      • After distillation, the team develops the test code and product code to implement the product features.
    • 4) Demo :
      • Once the product features have been developed, the team demonstrates them to the customer or business stakeholders for feedback.
  • [Lean-Agile Software Development: Achieving Enterprise Agility. Alan Shalloway, Guy Beaver, James R. Trott.]
• 4 steps in Acceptance Test Driven Development (ATDD) = 4 « D »s (Pneumonic : DiDiDeDe) :
  • 1) Discuss
  • 2) Distill
  • 3) Develop
  • 4) Demo
• Acceptance Test Driven Development (ATDD) is the technique based on the test driven approach where the team discusses the acceptance criteria with the Business so that a detailed set of tests are designed in advance and is accepted by the business and stakeholders.
  • The Acceptance Test Driven Development (ATDD) cycle starts from story discussions and then team distill this, followed by development and demo of item as mentioned in acceptance before marking this as DONE.

Testing and TDD

• Test Driven Development (TDD) is an agile methodology that has software developers develop automated software tests before developing software that implements product features.
  • This helps ensure quality as each bit of feature software is tested individually to remove bugs and improve performance before it is integrated with the final product. [The Art of Agile Development. James Shore.]
• The Test Driven Development (TDD) process has four basic steps :
  • 1) Write a test,
  • 2) Verify and validate the test,
  • 3) Write product code and apply the test,
  • 4) Refactor the product code.
• An example may be that a user has to enter an age value.
  • A good test is to make sure the user data entry is a positive number and not a different type of input, like a letter (i.e., write the test).
  • The programmer would verify that entering a letter instead of a number would cause the program to cause an exception (i.e., v&v the test).
  • The programmer would then write product code that takes user entry for the age value (i.e., write the product code).
  • The programmer would then run the product code and enter correct age values and incorrect age values (i.e., apply the test).
  • If the product code is successful, the programmer would refactor the product code to improve its design.
  • Using these four steps iteratively ensures that programmers think about how a software program might fail first and to build product code that is holistically being tested.
  • This helps produce high quality code.
  • [The Art of Agile Development. James Shore.]
• 4 steps in Test Driven Development (TDD) = WVWR
  • 1) Write a test
  • 2) Verify and validate the test
  • 3) Write product code and apply the test
  • 4) Refactor the product code
• By doing Test Driven Development (TDD) we control Scope creep.
  • By stating explicitly and objectively what the program is supposed to do, you give yourself a focus for your coding.

Frequent Verification and validation

• Because each iteration typically produces a working product that is built and integrated and iterations are typically two to four weeks in length, there is frequent verification and validation to ensure product quality.
  • Verification is the confirmation that a product performs as specified by a customer (e.g. as indicated by a user story),
  • Validation is the confirmation that a product behaves as desired (i.e., meets the customer’s need).
  • Sometimes a product may be built and integrated to specification – that is, it can be verified – but it does not meet the intent of the customer – that is, it cannot be validated.
  • [Agile Software Development: The Cooperative Game – 2nd Edition. Alistair Cockburn.]

More informations at PMI-ACP exam