Unit 4: Agile Testing - Subjective Questions

Agile is an iterative and incremental approach to software development in which requirements, development, testing, and delivery evolve through collaboration and continuous feedback.

Key characteristics of Agile include:

• Iterative development: The product is developed through short, repeated development cycles.
• Incremental delivery: A usable product increment is delivered at the end of each iteration.
• Customer collaboration: Customers and stakeholders regularly provide feedback.
• Adaptability: Teams can respond quickly to changing requirements.
• Cross-functional teamwork: Developers, testers, designers, and business representatives work together.
• Continuous testing: Testing is performed throughout development rather than only after coding is complete.
• Frequent delivery: Working software is delivered at regular intervals.

In mobile application development, Agile helps teams respond to frequent operating-system updates, device fragmentation, user feedback, and changing market requirements.

Agile testing is a continuous testing practice that follows Agile development principles. Testing begins early and continues throughout every iteration.

Role of Agile testing in mobile development:

• Testers participate in requirement discussions and identify test conditions early.
• Mobile features are tested within the same sprint in which they are developed.
• Automated tests provide rapid feedback on new builds.
• Regression testing verifies that existing functionality is not affected by changes.
• Testing is performed across different devices, screen sizes, operating systems, and network conditions.
• Continuous integration can automatically execute tests whenever code is committed.
• Defects are reported and resolved quickly through close collaboration between developers and testers.
• Feedback from users and stakeholders is incorporated into later sprints.

Thus, Agile testing improves product quality, reduces late defect discovery, and supports frequent mobile application releases.

Scrum is a lightweight Agile framework used to develop and deliver complex products through short, time-boxed iterations called sprints.

Major components of Scrum are:

• Accountabilities:
  • Product Owner: Maximizes product value and manages the Product Backlog.
  • Scrum Master: Facilitates Scrum and helps remove impediments.
  • Developers: Build, test, and deliver the product increment.
• Events:
  • Sprint
  • Sprint Planning
  • Daily Scrum
  • Sprint Review
  • Sprint Retrospective
• Artifacts:
  • Product Backlog: Ordered list of product requirements.
  • Sprint Backlog: Work selected for the current sprint and the plan to complete it.
  • Increment: Completed and usable product functionality.
• Commitments: Product Goal, Sprint Goal, and Definition of Done.

Scrum promotes transparency, inspection, adaptation, collaboration, and frequent delivery of value.

A Scrum team contains three main accountabilities:

1. Product Owner

• Defines and communicates the Product Goal.
• Creates, orders, and clarifies Product Backlog items.
• Prioritizes work according to customer and business value.
• Communicates with stakeholders.
• Accepts completed work based on agreed criteria and the Definition of Done.

2. Scrum Master

• Helps the team understand and apply Scrum.
• Facilitates Scrum events when required.
• Removes or helps resolve impediments.
• Coaches the team in self-management and continuous improvement.
• Protects the team from unnecessary interruptions.

3. Developers

• Plan the work needed to achieve the Sprint Goal.
• Design, develop, test, and integrate product functionality.
• Maintain quality according to the Definition of Done.
• Adapt the Sprint Backlog as new information is discovered.
• Take collective responsibility for the increment.

In mobile testing, testers generally work as part of the Developers and contribute to automation, exploratory testing, device coverage, and quality assurance.

A Sprint is a fixed-length Scrum event during which the team creates a valuable and usable product increment.

Purpose:

• Convert selected Product Backlog items into completed functionality.
• Achieve a clearly defined Sprint Goal.
• Obtain rapid feedback and reduce development risk.

Duration:

• A sprint lasts one month or less.
• Many teams use one-week or two-week sprints.
• Its duration should remain consistent to establish a predictable working rhythm.

Activities within a sprint:

• Sprint Planning
• Daily Scrum meetings
• Development and continuous testing
• Backlog clarification when needed
• Sprint Review
• Sprint Retrospective

Expected outcome:

The team should produce at least one usable increment that satisfies the Definition of Done. For a mobile application, this could be a tested login feature that works on the supported devices and operating-system versions.

