EuroSTAR Software Testing Conference 2009 presentation on Low Budget Tooling - Excel-ent by Mattias Diagl. See more at conferences.eurostarsoftwaretesting.com/past-presentations/
2. Agenda
1. Real Life
2. Myths about tools
3. Example: Defect management
4. Example: Test specification and test management
5. Example: Test case design and test case generation
6. Conclusion
4. Common Statements – True or False?
Commercial tools are expensive.
Freeware tools are unreliable.
In the long run, homemade tools are more expensive than
commercial tools.
Spreadsheets are bad databases.
Good testers need good tools.
It is better to buy a tool than to build a tool.
5. Example: Defect tracking (Excel)
ID Label Date TesterDeveloperSeverityPriorityStatus Description History
1 Wrong Label on Icon27.07.09 AB JH 4-Typo 4-Low 2-Open Label should be "CarConfigurator", is 2-Open (28.07.09 - JH)
2 Model without price 27.07.09 AB CL 2-Restrict2-High 1-New Price for model "Rolo" is 0€, should be 12.800,-1-New (27.07.09 - AB)
7 Wrong discount 27.07.09 MD CL 2-Restrict2-High 4-InProcess
Discount is granted only at 4 items, should be
at 3 items
4-InProcess (28.07.09 - CL)
2-Open (28.07.09 - CL)
1-New (27.07.09 - MD)
8 Config dialog 28.07.09 MD PK 3-Workaround3-Medium1-New
The buttons in the configuration dialog are at
wrong positions (cf to gui guidelines)
1-New (28.07.09 - MD)
15 App Crashs after Start28.07.09 DR JH 1-Crash2-High 5-Test The application crashes immediately after start 5-Test (28.07.09 - JH)
What you can do
Store your data (insecure)
Work concurrently (limited)
Filter data
What you can‘t do
Manage large projects
Real concurrent work
Have a role based workflow
Automatically send messages
Keep some historical values
Reporting…
Conveniently track your history
Get a clear view on the data
if you are using detailed
attributes
6. Example: Testspec & Testmanagement
(Excel)
Requirements document: Functional Specification myCar
Test object version: 1.0
Test specification date: 01.04.2009
Path: P:projectsimbussamplenewdocs
Reviewer: John Doe
Framework
Required tools: Word, Excel
Test environment: Standard
SW environment: Standard
HW environment: Standard PC
Referenced documents: cf. Req. Document
Remarks: -
Status
# test cases created
# requirements
Anteil (in %)
Status wk 19 wk 20 wk 21 wk 22 wk 23 wk 24 wk 25 wk 26
open 0 0 0 0 0 0 0 0
ok 0 0 0 0 0 0 0 0
nok 0 0 0 0 0 0 0 0
blocked 0 0 0 0 0 0 0 0
executed (total) 0 0 0 0 0 0 0 0
planned (total) 1 3 4 5 6 8 9 10
percentage 0 0 0 0
Status
open
ok
nok
blocked
total
0
test cases total 1st reg.test A
10
System Testing Specification
Test case creation progress
0
2nd reg.test B 3rd reg.test C
Test execution progress
0
0
wk 14
0
0
0
0
0
0
0
0
0
0
0
0
status of test cases in execution
0
0
00
2
0
wk 15
10
4
250 166,6666667
6
10
wk 16 wk 17
10
7
142,8571429
0
2
4
6
8
10
12
wk 19 wk 20 wk 21 wk 22 wk 23 wk 24 wk 25 wk 26
t
e
s
t
c
a
s
e
c
o
u
n
t
planned (total)
executed (total)
0
2
4
6
8
10
12
wk 14 wk 15 wk 16 wk 17
t
e
s
t
c
a
s
e
s
# test cases created
# requirements
Testcase # Type Priority Requirement Creator Created Tester Test date Status Bug # System Precondition
xxxx Reg.test ?
high/
medium/
low Requirement
Name Date Name
Date
ok/
nok/
blocked/
open
#
1 2
TUW_0010 high check basic details md 08.04.2009 md open CarConfig …
Organisation Contents
What you can do
Keep your data…
Get comprehensive reports
(test progress…)
What you can‘t do
Span reports across test objects
Work in large teams
Manage large projects
Versioning (or forget reporting)
Only limited workflow…
Only limited support for logging
of multiple test cycles
7. A Professional Test Management Tool: TestBench
Version control for test cases and test execution data
Concurrent, distributed work
Control large projects with a large number of people and test cases
Provide statistical data across test cycles
Interfaces with other tools readily available
Workflow, role model…
8. Example: Test design (CEG)
Support advanced test
techniques
Generate test
cases/test data
9. Conclusion: Why we prefer professional tools
Office based tools are only advisable for small projects or
small teams (in general - there are exceptions)
Functionality of homemade tools is often limited due to
limited development resources
Functionality of homemade tools is often limited as it
represents the skill level/maturity level of the organisation
Professional tools provide more comprehensive features
Professional tools provide support (not usually for free tools)
Development effort for professional tools is shared by all the
customers – so they are (should be?) cheaper in the long run
(don‘t forget maintenance…)
Higher productivity
From (many) documents to (one) database
Know-how is for all projects
Easy to use
10. Conclusion: Why we might still use homemade tools
If we can‘t get a "real" tool:
Because there is no budget
It is not yet available (interim solution)
It might be easier to get the budget for people to build a tool,
than to get the budget to buy a tool (regardless of the final
costs – don‘t forget maintenance…)
If we see that staff can not handle professional tools *today*
If we need time to figure out our real needs
If we need features which are not available in commercial
products
Commercial tools might not „fit“ our people
If a quick solution is needed
11. Conclusion: Risks & Opportunities
Risks in creating advanced tools based on office products:
Eventually, higher costs than commercial tools
Working with office based tools is generally less efficient
Own solution might block progress
It’s likely to get a high complexity in the interaction of many
simple documents missing overview, mistakes, lacking
precision
Opportunities:
A solution is available at short hand
The solution will fit our environment
Customising is possible and cheap
We still might buy a professional tool later
12. Be not afraid of going slowly;
be afraid only of standing still.
Chinese Proverb
a practical approach, from a pilot (that may be too easy) - the message is a little unclear - may be too much material for a mini-track - doesn't sound like any novel ways of automating (but it is a case study) - the author mentions agility, but then seems to contradict this with heavy elements such as reporting and cycles of several months - if agile, cycles are weeks or one month at most
Story: company deleting solved issues from list
Stage 1: Basic testing capabilities - No tools are required. Focus is on processes.
Stage 2: Testing capabilities improve, test management is gaining in importance - Home made tools fit enough to meet the requirements;professional tools might overstrain some of the testers
Stage 3: Mature test process and experienced testers - More advanced tool support is desired, professional tools start to replace custom solutions