Agile testing is a software testing practice that
follows the principles of agile software
Involves all members of a cross-functional
agile team, with special expertise contributed
by testers, to ensure delivering the business
value desired by the customer at frequent
intervals, working at a sustainable pace
The role of Agile Testing
Agile teams do need testers
with strong testing skills
They might need QA in a different form/shape!
Your function is to support the business by
helping them understand the business and
The 9 principles...
Testing moves the project
Testing is not a phase
On traditional projects, independent testers are responsible
for all test activities.
In Agile, getting the testing done is the responsibility of the
whole team. Yes, testers execute tests. Developers do too.
The need to get all testing done in an iteration may
mean that the team simply cannot do as much in
each sprint as they originally thought.
If yes, then Agile has made visible the impedance mismatch
between test and dev that already existed.
The team was not going as fast as they thought. They
appeared to be going quickly because the developers were
going fast. But if the testing isn't done, then the features
aren't done, and the team just does not have the velocity they
Goldratt's TOC says that the whole team can only
go as fast as the slowest part.
To go faster, the team has to widen the throughput of the
Reduce feedback latency
Test Planning for one release – in
- Merges ~ all 6.2 HF1 -6.2HF6 = 150 defects
Dev Build Start
Test Case Development
Cal Total Reso
Days PDs urces Rate
QA ,QA Aryaans
Regression Testing ~Tier3 (1000 testcases)-need to
skip incase of bandwidth issue
Test Case Development
6.3 CHR Testing [Estimated Cases ~ 1000]
Merge Defect Validation all 6.2 HF1 -6.2HF5 defects
3.5 100 tc/day/person
Only rejected defects and automation run critical fixes
Acceptance Scenario and Unautomated sanity Testing
Regression Testing ~6000 testcases (Tier1,Tier2 and
Tier3 ;these are non automated cases of the modules
related to the defects tagged for 6.3 on dhruva)
02-03-11 08-03-11 - 5 cal days -(2000 testcases)
4 QA Aryaans
10 Resources - 80 tc/day/person to fill in the
bandwidth for execution of 4000 testcases for 5 cal
- Defect Validation - QA Initiator Closure ~ 50 +
- CHR Defects ~100
QA - Aryaans + 1 QA
Defect Validation - Merges ~75
Regression Testing(Unexecuted) ~ 100 testcases
Initiator Closure Defect Validation (CHR + Regression )
3 15 defects /day /person
So, 60mm of DCUT needed 20-25mm (10mm for testing + 10 developers
for supporting all defects from testing) over a period of 6-8 weeks to make a
Team is delivering continuously...
Changes to scope can be taken anytime and delivered in 3-4 weeks
Testing is part of the Development process
Everyone tests! Development automates UTC; Testing automates ST
Tests Represent Expectations
Fix bugs asap... keep the code
Reduce test documentation
Lightweight Documentation: Instead of
writing verbose, comprehensive test
documentation, Agile testers:
Use reusable checklists to suggest tests
Focus on the essence of the test rather than the
Use lightweight documentation styles/tools
Capturing test ideas in charters for Exploratory
Leverage documents for multiple purpose
Leverage One Test Artifact for Manual and
Today, we invest in extensive, heavyweight step-bystep manual test scripts in Word or a test
Instead, capture expectations in a format supported
by automated test frameworks like FIT/Fitnesse.
The test could be executed manually
More importantly that same test artifact becomes an
Tested is part of “DONE”
Test Driven (not Testing Last)
4 key practices
Test Driven Development
Automated System-Level Regression
Acceptance Test Driven
The testing pyramid...
In most environments
But let us understand this in more
Impact of Agile Requirements
Agile testing must be iterative
Agile testers cannot rely on having complete
Agile testers must be flexible
The techniques exist to make this possible...
Testing in the Agile world...
Let us discuss these test cycle
Development Team Testing:
Testers are embedded in the development team, working side by side to build the
Focus of their testing efforts are often on confirmatory testing
Agile teams will take a whole team approach
Developer regression testing or better Test-Driven Development (TDD).
Parallel independent testing.
Continuous independent testing parallel to construction iterations throughout the
Goal: find defects that got past the development team
Perform higher forms of testing such as system integration testing, security testing,
Need significant testing skills, complex tools, and often complex pre-production testing
10-15:1 ratio between people on the 2 teams
In larger organizations, one team can support several development teams
Where can you apply
doc - JIT
Seen more with pair
What happens when
we extend this to the
TDD at the requirement
Acceptance TC is a
expectation of the
Write a single
acceptance test; make
code changes to pass it
Requirement spec (JIT)
If you do ATDD, you
don’t need to TDD
Also, called BDD or
Some industry trends...
Some industry trends...
Implications for Test Practioners
Become generalizing specialists
Be prepared to work closely with developers.
Once again, be flexible.
Focus on value-added activities
and again... Be flexible
Finally... Why Agile Testing
Speed needs discipline – the fast car vs slow car analogy
Agile teams will take a whole team approachTesters are embedded in the development team, working side by side to build the systemFocus of their testing efforts are often on confirmatory testingdeveloper regression testing or better Test-Driven Development (TDD).
Business Facing: means functional test casesTechnology Facing: means technical test cases like for cross browser support. However, what browser should be dominant browser is still a business decision.Critique Product Testing: typically defect discovery processSupport Development Testing: testing that supports ability to make code changes (regression)
Become generalizing specialists. The implication of whole team testing is that most existing test professionals will need to be prepared to do more than just testing if they want to be involved with agile projects. Yes, the people on independent test teams would still focus solely on testing, but the need for people in this role is much less than the need for people with testing skills to be active members of agile delivery teams.Be flexible. Agile teams take an iterative and collaborative approach which embraces changing requirements. The implication is that gone are the days of having a detailed requirements speculation to work from, now anyone involved with testing must be flexible enough to test throughout the entire life cycle even when the requirements are changing.Be prepared to work closely with developers. The majority of the testing effort is performed by the agile delivery team itself, not by independent testers. Be flexible. This is worth repeating. ;-)Focus on value-added activities. I've lost track of the number of times I've heard test professionals lament that there's never enough time nor resources allocated to testing efforts. Yet, when I explore what these people want to do, I find that they want to wait to have detailed requirements speculations available to them, they want to develop documents describing their test strategies, they want to write detailed test plans, they want to write detailed defect reports, and yes, they even want to write and then run tests. No wonder they don't have enough time to get all this work done! The true value added activities which testers provide are finding and then communicating potential defects to the people responsible for fixing them. To do this they clearly need to create and run tests, all the other activities that I listed previously are ancillary at best to this effort. Waiting for requirements speculations isn't testing. Writing test strategies and plans aren't testing. Writing defect reports might be of value, but there are better ways to communicate information than writing documentation. Agile strategies focus on the value-added activities and minimize if not eliminate the bureaucratic waste which is systemic in many organizations following classical/traditional strategies.Be flexible. This is really important.