Unit 4: Agile Testing

I. Orientation — Iterative Quality in Agile Development

Agile testing is a continuous quality activity performed throughout iterative software development rather than only after coding is complete. Agile methods became widely associated with the Agile Manifesto (2001), which emphasizes working software, customer collaboration, responding to change, and frequent delivery. Testing is integrated with development, planning, feedback, and release decisions.

• Iterative delivery: Work is divided into short cycles so that usable software and test feedback are produced regularly.
• Whole-team responsibility: Developers, testers, product representatives, and stakeholders contribute to product quality.
• Early and continuous testing: Test design, automation, exploratory testing, and defect analysis begin during development.
• Customer value: Features are prioritized according to user and business value, not merely technical convenience.
• Adaptability: Requirements can be clarified or reprioritized when evidence, user feedback, or market conditions change.
• Definition of Done: A work item is complete only when agreed quality conditions, such as implementation, testing, review, and documentation, are satisfied.

II. Agile — An Adaptive Development Approach

A. Orientation

Agile is a set of values and principles for developing software through short feedback-driven iterations. It is a mindset and family of approaches rather than one fixed process; Scrum, Kanban, and Extreme Programming are examples of Agile practices.

B. What is Agile?

Agile is an approach that delivers software incrementally, welcomes changing requirements, and uses frequent collaboration and feedback to reduce delivery risk.

• Incremental development: A large product is divided into small increments. For example, a mobile banking application may first deliver login, then balance viewing, and later fund transfer.
• Frequent feedback: Stakeholders inspect working features at regular intervals instead of waiting for a final release.
• Customer collaboration: Product representatives clarify expected behavior using examples such as “a locked account must display a recovery option.”
• Responding to change: A high-priority security requirement can be added to upcoming work even if earlier plans change.
• Working software: Demonstrable, tested functionality is stronger evidence of progress than completed documents or lines of code.
• Agile testing: Testers contribute to acceptance criteria, test planning, automation, exploratory testing, and risk analysis throughout the iteration.

III. Scrum — A Framework for Managing Agile Work

A. Orientation

Scrum is a lightweight framework for solving complex problems through iterative delivery and empirical process control. It uses transparency, inspection, and adaptation: the team makes work visible, evaluates results, and changes its approach when evidence shows that improvement is needed.

B. What is Scrum?

Scrum is an Agile framework organized around defined accountabilities, events, artifacts, and a potentially releasable product increment.

• Accountabilities: The Product Owner maximizes product value, the Scrum Master supports effective Scrum use, and Developers create the usable increment.
• Product Backlog: This ordered list contains desired product work, such as features, defects, technical improvements, and research tasks.
• Sprint Backlog: This contains the selected backlog items for the current Sprint and the Developers’ plan for delivering them.
• Increment: The Increment is the usable, integrated result produced during a Sprint. It must meet the team’s Definition of Done.
• Empirical control:
  • Transparency: Backlog status, progress, quality, and impediments are visible.
  • Inspection: The product and process are examined frequently.
  • Adaptation: Plans or practices are adjusted when inspection reveals a problem.
• Testing contribution: Automated regression tests, device checks, API tests, and acceptance tests help the team inspect product quality before review or release.

IV. Sprint — A Time-Boxed Delivery Cycle

A. Orientation

A Sprint is Scrum’s basic delivery cycle. It creates a predictable opportunity to achieve a valuable, usable product increment while protecting the team from uncontrolled changes to the Sprint Goal.

B. What is Sprint?

A Sprint is a fixed-length period, commonly one to four weeks, during which the Scrum Team works toward a Sprint Goal and produces a usable Increment.

• Time-box: A two-week Sprint has a fixed calendar duration; unfinished work does not automatically extend the Sprint.
• Sprint Goal: This gives the Sprint a coherent purpose, such as “enable customers to securely reset a forgotten password.”
• Selected work: Developers choose feasible Product Backlog items while considering capacity, dependencies, technical risk, and testing effort.
• Quality boundary: Work is not complete merely because code compiles. It must satisfy acceptance criteria, pass required tests, and meet the Definition of Done.
• Scope adaptation: Details may be clarified during the Sprint, but changes must not undermine the Sprint Goal or reduce product quality.
• Incremental testing: Tests are executed as features are built; delaying all testing until the final Sprint day creates avoidable integration and defect risk.

C. Sprint Planning

Sprint Planning starts the Sprint by establishing why the Sprint is valuable, what can be delivered, and how the work will be accomplished.

• Purpose: The team converts ordered backlog items into a realistic Sprint plan.
• Sprint Goal: The Product Owner explains the desired outcome, and the team agrees on a concise goal connected to user or business value.
• Capacity assessment: Developers consider available people, holidays, support duties, and known technical constraints rather than assuming full-time capacity.
• Item selection: Higher-priority items are selected first, provided they are sufficiently understood and small enough to complete.
• Testing effort: The plan includes test-case design, automation, environment setup, test data, device coverage, accessibility checks, and defect resolution.
• Implementation plan: Developers break selected stories into tasks such as coding, API validation, UI automation, and exploratory testing.
• Worked example: For a password-reset story, tasks may include token generation, reset-screen implementation, invalid-token handling, API tests, and Android/iOS automated UI checks.

