Types of Testing Supported by TestingWhiz
TestingWhiz is supporting the following types of testing:
1. Keyword-Driven Testing
2. Data-Driven Testing (DDT)
3. Risk-Based Testing (RBT)
4. Web Service Testing (REST & SOAP)
Keyword-Driven Testing
It is a type of functional automation testing framework which is also known as Table-Driven Testing or Action Word Based Testing.
A table format is used to define Keywords or Action words for each function that would be executed
Steps & Configurations
1. Create a Test Suite under Test Project
2. Add a Test case
3. Select the Test command as Open Page from the drop-down
4. Input www.google.com in Value column
Data-Driven Testing (DDT)
It is a scripting technique that stores test input and expected results in a table or spreadsheet so that a single control script can execute all of the tests in the table.
It is a testing methodology where test input and output values are read from data files and are loaded into variables in the test scripts.
It allows users to execute the same test(s) multiple times with different set of data
Steps & Configurations
1. Click on Data Table Tab
2. Add a Data Table
3. Name the Data table as Login Data
4. Add Fields as Username and Password
5. Either add different sets of data manually or add data by importing an Excel file
6. Once the fields and the default input values are defined, create a Test Script in the Test Project Section with a Test command that fetches data from the Data table
7. Add a Test Case name as Login
8. Select Test Command as Open Page and add Value as http://www.testing-whiz.com/demoscripts/place-holder.html
9. Add next step and select Test command as Loop Start to start the process of login with different usernames and passwords
10. Add Value as Login Data (Name of Data table) to fetch all the usernames and passwords stored in the Data table
11. Select Test command as Input, add Object as txtUser and insert Value as ${LoginData.username}
12. Select Test command as Input, add Object as txtPass and insert Value as ${LoginData.password}
13. Select Test command as Click and Wait and Object as btnLogin (to click and wait for login after each combination of usernames and passwords)
14. Select Test command as Loop End (To try logging in with various usernames and passwords until the login is successful)
Risk-Based Testing (RBT)
Risk-Based Testing is a type of software testing in which functions and features are tested based on priority (Critical, High, Medium, Low). It uses risk analysis to recognize proactive chances to take out or avoid defects through non-testing activities and to help users select which test activities to perform.
This kind of testing includes both mitigation (testing to give chances to decrease the likelihood of faults, especially high-impact faults) and contingency (testing to know a workaround to create the defects that get us less painful).
TestingWhiz enables a user to perform Risk-Based Testing by defining the risks at the Test Case level. This gives a user the granular advantage to test even at the critical parts of her/his application.
Steps & Configurations
1. Create a new Test Case under a Test Suite
2. Right click on the Test Case and open Properties to define the Priority from the drop-down for performing RBT
 By default, priority will be set as Medium. |
3. For enabling Risk Based Testing, go to Tool Configuration Settings → Risk-Based Testing
4. Mark the checkbox RBT enabled execution
Choose the Priority of the respective Test Case as High, Medium or Low by marking the respective check box and click Apply to enable the
5. Test Case will be executed according to priority
Web Service Testing
A web service is a collection of open protocols and standards used for exchanging data between applications or systems. Software applications written in various programming languages and running on various platforms can use web services to exchange data over computer networks like the Internet in a manner similar to inter-process communication on a single computer.
There are 2 ways to implement Web Services
1. REST (REpresentational State Transfer architecture) Web Service
2. SOAP (Simple Object Access Protocol) Web Service
1. REST Web Service Testing
REST means REpresentational State Transfer; it is an architecture that generally runs over HTTP
The REST style emphasizes the interactions between clients and services, which are enhanced by having a limited number of operations. REST is an alternative to SOAP and instead of using XML for request REST uses simple URL in some cases. Unlike SOAP, RESTFUL applications use HTTP build in headers to carry meta-information.
Steps & Configurations
1. Create a new Test Case under a Test Suite
2. Select Test Command as Execute and Action as Rest Web Service from the drop-down
3. Click 
from Value column and “Execute Rest Web Service Test Command” window will be open
4. Enter the URL of the Web Service
5. Select the type of Method (Get, Post, Put, Delete) supported by the REST URL from the drop-down
6. Specify the Headers (if any) in Request Header fields. The user can also specify multiple Headers separated in multiline
7. Specify Request Body parameters. The user can also specify multiple Request Body Parameters separated in multiline
8. Enter the variable name in Target Response Code field to store the Response code after execution
9. Enter the variable name in Target Response Header field to store the Header Response after execution
10. Enter the variable name in Target Response Body field to store the Response Body after execution
11. The user can specify the service Timeout (in milliseconds) period in milliseconds to control script behavior
| Default Timeout would be 6000 milliseconds. |
12. Click Save
The user needs to parse message received as Target Response Body in REST Web Service
13. Select Test Command as Parse and Action as JSON Message from the drop-down
14. Click from Value column and “Parse JSON Message Test Command” window will be open
15. Enter the Source Variable in which JSON Expression needs to be evaluated
| The user needs to specify the same variable value which was specified in the Response Body field of Execute → Rest Web Service Test Command. |
16. Enter the JSON Expression to extract data from the JSON Response variable specified above
|
 |
17. Specify the Target Variable name to store the result of the JSON Expression after execution
18. Click Save
Refer File → Open Sample → Rest Web Service for more information.
|
2. SOAP Web Service Testing
SOAP is a standard protocol defined by the W3C Standard for sending and receiving web service requests and responses.
SOAP uses the XML format to send and receive the request and hence the data is platform-independent data. SOAP messages are exchanged between the provider applications and receiving the application within the SOAP envelope. SOAP uses the simple HTTP protocol.
Steps & Configurations
1. Create a new Test Case under a Test Suite
2. Select Test Command as Execute and Action as SOAP Web Service from the drop-down
3.
4. Enter the WSDL of the SOAP Web Service
| WSDL (Web Services Description Language) is an XML based language which will be used to describe the services offered by a web service.
It describes all the operations offered by the particular web service in the XML format. It also defines how the services can be called, i.e. what input value have to provide and what will be the format of the response it is going to generate for each kind of service. |
5. Click on Validate WSDL to get all the functions supported by the specified WSDL
6. Select the type of Method from the drop-down populated based on the specified WSDL
7. Specify the Request based on the Method selected. The user can edit the parameters and XML Request text inside the Request field
8. Enter the variable name in Target Response Code field to store the Response code after execution
9. Enter the variable name in Target Response Header field to store the Header Response after execution
10. Enter the variable name in Target Response Body field to store the Response Body after execution
11. The user can specify the service Timeout period in milliseconds to control script behavior
12. Click Save
The user needs to parse
13. Select Test Command as Parse and Action as XML Message from the drop-down
14. Click
15. Choose
16. If the user chooses a Variable option, then enter the Source Variable in which XPath needs to be evaluated.
| The user needs to specify the same variable value which was specified in the Response Body field of Execute → SOAP Web Service Test Command. |
17. If the user chooses a File option, then select the Source File from 
18. Enter the XPath to extract data from the XML Response variable specified above
List of Operators with descriptions which are used in XPath. |
19. Specify the Target Variable name to store the result of the XPath after execution
20. Click Save
Refer File → Open Sample → SOAP Web Service for more information. |
About
location
125 Village Boulevard,
Suite 315, Princeton,
NJ 08540, USA
PHONE | EMAIL
info@testing-whiz.com
