Automation? It’s Easy as Pie!

Our CIO and Automation enthusiast Jair Tabares Plebani talks a little bit about some common issues when companies decides to start test automation.

Very often we hear managers and IT sales people talking about the wonderfulness of the automation practice in QA, how it will reduce production bugs, time to market, how quickly company will get the ROI and finally cost by reducing manual QA.

It is at this point where automation fails! Is at this point where a project starts losing money and where QA Engineers start looking unprofessional. From the very beginning, the definition of the automation is a lie from people that has not idea about QA automation.

Let me explain a bit: You cannot make “an attempt to” automate your testing suite, you cannot try to “automate few regression test to reduce time”... well in fact you can, but it will conduce you to lose time, effort and to have a bunch of unusable code.

As a Project manager that likes to reduce the number of bugs on production by detecting them earlier on SIT phase, you need to think carefully:

1. QA automation would be development effort
2. As any other development effort, it will be development project
3. As any development project you will need to have developers creating code
4. As any development project you will need to have an Architect
5. As any development project YOU will ALSO need to:
   a. Think if you really need automation
   b. If you need automation, you need to make a QA Automation Plan
   c. When you have a plan, you need to make a QA Automation Strategy
   d. When you have the Plan and the Strategy, you need to get approval and budget
   e. If you are very lucky and get this, you need to find the correct people
   f. When you get part of the people, you will need to figure out that you don’t forget to put into the plan your QA Automation MVP or POC

 As you see, QA Automation is a development project, and if you don’t see in that way, the risk of a big failure (and probably to lose your job) increases.

 But wait… this does not end here. Now you that you learned that QA automation is not a simple thing, you need to go deeper and get the other risks you are facing:

1. Tools: more than once, managers are impressed by the brochure of a tool they found on internet or a call a sales person gives to them. Or worst, they are fascinated after hearing a success story from another person about some experience on another company. These are examples of a big NO!

Unless you have a lot of experience on Automation, let your team participate into the discussion. You would like to have in mind:

1. Your dev team: if you want support for your QA automation team and want to have a common dev language
2. QA community: if for some reason you need to use a different language check community, would not be easy to get much support or engineers if you want automation in Fortran
3. Your budget if you want to use a commercial tool
4. If you go for a commercial tool, think about tool dependency:
   i. What if vendor stops supporting the tool?
   ii. What if we develop a new feature that the tool does not support?

2. Roles and Responsibilities: is very common that managers decide to hire a Senior Engineer to build the whole framework on earlier stages, let him get all the knowledge and then hire other engineers to work with him, centralizing the knowledge on a unique “Atlas”. What would happen if you Fire Atlas? What if he leaves for a better job?

3. The Salesman Lie: any sales person that wants to sell you automation projects would throw any of the following lies:

1. The team would be able to automate 100%
2. We could have any tester doing automation
3. Immediate ROI
4. Self maintenance Automation assured that your product can go without bugs.

All these promises are not true. All these as goals are unrealistic. As any development project, automation goes step by step, growing from error to error

4. Any QA can automate: a very common thing is that managers ask manual QA’s without any expertise on coding or development is to start creating automation because is very easy just to record and play with some awesome tools. You easily face:

1. Record & play scripts without any flexibility
2. No reuse of code
3. No documentation
4. More refactor time when QA’s learn to code to be able to gain flexibility
5. Spaghetti code on early coded stages
6. Weird names on variables from the code
7. No modularity
8. Long scripts

5. Hurry up Tim, the end is near! As a manager you realize you need to show progress on automation, so you just push your team to “automate more and more, don’t spend time on refactors”. You know how this end… after few months, nobody cares about the red status on the automation suite… no one wants to refactor this huge monster

6. And many, many other things…

Now that you got this, still thinking that QA Automation is easy as ABC?