- Understand the principles behind the agile approach to software development - Differentiate between the testing role in agile projects compared with the role of testers in non-agile projects - Positively contribute as an agile team member focused on testing - Appreciate the challenges and difficulties associated with the non-testing activities performed in an agile team - Demonstrate a range of soft skills required by agile team members

1. Agile Testing
D A Y 1 – A G I L E P R O C E S S E S
S H U C H I S I N G L A , P M I - A C P , I T I L ( F ) A N D I S E B
1

2. Agenda - Day 1
Introduction to Agile
Test Approach – Agile Way
Roles in Agile
Exercise
2

3. Waterfall’s Demise
3
Problem
Serialized Process
Planning far in advance
Lack of visibility
Project Timeline
Static Requirements
Consequences
Strict sequential chain of the project phases.
Previous phase has to be completed before starting the next phase.
Products no longer match reality by the time they are released
Teams don’t realize they are behind schedule until end
Working model can only be seen at end
Timeline is planned at the start. If one phase is delayed all other phases are also delayed.
Requirements cannot be changed or modified in middle.
In larger and complex projects about 60% of the initial requirements are changed
throughout the project

4. Agile’s Rise
4
Problem
Serialized Process
Planning far in advance
Lack of visibility
Project Timeline
Static Requirements
Agile’s Solution
Iterative approach with tasks broken into small increments
Plan for what we know, and we have left sufficient allowance in our plans for what we don’t
know.
Allows customer feedback throughout the process. Expectations of the customer are reset
at the beginning of each new iteration based on the previous iteration.
Delivers working software frequently, from couple of weeks to months; with preference for
shorter time scale
Scope is never closed; Continual reassessment of requirement priorities by the business

5. Agile an Introduction
5

6. Agile - Introduction
6
Agile is an alternative to traditional waterfall, It helps teams respond to unpredictability through
incremental, iterative work cadences, known as sprints.

7. 12 Principles..
Our highest priority is to satisfy the customer through early and continuous
delivery of valuable software.
Welcome changing requirements, even late in development. Agile processes
harness change for the customer's competitive advantage.
Deliver working software frequently, from a couple of weeks to a couple of months,
with a preference to the shorter timescale.
Business people and developers must work together daily throughout the project.
Build projects around motivated individuals. Give them the environment and
support they need, and trust them to get the job done.
The most efficient and effective method of conveying information to and within a
development team is face-to-face conversation.
7

8. 12 Principles..
Working software is the primary measure of progress.
Agile processes promote sustainable development. The sponsors, developers, and
users should be able to maintain a constant pace indefinitely.
Continuous attention to technical excellence and good design enhances agility.
Simplicity — the art of maximizing the amount of work not done — is essential.
The best architectures, requirements, and designs emerge from self-organizing
teams.
At regular intervals, the team reflects on how to become more effective, then tunes
and adjusts its behavior accordingly.
8

9. Agile Manifesto
9

10. Agile Manifesto
We are uncovering better ways of developing software by doing it and helping others do it.
Through this work we have come to value:
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
That is, while there is value in the items on the right, we value the items on the left more.
10

11. Individuals and interactions over
processes and tools
Focus on empowered, self-managing teams
Autonomous teams do not need the day-to-day intervention of management
Management protects team from outside interference
Agile teams are amalgamation of varied professional skills
Agile team members are able to step in for each other as necessary
11

12. Working software over comprehensive
documentation
Traditionally we measure progress by the percent complete of the functional milestones
Agile teams provide actual working product as a status report, “product review”
Design changes as the system is built, results in outdated documentation
Agile teams prefer face-to-face communication over documentation which is simpler, faster,
and more reliable
12

13. Customer collaboration over contract
negotiation
Contract negotiation, Identify and define everything and spells out the payment and date
specifications
Customers become a part of the development process
Writing specs down and throwing them over the fence is simply not effective
13

14. Responding to change over following a
plan
It’s much easier to respond to change when the organization and the customer share a clear
understanding of the project’s status
In plan-driven environments, all requirements are specified up front, broken down to the task
level and estimated
Agile plans follow more of a rolling wave approach using top-down planning
14

15. Agile Methodology
15

