Test Automation
Do we still need test specialists?
Håkan Rönngren, T2 Data AB
Who am I?
2000 2010
Continuous Delivery
Test Automation
Software Development
The next 28 minutes...
Why do we want automatic tests?
Some things to consider
Goals of the Game
Immediate Feedback
Dev Test
Dev Test Dev TestDev Test Dev Test Dev Test
Immediate Feedback
The faster and cheaper the test, the closer to
the developer it should run.
❖ Development Environment
❖ Hooks in Revision Control
❖ Review Tools
❖ Scheduled Builds
Become able to test more
Hardware Variants
Software Versions
Test Suites
Where does the ROI come from?
Early bug discovery
Accuracy
Visibility
Coverage
New tests (load, stress…)
More interesting work
Challenges
Don’t just automate manual tests
Briefly written, require knowledge
Incomplete, require investigation
Not modular, no reuse
Don’t expect to automate everything
Manual end-to-end
Acceptance
Exploratory testing
Just difficult
Test Strategy
Where does your automatic testing fit in?
What does it require?
Test objectives
Test levels
Test groups
Priorities
Roles & Responsibilities
Change Management
Test Environments
Test Tools
Risks and Mitigations
Scheduling
Traceability
Test Reporting
Don’t get dazzled by tools
❖Have specific expectations
❖Prioritize according to your test strategy
The Infamous Metrics Trap
Number of Test Cases ≠ Test Effectiveness
Coverage Measure ≠ Test Effectiveness
Tests are code
Gestures may be hard to maintain
Programming skills needed
Revision control
Focus on maintainability
In an agile world, things change all the time
Make sure your tests are:
❖Clearly structured, not redundant
❖Comprehensible and clearly scoped
Improve your testability
Preparable Controllable Observable
Training
Include everybody
❖What is being tested?
❖How do I get and interpret the results?
❖What am I supposed to contribute?
❖How can I solve problems?
Look at the whole picture
Higher test tempo means much more data
❖What features are in this test run?
❖What test results did my commit get?
❖Who committed to this test run?
❖What test results did this delivery get?
❖Is this failure new/known/recurring?
❖Is this bug report fix verified by a test?
Improve continuously
If you are not going up, you are going down.
Take a LEAN perspective on your automatic
testing.
Conclusions
❖Know what you want
❖Also know how you expect to get it
❖Take a holistic approach
❖A complement, not a substitute
❖Requires time, investments and training
❖Focus on maintainability
❖Never stop improving
Any money to save here?
“Okay, so here is the deal.
You write that test
automation thingy that does
your job, and then I fire you.”
(Yes, probably a lot. Fire
that boss immediately.)

Test automation: do we still need test specialists?

  • 1.
    Test Automation Do westill need test specialists? Håkan Rönngren, T2 Data AB
  • 2.
    Who am I? 20002010 Continuous Delivery Test Automation Software Development
  • 3.
    The next 28minutes... Why do we want automatic tests? Some things to consider
  • 4.
  • 5.
    Immediate Feedback Dev Test DevTest Dev TestDev Test Dev Test Dev Test
  • 6.
    Immediate Feedback The fasterand cheaper the test, the closer to the developer it should run. ❖ Development Environment ❖ Hooks in Revision Control ❖ Review Tools ❖ Scheduled Builds
  • 7.
    Become able totest more Hardware Variants Software Versions Test Suites
  • 8.
    Where does theROI come from? Early bug discovery Accuracy Visibility Coverage New tests (load, stress…) More interesting work
  • 9.
  • 10.
    Don’t just automatemanual tests Briefly written, require knowledge Incomplete, require investigation Not modular, no reuse
  • 11.
    Don’t expect toautomate everything Manual end-to-end Acceptance Exploratory testing Just difficult
  • 12.
    Test Strategy Where doesyour automatic testing fit in? What does it require? Test objectives Test levels Test groups Priorities Roles & Responsibilities Change Management Test Environments Test Tools Risks and Mitigations Scheduling Traceability Test Reporting
  • 13.
    Don’t get dazzledby tools ❖Have specific expectations ❖Prioritize according to your test strategy
  • 14.
    The Infamous MetricsTrap Number of Test Cases ≠ Test Effectiveness Coverage Measure ≠ Test Effectiveness
  • 15.
    Tests are code Gesturesmay be hard to maintain Programming skills needed Revision control
  • 16.
    Focus on maintainability Inan agile world, things change all the time Make sure your tests are: ❖Clearly structured, not redundant ❖Comprehensible and clearly scoped
  • 17.
    Improve your testability PreparableControllable Observable
  • 18.
    Training Include everybody ❖What isbeing tested? ❖How do I get and interpret the results? ❖What am I supposed to contribute? ❖How can I solve problems?
  • 19.
    Look at thewhole picture Higher test tempo means much more data ❖What features are in this test run? ❖What test results did my commit get? ❖Who committed to this test run? ❖What test results did this delivery get? ❖Is this failure new/known/recurring? ❖Is this bug report fix verified by a test?
  • 20.
    Improve continuously If youare not going up, you are going down. Take a LEAN perspective on your automatic testing.
  • 21.
    Conclusions ❖Know what youwant ❖Also know how you expect to get it ❖Take a holistic approach ❖A complement, not a substitute ❖Requires time, investments and training ❖Focus on maintainability ❖Never stop improving
  • 22.
    Any money tosave here? “Okay, so here is the deal. You write that test automation thingy that does your job, and then I fire you.” (Yes, probably a lot. Fire that boss immediately.)

Editor's Notes

  • #6 Q: who work in an agile environment? Can’t afford to not be on track => immediate feedback is vital
  • #8 If you are in the Embedded world...
  • #10 Challenges to overcome...
  • #12 These guys won’t discover any bugs that you haven’t already foreseen
  • #15 Q: all managers and team leaders, please raise your hands. Major cause of test suite elephantiasis => expensive and demoralizing
  • #17 People won’t have confidence in test suites that have become obsolete
  • #18 How hard is it to set up a well-defined state for tests? Is all vital application logic easily reachable from test scripts? How can you observe the outcome without depending on your application?
  • #19 Depending on the decisions in your test strategy, different people require different testing. Include everybody, or expect a slow, costly adoption with endless support needs
  • #21 If you are not going up, you are going down