Types of Automated Tests and Some Misconceptions About Test Automation

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.

Misconceptions About Test Automation

#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.

The most popular GUI testing tools are QTP (Now called UFT), Selenium, Test Complete and Microsoft Coded UI (which is a part of Visual Studio ultimate and premium editions).

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?

Confused? Right?

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.

Conclusion:

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.

Recommended reading

21 comments ↓

#1 Gurpreet

Good Article…Learing a lot from this website.
Looking forward to read more articles on this topic.

#2 Tejaswini

Must read series …waiting for next “how to start test automation in your organization step by step”

#3 prince

Must read article for all the testers..
n can we use TestNG also as a Unit testing tool..?

#4 Shiela

Thanks for this. This topic is very interesting.

#5 Jo

Hi Very Nice blog,

I have doubt
1. Automated Unit Tests:- Dev team will do
2. Automated Web Service / API Tests:
3. Automated GUI Tests.: what will test how to test?

And where tester will to Regression testing?

Must read series …waiting for next “how to start test automation in your organization step by step”

#6 Kesav

Awesome article… This article will change the mindset of Testers.

#7 Mohammad Saad

Gurpreet,Tejaswini,prince,Shiela,Jo,Kesav. Thank you all for your appreciation.

#8 Mohammad Saad

@Jo, These all test types can be part of your regression testing. Regression Testing means to find a bug in your existing functionality in case of change in your application. This change could occur on unit level, API Level or GUI level. So regression can occur anywhere.

#9 Mujahid

Very nice article.

#10 Prateek Mishra

Superb knowledgeable share.

#11 Dnyanesh

DevOps is good upcoming option to integrate automated unit test in given release cycle

#12 Mitul Thesiya

Everything is perfect and same realized in my Test Developer Role in one of my recent project.

Words for Automation are also true for some of misconceptions.

Thanks to share. :)

#13 RushiD

Superb Article!

I experienced that if we are ready with automated test scripts, it helps a lot in Regression testing and we get a chance to verify the newly implemented changes.

Waiting for “Framework” article @Mohammad Saad
Thanks!

#14 Navjot

Awsome….thankyou very much STH (Y)

#15 arunsagar

which concepts we should learn for programming,for testing<,,what are the ways to learn,,where we can get it?plss refer me

#16 Heena

Amazing Description on Automation … Learned a lot from it.. Waiting for more topics on the same. Thanks for bringing it up.

#17 Karthik Rajesh

Thanks for the article, very useful..Could you please add article on automating API tests.

#18 Dinesh

Very useful :-)

#19 Sumeet

Thanks for the very useful information………..

#20 Lily

Good article!
help me a lot in my job.
Thank you very much!

#21 Selva

Very useful for me to improve my activity.

Leave a Comment