GETTING THINGS DONE WHAT TESTERS DO IN AGILE SPRINTS

© 2021 Robert Sabourin 1

GETTING THINGS DONEWHAT TESTERS DO IN AGILE SPRINTS

Agile Testing Blends …

• Doing the right thing

• Eliciting user stories

• Domain knowledge

Validation

• Doing the thing right

• Test-driven development

• Automated story testing

Verification

• Learning

• Adapting

• “To boldly go ...”

Exploration


1

2


Testing Is a Skill Set

Skills

• Specialized

• Competencies

• Approaches

• Methods

• Techniques


Testing in Agile Projects Supports…

• Customers

• Developers

• “Stakeholders”


3

4


Scrum


Quality

• Agile teams do not have quality police


5

6


Quality

• Agile team members share responsibility for product quality


Team Approach to Testing

• Testing activities

– Testing activities can be done by any suitably qualified team members

– Development activities can be done by any suitably qualified team members

– Developers should be able to take on some testing activities

– Testers should be able to take on some development activities


7

8


Coaching

Programmers

Testers


TESTING’S ROLE IN PLANNING

Planning


9

10


Testing’s Role in Planning

Testing is a critical part of planning

Elaborate and clarify story tests with customers and users

Identify testing activities to support development


BACKLOG GROOMING

Planning


11

12


Story Grooming Sessions

•High priority stories

•Groomed prior to implementation

•Objectives: understand, clarify, examples, estimate

Improve stories

•Team elicits acceptance tests (examples) from product owner

•Consider normal, alternate and error flows of story

Elicit acceptance tests

•Clarify description

•Explore alternate interpretations

Clear up ambiguities



• All team members participate

• Diverse perspectives discussed

Team building

• Invest a fixed amount of time

• Do not have to review all stories in one session

Time-boxing

• Team estimates story size

• All work is considered

Get team buy in


13

14



•Clarify & understand story

•Elicit acceptance tests

•Relate new stories to existing functionality

Wisdom: good points


TESTING ACTIVITIES IN THE SPRINT

Planning


15

16


Whiteboarding

Co

mp

are

Desig

n

Alt

ern

ati

ves


Sprint Backlog Tasks

Sprint planning meeting

The team breaks each Sprint backlog entry into tasks

Development, testing and documentation activities are planned together


17

18


Testing Activities in Sprint Backlog

Basis for testing

Story

Acceptance tests

Technical work

Product use

Environment



Infrastructure tasks

Tools

Frameworks

Test automation

Test environments


19

20



Test data tasks

Generation

Capturing

Organization

Validation



Non-functional testing tasks

Experiments to study quality factors

Static analysis

Collecting and analyzing information from test frameworks


21

22



Functional testing tasks

Confirmation of developed features

Story testing

Cross-functional testing



Software robustness tasks

Attacks

Failure modes

Error recovery


23

24



Exploratory testing tasks

Close gaps in testing

Look for interactions between stories

Experience-based testing


Structure Related Testing Activities

• Team explores design alternatives

– Elements being added

– Elements to be changed

– Elements to be deleted

– Third party components being integrated

– Reuse objects

– Repurpose objects


25

26



• Team identifies testing tasks related to elements being changed

– Access element being changed

– Gets data from element being changed

– Controls element being changed

– Observes element being changed

– Invokes element being changed



• Testing tasks relate to exercising

– Other features

– Workflows

– Business process

– Data flows

– Usage scenarios


27

28



• Implement testable code– Controllable

• Ensure all features or characteristics can be controlled• Anything a user can do or an event can trigger should

be controllable

– Observable• Ensure application variables can be set and queried

programmatically

– Defined API exists for all aspects of the product being developed

– Add fixtures to allow for automated story tests


Static Analysis at Build Time

• When building software many metrics can be captured using static analysis tools

– Code size

– Code complexity

– Code standard compliance

– Potential security risks


29

30


TEST-DRIVEN DEVELOPMENT

In the Heat of the Sprint


Test-Driven Development

