Moreover automation is used to downsize manual effort not to replace the same.
Types of Framework:
There is no hard and fast rule to design a framework.
a.Record and playback
- Data Driven Automation Framework
- Keyword Driven Automation Framework
- Modular Automation Framework
- Hybrid Automation Framework
- BPT Framework.
- Device Testing Automation- Device Simulation Framework
Record and playback framework in Automation
This is a simple record and then playback. The only enhancement is to parameterize the data that changes. It is having less re usability. It is the only driver and delivers the concept. Capturing tests by recording the actions of a manual tester seems attractive, but this approach does not scale to large numbers of automated tests.
A captured script is a linear representation with specific data and actions as part of each script. This type of script may be unstable when unexpected events occur. Most of the time scripts are not modified to check the change in software but a new script is build to test. It is often referred to as the Linear framework.
When you can go for record playback?
Mostly when your application is like mainframe where we can only tab around the application and send test data. So if any application only accepts keystroke, then record and playback could be an option.
Script1+Test Data 1 +repository1.mtr—>i.e/any browser–>UAT
Script2+Test Data2 + repository2.mtr—>i.e/any browser–>UAT
Script3+Test Data3 + repository3.mtr—>i.e/any browser–>UAT
It is very easy way of developing and delivering script.
Record playback framework is the quickest way to develop test scripts. It is having zero reusability. It commonly follows the spaghetti test development pattern. Nontechnical or novice coders can develop Automation test cases.
Test iteration is controlled by Run Tab of test settings. Action options can be configured to Action call properties.
Let us understand how many recordings are there in QTP.
There are 3 types of recording:
- Normal Recording – done on a standard object. Mainly context sensitive. It is the default recording mode. By this QTP recognizes the application property depends on the assistive and mandatory property. Mainly click,dbclick,drag,drop etc
- Analog Recording- Based on the track. Records the movement of the mouse. This is useful when objects are not identified by regular recording mode. It is relative to the screen or to the specific window. if screen changes by dimension, it is very difficult to handle. It can record the keyboard operation though.
- Low level-It is applicable when QTP cannot identify the object at all with the above two methods. It records all run time objects. It is also dependent on position. QTP can automatically switch to the low-level recording if needed.
Let us look at how QTP runs in those cases: Run mode also have three categories.
- The normal mode of running: Useful for debugging. Executes slowly and lets us see the application changes.
- Fast mode: It is good when your application is fully up and running. Executes very fast. Not recommended when the application is slow or responding slowly.
- Update mode: useful when the application is changing. We can update the objects description, the checkpoint values, active screen image. But it can not update the parameterized values such as data tables, environment variables. Navigation Automation–>Update Run mode
Let us understand what are the disadvantages of the record-playback framework.
- It is a one-time activity
- The data is not parameterized hence coded values are present [I mean test data are hard coded]
- Scalability is low.
- No portability
- Maintenance is high.
- ROI is lowest among all the framework
- Test assets, reusability, and resource productivity is lowest among all the framework
- This type of script is not reliable.
- Can not handle complex test design
Data Driven Automation Framework
Repeated use of Test Scripts with different inputs. A data-driven approach separates out the test inputs (the data), usually into a spreadsheet, and uses a more generic script that can read the test data and perform the same test with different data.
Generally, where the flow remains the same and objects do not change, Data-driven framework can be very useful. Testers who are not familiar with the scripting language can enter test data for these predefined scripts. Input data is given a pool of data set.
Even the output data comes out from the data pool. It helps us to reduce coding for a large dataset. Ease of Testing of Time consumption. It is best used in IBM-Rational Robo. Data is not hardcoded here, instead, data are stored and provided from a data source like -XML, Excel, flat file, Database or combination of all. As the data layer is separated from the code , the same scripts can be reused multiple time.
- There is no model to be followed to generate automation test cases.
- Coverage is limited.
- Coverage is time bound.
- Looping almost disappears.
- No of variables grows up which sucks up machine performance.
- The data table may become too huge and too complex.
- Reusability is very less.
- Domain-specific languages are poorly researched and hard to design.
- Need close collaboration between functional and automation team.
Keyword Driven Automation Framework
Steps and data are fed to the automation tool. Automation tool judges the steps and input data from a data pool, It gave the output data. In a keyword-driven approach, the spreadsheet contains keywords describing the actions to be taken (also called action words), and test data.
Testers (even if they are not familiar with the
scripting language) can then define tests using the keywords, which can be tailored to the application being tested. It is very sensitive towards data design. This is based on generic keyword based.
The advantage is the setting of keywords can test window/web/Oracle etc based application.
With the advancement of automation framework, after record and playback, Keyword driven framework is the most robust and acceptable framework while automating huge test cases.
The more the framework easy to use ,more and more test engineers will jump into automation that will intern increase the coverage and testcase count.Automation will never face the starvation issue as there will be plenty of test cases to automate.It is true that sometimes,if we change the approach , we may get more bugs via automation.Breadth over depth approach to testcase automation gives more bugs. Instead covering all features ,it is better to go for a specific features covering all the objects. There should be a balanced approach for selecting depth and breadth testing.