Your SlideShare is downloading. ×
Why Automate
Why Automate
Why Automate
Why Automate
Why Automate
Why Automate
Why Automate
Why Automate
Why Automate
Why Automate
Why Automate
Why Automate
Why Automate
Why Automate
Why Automate
Why Automate
Why Automate
Why Automate
Why Automate
Why Automate
Why Automate
Why Automate
Upcoming SlideShare
Loading in...5

Thanks for flagging this SlideShare!

Oops! An error has occurred.

Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

Why Automate


Published on

automation for beginners

automation for beginners

1 Like
  • Be the first to comment

No Downloads
Total Views
On Slideshare
From Embeds
Number of Embeds
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

No notes for slide


  • 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
    • QTP – VBS
    • 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 fine after 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
  • 11.
    • 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
  • 21.
    • 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
  • 22.
    • 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