Agile Testing 1210187639850462 9

Agile Testing
Embrace Uncertainty Naresh Jain naresh@agilefaqs.com
Licensed Under Creative Commons by Naresh Jain

1
Objective
Introduce Agile Testing Concepts Some background about Agile Compare with Traditional Testing practices Highlight the fundamental shift in Thought Process Discuss some tools and techniques used Some pointers to help you try some of these techniques

2
Traditional Software Development

With great optimism and the best of intentions, The Project Plan is announced
Analyze
Design
Code
Test/Bug Fix
s ent Dev m ire f to qu Re ed of and H
e od t C ed o Tes t ple off t m Co ded han

Source Agile/QA Testing - Elisabeth Hendrickson

3

With great optimism and the best of intentions, The Project Plan is announced
Analyze
Design
Code
Test/Bug Fix
s ent Dev m ire f to qu Re ed of and H
e od t C ed o Tes t ple off t m Co ded han

Release

3
Reality
Inevitably, the project plan is revised
Analyze, Design and Code
Test/Bug Fix
e od t C s ted to Te ple off m Co ded han


4
Reality
Inevitably, the project plan is revised
Analyze, Design and Code
Test/Bug Fix
e od t C s ted to Te ple off m Co ded han

Release

4
Controlling the Chaos

5

Traditional testing practices attempt to manage the chaos (or at least avoid the blame):

5

Traditional testing practices attempt to manage the chaos (or at least avoid the blame): Last Defender of Quality stance

5

Traditional testing practices attempt to manage the chaos (or at least avoid the blame): Last Defender of Quality stance Strict change management

5

Traditional testing practices attempt to manage the chaos (or at least avoid the blame): Last Defender of Quality stance Strict change management Detailed preparation and up front planning

5

Traditional testing practices attempt to manage the chaos (or at least avoid the blame): Last Defender of Quality stance Strict change management Detailed preparation and up front planning Heavyweight documentation

5

Traditional testing practices attempt to manage the chaos (or at least avoid the blame): Last Defender of Quality stance Strict change management Detailed preparation and up front planning Heavyweight documentation Strict entrance and exit criteria with sign-offs

5

Traditional testing practices attempt to manage the chaos (or at least avoid the blame): Last Defender of Quality stance Strict change management Detailed preparation and up front planning Heavyweight documentation Strict entrance and exit criteria with sign-offs Heavyweight test automation focused on regression

5

Traditional testing practices attempt to manage the chaos (or at least avoid the blame): Last Defender of Quality stance Strict change management Detailed preparation and up front planning Heavyweight documentation Strict entrance and exit criteria with sign-offs Heavyweight test automation focused on regression Attempts at process enforcement
5
Project Management Triangle

6
Project Management Triangle
op e
Quality ??
Tim
Sc
e
6
Cost/Resource
Lower cost of change through higher quality software

Traditional cost prole

7

Time spent: Finding defects Fixing Defects Regression Testing Deploying

7

Time spent: Finding defects Fixing Defects Regression Testing Deploying
Agile system cost prole
More defects found & corrected causes lower cost of defect correction

7
Building Quality into the Process

8
Building Quality into the Process
Toyoda Loom

8
Lessons from Queuing theory
Utilization (%)
Source: Beyond Agile Software Development Becoming Lean, Mary Poppendieck, Poppendieck.llc

9

10

10
50 % done?

10
Applying Lean Principles to Software Development ... A better way of doing the same

11
End-to-End small slices of work

11
End-to-End small slices of work
20 % done = 100 % usable

11
Traditional vs Agile
Project Plan/Estimation Requirements Gathering Use Cases / Functional Specs Design Specifications Code Test Fix / Integrate Inception $
$ $

12
Agile = Continuous Stream of Value

Release 1 Release 2
iteration iteration iteration iteration iteration iteration iteration 1 2 3 4 5 6 7
Completed Working Features Designed, Coded and Tested


13
Agile = Continuous Stream of Value

Release 1 Release 2
iteration iteration iteration iteration iteration iteration iteration 1 2 3 4 5 6 7
Completed Working Features Designed, Coded and Tested


