I noticed something in Windows 7 Explorer. Well, I noticed something missing. In the upper left corner of a Windows application, there’s a little icon not unlike the fav icon you get on the browser bar in a Web browser. You might not know this, child, but you can click that icon to get a short menu of window manipulation or you can double-click it to close the window. This has been pretty standard since OS/2 (go ask your grandpa what that means).
But in Windows 7 Explorer, there’s no icon. But the menu remains when you click that portion of the title bar:

Which got me to thinking.
If you’re working on a mature application, say something that’s been built two years ago, has customers, and plans new releases without a complete rewrite in the latest technology/platform fad, what do you do when your company sunsets a feature?
You know, they determine that the customers don’t use it and they don’t want to maintain it any more, so they turn off the Fax feature. What do you do, QA?
You tear the relevant test cases out of the binder (ask your grandpa) and schedule 2-5pm Friday for margaritas!
Well, that might be what you could do. But what you should do is analyze where that feature is exposed. Not just the Fax to dialog box, not just the Fax to menu item. Features woven into a robust application get exposed to the customer in a number of ways.
- Steps in a wizard where the Fax to is an option.
- Hotkeys.
- Spots in the online help that launch the page/dialog box.
- The documentation and marketing materials.
- Buttons in other features that shortcut to the deprecated feature.
Only you know, or should know, where the features are exposed across your application. The developers look at their trees and don’t see the forest.
The simple act of excising features and dialog boxes, windows, or pages from the application requires not only the removal of test cases and test scenarios, but also the creation of separate tests to make sure it was removed completely and cleanly.