Usually, to test applications we have to know how to use different tools, in order to make a more thorough technical assessment of the product. Since different projects require different tools, which tools should a quality analyst definitely know? The answer isn’t straightforward.
JMeter, Postman, Selenium, Appium were the names that came up when we asked the members of our brigade, depending on the characteristics of the project they were working on. Nevertheless, something we all agreed upon was that knowledge about database engines was necessary.
Why Should QAs Know About Databases?
Chatting with one of our DevOps talents, Rogelio Di Pasquale, we agreed that in quality analysis, it’s important to understand how the application works and give feedback on the actions that are planned to happen.
When testing, I want to know “if I execute this, I get this result”. But the range of potential outcomes is big, and we cannot know whether an error is related to a planned change.
If a QA can say, “When I generate this, these data are loaded into the database and consumed by that service,” then they will be able to detect where the process fails.
Knowing about databases is also useful to trigger expected actions in a flow. There are data stages with specific functionalities, and we can either wait for these stages to occur or act on them.
More often than not, especially in extreme cases, as QAs we have to manipulate data in order to run certain tests. Knowing how a data model works, performing quality analysis and generating values on our own helps to accelerate the process, which results in better testing efficiency and independence to manage a database engine. In addition, we can mitigate the dependency that results from the imperative to hardcode something; review an update in any field of a table; or replace data at the base, given that it wouldn’t be possible from the frontend, as end user.
However, it’s worth mentioning that manipulating data for testing isn’t entirely “advisable” for every type of testing (for example, in regression or smoke testing) because of false positives. On the contrary, it’s recommended for border testing, where generating this type of data in a “real” context is more complex and implies forcing the data in some way.
Relational vs. Non-Relational Databases
Regardless of each one’s preference, the brigade agrees that in quality analysis, knowing more about either one or the other kind of database doesn’t make much of a difference. The important thing is to understand how databases are organized based on the product in development and how to consult them in order to comprehend how data travel.
In other words, it’s important to know where logs are stored, considering that they can be saved in different formats: numeric, boolean or text —the most popular option.
From our experience, knowledge about relational databases is more required for QA profiles who are starting in a project. However, as we said, if you already know about models and database engines, the rest is easier to learn.
If you’re not sure where to start, we recommend Mysql, an open source database management system. It’s multi-platform and many clients can connect, so you can work with the one of your choice. It’s also robust enough to be in production and light enough to install in your computer.
In conclusion, knowing about databases helps QAs to be independent and acquire technical expertise, which is a plus for the entire team as well. When a QA says: “This data isn’t persisting on the database,” it means that they understand the stages of the functionalities, thanks to which they can implement better quality processes.