1. How lean is your testing?
Lean software development is gaining support but how does that affect your testing? Different organisations and projects require different approaches to testing
but we should all be following the lean principles of ‘Seeing the whole picture’ and ‘Building Integrity in’. Could you ‘eliminate waste’ and ‘empower the team’? Use
this chart to help you decide if you’re using the leanest possible approach to testing for your project.
Features
of a Tester
Cowboy Lean Agile V-Model Totally
enterprise
Documentation What documentation?
Automated tests written before
and during development which
later serve as documentation
(ATDD)
Automated tests written before
development begins (ATDD)
Manualtestingisdocumentedusing
light-weight,easychangeabletestplans
suchasmind-mapsorGoogledocs
Integration test plan and System
test plan written using design
documents. Unit and Integration
tests created but less likely to form
business facing documentation
Doitbythebook.Makesureyou
haveTestPolicies,strategiesandtest
planswrittenandsignedoffbefore
testingbegins.Testentryandexit
criteriashouldbedocumented
Tools What tools?
Lightweight tools that can be
quickly set up and learnt
Bug management tool
Test management tool
Bug management tool
Test management tool
Bug management tool
Time management tool
Role
I’m only a tester in
my spare time
Likely to involve tasks outside
of traditional testing: user
support, coding, marketing etc
Dedicated tester within mixed role
team i.e. tester on a scrum team
Dedicated tester within a test
team. System testing and
Integration testing are clearly
defined phases and may involve
different teams of testers
Multiple test teams are usually
involved to cover integration,
system, security, performance and
acceptance testing. Off-shore is
probably the norm
Learning Hard Knocks!
Peer Knowledge Swap
Hard Knocks!
Internet / Blogs / Communities
Books
Peer Knowledge Swap
Internet / Blogs / Communities
Books
Books
Formal Training Courses
Formal Training Courses
Test Planning We don’t plan testing Just in time Scheduled but fast paced
Formal. Clearly defined test
analysis and execution phases
Very formal. Dedicated team
members to plan and estimate
testing phases
Release
schedule
Codeandpush.Repeattofix
everythingthatbreaks
Releases are frequent and form
part of the ongoing development
and release cycle
Frequent.Releasesprobablynot
scheduledbutinsteadshipping
assoonastheyare‘ready’
Releases are frequent and
form part of the ongoing
development and release cycle
Frequent, planned
release schedule
Releases are frequent and form
part of the ongoing development
and release cycle
Infrequent. Well defined with clear
development and test phases
Release is likely to indicate
completion of the project
Rarely. Releases are
a very big deal
Release is likely to indicate
completion of the project
Bug
prioritisation
Unlikely to happen.
Bugs picked up and fixed as
developers wish
Frequently re-prioritised
against features
Severity and priority defined but
room to re-prioritise to meet
release schedules if needed
Clearlydefinedpriorityandseverity
ratings.Classificationsareusually
partofacompanywidestandard.
Testingphaseswillbeextendedifpre-
agreedlevelsofbugsareexceeded
Bugs reported and classified
as defined in industry
defined standards
Bug tracking
Bugs don’t need tracking -
just get ‘em fixed!
Bugs raised by pretty
much everyone
Physical bug reports (index
cards, post-it notes)
Bugs raised by product owners as
well as developers and testers
Bugs recorded in a bug
management tool
Bug reports coming mostly
from the testers
Recorded in a test management
system and likely to be linked
to test plans
All bugs are raised by testers
Recorded in a test management
tool and linked to test plans,
requirements, technical specs etc
Goal Get this code live
Quick releases to get feedback
from users. Testing is complete
when the Minimal Viable
Product (MVP) is usable
Maintaining as few production
bugs as possible in an iterative
environment. Regression testing
favoured above new feature testing
Aiming for no bugs in production
Aiming for no bugs in production
plus a usable, secure, functionally
valid and performant system
Brief
HistorY
OF
Time
a
FrenchEdition
ATDD(AcceptanceTest
DrivenDevelopment):
A collaborative activity
where the whole team
works to produce
Acceptance Criteria with
examples before the
development begins. The
goal is to create a shared
understanding of the
product or feature.
MVP(Minimal
ViableProduct):
Frequently used in
Start-ups to define the
features needed for
launch and nothing more.
Popularised by Eric Rees.
Leandevelopment
principles:
Eliminate Waste, Amplify
Learning, Decide as late
as possible, Delivery
as early as possible,
Empower the team,
Build Integrity in,
See the whole picture.
By Rosie Sherry & Amy Phillips