How to use QTP and Quality Center for daily automated regression test Type: BTO Applications
Upcoming SlideShare
Loading in...5
×
 

Like this? Share it with your network

Share

How to use QTP and Quality Center for daily automated regression test Type: BTO Applications

on

  • 10,055 views

An overview of how to use QTP and Quality Center for daily automated regression test Type: BTO Applications, using a case study of ATP

An overview of how to use QTP and Quality Center for daily automated regression test Type: BTO Applications, using a case study of ATP

Statistics

Views

Total Views
10,055
Views on SlideShare
10,055
Embed Views
0

Actions

Likes
1
Downloads
62
Comments
1

0 Embeds 0

No embeds

Accessibility

Categories

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
  • sujet interessant
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

How to use QTP and Quality Center for daily automated regression test Type: BTO Applications Presentation Transcript

  • 1. Session ID: BTOT-TU-1800/1
    Twitter hashtag #HPSWU
  • 2. How to use QTP and Quality Center for daily automated regression test Type: BTO Applications
    Speaker Name: Test Manager Maja Usbeck Cao
    and Test Specialist Claus Haslund Andersen
    Date: 30. november 2010
    Session ID: BTOT-TU-1800/1
  • 3. Agenda
    • ATP – the company and the test organisation
    • 4. System landscape and regression test
    • 5. Requirements for our testing tools and automated test setup
    • 6. The setup for automated testing
    • 7. Communication with relevant stakeholders
    • 8. Daily mail with graphs
    • 9. Daily follow-up on the nightly runs
    • 10. Progress on developing automated tests
    • 11. How did we get there? Prerequisites for our autotest setup
  • Brief presentation of ATP: Company tasks
    Regulated tasks
    Customers contact with the ATP Group
    Pension og Security
    Security
    Pension
    Pension Danmark
    JØP (Unit Link)
    DA-Barsel
    ATP
    SP
    SUPP
    LD
    AER
    AES
    FerieKonto
    LG
    Barsel.dk
    Pension(Pension services)
    Vocational training (internship grants)
    Maternity(salaries refunding)
    Occupational disease(Workers’ compensation insurance)
    Bankruptcy(pay compensation)
    HolidayHoliday pay)
    4.4 million Danes come in contact with the ATP Group's products. Total products
    ensures our customers a basic economic security during and after their working lives.
  • 12. Test Organization
    The test resources
    3 Head of Test
    6 Test Managers (RTM, TI and TM)
    9 Test coordinators
    3 Test specialists (automated test and test data)
    Up to 4 IT-Testers and students workers (ITU and DTU)
    23 Test consultants
    Responsibility area
    Test in projects and Sustained Engineering
    Test methods, TDM and test tools (QC, QTP and Loadrunner)
  • 13. Test Organization - automatisation
    Centralized automation team
    Building principles and guidelines
    Coordination across the organization
    Upgrade & support of the tool
    Building regression test
    Maintenance of automated test
    Responsibility for the daily runs
    Sometimes QTP developers are lent to projects for a period of time
  • 14. SAP client
    Guitalis
    Doc./Papyrus/WAS
    Kerne/.NET/DB2
    SAP
    Masterdata/WAS
    WFM/WAS
    Broker / Websphere MQ
    Websphere
    HTTP
    Portal 360o
    Portal
    ATP Business Platform - Logical overview
    Execution of:
    • GUI transactions
    • 15. Service requests
    • 16. Batch runs
  • Test of new functionality
    Regression test of previously delivered functionality
    Release
    1
    2
    3
    5
    4
    6
    7
    Regression test purposes
    Regression testing aims to test whether any errors occurs in already implemented functionality, when implementing new or changed functionality.The extent of regression test and risk of missing regression test increases in proportion to the implementation of new functionality (see illustration).Missing/incomplete regression test represent a quality risk
  • 17. Requirements for our Testing Tools
    We want to use our current tools Quality Center and QTP
    We have to be able to run our test set on a scheduled basis: Daily, weekly and individual dates
    Automatic re-running tests that fails the first time (based on percentage of failed tests in a test set)
    Distribution of loads on x number of machines (so we continuously can expand our setup)
    Grouping of servers, so test on different releases is possible (Sustained Engineering and release)
    Troubleshooting - current screenshots of the machines and embedded error detection in scripts
    We need to know the expected execution time for a test set (Crucial when time is short eg. emergencies)
    Don’t think: What you can get – Think : What you want!
  • 18. Automation focus areas
    • Services
    • 19. Alive
    • 20. Functional
    • 21. Batch runs (via gui)
    • 22. Start of batch run
    • 23. Check result
    • 24. System testing
    • 25. Deep functional
    • 26. Testdata
    • 27. Creation of data
    • 28. Deleting data
    • 29. Environments
    • 30. Component
    • 31. Integration
    • 32. Pilot
  • Doc./Papyrus/WAS
    Masterdata/WAS
    Kerne/.NET/DB2
    SAP
    WFM/WAS
    Broker / Websphere MQ
    Websphere
    HTTP
    Portal 360o
    Portal
    Test of Service requests - solution
    There are 6 main systems providing services.
    Application for communication (Broker).
    The portal using these services.
    One automated BPT component in Quality Center.
    QTP
    QC
    ATSA
  • 33. Automation Test environment
    Automated Test Scheduler Application (ATSA)
  • 34. What is the ATSA and how does it work?
  • 35. Daily status on the test execution
    Daily mail with information on the execution of automated tests
  • 36. Daily monitoring of test execution
    The main reason that there are 26 failed tests, time out and changed data.
    Errors are described in details below (note that you can not compare the numbers directly, as part of the failed setup test cases are not counted as
    test cases)
    Portal:
    PD: Passed.
    DFO: Errors due to environmental instability. There is created POB-action on that.
    SUPP: Passed
    Service requests:
    Alive test:
    ATP: 2 Broker Time out (Defect 16159).
    PD: 5 Broker Time out (Defect 16159).
    Functional:
    AER: Passed.
    ATP:3 Broker Time out (Defect 16159).
    PD:2 fails because of environment setup (service call is send to wrong environment).
    1 Broker Time out (Defect 16159).
    SUPP: 1 Broker Time out (Defect 16159).
    Kernel:
    ATP: 2 errors in death batch job because of time out of the stakeholder replication
    3 data / environment errors on K060.
    PD: 3 kernel time outs
    5 Data / rounding errors on the letters and H150
    3 fails due to customer agreement does not work (H150). Defect has been created
    SUPP: 9 Data / rounding error on the letters and F02
    4 fails because of data / setup
  • 37. Number of automated tests over time
  • 38. Approach on automated test
    • Standard for BPT (content, size and structure)
    • 39. It is mandatory to use BPT in all regression tests
    • 40. Education in BPT components (workshops on our customers applications)
    • 41. Review of the BPT components (both manual and automated)
    • 42. Code guideline
    • 43. Code review
    • 44. Automation team located in the same room (communication)
    • 45. Data discipline in QC is crucial (data for our graphs)
  • Test data and change of test environments
    • Test data used for the automated tests must be reserved in all test environments
    • 46. Solution established for deleting and reload of data in our component test environments
    • 47. The automated test generates data and cleans up data
  • How did we get this far
    • Management focus on automation - it has taken a long time to reach this far (maturity)
    • 48. Visibility on automated testing - we get that by sending out a daily mail with graphs and mark all defects found
    • 49. We can test a large part of our regression tests automatically in one night and it can be used for bug fixes in production
    • 50. Over time - lower costs on our regression test
    • 51. Centralized automation team is crucial for our success
    • 52. Important to focus on maturity of the company (we are now TMMi level 2 – moving towards level 3)
  • Continue the conversation with your peers at the HP Software Community hp.com/go/swcommunity