What is worksoft certify?

Worksoft Certify is an Automation tool, widely used to Automate SAP functionality.

Worksoft Certify supports the below platforms
SAP HANA, SAP Portal, SAP GUI, SAP Business Objects, Siebel, Oracle, IBM Maximo, HTML, JAVA, FLEX, Silverlight, Web Services (SOA), Visual Basic, Adobe, MS Office, Excel, .NET, C++, PowerBuilder, Crystal Reports, and applications built for mobile devices such as iPhone and Android systems.

What is Software Testing?

Software testing is the process of executing a program with the intent of finding a error.
A good test case is one that has a high probability of finding an as yet undiscovered error.
A successful test case is one that uncovers an as yet undiscovered error.

How to release the test objects after they have been used in your QTP Script?

Solution
‘***********************************************************************************************************************************************************************‘
Copy this code to QTP window – From here to
‘***********************************************************************************************************************************************************************'Object description file where all objects are defined -
 These objects will be created in the memory only when you initialize them -
CommentExecuteFile "Give objects repository file" 

 'Object initialization'
setObj_wnd_Loing is a user defined function which creates a instance of your Window object and returns the object- Comment
setObj_wnd_Login wnd_Login
'setObj_txt_UserName is a user defined function which creates a instance of your UserName object and returns the object- Comment
setObj_txt_UserName txt_UserName
'setObj_txt_Password is a user defined function which creates a instance of your Password object and returns the object - Comment

 'From this point:
 It will be your application regular code
Example:
Sapwindow(wnd_Login).SAPEdit(txt_UserName).Set "admin"
SAPWindow(wnd_Login).SAPEdit(txt_Password).Set "*******"

‘Un-initialization of Objects'
Once you are done with the objects just release them from the memory'
 set wnd_Login = nothing
'set xt_UserName = nothing
'set txt_Password = nothing.


'You don’t have to touch the existing code, except initializing the required objects before starting the scenario/feature and once you are done with the object release them from memory.

Continue of Test Metrics and Measurement

Continue  of Metrics

Defects per 100 Hours of Testing:
Defects per 100 Hours of Testing is calculated as the number of defects found in the product with respect to the effort spent.
Formula:
Defects per 100 hours of testing = (Total Defects found in the product for a period/Total hours spent to get those defects)*100
Conclusion:
 From the Above formula we can say effort plays an important role in judging quality.

Test cases Executed per 100 Hours of Testing:
Test cases Executed per 100 Hours of Testing can be calculated as Formula:
Test cases executed per 100 hours of testing =(Total test cases executed per a period/total hours spent in test execution)*100
Conclusion:
 From the Above formula we can say Test Cases Executed per 100 Hours of Testing helps in tracking productivity and also in judging the product quality.

Test Cases Developed per 100 hours of Testing:
Test Cases Developed per 100 hours of Testing can be calculated as
 Formula:
Test cases developed per 100 hours of testing =(Total test cases developed for a period/total hours spent in test case development)*100
Conclusion:
 From the Above formula we can say Test Cases Executed per 100 Hours of Testing helps in tracking the count of added/modified and deleted test cases.

Defects Per 100 Test Cases:
Defects Per 100 Test Cases can be calculated as
 Formula:
Defects per 100 Test Cases =(Total defects found for a period/Total test cases executed for the same period)*100
Conclusion:
 From the Above formula we can say Test Cases Executed per 100 Hours of Testing helps in tracking the quality of the Product.

Defects Per 100 failed Test cases:
Defects Per 100 failed Test cases can be calculated as
 Formula:
Defects per 100 failed Test Cases =(Total defects found for a period/Total test cases failed due to those defects)*100
Conclusion:
 From the Above formula we can say Test Cases Executed per 100 Hours of Testing helps in tracking and judging the quality of the Product.
Closed Defect Distribution:
Objective of testing team also to ensure all defects identified are fixed and tested

Summary:
Metrics are meant for process improvement, project management and to assess and improve product quality.





 

Test Metrics and Measurement

Metrics derive information from raw data with a view to help in decision making”
Relationship between Data Points
Pointers for future planning

Why Metrics are needed for testing?
When to release the Product
What to release
Whether the product is being released with known quality

Types of Metrics:
Broadly classified in to two
Product Metrics
Process Metrics
Product metrics
Project Metrics
Progress Metrics
Productivity Metrics

