Database Testing - Watch your “Back” while on a “Bug Hunt”!

I tend to compare Software Testing with that of a War! In a war, usually there are two (can be more) opponents, always in search of a chance to expose/harm/defeat the other. Similarly, testing is a process when the testers have to watch out for bugs/defects and hunt them down before it is too late! Bugs/Defects possess the power to seal the destiny of a Project/Product under development, if not caught in time. If the testers are unable to catch the bugs/defects in time, the undetected bugs/defects might harm the Product/Project in a variety of ways. It can range from unhappy clients/users, financial losses, law suites, loss of human lives, compromising application security, and so on. Hence, finally it is a game of expose-or-be-exposed! Expose the bugs/defects or allow them to be shipped with the product and harm you later on, in a big unexpected way!

Ask any military person and he would tell you that one of the golden rules of wars is to “watch you back” while in a battlefield. You become inattentive and loose sight of the things going on your backside and you are gone! It takes just one bullet to hit you at the right place and it is all over!

It can also happen to you as a tester if you don’t watch your back while testing! As I said testing is also like a war, where the testers are on a mission to hunt down the bugs/defects as quickly and as cleanly as possible. While on a bug hunt, also keep your eyes and ears open to your back! By “back” I actually mean the backend of the application. Things might look clean and free from any defects when looked from the frontend [the GUI (Graphical User Interface) or whatever UI you might be having in your AUT (Application Under Test)]. But a quick look at the backend [the database on which the application might be running] might be having a different story altogether to tell!

Backend/Database Testing is equally important as that of Frontend Testing. Once I was testing a web portal, which dealt in selling of music albums and other music related items. I was assigned to test the web portal when it was in its final stages of shipment. The release deadline was near. And my Test Manager wanted me to verify the already tested (there was a separate team of testers testing it since early development phases) portal just as a final testing touch. I was asked to test the whole web site within 3 working days. Let me tell you; sometimes “where-to-start” can become the biggest question under such testing circumstances. Anyway, I checked again with my Test Manager and made the testing mission clear before starting testing. And the testing mission was to test and find out as many showstopper bugs as possible within the stipulated time (3 working days)! And I was on.

I usually prefer to start with the Login Pages (assuming that there is such Login option) while testing web applications. There are at least a couple of reasons behind it. Login pages serve as the entrance to most of the web sites/portals. I believe, it is worth testing the Login Page first as there is always a chance to get a feeling of what lies within. You must have heard the proverb – “Morning shows the Day”! In case of web application testing, I believe the same proverb applies too; albeit in a different form – “Login Page has good chance to show the state of rest of the Application”. Anyway, that is my belief. And fortunately I might be wrong too!

Coming back to my narration, I started off with the Home Page, which was leading to the Login Page. Let me tell you that it was a medium sized web portal developed in J2EE, JSP, JavaScript, and AJAX, with SQL Server as the backend! A quick look at the login process seemed to be clean enough. The different types of access validations looked to be in right place. I was able to create new Login Ids and the validation for restricting the creation of duplicate Ids was also working nicely. The Password validations appeared to be working without any problem (at least it seemed so at that time) too! The Password fields were showing the Password as a string of asterisks (as expected). And the Copy-Paste was disabled in the Password field.

While testing, I start feeling uneasy when everything seems to work perfectly without a glitch. You may call it a result of the obsession of a tester for bugs/defects. But I just can’t help it. When I test something hoping to find some defects and suddenly I discover that everything is working perfectly, I start to doubt my testing! I start thinking – “Am I missing something here? How come is it possible that everything in this feature works so perfectly without a hiccup?” In this case also my immediate feeling was the same after I didn’t see any apparent defects in the login process. And suddenly I had one more test idea! “How if I check the database where the Login credentials and Passwords are supposed to be stored!”

So I started the SQL Query Analyzer in my system. If you have ever worked with Microsoft SQL Server at all, you might have run across SQL Query Analyzer. This tool is essential for running ad hoc queries and executing SQL statements. Query Analyzer offers a quick and nifty method for performing queries against any of your SQL Server databases. It's a great way to quickly pull information out of a database in response to a user request, test queries before implementing them in other applications; create/modify stored procedures and execute administrative tasks. All I needed in this case was to execute a simple Join to fetch the required Login credentials along with the Passwords from the database. And to my utter surprise, I saw that the Passwords for all the Login Ids were right in front of my eyes – unencrypted and easily readable by any human being! This was something, clearly against the business rules of the web portal. The Passwords were supposed to be encrypted before they were to be stored in the database. And here was a different story. Checking with the developer lead revealed that there was actually an algorithm in place to encrypt the passwords before storing them in the database. But somehow, after the encryption process, the original data was being stored in the database instead of the encrypted data! However once discovered, this defect was considered as a major one and was fixed soon. Had I not tested this in the database, there were chances that this defect would have been shipped along with the web portal and could have easily resulted in a major vulnerability/security hole!

Why Backend/Database Testing becomes so essential?
A backend is the engine of any client/server system. If the backend malfunctions, it may cause system deadlock, data corruption, data loss and bad performance. Many frontends log on to a single SQL server. A bug in a backend may put serious impact on the whole system. Too many bugs in a backend might cost tremendous resources to find and fix bugs and delay the system development.

It is very likely that many tests in a frontend only hit a small portion of a backend. Many bugs in a backend cannot be easily discovered without direct testing. Backend testing has several advantages. The backend remains no longer a "black box" to testers. We have full control of test coverage and depth. Many bugs can be effectively found and fixed in the early development stage.

Sometimes it is not easier to understand and verify a backend as compared to a frontend because a frontend usually has friendly and intuitive user interfaces. A backend has its own objects, such as, tables, stored procedures and triggers. Data integrity and protection is critical. Performance and multi-user support are big issues. Slowness in operation can result in performance bottlenecks and can be vital to the project’s future. To be able to do backend testing, a tester must have strong background in SQL server and SQL language.

Backend test methodology has many things in common with frontend testing and API testing. Many test methods can be used for backend testing. Structural testing and functional testing are more effective approaches in backend testing. They are overlapped in some test approaches. However, the two methods may discover different bugs. It is strongly recommended that testers should do both types of testing. There are many other test methods that can be applied to backend testing. Some are:

Structural Testing:
A backend can be broken down into a finite number of testable pieces based on a backend’s structure. Tests will verify each and every object in a type of structure.

Functional Testing:
A backend can be broken down into a finite number of testable pieces based on application’s functionality. The test focus is on functionality of input and output but not on the implementation and structure. Different projects may have different ways to break down.

Boundary Testing:
Many columns (fields) have boundary conditions. For example, in a column for percentages, the value cannot be less than zero and cannot be greater than 100%. We should find out these types of boundary conditions and test them out.

Stress Testing:
It involves subjecting a database to heavy loads. For instance, many users heavily access the same table that has a large number of records. To simulate this situation, we need to start as many machines as possible and run the tests over and over.

There can be many more dimensions to Backend/Database Testing. Explore it more to find out more ways to test the backend. If you know of any such ways to make Backend/Database testing more interesting, do share with me via your Comments.

Happy Testing…

Share on Google Plus

About Debasis Pradhan

Debasis has over a decade worth of exclusive experience in the field of Software Quality Assurance, Software Development and Testing. He writes here to share some of his interesting experiences with fellow testers.