How to Automate Your Tests Without Programming Skills – Execution

This is the second part of a three-part blog post series regarding test automation for manual testers without any programming background. This blog post deals with the opportunities that manual testers have in the automation category of “Execution“.

If you haven’t read the first part regarding preparation tasks, it’s recommended to do so prior to reading the section on Execution.

• Categories for test automation
• Learning how objects are recognized in test automation
• Working with the object repository and organizing this
• Building test automation actions from the ground up
• To be continued…

Categories for test automation

Below you’ll find an outline with the three different areas for manual testers to consider when jumping into test automation: Preparation, Execution and Analysis. Within each of these categories, there are specific sections in which manual testers can make contributions right away. This blog post will cover the second category listed: “Execution”.

Learning how objects are recognized in test automation

This is a key area of understanding for a functional test analyst – how objects and controls are identified by the test automation associate or the test automation solution. There may be a new term to some called the ‘Accessibility’ layer. What this is reference to are those attributes and properties that are made accessible from the development team. Some examples of this are Object Name, Object Index, Inner Text, Caption, Label, etc. The test automation solution latches on to one of these properties to be able to accurately identify this test step with repeated success.

This is such a key attribute to be able to know how the test automation analyst is working or how the test automation solution is functioning to replay your tests with success each and every time.

Working with the object repository and organizing this

You may have an application that has a number of forms, windows or screens. Then on each or some of these forms, there may be 30+ controls or objects contained within here. When the automation solution is interacting with each of these, the object repository itself could get very large. The object repository is the collection of objects that the test automation solution has either clicked, pressed, inputted data or done any other event on that specific object.

With respect to the section above, there are attributes that the test automation solution has been in contact with and that information is stored in the repository. This information is centralized so you would not have to record or write another test to be able to work with that object. What you may see though is a series of controls that may or may not have good object names or other properties for automation. For example, if you have a series of radio buttons for each state in the United States, the name of the object might be RadioButton1 through RadioButton50.

What’s recommended is that following the initial recording or coding for that object, make sure to edit the name of the object to make it more meaningful if it is not already. Ranorex has an object spy tool called Ranorex Spy that can aid with this. You don’t want to have to go back to the object repository to figure out object names for a test you did weeks or months ago.

Building test automation actions from the ground up

When starting off with an automation effort just like anything else, planning is key. It would be good to have an idea of how you wanted this structured, but it should not be mandatory. For example, you may create the following structure for your automated test cases:

Login TC – Administration TC – Work Order TC – Checkout TC

What if there are steps you want to add to the Administration TC that impact the Work Order TC and ultimately the Checkout TC? Does that mean you have to re-record or re-code? You shouldn’t.

What is recommended is to concentrate on a quality recording, end-to-end. Make sure the steps flow clean with the proper objects clicked. If done through code, the test automation analyst should build this in such a way that there is flexibility to add new test logic so the functional test analyst can modify this as needed without starting fresh. If you wouldn’t recreate a brand new test case for adding new test steps in a manual test case, then you shouldn’t have to with automated test case.

To be continued

Now you have read the second part of “How Manual Testers Can Break into Test Automation” covering “Execution”, one more blog post will follow discussing the “Analysis” aspect. Stay tuned, this is coming soon…