Testing AR XIII Conference

Once again I was invited to speak in Testing Ar meetup. This time the meetup was in Belatrix that is really a great place to do this kind of events.

This time I talked about the “Non event” of 2016, Selenium 3. Why small changes made a great change towards the future of testing automation.

Testing Ar is a great QA community from Argentina, very well organized and with superb people. Every month they do meetups in different companies.  If you want to see Testing Ar events you can see their meetup site here. If you want to see past events you can see their youtube channel.

 

Here is the conference (In spanish):

TestingAr VII a really nice Meetup

TestingArVII

Yesterday I had the honor to speak in one of the greatest QA meetings in Argentina: TestingAr. In the seventh edition it was hold at Belatrix headquarters in Buenos Aires and I talked about What, when, where and why to automate. It was a great experience, I wish I can be in more meetings like this.

The video is in Spanish (as it was the Meetup) and cannot be inserted, so the link is shown:

Link To The Video

After that there was a lot of food and beer and then a great explanation of Docker was done by Matias Lespiau, he really knows a lot about Docker, really enjoyed hearing his conference.

Link To The Video

And then a lot of questions, more contacts, more beer, exchanging experiences, well it was a great night.

Test automation. Dealing with common excuses

free_shutterstock_58878098_robot

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.