Functional automation testing, when and when not

I think all of us (or most of us) love automation testing, not only because we learn a lot about the code of the project we are at, but also because it saves time while the project advances and you can focus on other areas while the testing is running, finally, you can learn more while you're coding your automation scripts.

I have worked in a lot of projects (E-commerce, finders, intranets, matchmakers, TV channels, and a lot more) however not all the projects should be automated, of course you can automate what you want, but does it make sense ? for me the answer is no, what makes sense for me is to automate things you do daily that takes a lot of time to be done manually, if you ask me, look and feel or UI testing should not be automated, you can quickly check with your eyes the look and feel and UI of the project you are testing faster than doing a code that will check styles or correct UI, as I said in my previous post, testing takes priority over everything, this includes automation, test cases, feature files, etc. However flows like a registration, search, login, purchase a product, edit your account, configurations, among other transactions and heavy functionality flows of the system are the great candidates for automation testing.

When automating stuff you need to think about the impact and the time invest and think about the future, if you do a script today, will it have impact in a month or three ? will it help the health of the project ? will it help you to finish faster your tests ? are the tests you are doing checking or actually testing ? How long is the project going to last ? There are a lot of things to take into account when doing automation and you should ask yourself these questions before deciding something, you may end up doing unnecessary work and wasting your time on scripts that won't have impact or will be deprecated.

It would be great to have an automation culture in which every person of the project can identify areas to automate, no matter if the person is not the one that will do the code. Automation is great but I have found out that assigning a resource for only automation is really difficult, clients prefer a QA that can do both, but again the main focus is to test, think about this, the time you spend on automation may be time you need to spend on testing and make some progress, that's why is really hard to allocate automation testers or QA Engineers to only do automation on projects, of course, this depends on how the project is sold, how big the team is and how the client wants it.

 So as you can see not all areas on a project should be automated, you can do it but the impact and time invest won't be the best, it's part of the experience and knowledge of QA to know and say no on when and when not to automate stuff. 

This is my vision on when and when not do functional automation, once again the choice is yours, Don't spend time coding stuff for visual QA, there's a great tool for visual automation called Ghost Inspector, it's like a record and play tool which compares your first script with another new one just by making clicks as assertions, I have use it and it works great, download it and let me know if you like it, however in terms of visual stuff I would always choose manual testing. 

To finish this entry, there's a great quote I heard from someone once it says: "Human work can't be replaced for a robot in QA" and I think it's true we need automation but manual QA and human skills in QA are irreplaceable.

Next Tuesday the topic will be exploratory testing, stay tuned!