www.extremeprogramming.org

“There is a rhythm to developing software unit test first. You create one test to define some

small aspect of the problem at hand. Then you create the simplest code that will make that

test pass. Then you create a second test. Now you add to the code you just created to make this new test pass, but no more! Not until you have yet a third test. You continue until there

is nothing left to test.”


31

32



Elisabeth Hendrickson

Quality Tree Software, Inc.

“When practicing TDD, I use each test as a way to express an expectation about the code that isn't true yet. Then I make

that expectation true, refactor the code, and move on to expressing the next expectation. It's a little like writing an

article by deciding what question to answer next in the prose.”



Begin with the end in mind

Define test

Implement test

Then “Develop the simplest code to pass the test”


33

34



How experienced testers may help

Many developers have limited expertise in test design

Test design experts can coach developers and offer peer reviews and critiques to help improve unit tests and design test data sets



• Robert C. Martin’s Three Laws of Test-Driven Development

1. “You may not write production code until you have written a failing unit test.”

2. “You may not write more of a unit test than is sufficient to fail, and not compiling is failing.”

3. “You may not write more production code than is sufficient to pass the currently failing test.”


35

36



Red Green Refactor

Kent

Beck© 2015 Robert Sabourin 37

ACCEPTANCE TEST DRIVEN DEVELOPMENT



37

38

http://en.wikipedia.org/wiki/File:Kent_Beck_no_Workshop_Mapping_XP.jpg


Acceptance Test Driven Development

ATDD

Business facing examples

Elicited from customers

Concrete goals

Guide and focus development

Basis for top down regression


Acceptance

Test Driven

Development


39

40


BEHAVIOUR DRIVEN DEVELOPMENT



Behaviour Driven Development

• David Chelimsky - 2010

– “Behaviour-driven development is about implementing an application by describing its behavior from the perspective of its stakeholders.”


41

42



• Describing behaviour

– Given

• Something true

• A precondition

– When

• Event

• Trigger

– Then

• Expected outcome

• Ending state



• Example description with Given/When/Then tirade:

Given I have $100 in checking

And I have $20 in savings

When I transfer $15 from checking

to savings

Then I should have $85 in checking

And I should have $35 in savings


43

44


EXPLORATORY TESTING



Exploratory Testing

Learning

DesignExecution


45

46


Exploratory Testing

• “Exploratory software testing is a style of software testing that emphasizes the personal freedom and responsibility of the individual tester to continually optimize the value of her work by treating test-related learning, test design, test execution, and test result interpretation as mutually supportive activities that run in parallel throughout the project.”

— Cem Kaner’s Blog :

On the craft and community of software testing


Exploratory Testing: A New Perspective

Find gaps in automated

tests

Holes

Omissions

Inconsistencies

Emergent behaviors

Surprises

Side effects

Weakness

Attributes across story boundaries

Security

Performance

Characteristics


47

48


Charter Statement

• Statement of mission

• Ties to purpose

• Focuses work

• Confirms understanding

• Delineates scope


Charter Types

• Capabilities

• Across Story Relationships

• Failure Modes

• Robustness

• Quality Factors

• Usage Scenarios

• End to End

• Creative Ideas

• States

• Sequences

• Data

• Environments

• White Box


49

50


Exploration Notes

Take notes

about test

decisions

Map out

where you

have been

and what you

discovered


Timeboxed Sessions

• About two hours

• Uninterrupted

• FocusedTypical

• 15–30 minutes

• Punctual

• ConfirmationsShort

• Several hours or days

• Experiments

• Non-functional chartersLong


51

52


Press pause button

• After timebox we stop

• Can resume later

Review findings

• What works?

• What does not work?

• What did we learn?

• What do we want to learn more about?

Did we learn enough?

• Will we benefit from another session on the same charter?

• Should we try a new charter?

At End of Session


Session-based Exploratory Testing

Kick Off

Prepare

Run

Complete

Review

Follow Up

Confirm charter

Ready environment

Prepare data

Session 90–120 min

Learn Design Execute