D. Backlog Refinement

Backlog Refinement is the ongoing activity of clarifying, splitting, estimating, and ordering future Product Backlog items.

• Purpose: Refinement reduces uncertainty before items enter Sprint Planning; it is not normally a formal Scrum event with a fixed duration.
• Clarification: The team identifies missing rules, such as token expiry after 15 minutes or rejection of a previously used reset link.
• Acceptance criteria: Criteria describe observable conditions for acceptance, including success paths, validation errors, permissions, and relevant device behavior.
• Splitting: A story that combines login, biometric authentication, and account recovery may be divided into smaller vertical slices.
• Dependencies and risks: The team records external services, test environments, unavailable devices, privacy constraints, and integration risks.
• Estimation readiness: Items should be sufficiently understandable, appropriately sized, and testable before selection.
• Tester contribution: Testers expose ambiguous behavior and identify edge cases before coding makes changes expensive.

E. Sprint Review

The Sprint Review is a collaborative inspection of the Increment with stakeholders, used to gather feedback and adapt the Product Backlog.

• Purpose: The review evaluates the product outcome, not individual performance or merely the number of completed tasks.
• Demonstration: The team demonstrates working, integrated functionality using realistic flows, such as resetting a password and then logging in with the new password.
• Evidence of quality: The team can report automated test results, known limitations, supported devices, performance observations, and unresolved risks.
• Stakeholder feedback: Feedback may alter priorities, acceptance criteria, or future backlog items; it should be converted into visible Product Backlog work.
• Incomplete work: Items that do not meet the Definition of Done are not presented as completed increments and return to the backlog for future consideration.
• Release distinction: A reviewed Increment may be releasable, but the Product Owner decides release timing according to product and business needs.

F. Sprint Retrospective

The Sprint Retrospective is a team event for inspecting the way work was performed and selecting improvements for the next Sprint.

• Purpose: The team examines collaboration, process, tools, quality practices, and impediments in a constructive environment.
• Evidence-based discussion: Useful evidence includes escaped defects, flaky-test counts, build duration, blocked tasks, and review delays.
• Success analysis: The team identifies practices worth retaining, such as running API tests on every pull request.
• Problem analysis: A recurring mobile test failure may be traced to unstable test data, device lab availability, or excessive waits in UI automation.
• Action selection: The team chooses a small number of measurable improvements, such as reducing a 20-minute smoke suite to 10 minutes or removing a known flaky test.
• Follow-through: Improvement actions enter the next Sprint plan or backlog so that the retrospective produces observable change rather than discussion alone.

V. User Story — A Small Statement of User Value

A. Orientation

A User Story expresses a product need from the perspective of a user or stakeholder. It encourages conversation about value and behavior rather than prescribing an implementation, while acceptance criteria provide concrete conditions for determining whether the need has been met.

B. What is User Story?

A User Story is a concise description of a desired capability, commonly written in the form: “As a [user], I want [capability], so that [benefit].”

• User: The role identifies who receives value, such as a registered customer or system administrator.
• Capability: The requested behavior should be specific enough to discuss and test, such as “receive a push notification for a completed payment.”
• Benefit: The reason explains value, for example, “so that I can confirm the transaction without reopening the application.”
• Acceptance criteria: These define observable outcomes, including notification content, delivery conditions, permission handling, and behavior when notifications are disabled.
• INVEST qualities: A useful story is generally Independent, Negotiable, Valuable, Estimable, Small, and Testable.
• Three-amigos collaboration: Product, development, and testing perspectives can examine the story together to discover missing scenarios before implementation.
• Testing scope: A mobile story may require unit, API, UI, compatibility, network, interruption, accessibility, and security testing depending on its risk.

C. How to give story points?

Story points are relative estimates of a backlog item’s total effort, complexity, uncertainty, and risk; they are not hours and should not be used as individual performance scores.

• Relative comparison: The team compares a new story with a reference story. If a simple login-validation story is 2 points, biometric login might be 5 because it involves more integration and device variation.
• Scale: Teams often use Fibonacci-like values such as 1, 2, 3, 5, 8, and 13. Increasing gaps represent increasing uncertainty.
• Shared assumptions: Before estimating, clarify what is included: coding, review, automation, test data, device coverage, documentation, and defect correction.
• Planning Poker: Each member privately selects a value, reveals estimates simultaneously, explains differences, and repeats until the team reaches a reasonable consensus.
• High disagreement: A 3 versus 13 usually signals different assumptions, such as one person excluding iOS testing while another includes it.
• Large stories: A story estimated at 13 or higher is often split or refined because its uncertainty makes Sprint planning unreliable.
• Example: A “change profile photo” story may receive 5 points because it includes permission prompts, image-size validation, upload failure handling, backend integration, and Android/iOS checks.
• Velocity limitation: If a team completes 24 points over several Sprints, that historical velocity can support forecasting, but it does not make points a universal unit or guarantee future capacity.