Professional software testers need database viewing tools that offer a large variety of exceptionally intuitive...
options. The database tool used must not require a significant learning curve before you can view and update data. Next, it needs to have a variety of user levels, from beginner to advanced, and still be straightforward, quick and efficient to use. Often, developers recommend database tools, so, to be used, the tool has to work for multiple user types and skill sets. Not an easy task.
What else the database tool needs is based on personal preference. I don't care for an intensely UI-based cover. I prefer to deal with SQL and the results of queries without an unnecessary middleman (the UI) in-between. I don't care for UI interference -- or the need to configure every view to use the tool effectively. Typically, as a QA tester with medium SQL skills, I need to view and update data, and perhaps verify the properties or a view -- that's it. I don't want to spend additional time learning the tool because I need to learn it on the job, or on the go. At the same time, I need accurate results and meaningful error messages so I can figure out, or get a hint of, why a query isn't working as I expect it to. As a QA tester I need to be able to determine in a short time if it's my query or an actual data problem. In this tip, I'll discuss features that are useful for software testers who are not SQL experts, including the query editor, error messaging, debugging and the ability to control test database damage.
Intuitive query editor window. Most database tools do a great deal more than needed for software testing. Business intelligence and data analytics may be useful in the long run, but the focus for testing needs is much simpler. For instance, first and foremost, testers need an easy way to query tables to view data. The query editor window functions as an entry point to SQL, or you can choose to open a saved file. A useful feature is the ability to automatically launch a saved query directly into the editor window so there's no need to copy and paste SQL queries saved in other applications.
The addition of a tree view to access databases, views and other items is useful so testers know exactly what they are looking at. Additionally, if a specific table's existence is needed, the tree view provides an easy and effective way to drill down into details. For example, if a tester needs to check the properties of a view or check security settings, the simple tree view provides easy access.
Another useful feature is the ability to highlight a single line in a saved query containing multiple lines, execute only the single line, and either view the results immediately or send them to a file. The results viewer is easy to read and scrolls without problems.
Effective error messaging. As most testers experience it, error messaging is not considered a high priority for the majority of applications. However, effective and useful errors are a necessary and critical feature for a database testing tool. If a tester is unable to decipher useful hints or accurate clues from the error message, he most likely will abandon the tool and use another one. Often it comes down to a choice of finding another database tool that's easier to use or searching the Internet for help. Users of any tool should never have to search the Internet for help using a tool.
Why not use the tool's help menu? In my experience, if I don't understand the error messages, it's highly unlikely the help text will be useful. Error messages for any SQL query, from a simple select to a more complex query, should generate useful error messages. The following example helps locate the error but gives the user no indication of what's wrong with the syntax:
Msg 101, Level 5, State 1, Line 8
Incorrect syntax near 'sel'
It's somewhat useful because there's at least a hint of what's wrong -- the syntax is incorrect. However, it would be more helpful if a user had more details, such as an example. Perhaps something like this:
Msg 101, Level 5, State 1, Line 8
Incorrect syntax near 'sel'; Command lines contact key words like Select followed by an operator and table name or value. Select * from <tablename>.
In this example I'm noting the location of the error and the type of error and providing an example of a valid statement. Examples go a long way toward creating lifetime, dedicated tool users.
Automatic debugging feature. The inclusion of an automatic debugger is helpful when error messaging isn't as useful as it could be. Typically, an automatic debugger executes at the click of a button and generates a list of error messages on the SQL query in a separate window. The debugger or query editor window may be decorated with colorful visual indicators pointing the user to the location of the errors. For the larger, more complex SQL queries used for testing, the ability to close off and debug between checkpoints is useful. Often, this feature may be mimicked by using a line-by-line manual debugger and choosing to skip or step into functions.
Ability to set access authorization. Setting object security to prevent accidental or incidental data deletion is crucial even when you're strictly using a test environment database. Why protect test data? Because testers don't have time to recreate test data every time an adventurous tester accidentally deletes data rows. Delete is definitely a function testers need the ability to control.
Along the same lines, a valuable database testing tool feature is the ability to secure updates. For example, a tester accidentally overwrites the main configuration table for the test environment, instantly resetting all values to 1 even if that value is invalid. The test environment is rendered unuseable, and it takes anywhere from several hours to days or weeks to repair. Avoiding unnecessary downtime keeps testers sane and release schedules on track.
Learn about database testing from the cloud
Understand database security terms