What is Backend Testing and How to perform it?
Software Applications are complex; there is more than what meets the eye.
Most system testing efforts go through GUI. This is because testing validates if the software is ‘fit for use’ by the end-user or not. End-users use GUI and so do we; that is why it is really important that software fares well in this area.
But, software has a lot of other elements too that aren’t directly visible or available to the user for direct interaction. It does not make these elements any less important and they must too undergo thorough testing.
The combination of all these well-functioning elements makes a fully formed software application. We can combine everything we do not directly see as ‘Back-end’.
Some of the Backend Testing elements are:
Depending on the nature of the application a back-end can include various network configurations, communication protocols, etc. But most often, it is there three elements.
Let us now see what is involved in testing each of these components and how.
Backend Database Testing
Most commonly when the term ‘Back End Testing’ is used, it implies Database testing.
The database is an important element of any application. When the GUI and the DB interact with one another seamlessly your application works well. If there are problems, you experience inconsistent results, security threats and performance bottlenecks.
Databases are usually validated for:
- ACID properties
- CRUD operations
- Business rule conformance
Advanced ETL and data warehouse maintaining systems will need tests run against them too.
For more information on these testing types, please check out the following articles that are already on our site=>
- All About Database Testing – Why, How, and What to Test?
- ETL vs. DB Testing
- ETL Testing – Tips, Techniques, Process and Challenges
In addition to the content in the above links, the important aspect to reiterate is that Database, ETL, and Data warehouse testing need enhanced knowledge of the SQL.
Many tools are often employed by testers to interact and validate the DB behavior through queries.
Let us look at a few categories of these Backend Database testing tools:
#1) Interfaces that let you connect and run your queries against the databases.
Some of them have a GUI and some don’t.
- TOAD: I am sure everyone has heard of this. It supports many DBs and platforms. It comes both as free and commercial versions. More information, resources, and the free version is found at toadworld
- pHpMyAdmin: This is an excellent open source tool that lets you run queries and interact with your DB via a User interface. I have personally used this and my team loves how intuitive the tool is. We needed zero training to get comfortable. I highly recommend this tool if you are looking for a connection medium to your MySQL and MariaDB databases phpmyadmin
- HeidiSQL: Very similar to pHpMyAdmin. It connects to MySQL , Microsoft SQL databases, and PostgreSQL. Open sourced. Find more information at hheidisql
The list of tools is endless, but the above are some of the most popular choices.
#2) DB load and performance benchmarking tools:
- HammerDB: It is an open source tool that many DB experts vouch for. I have personally not used this but it supports many databases. From the screenshots and the looks of it, it looks like a tool worth checking out. More details at hammerdb
- SLOB: The Silly Little Oracle Benchmark tool helps you time and assess I/O style of DB transactions. It can help you understand CPU, Memory and processing times for bulk transactions on your system. More details at kevinclosson
- Swingbench: This is a very similar tool to HammerDB. This works on Oracle DBs and is very effective. To understand the tool and its features try this guide: dominicgiles
API is strictly speaking not the back-end but since we are loosely grouping everything that is not visible to the end-user as the back-end, let’s talk about this briefly too.
API stands for Application Program Interface and this is basically where all the programming logic resides. It does not have a UI which is one of the biggest challenges when it comes to testing it. On the other hand, since APIs are generally created before the application’s UI comes into existence, testing the API usually means early testing.
Messaging and send/receive calls are used instead of direct send and receiving of input and output data.
The most popular tool used for API testing is SOAPUI.
- STH as an extensive tutorial on SoapUI at => 15+ SoapUI Tutorials – Your Complete Guide to SoapUI
- HP UFT too can help you with this => 16 New Features of HP UFT – QTP vs UFT
All databases and Applications themselves are installed on servers that keep these systems up and running.
There are a few tests that are run here:
#1) Installation: Once the installation is complete, you can go to the respective folders and make sure that the files/elements have made it to their target folders in the way they were supposed to. Now, if you are wondering ‘how will I know where everything needs to go?’ ask your development or deployment teams and they can confirm this for you.
This step might not be mandatory, but some companies use manual deployments. In that case, it could become an important smoke/sanity test step.
#2) Logs: There are logs maintained for every transaction’s status in the servers. This will give us insights into whether the end-to-end process has been a success.
Sometimes the front end is sending valid data and the database might get updated right. What if this operation is throwing an exception, causing a memory leak, or causing some kind of a malfunction? It is the server side logs that will reveal this information to you.
It is not a rule, but generally, most servers are UNIX based systems. So to be able to work through them easily, you are going to need a way to connect to your server.
PuTTy, hands down is the most popular choice to connect to your servers. Putty is an open source product and needs no installation. All you have to do is download and use it.
UNIX systems don’t have a graphic user interface and that is what makes them perfect to be App and DB servers. They are secure, abstract, faster and cheaper. There are many flavors of UNIX and due to the absence of GUI, we will have to use commands to communicate with the server. We all have our go-to resources for UNIX commands and this one is mine: freeengineer
#3) Server’s performance and security:
Just like any other part of the software, the server has to be secure and responsive.
There are many tools available to check this and to find one that works for you, check out this list: 30+ Most Popular Web Application Testing Tools
As you must have noticed, this article alone will not help you learn Backend testing in its entirety. However, it points you to resources and references that will aid you to master it. So, bookmark it for reference!
Also, for those of us who tend to think functional testing is all about GUI and Front end, this article should expose that it is not the case.
Whether you are looking in the DB or checking in the log for a transaction’s status or sending a request message to a certain service, you are validating the program’s fitness to be used.
In other words, it’s functionality. The ‘where you test’ and ‘how you test’ differ.
Just like an application has to be working from all ends to be successful, we testers have to understand and explore the many facets of a software system to declare it ready to be used.
About the author: This article is written by STH team member Swati S.
It is your turn to share!
Tell us how we did with this article. Is there any other type of backend testing that you do? What tools do you use? What techniques have you found helpful? Any challenges?
Your comments, questions, participation and readership are precious to us!