In this second part of test automation tutorials series, I will briefly describe the types of automated tests and then most importantly I will clear some misconceptions about test automation.
Types of Automated Tests:
There are three main types of automated tests.
#1. Automated Unit Tests
Automated Unit tests are written to test on code level. Bugs are identified in the functions, methods and routines written by developers.
Some companies ask developers to do unit testing themselves and some hire specialized test automation resources. These resources have access to source code and they write unit tests to break the production code. Due to the presence of unit tests, whenever the code compiles, all unit tests run and tell us the result that whether all functionality is working. If any unit test fails, that means there is now a bug present in the production code.
Some of the most popular tools present in the market are NUnit and JUnit. Microsoft also provided its own framework for unit testing called MSTest. Go through the websites of these tools and they will provide examples and tutorials on how to write unit tests.
#2. Automated Web Service / API Tests
An Application Programming Interface (API) makes it possible for software to talk to other software applications. Just like any other software, APIs need to be tested. In this type of testing, GUI is usually not involved.
What we test here is usually the functionality, compliance and security issues. In web applications, we can test the Request and Response of our application that whether they are secure and encrypted or not.
This is one of the examples where we can use API Testing. The most popular tool for API testing is SOAPUI which has both free and paid versions. There are other tools as well, which you can use according to your need.
#3. Automated GUI Tests.
This type of automated testing is the toughest form of automation because it involve testing of User interface of the application.
It is tough because GUI’s are highly subject to change. But this type of testing is also closest to what users will do with our application. Since the user will use the mouse and keyboard, automated GUI tests also mimic the same behavior by making use of mouse and keyboard to click or write to objects present on the user interface. Due to this, we can find bugs early and it can be used in many scenarios such as regression testing or filling up forms which takes too much time.
Some Misconceptions about Automation Testing
Over the years, I have heard some misconceptions about test automation. I think, I should clear them too in this article.
Misconception #1. Automation is here to replace manual testers.
Test automation is for helping the testers to make testing faster and in a more reliable manner. It can never replace humans.
Think of test automation as a car. If you walk, you will take around 20 minutes to reach your home. But if you use a car, you will reach in two minutes. The driver of the car is still you, a human, but.. the car helps the human to achieve his/her goal faster. Also, most of your energy is saved, because you didn’t walk. So you can use this energy to perform more important things.
Same goes with automation testing. You use it to quickly test most of your repeated, long and boring tests and save your time and energy to focus and test new and important functionality.
As James Bach said a wonderful quote:
“ Tools don’t test. Only people test. Tools only perform actions that “help” people test. “
Tools can click on objects. But where to click will always be told by a manual tester. I think you get my point now.
Misconception #2. Everything under the sun can be automated
If you try to automate 100% of your test cases, maybe you will be able to do so, but if that you could do, then our first point becomes false. Because if everything is automated, what will manual tester do?
Actually the point is, you cannot automate 100% of your test cases. Because we, as testers, believe that no application can be 100% tested. There will always be some scenarios which we will miss. There will always be bugs that come only when your application will be used by clients.
So if the application cannot be 100% tested, how you can promise 100% automation?
Also, there is a very thin chance that you will be able to automate all of your existing test cases. There are always scenarios which are difficult to automate and are easier to do manually.
For example, One user will enter the data, the second user will approve the data, third user will view the data and fourth user is prohibited to view the data. These scenarios can be automated, but they will take a lot of time and effort. So it will be easier, if you just do that manually.
Remember, we use cars to go distances, but there may be lengthy signals on the way, there will be fuel consumption, there will be parking space issues, parking charges and a lot more headache. In some scenarios, we just walk and reach to our destination :).
So, you should not try to automate everything. Only automate those scenarios which are important and take a lot of time to do manually.
Misconception #3. Automation only involves recording and playback.
Please don’t live in a fantasy world. This fantasy is actually created by false advertisements from different automation tool vendors. They say you just record and playback your steps and your test cases will be automated. Well, that’s a Big Lie!
Automation is everything but recording and playback. Pure automation engineers normally don’t use recording and playback feature at all. Recording and playback are generally used to get an idea how the tool is generating script for our steps.
Once we get to know the scripting, we always use scripting to create automated tests. Remember, you must know programming if you want to do test automation. On the other hand, don’t be dis-hearted if you don’t know programming. Because like any other task, programming can also be learned with practice and dedication.
I have known people, who are not even from Computer science background, but they learn programming and now they are awesome automation engineers. At Microsoft, they hire testers who can do programming. They are called SDET (Software development engineers for test). The first line of Job description says “SDET’s write a lot of code….”.
Please learn programming, don’t run away from it. It will make you an amazing tester.
I hope this article will help you to clear some concepts related to test automation.
In the next article, I will discuss about how to start test automation in your organization step by step.
Feel free to give your feedback and suggestions, it will help us to improve in our future articles.