This post was part of a series I wrote for Improving and originally posted on the Improving’s Thoughts Page.

As projects grow, many reach a point of looking into automation. To Automate or not to Automate, that is the question. Due to its many benefits, most choose to start automating. But where do you start? Start with your goal. Pulling from the previous discussion, I propose that our goal in automating is to reduce the overall cost of increasing our confidence in a release of our software. But developing a new organizational capability takes time and resources. So our first task is to determine what resources we’ll need. When starting a new automation effort, the project is bound to hit some snags. Simple things like how to share ownership of the automation code amongst a team of QAs can trip up infant efforts. Whether its version control, or debugging a broken script, many of the pitfalls you run into when starting an automation effort are just the mechanics of effective enterprise development. But guess what? You already have team members talented in those mechanics; your developers!

Fundamentally, creating an automation system is all about programming. And it is programming which you really want your QAs to own at the end of the day. After all, you really don’t want the same person who wrote a feature also testing it for you. So starting up an automation process is going to ask your QAs to operate in a new space. And if you’ re asking your QA to operate in a programming space, why wouldn’t you give him one of your best tutors? Your QA needs to learn to program in order to automate.

As your QA programs your automation system, they’ll run into challenges like abstraction. Your developers work with this concept frequently. Your QA may run into a mistake in their test script. This is Debugging. Your developers are well practiced in this work. Considering the larger picture, your infant automation system has some big design decisions ahead of it, which is software architecture. Again, you have the expertise on your team already. Perhaps here you need a more senior developer, or even an architect. Nevertheless, the programming knowledge you need is available through collaboration between developers and QA.

{Image: Picking a team?}

Picking your players

With this in mind, let us consider an MVP type case. You might vary the exact composition of your automation team to start. But let’s use one Developer and one QA for consideration and simplicity. You might not want to dedicate someone 100% to automation, and that’s fine, so long as we keep in mind that we’re making a tradeoff. Further recall that not all tradeoffs are 1 to 1. You might allocate your team 50% to automation and 50% new feature development. But don’t expect to get the automation done in just twice the time. The task switching between feature work and automation will slow your progress. You might choose to have more people involved in your initial effort, and that can be good as well. But keep in mind that the larger your team gets, the more overhead you’ll spend. It takes more effort to keep a group of 10 aligned on a goal, and to keep them from stepping on each other’s toes. Where a team of 2 can usually maintain

good alignment and cohesion with relatively little effort. So bear this in mind as we explore the kinds of team members you might want, and the kinds of challenges they’ll face.

Returning to the single Developer and single QA case, let us consider the particular pairing of talents an infant automation effort needs to succeed. Since QA must own the system, we will start with them. Naturally, you will want someone strong in test case development.

But that strength alone isn’t sufficient. You particularly need someone who can articulate the steps necessary to the effort. Someone who can do so without the aid of the application at their fingertips. Ideally, they should be able articulate the cases in human language, without getting bogged down in the details. They, of course, must be able to speak to the details of how when it is time. But the articulation without having the system at hand is often the more difficult. Since we’re talking about automation, you will need to find someone willing to learn a new skills. It is possible that it is an entirely new skill to some of your team. If you, however, find someone already practiced in another test automation framework, take time to consider your needs. Each framework may have its idiosyncrasies. If you are using the framework they are familiar with, then that lowers your barrier to entry! And in such a case, the other talents are more the judge of whether they are a good fit. However, if you are looking at a new tool, you should take some extra time to consider the challenges your situation presents. With different idiosyncrasies, what worked well for one framework may not work for another. Is your experienced team member flexible in their approach? Are they willing to try to learn to use the framework for how the framework seeks to be used? If so, then their experience will be a benefit to your new automation team. If not, it may be more harm than good. So overall, you want a flexible, articulate QA team member. Experience in other automation is a plus, but it is not necessary. What is important is that they are approaching this project with the intent to learn.

Finding the right coach

Pivoting now to consider the Developer, we need a different variety of talents. Certainly, we want a strong programmer, but that is not enough. Since QA must own the system at the end, we need someone more as a guide. While it is certain that your developer will get their hands dirty in the code, we need them to play the coaching role far more often. Finding someone approachable, and kind is a good start. After all, we need our QA to be able to ask plenty of beginner questions. Moreover, you need an effective communicator. Many of the practices which our QA must now learn can be complex. It will take time and patience to effectively teach them, so your ideal Developer must also be patient. And they need to be able to articulate not only the concepts to be used, but they must also help teach the rationale behind them so that our QA may grow to independence. Recall that our goal is a system which our QA can extend and maintain. The practices your Developers are already familiar with will enable that. But we must teach them, not merely practice them. Failing in that regard will burden the automation effort with the pitfalls which might be avoided. Thus, effective information and practice sharing are a must.

