In any given automation tool the overall control of AUT is by Object identification technique. By this unique feature the tool recognizes the Application as an medium to interrogate with the Tester supplied inputs and tests the mobility of the Business Logistics.
Invoking this object identification technique the test tool does have certain control features that checks the application at various given point of time. Innumerous criteria, myriads of object handlers, plenty of predefined conditions are the features that determine the so-called object based features of the Functional Check points. Each tester has a different perspective of defining the Control points.
If. … Else:
1. Before we start the “if else” construct the nature of the control point is commented along side.
For e.g.,
# Home Page Validation
If ( == “0”)
print (“Successfully Launched”);
else
print (“Operation Unsuccessful”);
2. For all Data Table operation the return-code of the Open function should be handled in the “if else” construct.
Check Points
1. Any checkpoints should not be a component of X & Y Co-ordinate dependant. In practical terms if there is a Check point that is defined on X,Y Parameters then the usability of the control point wouldn’t make any sense for the application to test. The following are some of the criteria which denotes the do’s and don’t’s of checkpoints.
| S.No | Check Point | Include | Exclude |
| 1 | Text Check | Capture Text, | Position of the Text, Font & Font Size, Text area, |
| 2 | Bitmap Check | only the picture | Window or Screen that holds the picture, x-y co-ordinates, |
| 3 | Web Check | URL Check, orphan page | Avoid any text validation |
1. As a case study, the WinRunner automation tool is mentioned here as examples for creating check points. Usage of OBJ_CHECK_INFO or WIN_CHECK_INFO can be avoided and inculcate the idea of creating always the GUI Check point with Multiple Property. The advantages are to identify every small object with its clause, properties and its relativity with the previous versions.
This not only enables the Regression comparisons but also it gives you the flexibility of defining the GUI Checks in all Physical state of the Object.
RELATED POST
ERROR CHECK LIST FOR INSPECTIONS
WALK THROUGHS IN TESTING
TESTING FOR SPECIALIZED ENVIRONMENTS PART ONE
TESTING FOR SPECIALIZED ENVIRONMENTS PART TWO
VALIDATION TESTING
SYSTEM TESTING
DEBUGGING AND TESTING
DEFECT AMPLIFICATION AND REMOVAL
ITERATIVE SPIRAL MODEL
STANDARD WATER MODEL
CONFIGURATION MANAGEMENT
CONTROLLED TESTING ENVIRONMENT
RISK ANALYSIS PART ONE
RISK ANALYSIS PART TWO
BACK GROUND ISSUES
SOFTWARE REVIEWS PART ONE
SOFTWARE REVIEWS PART TWO
SOFTWARE RELIABILITY
SAFETY ASPECTS
MISTAKE PROOFING
SCRIPT ENVIRONMENT
V MODEL IN TESTING
No comments:
Post a Comment