Wrap up

Collect all notes data

Review findings

Reassess goals

Piece together map


53

54


Pairing Testers with …

•Improve observation

•Feed off other’s experiences

•“XP” ish

Other testers

•White box perspective

•What is it programmed to do?

•What is it supposed to do?

Developers


Pairing Testers with …

• Access correctness

• Drive from business perspective

• Identify missing functionality

Subject matter experts

• Usability gurus

• Performance engineers

• Security experts

Test domain experts


55

56


Heuristics


Heuristics

Guide exploration

Rules of thumb

Fallible but useful


57

58


Some Example Test Heuristics

• Create Read Update DeleteCRUD

• Too Big, Too Small, Just RightGoldilocks

• Application Logic, Input Method, MemoryTake AIM

• Construct ProgressivelyBaby Steps

• Conditions trigger actions?

• Actions caused by conditions?Action/Effect

• Confirm Screen, Database, ReportTriangulate


Debugging and Troubleshooting

Pair with developer

Work in IDE

Simulate conditions

Tracing code

What if analysis


59

60


NON-FUNCTIONAL TESTING



Non-Functional Testing

Quality Factors

Attributes

Characteristics

Reliability

Other “-ilities”


61

62


Non-Functional Testing Challenges

Goals

• Elicit

• Articulate

• Quantify

Subjective

• Needs or wants?

• Relative or absolute?

• What is good enough?

Tests

• Tricky to orchestrate

• Difficult to interpret results

• Challenging to baseline or regress


Non-Functional Agile Challenges

Time

• Analysis

• Model

• Prepare

• Run

• Interpret

Change

• Baselines

• Goals

Software

• Continuous integration

• Incomplete product builds


63

64


Product Backlog Stories

Emphasize system attributes

Security stories

Usability stories

Performance stories


Product Backlog Constraints

Tom Gilb, Competitive Engineering, suggests defining

Scale: "What is measured"

Meter: "How to measure (method)"

Target: "Level we're aiming for. Success"

Constraint: "Level we're seeking to avoid. Failure"

Benchmark: "Where we are today"


65

66





Light tests

•Low source code complexity suggests maintainability

•Slow unit tests suggests performance problems

•Novice user questions suggest usability concerns


67

68


Non-Functional Experimentation

• Iterative

• Implement trial

• Measures result

Timebox non-functional tests

• Pause

• Review findingsAfter timebox

• Investigate more

• Refactor goal

• Move on to something elseNext steps



Daily performance tests

Decide what experiment to run

Review results in stand-up meeting

Decide what to do next

Use a flexible tool set


69

70



Instrumentation, hooks, and logs

• Isolate bottlenecks

•Resource usage

•Load generation

•System monitoring


Non-Functional Long Tests

Continuously running tests

Frequently pause and restart with new builds

Runs typical transactions in simulated realistic environment


71

72


CUSTOMER DEMO

At Sprint’s End


Customer Demo

No surprises

Tradeoffs acceptable

Priorities understood


73

74


Customer Demo

Demonstrate functionality

•Exercise all story tests

•Demonstrate relationships

•New stories

•Existing functionality


Customer Demo

Demonstrate non-functional product characteristics

•Non-functional backlog entries

•Performance

•Constraints


75

76


RETROSPECTIVE

At Sprint’s End


Retrospective

•Review by team of work done

•Review what worked well

•Review what did not work well

Work done

during sprint


77

78


Retrospective

Test improvements

•Any wasted time?

•Any missing tasks?

•Any concerns about automation?


Retrospective

•Strengths

•Weakness

•New ideas

Testability


79

80


Retrospective

Collaboration concerns

Customers

Developers

Other teams

Suppliers

Synchronicity


Retrospective

Bugs found

• Any common cause?

• How can we avoid them?

• How were bugs injected?


81

82

Date post:	29-Dec-2021
Category:	Documents
Upload:	others
View:	4 times
Download:	0 times

GETTING THINGS DONE WHAT TESTERS DO IN AGILE SPRINTS

Documents