Why Automate


Published on

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

No notes for slide

Why Automate

  1. 1. Software Development Lifecycle (SLDC) <ul><li>QA process and the automation process can be different for different software lifecycles </li></ul><ul><li>2 most popular SLDC </li></ul><ul><li>Agile </li></ul><ul><li>Waterfall </li></ul>
  2. 2. Agile <ul><li>Complete software development is broken in many sprints. </li></ul><ul><li>For every sprint, certain software features need to be completed </li></ul><ul><li>Each sprint is typically 2 to 3 weeks </li></ul>
  3. 3. QA process for Agile <ul><li>2 kinds of testing needs to be done: </li></ul><ul><li>New feature testing- Make sure new features working properly </li></ul><ul><li>Regression testing- Make sure features from last weeks are still working </li></ul><ul><ul><li>Regression testing are automated. Tests for new features from each sprint are added to existing automation tests. </li></ul></ul>
  4. 4. Waterfall <ul><li>Waterfall SLDC consists of following steps: </li></ul><ul><ul><li>Idea </li></ul></ul><ul><ul><li>Analysis </li></ul></ul><ul><ul><li>Design </li></ul></ul><ul><ul><li>Development </li></ul></ul><ul><ul><li>Test </li></ul></ul><ul><ul><li>Final product </li></ul></ul>
  5. 5. QA process for Waterfall <ul><li>Test case is prepared after Design and before Development </li></ul><ul><li>Automation is done after development when Software is relatively stable (towards the middle of test period) </li></ul><ul><li>Generally Smoke test and Regression tests are automated </li></ul>
  6. 6. Automation Testing <ul><li>Simulates actual user testing the software </li></ul><ul><li>Based on scripting languages </li></ul><ul><li>QTP – VBS </li></ul><ul><li>Selenium – Perl, Ruby, Python etc </li></ul><ul><li>Rational robot – SQABasic (similar to visual basic) </li></ul><ul><li>PAMIE – Python </li></ul><ul><li>High initial cost/effort </li></ul><ul><li>Pays off when used for long time. </li></ul>
  7. 7. When to Automate? <ul><li>When same tests need to be performed on an application repeatedly, automation comes handy. </li></ul><ul><li>Regression testing to check features are working properly </li></ul><ul><li>enter massive amount of data to the application to facilitate next level of testing (manual/automated) </li></ul>
  8. 8. Why Automate? <ul><li>Fast - Much faster in populating data and testing them </li></ul><ul><li>Reliable - tireless. no fatigue </li></ul><ul><li>Repeatable – same scenario can be recreated again and again following exact same steps. </li></ul><ul><li>programmable-expert users can program tests using standard VBS </li></ul><ul><li>Reusable - can use the tests even after the application changed </li></ul><ul><li>unattended testing - keeps testing without the presence of a tester (generally done over night to morning) </li></ul>
  9. 9. Why Automate? <ul><li>detailed test report - generates helpful report </li></ul><ul><li>maintain log of software health - QTP reports can show what was the over all health of the software </li></ul>
  10. 10. Test Methodologies <ul><li>Sanity Test – This test is conducted to determine if further testing can be done. This tests the most fundamental functionalities of the software. </li></ul><ul><li>Smoke test – Making sure every basic functionality of the software is working fine after software is updated with new codes. This is commonly automated </li></ul><ul><li>Regression Test – Previously working functionalities are still working fine. Automated in most cases </li></ul><ul><li>Integration test – How a specific part of the software interacting with other parts. </li></ul><ul><li>New feature testing – Testing a feature after development. Not automated most cases </li></ul>
  11. 11. <ul><li>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 </li></ul><ul><li>Functional Testing – Testing calculations, workflows </li></ul><ul><li>Format testing – Testing for looks, color, spelling. </li></ul>
  12. 12. Sanity->Smoke->Regression <ul><li>Sanity test takes the least amount of time (less than an hour) to conduct and covers only most fundamental functionalities at high level </li></ul><ul><li>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 </li></ul><ul><li>Regression test takes the most amount of time (one or two weeks) and this covers all functionality at low level (very detail) </li></ul>
  13. 13. Steps for automation <ul><li>Know the application and functional specifications. </li></ul><ul><li>Find out what steps need to be performed to complete the process </li></ul><ul><li>Find out what information from the application can tell you if the test passed or failed </li></ul><ul><li>Create the automation script (navigation and checkpoints) </li></ul><ul><li>Analyze the result </li></ul><ul><li>Verify the result manually </li></ul><ul><li>Log bug </li></ul>
  14. 14. Know the application and functional specifications <ul><li>Know spec </li></ul><ul><li>Know what is expected result </li></ul><ul><li>Find out what needs to be tested </li></ul>
  15. 15. Steps to perform the job <ul><li>After determining what needs to be tested, determine what steps needed to perform that test </li></ul><ul><li>A manual test case </li></ul><ul><li>Determine a step by step process </li></ul>
  16. 16. Determine good Checkpoint <ul><li>In the application, determine what can be good check point </li></ul><ul><li>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 </li></ul>
  17. 17. Automation <ul><li>Automate using VBS to navigate with in the application </li></ul><ul><li>Insert checkpoints in useful places </li></ul>
  18. 18. Analyze result and log bug <ul><li>View Test result/report. Try to understand in which step Test failed. </li></ul><ul><li>Verify assumption by trying out manually </li></ul><ul><li>If the assumption is true, log bug. </li></ul>
  19. 19. QTP <ul><li>Quick Test Pro </li></ul><ul><li>Winrunner is replaced by QTP </li></ul><ul><li>From Mercury </li></ul><ul><li>Integrated with other Mercury product: Quality Center,Test Director </li></ul><ul><li>Record and Play option for simple tests </li></ul><ul><li>VBS programming for complex tests </li></ul>
  20. 20. How QTP works <ul><li>To perform certain tasks, QTP needs to identify objects in the page </li></ul><ul><li>Browser </li></ul><ul><li>Frame </li></ul><ul><li>Image </li></ul><ul><li>Link </li></ul><ul><li>Page </li></ul><ul><li>ViewLink </li></ul><ul><li>WebArea </li></ul><ul><li>WebButton </li></ul><ul><li>WebCheckBox </li></ul><ul><li>WebEdit </li></ul><ul><li>WebElement </li></ul><ul><li>WebFile </li></ul><ul><li>WebList </li></ul><ul><li>WebRadioGroup </li></ul><ul><li>WebTable </li></ul>
  21. 21. <ul><li>There can be many of same object in the page but QTP needs to perform an operation on only one </li></ul><ul><li>QTP separates that object from others by specific properties unique to that object </li></ul><ul><li>QTP defines an object in an hierarchical manner </li></ul>
  22. 22. <ul><li>For example, when QTP want to click on “Search” on google page: </li></ul><ul><li>It first defines the Browser, then defines the Page, then defines the webbutton (Search is a webbutton) </li></ul><ul><li>QTP needs to identify each of the object uniquely </li></ul><ul><li>QTP programmer needs to define each object such a way that QTP does not confuse with other objects </li></ul>