How to Do Test Automation Without Coding
Believe it or not, carrying out successful test automation without coding is not difficult. Read on to learn how to do it.
Join the DZone community and get the full member experience.Join For Free
Today’s development cycles are short. The marketplace requires quick response time for the customer. Process methods such as Agile and DevOps have enabled cycles to be shortened and releases quickened through Continuous Integration. Because of the need to get quality products out to the customer quickly, testing has become even more important as an integral part of the development, and it also must be accomplished quickly. Designing test cases that do not require coding can save inordinate amounts of time and ensure more accurate and quality product releases.
Testing has come a long way since the days of COBOL and Fortran applications. Back then, all the testing for user applications was done manually. This took a lot of manpower, time, and money. Writing user tests and performing them required performing repetitive tasks that were prone to human error. Testing was always done at the end of the development cycle and just before delivery of the product, which meant that the testing was rushed in order to get the product out the door. This kind of timeline saw product releases that were laden with bugs and errors.
Test automation is a necessity. However, all too often, when you automate testing, the thought is that you are required to code. Not all shops have programmers who are also available to write the code for unit testing. You are left asking how can you unit test quickly in a Continuous Integrated environment without coding.
Successful test automation without coding is not difficult; you can achieve it by implementing some simple processes. This article discusses a simple example of an application that can be automated without coding, the skills that are required on your team, and tools you can use to enable the tasks.
Why Automate Testing?
In revisiting the “why” for automating testing in your shop, we come back to the Agile and incremental development environment. In this environment, Continuous Integration starts at the beginning of a project on the very first day. Tests need to be run for every change that is made by developers and are often run several times each day. Passing the tests is the key measure of progress. However, the short time frame in between tests makes it impossible for manual testing.
Continuous Integration means continuous testing. Each time a new build is added with new features, you test those features to make sure they are functioning as they should and that they haven’t caused something that was working properly before to be broken due to the addition of features. Using people and manual testing methods are impractical. Automation is the answer.
Use the example of a Savings Calculator as an application where you might automate the testing.
A Savings Calculator application has the user enter a total goal amount to be saved and an amount to be saved in periods such as monthly, daily, quarterly and annually. Internally, the application needs to handle any errors that are entered. Each error situation needs to be tested as well as the correct inputs.
In applying user testing without coding, it is useful to see how a typical unit test works because the mechanisms for running the tests and the philosophy behind this is the foundation of many of the automated UI test platforms.
A Typical Unit Test
In the above graphic, on the left, you see the module that is going to be tested – a constructor method that takes the inputs for the goal amount and the periodic deposits. On the right, you see a unit test that calls the constructor and then checks to make sure that all of the computed values are in fact correct.
This does not require you to understand the code. The point here is that because you have a function in code (i.e., a unit), you can make tests that call to that function, thereby checking to see whether or not that specific function works under a number of different scenarios. A complete test suite runs many tests on the same function for both normal and error conditions.
We can see three different test situations in our example:
- The goal is divided evenly.
- The deposit does not divide goal evenly.
- A zero deposit is a proper exception being thrown to see if the error is handled correctly.
As a general practice, developers produce unit tests. We want to focus on building tests for the User Interface.
In our example of the Savings Calculator, we see this set of possible testers for the UI:
- Go to the page.
- Fill in the goal.
- Click “compute.”
The unit test would check these values and others like the extra remainder deposit in the event that the goal can’t be divided evenly or error messages if something was left off. Of course, it is possible to test this unit through writing code that replicates the actions made by the users.
Before we get further into the topic of testing without writing code, it is important to understand the architecture of the UI. The UI is more complicated because websites and GUIs are not APIs. UI testing relies on adapters, which is code that is available for APIs. In this way, the adapter is in between the UI and the test platform.
Recording User Interface Steps
Rather than writing code to run a test, the goal is actually to perform the steps. Because programming languages have evolved and technologies exist (like spreadsheets) that perform data manipulation and calculation, you now have the technology that allows you to record the steps you are going to test.
Using a recording application, instead of writing code you simply record the steps on the screen:
- Start the recorder.
- Go to the page.
- Enter the deposit amount.
- Hit the calculate button.
You activate the recorder, do a series of things, check the steps, check what occurs when action is taken, validate, and finally report the outcomes. These steps run over and over.
Breaking Test Cases Into Modules
In the event that you have test cases where there is much repetition and a lot of duplication, there is no need to record each step every time it is repeated. An example of such as test case is resetting the page. This would occur at the beginning of each test. So you would take the work of resetting the page and break it into its own module. Then the other modules would record separate things. By breaking large tests into smaller modules, you are able to build sophisticated tests. For specific data inputs, you can create tables that drive the testing.
Here is a quick checklist:
- For the same steps that repeat, break out into common modules.
- After recording a test, then you can copy that recording into test cases.
- Drive different data into a table.
- Start with recording for one value and turn into parameterize the one test by variables instead of hard values.
- Create table-driven tests. Many test environments support these.
- Use this same approach to test for live data – run all against test cases.
- Have a series of modules that provide usable capabilities.
- Make up different configurations of tests that run on each check in as a sanity test or other test that run every hour or daily. There is no coding required; use simple tables and a drag-and-drop interface.
What skill sets do you need on your testing team to create these cases? Here are the functions for recording UI processes.
- Recorders: The recorders are the foundation for doing all of this work.
- Editors: The editors clean up the recordings and make tests more generalized.
- Coders: The coders will go beyond simple, basic actions.
The recorders record the steps, actions, and create the modules out of UI elements. The editors perform these tasks:
- Clean up the recording.
- Create a repository or “modularize” by grabbing and dragging steps to other modules, if needed.
- Create data-driven tests.
You may be wondering what requires coding? In the effort to have 100% automated testing, these are tasks for coders:
- Calculate a value (i.e., to compare results).
- Perform conditional checking like a random pop-p.
- Complex looping; totals, grand total.
- External system access; go to another system.
- Create customer actions; like Excel actions specific.
Keep in mind you need to get a tool that uses a good recording and playback. In addition, use tools to write sequences one time that transfer to different platforms. Once you learn how to do it for one technology, that knowledge should be transferable to another technology. Your automation environment should support all of your platforms – Windows, PC, Apple, Mobile, Android, websites.
Though we are not recommending specific tools, we suggest that you do not use a simple open-source tool. Look for tools that have robust platforms. Try a few by testing them against your real applications. Consider the capabilities that you need (i.e., web, mobile, product-specific Apple or Android) and choose a tool that provides for those.
This has been a quick look at 10,000 feet of how you can automate testing successfully without coding. In summary, you should:
- Find a recording tool that works on your application platforms.
- Have recorders and editors on the team who can organize the units and modularize where it makes sense.
- Have knowledge of the system architecture, UI elements, and path expressions.
Through trial and error, you can find the tools and develop a process that works best for your organization. You will find that test automation without coding is an easy and efficient method that improves the quality of your process.
Published at DZone with permission of Christie Marsh, DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.