Progress Metrics :
Project can be tracked from two angles
How well the project is doing with respect to schedule and effort
How well the product is meeting the quality requirements for the release

Test Defect Metrics:
Defect metrics can be calculated by using the below factors
Defect Find rate
Defect Fix rate
Outstanding defects
Priority out standing defects
Defect Trend
Defect classification trend
Defect cause distribution

Defect Find rate:
Defect find rate can be defined as number of defects arrived for a certain period of time (Day or weekly) in an Product development cycle”.

Defect Fix Rate :
If the goal of the testing is to find defects as early as possible then it is natural to expect that the goal of development should be to fix the defects as soon as they arrive”
Last minute fixes – Risk to release date and quality

Outstanding Defects Rate:
= Total Defects Found – Total Defects Fixed
Curve close to zero - Developer fixes the defect as soon as the defect arrives.

Priority Outstanding Defects:
Filtering low priority defects and plotting outstanding defects by priority defects is called priority outstanding defects”
This will help us to find how many serious issues are uncovered in the product
Normally high priority defects are tracked during the period closer to release

Defect Trend :
Defect trend is the graph obtained by plotting the above discussed test defect metrics
Defect Classification Trend:
a chart to represent defects by classification
common defect classification
Extreme, Critical, Important, Minor, Cosmetic
Defect Cause Distribution:
Reasons for defects and the root cause
Area of focus to uncover more defects

Productivity Metrics:
What is Productivity Metrics?
Productivity metrics combine several measurements and parameters with effort spent on the Product.

What are the uses of Productivity Metrics?
Productivity metrics help the organization in finding the capability of the team as well as for other purposes, such as
Estimating for the new release
Finding out how well the team is progressing.
Estimating the number of defects that can be found
Estimating release date and quality.
Estimating the cost involved in the release.

Productivity Metrics Depends on the following factors
Defects per 100 hours of testing
Test Cases Executed per 100 hours of testing
Test Cases Developed per 100 hours of testing
Defects per 100 Test Cases
Defects per 100 failed Test Cases
Closed Defect Distribution

Automation Coding Guidelines

·       Coding Guidelines

o   Code Header

§  The code header should be listed in the beginning of the file. This Information provides a developer with a means of communicating with other readers of the source code. It provides a clear understanding during Maintenance. These comments should be as mentioned below:

o    ############################################################################

o    # Test Name      :

o    #

o    # Description   : Performs following:

o    #                     

o    #

o    # Author            :

o    # Created on      :

o    # Entry Point      : Main Screen

o    # Exit Point        : Main Screen

o    # Updated By     :

o    # Updated On     :

o    ###########################################################################

o   Function Header

§  Each function in any library file should have a header listed in the beginning of the function definition. This Information provides a developer with a means of communicating with other readers of the source code. It provides a clear understanding during Maintenance. These comments should be as mentioned below:

o    ###########################################################################

o    #

o    # Function         :

o    #

o    # Description      :

o    #

o    #

o    # Author            :

o    # Created on      :

o    # Entry Point      : NA

o    # Exit Point        : NA

o    # Updated By     :

o    # Updated On     :

o    ###########################################################################

o   Naming Conventions

§  Basic Naming Standards

• Use full English descriptors that accurately describe the variable/field/class…
• Use terminology applicable to the domain, from the point of view of the end user.
• Use all lower case characters when describing any variable.
• Use an underscore (‘_’) as a separator between two words of the variable.
• Use abbreviations sparingly. If you do so use them intelligently.
• Avoid names that are similar

§  Naming Functions

·         Methods should be named using a full English descriptor, using mixed case, with the all letters in lowercase.

·         Examples

·         public function login(in user_id, in password)

·         public function count_in_list(in obj_name, out count)

§  Naming Objects

·         For names of objects full English descriptor of the object prefixed with the object type should be used. This makes it easy to identify the purpose of the object as well as its type. Following prefixes should be used for different types of objects:

·         Sl. No.	·         Object Type	·         Prefix used
·         1	·         Text Box	·         txt
·         2	·         Lable	·         lbl
·         3	·         Buttons	·         btn
·         4	·         Radio Button	·         rd
·         5	·         Check Box	·         chk
·         6	·         Other objects	·         obj

·         Examples:

·         lbl_user_id

·         txt_password

