Test automation. Dealing with common excuses


Some companies still reject the idea of doing automation, and they have some arguments for that. In this post I will talk about the four most common that I heared:

  1. It takes time to program the base.
  2. It needs some difficult to get QA/Developers.
  3. It is easier to make only manual testing.
  4. “Maybe in the future…” excuse. So, the QA lose a lot of time testing manually and not getting time to automate test cases.

Let me say it clear:  I think that are only excuses of people that are afraid to change thinking that they are buying a risk. So for any of those excuses there is an answer, so lets talk about each one of them:

It takes time to program the base.

Yes, it takes time, but in long term it saves more. Automating the regression makes people in the team only think in new features leaving the everyday teting to a computer.

It needs some difficult to get QA/Developers.

Maybe this is the strongest excuse. The profile of a QA automation is someone that is half QA and half developer (depending on the project maybe more QA than developer or more dev than QA is needed, but lets say it is half and half). The truth is that today any developer should learn a little about QA (at least for knowing about how to face unit testing) and QA people should learn at least a little about development, not only because of automation, but because knowing what the developers are doing is a great thing. I remember being on the QA side and having to debug some Cobol code (even if I don’t know Cobol, knowing how to program made me understand a lot about what the developers were doing). So, if you get the right and motivated people, they will learn how to deal with the other part.

It is easier to make only manual testing.

Maybe you think that is easier to click a button and see the result than make the computer click the button and see the result. But think of this: a person works for 8 hours, he gets tired, makes mistakes, needs time to take a coffee, gets frustrated, have bad days. The computer doesn’t care about all this, it just works and do what was told to do. Another advantage: automated test can run at any time, you can make a scheduled task to make lists of tests run every night, or you can integrate a smoke to any new code commit, so the automation program can quickly see if the basic functionalities work well.

“Maybe in the future…”

If you make a QA team go over and over again a regression, a smoke or whatever, they will be running in circles without really doing lots of new things. Having those things automated will not only give lots of time to your QA team to work on more productive things, but will save time and money.

I am not saying that manual QA must disapear, there are lots of things that must be done manually, but adding automation to your project you will save lots of time and money and you will win quality and value. In future posts I will talk about what kind of test must be manual and which test cases should be automated.

Leave a Reply

Your email address will not be published. Required fields are marked *