While at a movie theater over the weekend, I noticed a couple of new self-service ticket machines. They look and function similar to ATMs: select your movie, slide your credit card, and print your tickets. Simple enough.

Inspired by James Bach, while I was waiting for a friend to show up I took a couple of minutes and tried to see what bugs I could find in the system. I'm sad to say I did not find much. I found only three problems that I would qualify as defects, and two issues that I would want to get clarification on before I wrote them up as defects.

Defect 1: The system would allow you to select up to ten tickets for each type of ticket you could purchase (adult, child, senior). While testing the limits of ticket selection and the proper calculation of the total amount, I noticed that if you max out the number of tickets for senior and child priced tickets, the system beeps at you each time you try to select more then ten tickets. However, when trying to select more then ten tickets priced for adults, there is no beep. This is a small issue, hardly worth the time it took to find it, but it should still probably be fixed.

Defects 2 and 3: I like these a lot. After I was done playing around with the system I had a chance to do some usability testing by watching people interact with the system. I noticed one case in particular that showed serious defects. A lady using the system selected her movie, entered her debit card information, and started waiting as the screen displayed "Please wait while processing your transaction." At this point the system was attempting to connect to whatever service it uses to process credit cards. As luck would have it, at that moment credit card processing for the theater went down. I know this due to the very vocal population of customers at the ticket counter. Unfortunately for the lady making her self-service purchase, the ticket machine seemed to have hung as well. It just sat there saying "Please wait while processing your transaction." No message saying "Timed out while connecting to service. Please try again." No message saying, "Trying your transaction again, please wait." Nothing. It just sat there.

After about five minutes, the lady finally lost her patience and started pushing the cancel button. She pushed it once. She pushed it a second time - harder. She then pushed it five times in rapid succession. She then put all of her weight into the pushing of the button and kept the button down for several seconds. This processed continued for some time. I counted her push the button over 40 times. Still the screen read, "Please wait while processing your transaction." So much for cancel... She then left the machine and went to the ticket counter for help.

The first defect is around error messaging in general. No indication was given to the user that a problem was encountered. Other observations gave me the impression that performance was acceptable to users under normal operating conditions. And after the ticket counter informed everyone that credit card readers were working again, I did not notice anyone else have performance problems with the ticket machine. My conclusion is that the machine encountered an error, but did not let the user know.

The second defect is that no indication was given to the user that her request to cancel had been received. Had the system simply said "Canceling request. Please wait while disconnecting from bank service." I think the user would have been satisfied that the system was still working, and would have waited for her transaction to cancel. Because she was not informed that the request had been received, she continued to pound on the keyboard. Note that her ticket purchase was canceled when the credit card service was restored. This was confirmed at the ticket counter.

Issue 1: The system was set up to limit ticket purchases to only movie times that were in the future. That is, if I wanted to watch a movie that started ten minutes ago (because I don't want to watch the thirty minutes of previews) I could not use the ticket machine. I would have to go to the counter. However, if I started my transaction before the movie time, and the movie start time elapsed while I was processing the transaction, I was allowed to continue.

Like I said, I don't think this is a bug, I would just want to check to ensure that this is in fact the behavior that was intended. I think I would want to know more about the conditions for the removal of a movie time from the list, and then go back and do more testing.

Issue 2: The system allowed me to purchase a child ticket for an R rated movie. You need to be either 18 or accompanied by an adult to see an R rated movie and I had not purchased an adult ticket. Again, I can think of scenarios where this would not be a problem: adult buys ticket in advance, when adult and child come to theater adult then buys child's ticket, etc..., but I would probably ask questions on this as well.

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.