How to Start with Test Automation?

  • Share
  • Sharebar
  • Share

I want to share with you six simple steps to start with test automation. Why? Because this is a blog about Agile Testing and we cannot talk about it without having a test automation in place. The biggest struggle with implementing automated testing framework is to have teams converting their development practices to agile software development. This issue is one of the framework independent issues and it is quite common under the agile development methodology umbrella. The most difficult step in test automation is to actually start using it on a project that is already going. I leave the choice of the testing framework to you, since it is a technology and environment dependent decision.

1. Break the Vicious Circle of Test Automation

First thing you need to do in order to start with an agile test automation is to realize that you are in the vicious circle of test automation. Just look at the picture below. Does it look familiar?

Agile Testing - The Vicious Circle of Test Automation

The Vicious Circle of Test Automation

You need to break that vicious circle and actually change your way of thinking. Just plan less work on new features and bring created automated tests as a regular Product Backlog Item to the iteration planning meeting. Write an agile test User Story showing real benefits for customers. In that case the benefit is that you will do agile testing faster and have more time to do more sophisticated testing, design more test cases, and do exploratory testing. And that will provide better product quality, more convenience for stakeholders, and higher customer satisfaction. This type of Stories is called Technical Debt and are valid members of the Product Backlog.

2. Find a candidate

When you look at your base of agile Test Procedures and Test Scenarios, the amount of work needed to automate them is overwhelming. But it’s the same with any work you are going to do. Let’s take writing a book as an example. Does the author write all chapters at once? No, he or she starts with notes and then write chapters one by one. The same goes with the automation of you Test Base. Find a candidate to be automated first.

How to find a good candidate? Answer these questions:

  • What is the most boring test to do?
  • Which Test Procedure has many repetitions/loops in steps?
  • Which Test Procedure needs a lot of data input?
  • Do you need to search for specific data to pass fail the Test Case? Does it require to parse same logs all over again?
  • What is the next feature to be developed?

These are your candidates. When you automate one of them, you will feel a lot of satisfaction and relief. That’s a good start.

3. Never Work with Abstract

Working with abstract is never a good idea. One looking at a piece of modern art will say that it’s an elephant celebrating freedom and somebody else will say that he sees three squares. That’s why if you want to build an agile testing framework or automate your Test Cases, you need to plan few things:

  • What is the technology you are going to use in your automation framework?
  • What is the format of automated test cases?
  • How do you document the code and how do you connect automated test scripts with your base of Test Cases?
  • What kind of reports are returned and in what format?
  • What is the environment to run the automated tested on and what is the environment to be tested?
  • How do you trigger run in the test framework?
  • How exactly are you going to plug this framework into your Continuous Integration system?

4. Make Proof of Concept

When you have a concept of what you what to achieve ready, you need to do a reality check. It often happens than some technologies do not work as it was described or you will run into environment specific issues that couldn’t have been predicted. Here with help comes a proof of concept. You need to set up a simple framework according to your concept and build one automated Test Case or one automated Test Procedure. Start with a trigger and end with the report you wanted to get. This way you can check capabilities and fitness of tools you have chosen and at the end have one piece automated. Building your agile test proof of concept you are going to create simple helper functions and data connectors and define data formats and inputs. Automating of the next Test Procedures will be easier having all of that in place.

Remember that you are building a proof of concept, not a prototype, so no cutting corners and workarounds. They tend to stay there for ages. In terms of Scrum we should say, that what you are going to deliver must be DONE.

5. Use DSL

As I mentioned in the previous paragraph, you are going to build a small library while working on the agile testing proof of concept. Purpose of using a library is re-usability. Any code written should be self-explanatory and well documented. Also you need to remember that the framework should be robust and easy in maintenance. The best way to achieve good quality re-useable and robust code base is to create a Domain Specific Language for your test framework. What does it mean in simple words? Let me explain that on an example.

To run a search in your web-based application to check if the expected amount of links is returned, you need to write quite a few lines of code. Most probably you have quite a few similar Test Cases in this area. So the best thing to do is to extract all the global initiatlization functions and common actions to one object called myApplication (you name it) and methods like myApplication. runSearch (searchString, expectedNumeberOfResults, firstLinkOntheList).

When you read that code and write new Test Cases in your IDE, you will learn the structure of the framework and use it naturally. And imagine that some screen or flow changes. If you have lots of independent procedures, you have a maintenance nightmare. With use of DSL, you have to change the code in one spot only and the Test Cases will pass again. You can even leave creating the library to experienced developers and have less technical people to write agile Test Procedures. This way the test automation will be fun and rewarding.

6. K.I.S.S.

Keep It Simple Stupid. You need to follow that rule the same as it goes with any other development work. Keep the design flexible and code simple as possible. Try to use out of the box solutions as much of possible and avoid changing third party code. In case of a tool update, you will be in lot of trouble or get stuck with an older version of software, because adopting changes will cost too much in overhead.

Now it’s Your Turn

Share other ideas of starting with test automation and issues you have solved in your journey to build a robust test framework for agile testing.


Similar Posts:

One Comment

  1. Archie says:

    This is really going to solve my problem.
    Thanks a ton! :)

Leave a Reply