You Are Not Done Yet: Special Modes And States

You are not done testing yet unless...you have tested your application in the following special modes and states. Ideally you would run each of your tests in each of these special cases, but I haven't yet met anyone who has that much time. More typical is to pick one case each day as the context in which to run your tests that day.

• Different zoom levels, as appropriate. One application I know of had a huge number of automated tests, and everything seemed hunky dory. Then someone thought to try changing the zoom level and found all sorts of issues. Oops.
• Safe Mode. Microsoft Windows has a special mode where just the essentials are loaded - the most basic display driver, a bare-bones network stack, and no start-on-boot services or applications. How does your app handle being run under these conditions?
• Sharing documents between multiple users and/or multiple machines, simultaneously and sequentially. This is especially important for programs that access a database (what happens when someone else makes a change to the record you are editing?), but if you can open documents off a network share, or you can open documents from a shared location on the local machine, someone else can do so as well - potentially the very same document you are editing.
• No file open, dirty file open, dirty-but-auto-saved file open, saved file open.
• Full screen and other view modes.
• Different application window sizes (document window sizes too, if your app has a multi-document interface); especially: default launch size, minimized, maximized, not-maximized-but-sized-to-fill-the-screen, and sized very small.
• Invoke standby, hibernation, and other power-saving modes whilst an operation is in progress. I discovered the hard way that when one application has a modal dialog up it blocks my OS from sleeping. I was *not* a happy camper!
• Resume your computer out of various sleep modes. Do in-progress operations continue where they stopped? Or do they restart? Or do they hang?
• Modified system settings. Set your mouse to move faster or slower. Change your keystroke repeat duration. Mess with your system colors. Does your application pick up the new values when it starts? Does it pick up values that change while it's running?
• Object Linking and Embedding (OLE). If your app supports OLE, you're in for a world of painfun! Does embedding other OLE objects in your app's documents work correctly? What about embedding your app's documents in other OLE-enabled applications? Do embedded applications activate and deactivate correctly? Do linked OLE documents update when the source of the link is modified? How does your app handle the linked document's application not being available?
• Multiple selection. What happens if you apply text formatting when you have three different text ranges selected? Or you paste when several different items are selected? What should happen?

The last two special states are not contexts in which to execute your test cases but rather additional tests to run at the end of each of your test cases:

• Send To. Many applications today have a handy menu item that lets you send the current document to someone as an email. I've seen nasty bugs where attempting to use this handy menu item crashes the application or worse.
• Cut, copy, and delete. To and from the same document, a different document, competing applications, targets that support a less-rich or more-rich version of the data (e.g., copying from a word processor and pasting into a text editor), targets that don't support any version of the data (what happens if you copy from your file explorer and paste into your application?)...you get my drift.

Posted by The Braidy Tester at 07:30 AM  Permalink