Click here to load reader

Why Automate

  • View

  • Download

Embed Size (px)


automation for beginners

Text of Why Automate

  • 1. Software Development Lifecycle (SLDC)
    • QA process and the automation process can be different for different software lifecycles
  • 2 most popular SLDC
  • Agile
  • Waterfall

2. Agile

  • Complete software development is broken in many sprints.
  • For every sprint, certain software features need to be completed
  • Each sprint is typically 2 to 3 weeks

3. QA process for Agile

  • 2 kinds of testing needs to be done:
  • New feature testing- Make sure new features working properly
  • Regression testing- Make sure features from last weeks are still working
    • Regression testing are automated. Tests for new features from each sprint are added to existing automation tests.

4. Waterfall

  • Waterfall SLDC consists of following steps:
    • Idea
    • Analysis
    • Design
    • Development
    • Test
    • Final product

5. QA process for Waterfall

  • Test case is prepared after Design and before Development
  • Automation is done after development when Software is relatively stable (towards the middle of test period)
  • Generally Smoke test and Regression tests are automated

6. Automation Testing

  • Simulates actual user testing the software
  • Based on scripting languages
  • Selenium Perl, Ruby, Python etc
  • Rational robot SQABasic (similar to visual basic)
  • PAMIE Python
  • High initial cost/effort
  • Pays off when used for long time.

7. When to Automate?

  • When same tests need to be performed on an application repeatedly, automation comes handy.
  • Regression testing to check features are working properly
  • enter massive amount of data to the application to facilitate next level of testing (manual/automated)

8. Why Automate?

  • Fast - Much faster in populating data and testing them
  • Reliable - tireless. no fatigue
  • Repeatable same scenario can be recreated again and again following exact same steps.
  • programmable-expert users can program tests using standard VBS
  • Reusable - can use the tests even after the application changed
  • unattended testing - keeps testing without the presence of a tester (generally done over night to morning)

9. Why Automate?

  • detailed test report - generates helpful report
  • maintain log of software health - QTP reports can show what was the over all health of the software

10. Test Methodologies

  • Sanity Test This test is conducted to determine if further testing can be done. This tests the most fundamental functionalities of the software.
  • Smoke test Making sure every basic functionality of the software is working fineafter software is updated with new codes. This is commonly automated
  • Regression Test Previously working functionalities are still working fine. Automated in most cases
  • Integration test How a specific part of the software interacting with other parts.
  • New feature testing Testing a feature after development. Not automated most cases


  • Critical Path Testing Testing for cases that has to work in order for the user to perform a task. This ignores corner cases. Most automation commonly takes critical path
  • Functional Testing Testing calculations, workflows
  • Format testing Testing for looks, color, spelling.

12. Sanity->Smoke->Regression

  • Sanity test takes the least amount of time (less than an hour) to conduct and covers only most fundamental functionalities at high level
  • Smoke test takes more time than sanity (half day or one day) and this covers all the functionality of the software but at high level
  • Regression test takes the most amount of time (one or two weeks) and this covers all functionality at low level (very detail)

13. Steps for automation

  • Know the application and functional specifications.
  • Find out what steps need to be performed to complete the process
  • Find out what information from the application can tell you if the test passed or failed
  • Create the automation script (navigation and checkpoints)
  • Analyze the result
  • Verify the result manually
  • Log bug

14. Know the application and functional specifications

  • Know spec
  • Know what is expected result
  • Find out what needs to be tested

15. Steps to perform the job

  • After determining what needs to be tested, determine what steps needed to perform that test
  • A manual test case
  • Determine a step by step process

16. Determine good Checkpoint

  • In the application, determine what can be good check point
  • A check point can be set on an object or value in the application that is particularly searched and a pass/fail report is created

17. Automation

  • Automate using VBS to navigate with in the application
  • Insert checkpoints in useful places

18. Analyze result and log bug

  • View Test result/report. Try to understand in which step Test failed.
  • Verify assumption by trying out manually
  • If the assumption is true, log bug.

19. QTP

  • Quick Test Pro
  • Winrunner is replaced by QTP
  • From Mercury
  • Integrated with other Mercury product: Quality Center,Test Director
  • Record and Play option for simple tests
  • VBS programming for complex tests

20. How QTP works

  • To perform certain tasks, QTP needs to identify objects in the page
  • Browser
  • Frame
  • Image
  • Link
  • Page
  • ViewLink
  • WebArea
  • WebButton
  • WebCheckBox
  • WebEdit
  • WebElement
  • WebFile
  • WebList
  • WebRadioGroup
  • WebTable


  • There can be many of same object in the page but QTP needs to perform an operation on only one
  • QTP separates that object from others by specific properties unique to that object
  • QTP defines an object in an hierarchical manner


  • For example, when QTP want to click on Search on google page:
  • It first defines the Browser, then defines the Page, then defines the webbutton (Search is a webbutton)
  • QTP needs to identify each of the object uniquely
  • QTP programmer needs to define each object such a way that QTP does not confuse with other objects