Automated

443 views

Published on

0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
443
On SlideShare
0
From Embeds
0
Number of Embeds
5
Actions
Shares
0
Downloads
12
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide
  • Structure: What it is/each part made of?Functions: What it does?Data: how it does it?Platform: what it depends upon?Operations: how it is used?Time: howit is affected by time?
  • Unit tests and functional system test are the obvious choice for automation. 70 % unit tests& 30% functional system tests will be optimal.
  • Automated

    1. 1. Automated test strategy<br />Ingve Brunvoll<br />
    2. 2. What to automate?<br />
    3. 3. Test quadrants -Test coverage<br />Supporting the team System tests<br />Critique product<br />Business tests<br />Unit tests<br />Technological<br />
    4. 4. Test quadrants – test strategy<br />
    5. 5. Test design<br />Ingve Brunvoll<br />
    6. 6. Method<br />1. Create a test plan for the area<br />2. Analyze existing test coverage and tests<br />2. Gather required coverage and missing tests<br />4. Determine test cases to develop<br />5. Determine what test oracles to use<br />6. Automate? = Yes: Develop tests using keywords. No: Improve manual test forms.<br />
    7. 7. A functional test case<br />Is an instance of a low level Use Case<br />Is one of the pathways through a test scenario<br />Can combine several positive, or at least one negative outcome<br />Can operate on four test levels:<br />Unit: Calling/Checking an atomic function<br />Integration: Calling/Checking internal functions that again calls other functions<br />System: Calling/Checking several functions when doing a specified user task<br />Acceptance: How the functions/tasks and appearance are supporting the actual customers processes/needs<br />
    8. 8. Use case vs test case<br />
    9. 9. How to find Test oracles<br />History versions<br />Company image<br />Comparable products<br />Claims/documentation<br />User expectations<br />Product itself<br />Purpose<br />Statutes<br />
    10. 10. Test cases – base them on structured analysis<br />Decision tables<br />State charts<br />User scenarios<br />Boundary value analysis<br />Careful and Un-ambigous Input/output value selection<br />
    11. 11. Best practise - automated test design<br />Think broad, start small<br />Use keywords for maintainability<br />Risk based – start with the subset of tests that usually breaks and hurts most<br />
    12. 12. Automated test framework<br />Ingve Brunvoll<br />
    13. 13. Test execution in framework<br />Test case 1<br />Test case 2<br />Goal: Make each test independent of each other, and ensure they are not breaking each other, for max integrity & test confidence, reproducable in the simplest way, and ensure a detailed product status quality feedback to the team<br />
    14. 14. Keyword driven testing<br />One test case consist of one or more keywords<br />Keywords are used by the test driver to run specific test scripts<br />Can represent technical concepts, functions, or be more abstract. i.e. represent a business model. Abstract keywords are more maintainable<br />Keyword instances does not embed scripts itself<br />Keywords and scripts can be reused by several test scenarios and test cases<br />Are defined in XML templates and used by test cases in a decoupled fasion<br />Keyword inherrits data driven testing, by sending parameters when invoking a keyword script library<br />

    ×