A User Story is a brief description of a product requirement written from the perspective of a user or stakeholder.

A common structure is:

As a type of user, I want a capability, so that I receive a benefit.

Example: As a mobile banking customer, I want to log in using a fingerprint so that I can access my account quickly and securely.

A good user story commonly follows the INVEST characteristics:

• Independent: It can be developed with minimal dependency on other stories.
• Negotiable: Details can be discussed and refined collaboratively.
• Valuable: It provides clear value to a user or business.
• Estimable: The team has enough information to estimate it.
• Small: It can be completed within a sprint.
• Testable: Its completion can be verified through acceptance criteria.

A user story is not a complete specification. Discussions, examples, acceptance criteria, and test scenarios provide the details needed for implementation.

Acceptance criteria are specific, testable conditions that a user story must satisfy before it can be accepted as complete.

Importance of acceptance criteria:

• Clarify the expected behavior of the feature.
• Establish a shared understanding among stakeholders, developers, and testers.
• Define the boundaries and scope of the story.
• Provide a basis for functional and automated test cases.
• Reduce ambiguity and rework.
• Support acceptance decisions during the Sprint Review.

Example user story:

As a registered user, I want to reset my password so that I can regain access to the mobile application.

Possible acceptance criteria:

• The user can request a reset link using a registered email address.
• A valid reset link is sent to the registered email address.
• The link expires after a specified period.
• The new password must satisfy the stated password rules.
• The user can log in with the new password after a successful reset.
• An appropriate error message appears for an invalid or expired link.

These criteria can be converted directly into positive, negative, security, usability, and automation test scenarios.

Story points are a relative unit used by an Agile team to estimate the overall effort required to complete a Product Backlog item. They do not represent exact hours or days.

Factors considered in story-point estimation include:

• Complexity: Difficulty of design, coding, testing, and integration.
• Amount of work: Volume of tasks required to complete the story.
• Risk: Possibility of technical failure, defects, or rework.
• Uncertainty: Lack of information about requirements or implementation.
• Dependencies: Reliance on other teams, APIs, devices, or external services.
• Testing effort: Number of test scenarios, platforms, devices, and operating-system versions.

Teams commonly use a modified Fibonacci sequence such as 1, 2, 3, 5, 8, 13, 21. Larger gaps represent increasing uncertainty in large stories.

Story points are team-specific. An estimate of 5 points from one team should not be directly compared with 5 points from another team.

Planning Poker is a collaborative estimation technique in which team members independently estimate a user story and then discuss differences.

Procedure:

1. The Product Owner explains the user story and its acceptance criteria.
2. Team members ask questions about scope, risks, dependencies, and testing requirements.
3. Each estimator privately selects a card, commonly from the sequence 1, 2, 3, 5, 8, 13, 21.
4. All cards are revealed simultaneously.
5. If estimates differ, the highest and lowest estimators explain their reasoning.
6. The team discusses hidden complexity or assumptions.
7. Voting is repeated until reasonable agreement is reached.

Benefits:

• Prevents one person's estimate from influencing everyone else.
• Includes development, testing, and integration perspectives.
• Reveals unclear requirements and hidden risks.
• Encourages team ownership of estimates.
• Produces relative estimates rather than unreliable time commitments.

For mobile testing, discussion may reveal extra work such as testing multiple devices, permissions, network interruptions, and operating-system compatibility.

Sprint Planning is the Scrum event that initiates a sprint. The entire Scrum team collaborates to decide why the sprint is valuable, what can be completed, and how the work will be performed.

Inputs:

• Ordered Product Backlog
• Product Goal
• Current product increment
• Team capacity and availability
• Past performance or velocity
• Definition of Done
• Known risks and dependencies

Major discussions:

1. Why is the sprint valuable? The team defines the Sprint Goal.
2. What can be done? Developers select Product Backlog items based on priority and capacity.
3. How will the work be completed? Selected items are decomposed into tasks or an implementation plan.

Testing activities must be included, such as automation development, device testing, regression testing, and defect verification.

Outputs:

