PMI-ACP Tools and Techniques: Product Quality

[PMI-ACP® Exam Study Notes] Agile Product Quality is one of the ten Tools and Techniques for the PMI-ACP® exam. The “Tools and Techniques” accounts for a total of 50% of all the questions to be found on the exam paper. According to the PMI-ACP® exam content outline, Product Quality includes Frequent Validation and Verification (V&V), TDD – Test Driven Development, ATDD – Acceptance Test Driven Development, DoD – Definition of Done and Continuous Integration.

PMI-ACP® Exam Importance: around 3-6 questions (~5% of all questions)

PMI-ACP® Tools and Techniques: Product Quality

• these tools support the continuous improvement process of Agile development – a process to build in high quality from the beginning through validation and verification at every steps
• the highest quality is achieved through the “built-in quality assurance” of Agile processes right from the beginning
• reactive quality assurance: daily testing and automated testing
• pro-active quality assurance: face-to-face communication, pair programming, coding standards, testing “risky” features in early sprints
• Definition of Done (DoD)
  • Done usually means the feature is 100% complete (including all the way from analysis, design, coding to user acceptance testing and delivery & documentation) and ready for production (shippable)
    • Done for a feature: feature/backlog item completed
    • Done for a sprint: work for a sprint completed
    • Done for a release: features shippable
  • The exact definition of done has been be agreed upon by the whole team (developer, product owner / customer, sponsor, etc.)
  • The definition of done includes acceptance criterion and acceptable risks
• Frequent Validation and Verification
  • early and frequent testing both within and outside the development team to reduce the cost of quality (change or failure)
    • validation: (usually external) the assurance that a product, service, or system meets the needs of the customer
    • verification: (usually internal of team) the evaluation of whether or not a product, service, or system complies with a regulation, requirement, specification, or imposed condition
  • Agile measure to ensure frequent validation and verification:
    • testers are included in the development team from the beginning taking part in user requirements collection
    • unit testings are created for continuous feedback for quality improvement and assurance
    • automated testing tools are used allowing quick and robust testing
    • examples: peer reviews, periodical code-reviews, refactoring, unit tests, automatic and manual testing
    • feedback for various stages: team (daily) -> product owner (during sprint) -> stakeholders (each sprint) -> customers (each release)
• Test Driven Development (TDD) – programming practice for developers for verification
  • also broadly known as test-first development
  • test cases (unit tests) are written before codes (i.e. think about the design first before coding)
    • allow the coders to focus on the end results
    • development driven by test cases (evolved from XP) to assure technical excellence and good design, write code unit all tests are passed
    • codes written in this way are high-quality, maintainable and reliable
  • the TDD processes:
    1. Red: write a failing unit test showing the intent of what the new code
    2. Green: write code to pass the test and add code to source repository
    3. Refactor / Clean: clean up the code (lean, mean and clear)
  • rules of thumb for TDD:
    1. Don’t write any new code until a failing test is written
    2. Test everything that could “possibly” break
    3. Always improve by refactoring and do small chunks of refactoring frequently
  • technical debts: compromises on code quality in order to meet the schedule
    • refactoring is paying back technical debts
• Acceptance Test Driven Development (ATDD) – testing practice for the team for validation
  • acceptance / functional tests are specifications for the desired behavior and functionality of a system (business requirements)
  • before development begins, the development team discusses collaboratively (with product owner, customers, stakeholders) acceptance criteria to create a set of concrete acceptance tests (for each user story)
  • help developers to build high-quality softwares fulfilling the business objectives reliably
  • the ATDD processes:
    1. Discuss – discuss with customer to gather acceptance criteria
    2. Distill – get the acceptance tests ready
    3. Develop – code and hook up and run acceptance tests
    4. Demo – using automated acceptance scripts to run the tests in demos
  • can make use of the Red, Green, Refactor model of TDD
• Continuous Integration
  • continuously integrate changes and merge codes to the codebase (as soon as ready, maybe several times a day) so every developers can pull the latest version of code for development to avoid code conflicts and lower the cost of fixing errors
  • the newly integrated codebase needs to go through testing (unit testing with automated testing tools and regression testing tools)
  • continuous integration setup:
    1. A source code repository
    2. A check-out and check-in process
    3. An automated build (compiles codes, runs tests and deploys)
    4. Discipline to work in small chunks
  • fixing a broken build is of top priority in continuous integration
  • Continuous Improvement
    • following Deming’s PDCA Cycle (plan – do – check -act)
    • process improvement and self-assessment for improved product
    • code refactoring
    • pair programming

Summary: Agile Product Quality

This PMI-ACP® Exam Study notes touches upon one of the many tools and techniques of the PMI-ACP® exam syllabus – Agile Product Quality. Agile Product Quality includes Frequent Validation and Verification (V&V), TDD – Test Driven Development, ATDD – Acceptance Test Driven Development, DoD – Definition of Done and Continuous Integration.