Along these lines, your ideal Developer needs a sound grip on system design. In effect, building an automation system is much like building another application. One which will require intentional design. This aspect in particular will make it hard for junior developers to be as effective as we’d like. As your Dev and QA work to develop the automation suite, they will need to make decisions about the path they take. These decisions will have rippling effects on your effort. They may improve your ability to extend and maintain, or they may significantly limit it. Now to be clear, just because a decision will have this impact is not an excuse to avoid making it. Give your team the permission to decide. But help them to review and evaluate those decisions at intervals. The longer a limiting decision gets left in place, the more likely it is to ripple throughout your system. So, to summarize, you want an effective communicator for your Developer. They need to have the design chops not only to design the system, but also to help teach. And as a result, they’ll need a teacher’s patience. If your QA can’t approach them, it won’t work.

{Image: Map and compass }

Charting the Course

Once you have your team selected, it’s time to get a lay of the land. The journey you are embarking on holds many pitfalls and snares, so let’s spend a few moments talking about some of the common traps new efforts can fall into. The good news is most of these challenges are easier to overcome if you are aware they are there. So, let’s build that awareness.

While automating you will encounter many development type challenges. The choices you make early on will dramatically affect the success you experience with your automation suite. Consider your automated testing project as if it were a new a software project, because it is one. Therefore, start with the user in mind. For automation, it is the QA who will be extending these tests in the future. If the QA cannot get the test code to control the application under test, then the automation tool isn’t very helpful. Most times this will mean the developer must add handles to their code to enable the automated system to grab onto those UI facets. This can be called a Test Harness, and it has many forms. In HTML, it could be as simple as some ids on the actual page elements. So, your first order of business is to develop a usable, but not labor-intensive test harness. Ideally, some practice which can be woven into regular development.

After establishing the test harness, the next temptation which plagues automation teams is adhering to a strict mechanical description of the actions taken on the application. To be clear, I don’t mean human descriptions, like ClickTheRedButton. Instead, I have seen automation systems bogged down in describing how do you find that red button. Then how do you get its handle. How do you ‘click’ a button? And then they look for some other element on the page to verify activity. While all this code is necessary for your automation script to run effectively, it is very difficult to read and maintain. Just consider the onboarding cost to bring a new team-member up to speed. The more code they have to sift through, the more likely they are to lose the intent of the test in the first place. You want to strike an appropriate balance between the mechanics of what you are doing in the application, and why you are doing it. The start of the solution for this challenge is in interface design. We want to provide QA with an interface that

allows them to describe what they want done, without pulling us into the murky depths of every step of how the automation code gets that done.

There is another concern here though. One more costly than decreased usability. Leaving your automation code to repeat itself, in direct description of its test execution also makes your infant test automation incredibly brittle. Consider the situation where you have 4 tests which all describe in that detail how to get to the Red Button. Open the page. Scroll a bit. Stop. Look for a Red button on the Left, etc. Then one day, a new feature comes in that adds another red button a little higher on the page. Suddenly all 4 of those tests break, because they were expecting the red button to be the first one on the page! Worse yet, you now have to find the place in 4 different, and lengthy scripts to fix the bug. Ouch! This is a pair of problems which are encountered by your developers frequently. Here our solution starts by looking for a way to appropriately share and reuse test-harness code for that fateful red button.

{Image: Box of Vocabulary flash cards or something similar}

Building your automation language

This path will lead you to the first of the software architecture decisions of your infant automation effort. How can you design your code to separate the interaction with the test harness, from the description of the steps of a given test case? Options abound for how to do this. And each has their own unique trade-offs. Each imposes a certain style of work on the system going forward. For this article, let us consider a library type option. In development, a library is really a container of reusable functionality. Think of it a little like a box of index cards with words on them. You can compose a sentence using the nouns and verbs available from your box. So too, can your developers help your QAs develop a set of cards, in this case functions, for interacting with the Test Harness. PageObjectModels[link], are a good example of how this can work. If your team adopts PageObjectModels for example, those 4 test cases might all interact with the same page model. And thus you’d only need to adjust that shared page model to account for the additional red-button. Ideally by giving it a better name than just ‘TheRedButton’.

What we’ve covered here is by no means the last word on how to start your automation effort. You will need to adapt these solutions to fit your needs, and your team. Only you know what you can spend on starting to automate. And as a result you’ll have to make different trade-offs than someone else. But with this discussion you’ve gotten a leg up on the effort and some useful questions to ask yourself. More than that, we also were able to briefly explore some of the common hazards at the start of the race. Hopefully this has left you more confident to start down the road of automation. If you’d like more insight into the process, or to get some help with starting, please reach out. And be sure to check back for the next article, where we’ll talk about how you can integrate your automation into your devops cycle for better value