• A clear Sprint Goal
• Selected Product Backlog items
• A delivery plan for completing those items
• The resulting Sprint Backlog

Sprint Planning is not simply task assignment; it is a collaborative forecast made by the team performing the work.

Capacity represents the amount of working time or availability the team has during an upcoming sprint. Holidays, leave, training, support duties, and sprint length affect it.

Velocity is the amount of estimated work, usually measured in story points, that a team completed according to the Definition of Done in previous sprints.

Use in Sprint Planning:

• Calculate the available capacity for the upcoming sprint.
• Examine velocity across several recent sprints rather than relying on one sprint.
• Consider whether the team composition or sprint duration has changed.
• Select stories that support the Sprint Goal and are realistic for the available capacity.
• Reserve sufficient effort for testing, automation, integration, and defect resolution.

Precautions:

• Velocity is a planning aid, not a productivity target.
• It should not be used to compare different teams.
• Teams should not inflate story points to show higher performance.
• Only work meeting the Definition of Done should count as completed.
• A forecast must consider complexity and risk, not only historical averages.

Used responsibly, capacity and velocity improve predictability without turning estimates into rigid commitments.

Backlog Refinement is an ongoing collaborative activity in which the Scrum team reviews and prepares Product Backlog items for future sprints. It is sometimes called backlog grooming, although refinement is the preferred term.

Activities performed during refinement include:

• Clarifying business requirements and user value.
• Adding or improving acceptance criteria.
• Splitting large epics or stories into smaller items.
• Identifying technical, testing, and external dependencies.
• Discussing mobile device, operating-system, permission, security, and network requirements.
• Estimating or re-estimating stories using story points.
• Reordering items according to value, risk, and urgency.
• Removing obsolete or duplicate items.
• Identifying research spikes for uncertain work.

The Product Owner remains accountable for Product Backlog management, but refinement involves the whole Scrum team. Effective refinement ensures that high-priority items are sufficiently understood, appropriately sized, and testable before Sprint Planning.

Backlog Refinement and Sprint Planning differ as follows:

Relationship:

Effective refinement makes Sprint Planning shorter and more focused. However, refinement does not replace planning. During Sprint Planning, the team still considers current capacity, priority, dependencies, and the Sprint Goal before selecting work.

The Sprint Review is held near the end of a sprint to inspect the completed product increment and determine possible future adaptations.

Purpose:

• Evaluate the product outcome created during the sprint.
• Collect feedback from stakeholders.
• Review progress toward the Product Goal.
• Adapt the Product Backlog based on new information.

Typical activities:

• The team explains the Sprint Goal and what was completed.
• Completed mobile application features are demonstrated on relevant devices or environments.
• Stakeholders examine the increment and provide feedback.
• The Product Owner discusses current backlog status and product progress.
• Participants discuss market changes, user feedback, risks, and release plans.
• New requirements or changes are added to or reordered in the Product Backlog.

Only work that satisfies the Definition of Done should be treated as part of the completed increment. The Sprint Review should be a collaborative working session rather than merely a formal presentation.

The Sprint Retrospective is a Scrum event in which the team inspects how the previous sprint was performed and identifies ways to improve quality and effectiveness.

Areas examined include:

• Team communication and collaboration
• Processes and tools
• Definition of Done and quality practices
• Test automation and regression execution
• Defect patterns and root causes
• Impediments and dependencies
• Successful practices that should continue

Common retrospective techniques:

• Start, Stop, Continue: Identify practices to begin, discontinue, or retain.
• Mad, Sad, Glad: Discuss emotional responses to sprint events.
• 4Ls: Examine what the team liked, learned, lacked, and longed for.
• Five Whys: Repeatedly ask why to identify the root cause of a problem.
• Sailboat: Identify goals, supporting factors, obstacles, and risks.

The team should select a small number of realistic improvement actions, assign ownership when appropriate, and review progress in the next retrospective.

Both events inspect results and support adaptation, but they focus on different areas.

For example, stakeholders may request an improved mobile checkout flow during the Sprint Review. During the Sprint Retrospective, the team may decide to execute checkout automation earlier in every sprint to detect integration defects sooner.

