- 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
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
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
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.
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
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
Editor's Notes
Failure to meet the purpose / solve the problem it was designed for - DSDM allows for user testing all through the development process, thus allowing developers to get prompt feedback on the usability and suitability of the product.
Cost outweighs benefits, or cost is too high altogether - In DSDM, a Business Study is done at the beginning of the project, greatly decreasing the likelihood of late surprises in the financial realm.
Poor communication between involved parties - DSDM stresses communication and collaboration between all interested parties - developers, users, etc.
The users finds the program either too hard to use that it does not work as expected - DSDM allows for user testing all through the development process, thus allowing developers to get prompt feedback on the usability and suitability of the product.
Hidden flaws surface in the system due to poor design or implementation - In DSDM, prototyping helps to ensure that the system is designed correctly and that everyone knows how it will work. Unit testing helps to uncover hidden bugs, and incremental development allows for user testing all through the development process.
Users resist the instantiation of the system, either for political reasons, or a lack of commitment to it - In DSDM, since the users are actively involved in the development of the system, they are more likely to embrace it and take it on.
The system is in-flexible and/or un-maintainable, and unable to adapt to change - Since DSDM emphasizes flexibility in design, this is not likely to happen with DSDM.
Scrum, occurs in small pieces, with each piece building upon previously created pieces. Scrum emphasizes empirical feedback, team self management, and striving to build properly tested product increments within short iterations.
Unlike XP, Scrum methodology includes both managerial and development processes.
this emphasis on an ongoing assessment of completed work is largely responsible for its popularity with managers and developers alike. But what allows the Scrum methodology to really work is a set of roles, responsibilities, and meetings that never change. If Scrum’s capacity for adaption and flexibility makes it an appealing option, the stability of its practices give teams something to lean on when development gets chaotic.
Team sprint focus is to get a failing customer to pass.
Team daily focus is to get failing developer tests to pass and then refactor.
Q1: Test Driven Development
Measure “internal quality” of system
Small unit tests drive design of small part of code.
Larger integration tests drive system design
Automated, in same language, done by programmers
Run often and at every checkin
Q2: Story Driven Development
Measure “external quality” of system
Story tests drive higher level system design
Tests are more functional; more examples & combinations
Tests boundary conditions, error handling, presentation
Q3:
Some tests in Q2 may be incorrect or incomplete
Team may misunderstand, agile customer may omit or forget something
Emulate how a real user would use the system
Manual testing – requires a human
Exploratory/session based testing
Q4:
Performance, robustness, security etc.
Sometimes not given enough focus on agile teams
Often requires specialized tools & expertise
* Tests on right hand side feed into stories/tasks for left hand side
Q1: Test Driven Development
Measure “internal quality” of system
Small unit tests drive design of small part of code.
Larger integration tests drive system design
Automated, in same language, done by programmers
Run often and at every checkin
Q2: Story Driven Development
Measure “external quality” of system
Story tests drive higher level system design
Tests are more functional; more examples & combinations
Tests boundary conditions, error handling, presentation
Q3:
Some tests in Q2 may be incorrect or incomplete
Team may misunderstand, agile customer may omit or forget something
Emulate how a real user would use the system
Manual testing – requires a human
Exploratory/session based testing
Q4:
Performance, robustness, security etc.
Sometimes not given enough focus on agile teams
Often requires specialized tools & expertise
* Tests on right hand side feed into stories/tasks for left hand side
pair testers with developers for:
exploratory testing
testing bug fixes
recreating newly found bugs
automating tests
fixing and testing "trivial" bugs as they are found - bugs that will only get fixed in geological timeframes
have testers report on overall product quality (I was recently introduced to "Low Tech Testing Dashboards" by Paul Carvalho that is perfect for this)
use testers as "consultants" and treat them as experts
shift testers to a lead role directing whole team testing close to release
use cards to drive exploratory test sessions
consider bringing in "outside" testers for fresh perspectives
voids the waste of tracking