How to design an automation test case or script?
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 site. Now, this looks simple enough, isn’t it? How does this become an automation script? (click on image to enlarge)
How to translate this manual test case into an automation script?
The following are the guidelines we are going to follow to achieve the translation into an automation script:
#1: State of the AUT: 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 won’t 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.
#2: Test Steps:
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.
Automation steps:
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.
#3: Verification and Validation
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.
#4: Test Data
The following are some of the questions that you might consider answering for your test data requirements:
1. Where to place it?
2. To hard code or not?
3. Security concerns?
4. Reusability concerns?
When you look back at the manual test script, you will notice that having the test data, the username and password available is one of the preconditions to even begin the test.
#5: Results
For a manual test case, you can put the result of each step in the “actual result” column. An automation tool’s result file contains the result of each step when executed.
Automation tools these days have very robust reporting features. However, you might still need to tailor the test results. So include the steps to write frequently to the result file so that you will know exactly what went on while the execution was happening. If the tool you are using does not support writing to the result file it generates, it is a good idea to have at least an excel sheet or notepad associated with each test to put in comments about the execution status as you go.
#6: Post Operations
Once you are done with testing it need not be explicitly mentioned in your manual test case to close the browser or close the AUT etc. As a tester you would do it diligently. In the case of automation test case, you can include these steps in your script. Clean up – is what I call these activities. Kill all the connections you created. Close all the apps. Release the memory.
Let us walk through each step:
Step 1: precondition. We are launching the IE with the Gmail.com URL programmatically.
Step 2 & 7: Sync statement. As we discussed above, these are important to making sure the AUT comes to the desired state before the next step execution follows.
Step 3 & 4: Data entry. All the data is hard coded into the script. Although not advisable, it’s a start.
Step 5: Change of AUT step. Step 5 includes clicking on Sign In button. You will not need a V&V when this statement gets executed. That is because, there is a subsequent statement and if that can run; it means the one before it has been successful. But if you are extra diligent, you can include one here.
Step 6 & 8: comments
Step 9 & 11: Conditional statement. V&V/Checkpoint. We are trying to see if the login has been successful by checking if there is an inbox link in the resulting page. If you note carefully, link with inner text, “inbox.*” is looked for. So irrespective of any number of new emails(which is variable) received, if you have an inbox link(which is always a constant) available, that means the checkpoint passed.
Step 10: Message box. For visibility
Step 12 & 13: These are the cleanup activities. You are signing out from the account and closing the browser.
Conclusion :
So, you see how easily an automation script unfolds when you have a well written manual script and a set of basic guidelines to follow. Since this is not an article concerning frameworks, I stayed clear from functions, reusability factors, parameterization etc. Test script being the fundamental building block, it is easy to improvise on a script when you have the basics right.
Are there any other factors you consider, another method you find easier or any guideline that you find hard to follow? Please let me know your feedback in the comments.
Welcome to QTP Tutorial 