A user story may progress through the Scrum cycle as follows:

1. Product Backlog creation: The Product Owner adds the story and orders it according to value, risk, and urgency.
2. Backlog Refinement: The team clarifies the story, defines acceptance criteria, identifies dependencies, discusses testability, splits it if necessary, and assigns story points.
3. Sprint Planning: The team considers priority and capacity, selects the story, connects it to the Sprint Goal, and prepares an implementation and testing plan.
4. Development and testing: Developers and testers collaborate to design, code, automate, integrate, and test the feature. Defects are resolved within the sprint where possible.
5. Definition of Done: The story is complete only when all agreed quality conditions are satisfied.
6. Sprint Review: The completed increment is demonstrated, and stakeholder feedback may create or reorder backlog items.
7. Sprint Retrospective: The team evaluates how effectively the story was delivered and chooses process improvements.

This lifecycle creates a continuous feedback loop in which product decisions and team practices are regularly inspected and adapted.

Example user story:

As a registered mobile application user, I want to log in securely using my email address and password so that I can access my account.

Acceptance criteria:

• The user can enter a valid registered email address and password.
• Valid credentials take the user to the account home screen.
• Invalid credentials display a clear error without revealing sensitive information.
• The password is masked by default.
• Required-field validation appears when either field is empty.
• The login request is transmitted securely.
• A loading indicator appears while authentication is in progress.
• A network failure displays a retry option without crashing the application.
• The feature works on supported devices and operating-system versions.

Estimation approach:

• Select a previously completed reference story.
• Consider UI implementation, API integration, security, validation, and session handling.
• Include testing across devices, network conditions, and operating systems.
• Consider automation, test data, dependencies, risks, and uncertainty.
• Use Planning Poker to reach a team estimate.

For example, the team might assign 8 story points if API integration and multi-device testing create greater complexity than a 5-point reference story. The value is relative and may differ between teams.

Agile welcomes change, but changes during a sprint must be managed without carelessly disrupting the Sprint Goal.

Handling changing requirements:

• The Product Owner and Developers discuss the effect of the change.
• The Sprint Backlog may be updated as more information becomes available.
• Scope can be renegotiated while preserving the Sprint Goal.
• A non-urgent change may be added to the Product Backlog for a future sprint.
• If the Sprint Goal becomes obsolete, the Product Owner may cancel the sprint, although this is uncommon.

Handling defects:

• Defects affecting current sprint stories should be resolved before those stories are considered done.
• Critical production defects may require immediate attention and replanning.
• Lower-priority defects can be added to and ordered in the Product Backlog.
• Automated regression tests should be added when suitable to prevent recurrence.
• Root causes and prevention measures can be discussed in the retrospective.

The team should maintain transparency, protect quality, and avoid declaring partially tested work complete merely to satisfy the original forecast.

The team can manage the sprint through the following stages:

1. Before Sprint Planning

• Refine high-priority stories such as product search, cart updates, and checkout.
• Add clear acceptance criteria and identify API, payment, device, and test-data dependencies.
• Estimate stories collaboratively using story points.

2. Sprint Planning

• Define a Sprint Goal, such as enabling users to add products to a cart reliably.
• Review capacity, past velocity, risks, and team availability.
• Select a realistic set of stories.
• Include coding, test automation, device testing, integration testing, and regression work in the delivery plan.

3. Sprint execution

• Collaborate daily and make progress visible.
• Integrate code frequently and run automated tests through continuous integration.
• Test supported screen sizes, operating systems, permissions, network conditions, interruptions, and orientation changes.
• Resolve defects early and update the Sprint Backlog when necessary.

4. Sprint Review

• Demonstrate only features meeting the Definition of Done.
• Gather feedback from stakeholders and adapt the Product Backlog.

5. Sprint Retrospective

• Examine quality, automation reliability, device coverage, communication, and escaped defects.
• Select measurable improvements, such as running critical regression tests on every build.

This approach integrates testing throughout the sprint instead of treating it as a final phase.