13
Becoming Agile : Delivering Value

Increase the rate of delivery (usually with smaller increments)

14
Becoming Agile : Increasing Feedback
Increase the rate and quality of feedback

15
Becoming Agile : Reducing Waste
Reduce waste

16
Agile Umbrella
Agile
XP DSDM Adaptive Crystal Lean Pragmatic FDD
Scrum

17
A typical XP Project

18
Project 1 year

18
Project Releases 1 year 3 months

18
Project Releases Iterations 1 year 3 months 2 weeks

18
Project Releases Iterations Days 1 year 3 months 2 weeks 1 day

18
Tasks
2 hrs

18
Tasks
2 hrs
Test-Code-Refactor Cycles
15 min

18
Source : http://www.extremeprogramming.org

19
Key Questions
Business Facing
Are we building the right product? Are we building the product right?
Technology Facing
20
Brian Maricks Test Categorization

Business Facing Supports Programming Critique product
Technology Facing
21
Brian Maricks Test Categorization

Business Facing Supports Programming
Acceptance Testing Exploratory Testing Low- prototypes UI and Usability Testing Unit Testing Performance Testing
Critique product
Technology Facing
22
Acceptance Test Driven Development

23
Story

23

Acceptance Criteria Story

23

Iteration

23

Automated Acceptance Tests
Iteration

23

Iteration
Automated Unit Test

23

Iteration
Automated Unit Test

23

Iteration
Automated Unit Test
Automated Acceptance Tests Exploratory Testing

23

Iteration
Automated Unit Test
Acceptance Criteria
23

Iteration
Automated Unit Test
Automated UI Tests
Acceptance Criteria
23

Iteration P E R F O R M E N C E
Automated Unit Test
Automated UI Tests
T E S T S
Acceptance Criteria
23
Test Driven Development
TDD Rhythm - Test, Code, Refactor

24

Add a Test

24

Add a Test Run the Test

24

Add a Test
Pass
Run the Test

24

Add a Test
Pass
Run the Test

Fail

24

Add a Test
Pass
Run the Test

Fail
Make a little change

24

Add a Test
Pass
Run the Test

Fail
Make a little change Run the Test

24

Add a Test
Pass
Run the Test

Fail

Fail

24

Add a Test
Pass
Run the Test

Fail

Pass Fail

24

Add a Test
Pass
Run the Test

Fail

Pass Fail
Refactor
24

Add a Test
Pass
Run the Test

Fail

Pass Fail
Refactor
24

Add a Test
Pass
Run the Test

Fail

Pass Fail
Refactor
24

Add a Test
Pass
Run the Test

Fail

Pass Fail
Refactor
24
Mike Cohns Testing Pyramid

25

GUI Tests

25

GUI Tests
Small in Number Tools: Selenium, Sahi, Watir, Abbot, Frankenstein

25

GUI Tests
Small in Number Tools: Selenium, Sahi, Watir, Abbot, Frankenstein
Acceptance Tests

25

GUI Tests
Small in Number Tools: Selenium, Sahi, Watir, Abbot, Frankenstein At least one per story Tools: Fit, FitNesse, RSpec, JBehave
Acceptance Tests

25

GUI Tests
Acceptance Tests
Unit Tests
25

GUI Tests
Acceptance Tests
Unit Tests
At least one per class or module Tools: xUnit, TestNG

25
FitNesse and Selenium Demo

26
What is the Role of a Tester on Agile Projects?

27

Testers are part of the team

27

Testers are part of the team Works closely with customers to dene acceptance tests for each story

27

Testers are part of the team Works closely with customers to dene acceptance tests for each story Tests each story as it is complete

27

Testers are part of the team Works closely with customers to dene acceptance tests for each story Tests each story as it is complete Practices pair testing

27

Testers are part of the team Works closely with customers to dene acceptance tests for each story Tests each story as it is complete Practices pair testing Provides continuous feedback to the team

27

Testers are part of the team Works closely with customers to dene acceptance tests for each story Tests each story as it is complete Practices pair testing Provides continuous feedback to the team Works closely with developers to do performance and other types of testing
27
Challenges