·         btn_ok

·         rd_access_type

·         Naming Constants

·         Constants are values that do not change. Use full English words all in uppercase with underscores between the words. First character should signify the type of constant as mentioned below in the table:

·         Sl. No.	·         Constants Type	·         Prefix used
·         1	·         Error constants	·         E
·         2	·         Button Names	·         B

·         Example:

·         E_INVALID_INPUT

·         E_NOT_ASSIGNED

·         B_PATIENT

·         EXISTS_TIME

·         This convention helps to distinguish constants from variables. It is recommendable not to define constants. If the constant doesn’t fall into any category a name can be used with no prefix.

§  Naming local variables

·         A local Variable is an object or data item that is defined within the scope of a block, often a member function. The scope of a local variable is the block in which it is defined. In general, use a full-fledged descriptor for local variable names.

·         Example:

·         search_string

·         first_char

·         Naming Loop Counters

·         Use i, j or k for loop counters, use them consistently.

§  Naming Parameters

·         Parameters should be named following the exact same convention as for local variables.

§  Naming GUI objects

·         GUI objects used by the system should follow the naming convention same as for objects. All the names generated by WinRunner for the objects of the application should be changed as per the guidelines before developing or recording the scripts.

o   Coding Conventions

§  Code conventions are important to programmers for a number of reasons:

§  80% of the lifetime cost of a piece of software goes to maintenance. Hardly any software is maintained for its whole life by the original author. Code conventions improve the readability of the software, allowing engineers to understand new code more quickly and thoroughly.

§  If you ship your source code as a product, you need to make sure it is as well packaged and clean as any other product you create.

o   Parameter names

·         Parameter names should be constructed like identifiers.

·         Example:

·         public function count_in_list(in obj_name, out count)

·         {

·         .

·         .

·         }

§  Declarations

·         Number per Line

·         One declaration per line is recommended since it encourages commenting.

·         Example:

·         # Boolean variable to contain 1 or 0

·         auto b_enabled;

·         # x position of the scroll button

·         auto x_scroll;

·         # y position of the scroll button

·         auto y_scroll;

·         Initialization

·         Try to initialize local variables where they're declared. The only reason not to initialize a variable where it's declared is if the initial value depends on some computation occurring first.

·         Placement

·         Put declarations only at the beginning of script or function. Don't wait to declare variables until their first use; it can confuse the unwary programmer and hamper code portability within the scope.

§  Conditions

·         if / else

·         Place the if keyword and conditional expression on the same line.

·         Example:

·         if (win_exists(…) = E_OK)

·         {  

o    win_activate(…);

o    set_window(…);

·         }

·         else

·         {

o    invoke_application(…);

·         }

·         WHILE

·         The WHILE construct uses the same layout format as the IF construct. The WHILE keyword should appear on its own line, immediately followed by the conditional expression. The statement block is placed on the next line. The curly braces may optionally be indented by up to 1 tab.

·         Example:

·         i = 1;

·         While(i<21)

·         {

o    type(i++);

·         }

·         SWITCH

·         The SWITCH construct uses the same layout format as the IF construct. The SWITCH keyword should appear on its own line, immediately followed by its test expression. The statement block is placed on the next line. The curly braces may optionally be indented by up to 1 tab character.

·         Example:

·         Switch(a)

·         {

·         case “xyz”:

o    b = a & “tw”;

o    break;

·         case “uv”:

o    pause(“hello”);

o    x = a;

o    break;

·         default:

o    x = a;

·         }

·         for Statements

·         A for statement should have the following form:

·         for (i = 1; i <= 20; i++)

·         {

o    run_me(i);

·         }

·         Return Statements

·         A return statement should not use parentheses unless they make the code more obvious in some way.

·         Example:

·         return E_OK;

·         return E_SUCCESS;

§  Comments

·         Example:

·         # This is the comment

§  Indentation

·         A tab should be used as the unit of indentation. The exact construction of the indentation (spaces vs. tabs) is unspecified.

·         Line wrapping for if statements should generally use the tab spacing rule, since conventional (4 space) indentation makes seeing the body difficult.

·         Example:

·         //USE THIS INDENTATION INSTEAD

·         if (condition1)

·         {

o    doSomethingAboutIt();

·         }

·         //OR USE THIS

·         if (condition1) {

o    doSomethingAboutIt();