CAT cheat sheet

The Agile Manifesto (2001) states four value pairs: individuals and interactions over processes and tools; working software over comprehensive documentation; customer collaboration over contract negotiation; responding to change over following a plan.

The twelve Agile principles include: satisfy the customer through early and continuous delivery; welcome changing requirements; deliver working software frequently (weeks, not months); business people and developers work together daily; build projects around motivated individuals; face-to-face conversation is the most efficient communication; working software is the primary measure of progress; promote sustainable development; continuous attention to technical excellence; simplicity-maximizing the amount of work not done; self-organizing teams; regular reflection and tuning.

Scrum roles: Product Owner (maximizes product value, manages Product Backlog), Scrum Master (serves the team by removing impediments and coaching Scrum), Development Team (self-organizing, cross-functional, 3–9 members).

Scrum artifacts: Product Backlog (ordered list of everything known to be needed), Sprint Backlog (subset selected for the Sprint plus a plan), Increment (sum of completed Product Backlog items). Each artifact has a commitment: Product Goal, Sprint Goal, Definition of Done.

Scrum events: Sprint (fixed length, typically 2–4 weeks), Sprint Planning (what and how), Daily Scrum (15 minutes, inspect progress toward Sprint Goal), Sprint Review (inspect Increment, adapt Product Backlog), Sprint Retrospective (inspect process and team).

Kanban core practices: visualize the workflow, limit work in progress (WIP), manage flow, make policies explicit, implement feedback loops, improve collaboratively. Kanban does not prescribe iterations; it uses a continuous flow model.

Extreme Programming (XP) practices include: pair programming, test-driven development (TDD), continuous integration, refactoring, small releases, simple design, on-site customer, collective code ownership, coding standards, sustainable pace.

Definition of Done (DoD) is a shared understanding of what it means for work to be complete; it is used to assess when a Product Backlog item is done. The Definition of Ready (DoR) is an optional agreement on when an item is ready to be taken into a Sprint.

The seven ISTQB testing principles apply in agile: testing shows presence of defects, exhaustive testing is impossible, early testing saves time and money, defect clustering, pesticide paradox, testing is context dependent, absence-of-errors fallacy.

Agile testing principle: testing is not a phase but an activity integrated throughout the lifecycle; testers collaborate with developers and business stakeholders from the start.

Whole-team approach: everyone on the agile team is responsible for quality; testers contribute testing expertise but do not own all testing activities.

Shift-left: testing activities (e.g., static analysis, reviews, test design) are performed as early as possible; testers participate in requirements refinement and design discussions.

Test pyramid: many unit tests (fast, isolated), fewer service/API tests, few UI/end-to-end tests (slow, brittle). The pyramid guides automation investment.

Testing quadrants (Agile Testing Quadrants by Brian Marick): Q1 technology-facing supporting the team (unit, component); Q2 business-facing supporting the team (functional, story, acceptance); Q3 business-facing critiquing the product (exploratory, usability, UAT); Q4 technology-facing critiquing the product (performance, security, non-functional).

Agile testing process: iterative and incremental; test planning occurs at release, iteration, and daily levels; test design and execution are continuous; test results drive adaptation.

Retrospectives: the team regularly inspects its process and identifies improvements; testers contribute testing-related improvement actions.

Test-driven development (TDD) cycle: write a failing test (red), write the minimum code to pass (green), refactor. TDD is a design technique; tests are written before production code.

Acceptance test-driven development (ATDD): collaborative practice where acceptance criteria are defined before implementation; tests are derived from those criteria and automated where possible.

Behavior-driven development (BDD): extends ATDD using a ubiquitous language; scenarios written in Given/When/Then format (Gherkin) describe expected behavior.

Three amigos: a business representative, a developer, and a tester collaborate to discuss a user story and produce shared acceptance criteria, reducing misunderstanding.

User story INVEST criteria: Independent, Negotiable, Valuable, Estimable, Small, Testable. Testable stories have clear acceptance criteria.

Acceptance criteria formats: rule-oriented (bullet list of conditions) and scenario-oriented (Given/When/Then). They define the boundaries of a story and are the basis for acceptance tests.

Exploratory testing: simultaneous learning, test design, and execution; session-based test management uses time-boxed sessions with charters and debriefs.

Agile test automation: automated regression tests are run continuously via CI; test automation pyramid guides layers; tools include unit test frameworks (xUnit), BDD tools (Cucumber, SpecFlow), and CI servers (Jenkins, GitLab CI).

Tester role in agile: collaborate on requirements and acceptance criteria, design and execute tests, automate regression tests, perform exploratory testing, facilitate defect prevention, and report quality metrics.

Testers participate in all team activities: daily stand-ups, sprint planning, backlog refinement, sprint review, and retrospective.

Testers advocate for quality and the customer; they help the team understand risks and non-functional requirements.

Testers contribute to the Definition of Done and Definition of Ready; they ensure testing activities are included in the team's definition of complete.

Testers support continuous integration and delivery: maintain automated test suites, monitor test results, and analyze failures.

Testers perform risk-based testing: identify and prioritize testing based on risk (likelihood and impact) to focus effort where it matters most.

Testers facilitate communication between technical and business stakeholders; they translate technical issues into business impact.

Testers measure and report quality: metrics such as defect density, test coverage, escaped defects, and automation percentage; use metrics to guide improvement, not to blame.