Automation always follows manual testing. Typically, one or more rounds of manual testing already would be performed on the AUT. This implies that manual test cases already exist and have been executed at least once.
For example, assume the following is your manual test case. It is a simple logging on to gmail.com website. Now, this looks simple enough. How does this become an automation script?
Automation testing process
The following are the guidelines we are going to follow to achieve the translation into an automation script:
The column precondition is nothing but a particular state of the background to be set for a certain step to be executed. This is especially important in two scenarios:
To begin the test: In this case, we need the browser available and launched. (The username and password availability will be dealt with in a little while). Now, how to write the same thing in the automation world? Consider QTP. You have an option to either launch the browser using programmatic statements or you can use the record and run setting dialog to set the properties. Setting these properties correctly is very crucial. Often this is the reason why a particular piece of code will work in a machine and wont work in the others.
To execute a certain step: For step2 to be performed we need step 1 to be done and complete. To do so manually, we can just wait until the step execution is done and the page gets loaded fully. Use the sync or wait statements in your automation script to wait until the desire state comes true.
Note: When you are running the same code for multiple sets of data, you would want to make sure that you are returning the AUT to the state that it should be before the next iteration start.
We can categorize the manual test steps into 3 categories:
Data entry Data entry steps are where you are entering some information as an input to your AUT. Change of AUT state steps these steps are the ones that will cause a change to happen to your AUT. It might include going a new page, a certain field being visible, an edit box being editable etc. Combination as the name implies, this is combination of both of the above types. Take the case of a checkbox, when turned on will make a certain field active. In that case, you are entering the value True for the checkbox field and it also results in a state of your AUT. In the above test case, only the type 1 and 2 steps exist.
Type 1: test steps 2 & 3 Type 2: Test steps 1 & 4 The pre-requisite to creating an automation script using any tool is to spend some time analyzing the tool as well as AUT. Try to see how both of them interact with each other. For example: QTP has 3 recording ways and each one works a different way. If you know how it identifies objects, you would know which one to use and use it better. If you have a web app where QTP can identify the objects easily, you can use the normal mode. If not you might have to use the analog or low level methods.
Data entry steps are not very different in the automation and manual methods. All you do is enter the data. The way you reference the field is different. Since it will be machine performing the steps, we just have to make sure we refer to the fields in the AUT in a way that the tool understands. That means, you have to use its logical name as used in the code.
For Change of AUT /Combination steps in a manual scenario, you perform the action (clicking or checking or entering) and verifying the change at one go. But in an automation scenario that is not possible. So we have to make sure we add steps for action and validation/verification.
Comments for readability.
Debugging statements these are especially important which you are creating and testing the test itself. Try to use message boxes frequently to output various values at various stages of test execution. This will give you a visibility into the test like nothing else would.
Output statements to write to results or any other external place like a notepad or excel sheet.
Without verification and validation the intent of testing is lost. Typically you will have to use a checkpoint (does not necessarily mean the inbuilt ones). So you will have to use a lot of conditional statements and also loop statements to build the logic.
An important thing to consider is- the attribute based on which you are basing your v&V should not be ambiguous. For example, for successful login, look for the inbox page display not for the number of new mails, because that is not a constant value.
So you have to pick something that is true every time a set of operations happen without fail.
The following are some of the questions that you might consider answering for your test data requirements:
Ready to start your tutorial with us? That's great! Send us an email and we will get back to you as soon as possible!