Automation Testing

 

1. Record/ Playback Testing Tools

 

Record the actions of manual test execution, allowing tests to run unattended, thereby greatly increasing productivity and eliminating manual testing mind-numbing repetition. However, even small changes to the application under test require manual re-recording of the test. This first generation of tools, therefore, is neither efficient nor scalable.

 

Pros	Cons
• No programming skill necessary! • Allows users to quickly generate automated tests based on existing manual test cases • Little or no training needed to start creating test automation	•  Often times the scripts recorded scripts don’t work correctly, so you must edit them manually (you end up programming!) •  Recorded scripts are very vulnerable to UI changes. •  Little or no reuse of scripts, which makes future updates difficult or impossible.

 

2. Scripting

 

Scripting, a form of programming in computer languages specifically developed for software test automation, solves many of the problems of capture/playback tools.

Script developers, however, must be highly technical, specialized programmers working in isolation from the actual testers. Additionally, scripts are best-suited for GUI testing and don’t lend themselves to embedded, batch, or other systems. And as changes to the application under test require complex changes to associated automation scripts, maintaining ever-larger script libraries becomes overwhelmingly challenging.

 

Pros	Cons
• Higher level of re-use, easier updates than record and playback. •  More maintainable and manageable (less code than recorded scripts). • In practice, you generally can record actions to generate code and then modify it to suit your needs. This technique saves time.	• Tests live in the code. To update a test, an automation engineer must update the code (high maintenance cost). • Testers have very little involvement in the creation of test automation in this approach. • This approach relies almost entirely on automation engineers.

 

3. Data Driven Testing

 

Separates automation scripts and data, decreasing testers’ reliance on automation engineers, and vastly increasing the possible variations and amount of test data. While greatly extending the usefulness of scripted test automation, data-driven testing remains maintenance-intensive.

 

Pros

Cons

• A parameterized test can be run many times with different input data. • Test data is now separated from the test scripts(lower maintenance cost) • Testers can update the data. • Automation engineers can update the scripts. • Test data can be created before the test have been completely developed, as long as you know the correct format for the data.

• Takes more planning and management than previous approaches. • Development of tests will usually take longer since mechanisms to access data must be created. • Tests still must be scripted by the automation engineer. Testers only have control over the data. • In this approach, tests are broken down into a series of actions representing the business processes of the SUT, such as enter client, transfer and check balance. • Individual actions are automated, not the tests. • The tests are now stored externally from the test scripts, typically in a spreadsheet.

 

4. Keyword Based Testing Automation

 

Keyword-based test automation’s elegant, structured approach simplifies work even further, reducing the time and expense of test design, automation, and execution by allowing team members to focus on their areas of individual expertise. Non-technical testers and business analysts can develop executable test automation from keywords representing recognizable end-user actions such as “login,” while automation engineers devote their energy to coding the low-level steps comprising those keyword actions, such as click, find text box A in window B , enter User Name etc.

Using this keyword-based method, test design are developed based on documents created by business analysts or marketing departments while the final details of the software to be tested are still unknown. This test automation process removes bottlenecks and facilitates effective use of highly-trained professionals’ expensive time.

The testing process further magnifies the keyword method’s cost benefits, as changes to the application under test typically necessitate revision of automation scripts. Using a keyword-based framework, changes to the application under test often require no new automation whatsoever or require merely simple alterations easily made by non-technical testers or business analysts, greatly reducing an organization’s maintenance needs. When necessary, automation engineers can make changes to the automated keywords without affecting the rest of the test.

Action-Based Testing, the foundation of TestArchitect, embodies the continued evolution of the keyword-based approach under the guidance of its original creator. Test design and automation organized around TestArchitect’s built-in actions and keywords often make possible automation of tests without scripting.

 

Pros

Cons

• Highest possible level of reusability and maintain abilities • Tests are separate from the automation, so testers can create and modify tests without having to change the underlying automation. • Testers can create the tests before the  application is ready for testing (just like manual test cases), based on requirements,  specifications, use cases, and other information. • One automation engineer can support many testers. • Testers can effectively create test automation without having to learn to write scripts in a test automation tool. • Automation test cases for the automation tool can also be used as manual test cases since they are easily readable and stored in a spreadsheet format that many testers are comfortable with.

• Setup time can be longer than other approaches. • May require a change in the way you approach testing and test automation.

 

5. Multi Level Keyword Test Automation

 

Multi-level keyword automation, a unique feature of TestArchitect, creates new higher-level actions from lower-level actions simply by typing names or dragging and dropping icons.

For example, the action Add Product To Inventory might be created by three simple, low-level actions: click, enter and click, to open a window by clicking on a button, copy text into a textbox in that window and click on a button to close the window.

Combining two or more high-level actions creates even more powerful actions, such as combining Add Product To Inventory and Check Product into one action called Update and Verify Inventory.