automation for beginners
Software Development Lifecycle (SLDC)
- QA process and the automation process can be different for different software lifecycles
- 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 SLDC consists of following steps:
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
- Simulates actual user testing the software
- Based on scripting languages
- Selenium – Perl, Ruby, Python etc
- Rational robot – SQABasic (similar to visual basic)
- 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)
- 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)
- detailed test report - generates helpful report
- maintain log of software health - QTP reports can show what was the over all health of the software
- 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 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)
- Verify the result manually
Know the application and functional specifications
- 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
- 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
- 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.
- Winrunner is replaced by QTP
- 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
- 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