28
Challenges
Technical Requirements are changing Bringing Testing Forward Moving from Manual Testing to Automation

28
Challenges
Technical Requirements are changing Bringing Testing Forward Moving from Manual Testing to Automation Organizational Tester/Developer roles are blurred Dev/Test Teams might be separate Everyone has not bought into agile practices
28
Challenges
Technical Requirements are changing Bringing Testing Forward Moving from Manual Testing to Automation Organizational Tester/Developer roles are blurred Dev/Test Teams might be separate Everyone has not bought into agile practices People
28
References
Agile/QA Testing - Elisabeth Hendrickson "Agile Testing Directions" - Brian Marick Beck, K. (1999). Extreme Programming Explained: Embrace Change. Addison-Wesley. Cockburn, A. (2004). Crystal Clear: A Human- Powered Methodology for Small Teams. Crispin, L., & House, T. (2002). Testing Extreme Programming. AddisonWesley. Poppendieck, M. & Poppendieck, T. (2003). Lean Software Development. Addison-Wesley. Schwaber, K. & Beedle, M. (2001). Agile Software Development with SCRUM. Prentice Hall. http://www.extremeprogramming.org
29

Agile Testing 1210187639850462 9

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Agile Testing 1210187639850462 9

Uploaded by

Copyright:

Available Formats

Agile Testing

Embrace Uncertainty Naresh Jain naresh@agilefaqs.com

Licensed Under Creative Commons by Naresh Jain

Licensed Under Creative Commons by Naresh Jain

Traditional Software Development

s ent Dev m ire f to qu Re ed of and H

e od t C ed o Tes t ple off t m Co ded han

Licensed Under Creative Commons by Naresh Jain

Traditional Software Development

s ent Dev m ire f to qu Re ed of and H

e od t C ed o Tes t ple off t m Co ded han

Licensed Under Creative Commons by Naresh Jain

Analyze, Design and Code

e od t C s ted to Te ple off m Co ded han

Licensed Under Creative Commons by Naresh Jain

Analyze, Design and Code

e od t C s ted to Te ple off m Co ded han

Licensed Under Creative Commons by Naresh Jain

Controlling the Chaos

Source Agile/QA Testing - Elisabeth Hendrickson

Licensed Under Creative Commons by Naresh Jain

Controlling the Chaos

Source Agile/QA Testing - Elisabeth Hendrickson

Licensed Under Creative Commons by Naresh Jain

Controlling the Chaos

Source Agile/QA Testing - Elisabeth Hendrickson

Licensed Under Creative Commons by Naresh Jain

Controlling the Chaos

Source Agile/QA Testing - Elisabeth Hendrickson

Licensed Under Creative Commons by Naresh Jain

Controlling the Chaos

Source Agile/QA Testing - Elisabeth Hendrickson

Licensed Under Creative Commons by Naresh Jain

Controlling the Chaos

Source Agile/QA Testing - Elisabeth Hendrickson

Licensed Under Creative Commons by Naresh Jain

Controlling the Chaos

Source Agile/QA Testing - Elisabeth Hendrickson

Licensed Under Creative Commons by Naresh Jain

Controlling the Chaos

Licensed Under Creative Commons by Naresh Jain

Controlling the Chaos

Licensed Under Creative Commons by Naresh Jain

Project Management Triangle

Licensed Under Creative Commons by Naresh Jain

Project Management Triangle

Lower cost of change through higher quality software

Licensed Under Creative Commons by Naresh Jain

Lower cost of change through higher quality software

Time spent: Finding defects Fixing Defects Regression Testing Deploying

Licensed Under Creative Commons by Naresh Jain

Lower cost of change through higher quality software

Time spent: Finding defects Fixing Defects Regression Testing Deploying

Agile system cost prole

Licensed Under Creative Commons by Naresh Jain

Building Quality into the Process

Licensed Under Creative Commons by Naresh Jain

Building Quality into the Process

Licensed Under Creative Commons by Naresh Jain

Lessons from Queuing theory

Licensed Under Creative Commons by Naresh Jain

Traditional Software Development

Licensed Under Creative Commons by Naresh Jain