This article is brought to you by Joe Colantonio. Original source

Now my time is split approximately 50/50 between creating automated tests for UI and creating tests for APIs like REST services. There are a few reasons for this:

1. Agile practices
   
2. The Internet Of Things

I’ve been involved with test automation for over 15 years, and in the beginning, pretty much all my test automation efforts focused on automating GUI user interfaces like thick client applications, browsers and even green screen for mainframes.

Agile Automation

With Agile development becoming the standard in most organizations, the ways in which we develop software and automate tests have changed dramatically.

GUI tests that go against a user interface tend to take longer to run.

During certain Agile practices like continuous builds, the amount of time it takes to receive feedback from a GUI regression suite of tests when new code is checked in is too long. In those cases, quicker feedback is needed.

Agile has also increased the frequency with which applications are released, which in turn has created an increased demand for new ways to quickly test them. GUI tests are typically too slow to get the test coverage we need during, say, a typical two-week sprint. Also, since API tests don’t rely on a UI to be ready, they can be created early in the development process.

Mike Cohen’s Testing Pyramid

In his book, Agile: Software Development Using Scrum, author Mike Cohn introduces the concepts of a test automation pyramid:

This image represents the opposite of the way most non-agile development teams perform automated testing.

GUI Test

GUI testing focuses on testing an application user interface to ensure that its functionality is correct. IDE GUI testing is at the top of the pyramid and represents a small piece of the total number of automation test types that should be created.

Unit Test

Unit testing makes up the largest section of the pyramid, forming a solid base. A Unit test is created to verify a single unit of source code, like a method. By doing this, developers can isolate the smallest testable parts of their code. Unit tests are the easiest to create and yield the biggest “bang for the buck.” Since unit tests are usually written in the same language that an application is written in, developers should have an easy time adding them to their development process.

Service – API Test

The middle Service layer is the “sweet spot” that tools like SoapUI, UFT API and rest-assured were created for. Service testing is also known as Integration testing. Integration testing focuses on verifying that the interactions of many small components can integrate together without issue. Since API tests bypass the user interface, they tend to be quicker and much more reliable than GUI tests. components can integrate together without issue. Since API tests bypass the user interface, they tend to be quicker and much more reliable than GUI tests.

The Internet of Things

The second change that is causing a shift towards API testing is the Internet of things. The Internet of Things is an everyday object with embedded functionality that allows it to talk over the web using HTTP or HTTPS to communicate with remote backend services.

Basically, more and more things will begin to have sensors embedded into them. The other day I saw a video of Enchanted Objects: Design, Human Desire, and the Internet of Things author David Rose being interviewed by John Stewart, who showed a medication “glow” cap, that will tell you when to take your medicine by blinking or texting you so that you don’t forget. This is just one minor application, but I’m sure you can imagine the endless possibilities for this type of technology.

Extending this trend outward, some estimates show that in 2020 there will be over 50 billion objects connected to the internet!

So how do you test, say, a scale that tweets, a refrigerator that tells you when you’re running low on milk, or bio sensors embedded in your clothing that can measure your stress level — and adjust your environment accordingly — based on that information?

None of these examples have a traditional user interface. So how do we test them?

First, let’s look at a typical API test flow:

API Headless Testing

What is an API (Application Programming Interface)? An API specifies how its software components should interact with each other. APIs can be created using a whole host of different technologies. APIs help facilitate communication between a client and a server.

The type of APIs that we’re most likely going to be testing are HTTP/HTTPS- based APIs where communication is done over the web. For example, say we have an internet scale that has an app that makes a request and receives a response from a backend service. How do we test them?

This article is brought to you by Joe Colantonio. Original source

P.S. What is the best way to learn something new? Only if you do it over and over again with your own bare hands… completing real tasks and being mentored by industry leaders! Unfortunately, you can show up at someone’s office and tell them: I want to learn this & that, please show me where’s my desk at and I will learn it all… I am a fast learner I swear!

However, there is a way to learn it via 100% hands-on approach We are starting our immersive (2 day) Bootcamp Intro to Rest API and Performance Testing >>> The Ultimate Mobile Test Automation Bootcamp.

This training is for Quality assurance professionals who would like to enter the space of backend testing. We are not going to lecture you about what is Rest API by books’ definition. From first minutes of this 100% hands-on bootcamp, we will make you to play with live FaceBook, Slack, and our in-house OrderMe app Rest API services and teach you how to test them with FaceBook dev console and  Postman tool.  You will also learn about CURL command line tool as well as how to automate your backend test via Ruby scripting. Finally, for desert we will introduce you to the performance testing with JMeter. 

Click here to learn more about the bootcamp.