Continuing with the "Replace Outlook Notes with OneNote" addin:
The first task a tester has to face when testing a few feature is deciding if the specification makes sense, is complete, solves the problem faced by the end user and is testable.
Here's the mini-spec I created for the Outlook addin to "replace" the Outlook sticky notes module with OneNote.
Scenario: A user (let's call her Tina) has Outlook installed and has been using the sticky notes module for awhile. She is aware of the limitations of that module and has decided to try OneNote. Tina loves OneNote and has decided to migrate her notes from Outlook to OneNote. She also wants to use OneNote instead of Outlook's note modules in the future. We will add a lightweight feature to Outlook to open OneNote instead of an Outlook note module.
So the first task I have on my plate if given this new feature to test is to decide if it fits Tina's needs. I want to focus on step 2 and look at it from a test point of view
This design step seems relatively easy to describe and to test at first glance. After thinking about this for a few minutes, I came up with this list of questions and comments about the design:
Examples of why ON couldn't boot Low memory It got uninstalled (and should the addin detect this and disable itself?) Locked out by an administrative setting
It looks like this step wasn't so well defined after all. I have a list of questions about the design of the feature, some questions about whether I need to request some features that make this more testable (logging), a laundry list of research to do and I'll have to follow up with the designer to get some of these questions answered.