16. Introduction to Agile Methodology
Agile methodologies embrace iterations
Small teams work together with stakeholders to describe requirements for the iteration,
develops the code, and defines and runs integrated test scripts, and the users verify the
results
It promotes adaptive planning, evolutionary development & delivery, a time-boxed iterative
approach, and encourages rapid and flexible response to change
16

17. DSDM
17
Dynamic Systems Development Method focuses on:
Delivery of the business solution, rather than just team activity.
Ensure the feasibility of a project before it is created.
It stresses cooperation and collaboration between all interested parties.
Makes heavy use of prototyping to make sure interested parties have a clear picture of all aspects of
the system.

18. DSDM
18

19. Scrum
19

20. Test Approach – Agile Way
20

21. Test Approach – Agile Way
21

22. Session Based Testing
A method specifically designed to make
exploratory testing auditable and
measurable on a wider scale.

23. Session Based Structure
Charter
Session
ReportDebrief
Parsing
Results

24. Agile Quality – A Team Deliverable
Agile Practice Benefits
Whole Team • Quality is not just a tester responsibility
• Quality is more than just testing
• Testing role shifts to quality infusion throughout
project life cycle
Continuous Integration • Developers cannot check in code with failing tests
Continuous Testing • Avoids long delays with “big-bang” testing after the
“final build”
• Bugs found closer to when they are introduced
making them easier to fix

25. Agile Testing Challenges
Team may not value testers
Testers may not value team
Unclear role of testers on team
Testing is often squeezed as deadlines approach
Developers and testers are often in different operational silos
Team may not have the skills or domain expertise to develop/test effectively

26. Agile Testing Approach
Testers are first class citizens on agile teams and part of the “whole team”
supporting customers, business stakeholders, developers and other team
members
Testers support quality infusion through entire team and product cycle
Test tasks and stories are planned and executed like development tasks and
stories
Automate where possible and use session-based testing for exploratory
testing
Communicate through information radiators

27. CritiquesProduct
SupportsDevelopment
Brian Marick’s Agile Testing Matrix
Functional Tests
Customer Tests
Story Tests/Examples
User Acceptance Tests
Exploratory Tests
Usability Tests
Unit Tests
Integration Tests
Performance Tests
Load Tests
Customer Facing
Technology Facing
Automate
Tools
Manual
Q1
Q2 Q3
Q4
Automate

28. CritiquesProduct
SupportsDevelopment
Tester Activities
Product Specifications
Test Ideas
Testing
UAT Design
Exploratory Testing
Usability Testing
Test Ideas
Test Development
Testing
Test Scripts
Testing
Test Analysis
Customer Facing
Technology Facing
Product Owner
Collaboration
IT
Collaboration
Customer
Collaboration
Developer
Collaboration
Q1
Q2 Q3
Q4

29. Agile Testing Iterations
Previous
Iteration
Stories
Working
Product
Q3, Q4:
Product
Testing
Current
Iteration
Stories
Working
Product
Q1:
Testing &
Collaboration
Next
Iteration
Stories
Working
Product
Q2:
Planning &
Test Ideas

30. Roles in Agile
30

31. Agile Team
31

32. Product Owner
Single person responsible for maximizing the return on investment (ROI)
of the development effort
Responsible for product vision
Constantly re-prioritizes the Product Backlog
Final arbiter of requirements questions
Accepts or rejects each product increment
Decides whether to ship
Decides whether to continue development
Considers stakeholder interests

33. Scrum Development Team
Cross-functional (e.g., includes members with testing skills, and often others not traditionally
called developers: business analysts, domain experts, etc.)
Self-organizing / self-managing, without externally assigned roles
Negotiates commitments with the Product Owner, one Sprint at a time
Intensely collaborative
Most successful when located in one team room, particularly for the first few Sprints
7 ± 2 members
Has a leadership role

34. Scrum Master
Facilitates the Scrum process
Helps resolve impediments
Creates an environment conducive to team self-organization
Captures empirical data to adjust forecasts
Shields the team from external interference and distractions to keep it in group flow (a.k.a. the
zone)
Enforces timeboxes
Keeps Scrum artifacts visible
Has no management authority over the team
Has a leadership role