Why Automate

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

Why Automate

Related slideshows

More Related Content

Why Automate