[textile]
Last weekend we held the first
Indianapolis Workshops on Software Testing. The attendees were:
- Mike Kelly
- Jason Horn
- Steve Lannon
- Denise Autry
- Linda Ellison
- Mike Goempel
- Rick Wellinghoff
Note that all attendees were from the Indianapolis area.
The topic we focused on for the five hour workshop was database testing. The following is a summary of presentations and ideas shared.
First Mike Goempel shared a
checklist and charter he uses when he performs exploratory testing on databases (and database related items). His story covered his experience on past projects using both formal and informal testing methods and it focused mostly on techniques he uses to gather information on the database and where he might be able to find errors. Specifically Mike shared some great ideas for and experiences around interviewing DBAs, architects, and developers for possible trouble points.
Jason Horn then presented a homegrown tool he developed to help both developers and testers work with and test the database. His tool "SQL Test Harness," should be moving to an open source community soon (Jason still has some changes he wants to make first). The main function of the tool is to provide information on the database. There are functions for searching the structure of the database for all instances of a specified object, getting the definition for objects and getting meta information on objects. And finally the tool allows you to execute some database commands using its interface (which is great if you are not comfortable with SQL).
There are some limitations Jason hopes to work out when he has more time (or with contributors), but I found it immediately useful. The tools also has some neat learning features that Jason hopes to talk about within the soon-to-be-added online help, but for now, it simply shows you the SQL it generates and executes, so you can modify and execute it yourself if desired.
After that, as a group we did a walkthrough of using an enterprise automation tool for database testing. Using IBM Rational Robot and a sample Access database, we created a couple of scripts that queried the database at runtime and compared the values in the database with the values show in the sample application's GUI. We did not spend a lot of time looking at script implementations, but there was a general interest in doing something in a scripting language.
Overall, I thought the workshop went well. There was a general agreement that the content was challenging, very context specific, and that the format worked well (the format is loosely based on the LAWST style of workshops). However some time was spent at the end of the workshop for a discussion as to why attendance was not as high as the workshop organizers had hoped.
It was the impression of the group that database testing is a challenging and intimidating type of testing. Most testers (in the Indianapolis market) are not very comfortable with their technical skills, and the level of technical competency involved in meaningful database testing is typically enough to discourage most people. This sparked a list of testing skills we thought someone interested in database testing might want to practice in order to gain more confidence:
- Boundary testing (see Goempel's checklist for more detail)
- Smoke testing
- Database unit testing
- Confirming database structure
- A simple test to ensure database connectivity
- Testing the persistence of data
- Database corruption and security testing (they tend to go hand in hand)
- Database performance testing
Next month's topic is on performance testing. Hopefully we will have a better turnout and learn just as much.
[/textile]
