• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
Why Automate
 

Why Automate

on

  • 775 views

automation for beginners

automation for beginners

Statistics

Views

Total Views
775
Views on SlideShare
772
Embed Views
3

Actions

Likes
1
Downloads
31
Comments
0

1 Embed 3

http://www.linkedin.com 3

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…
Post Comment
Edit your comment

    Why Automate Why Automate Presentation Transcript

    • Software Development Lifecycle (SLDC)
      • QA process and the automation process can be different for different software lifecycles
      • 2 most popular SLDC
      • Agile
      • Waterfall
    • 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
    • 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.
    • Waterfall
      • Waterfall SLDC consists of following steps:
        • Idea
        • Analysis
        • Design
        • Development
        • Test
        • Final product
    • 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
    • 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.
    • 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)
    • 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)
    • 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
    • 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
      • 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.
    • 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)
    • 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
    • Know the application and functional specifications
      • Know spec
      • Know what is expected result
      • Find out what needs to be tested
    • 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
    • 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
    • Automation
      • Automate using VBS to navigate with in the application
      • Insert checkpoints in useful places
    • 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.
    • 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
    • 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