Planning Your Manual Tests

The first step in designing an effective test process is the planning stage. In this step, you must identify and isolate all of the important features of your application. You can then compose a detailed plan to cover individual use cases and scenarios.

Let's say you are writing a manual test plan to test Internet Explorer. First, you would need to identify important features (such as Add Favorites). Then, you should identify a set of specifications for each feature. For example, what should be happening when the user clicks Favorites Add to Favorites?

Note

A rule of thumb is to use context awareness while you are building Test Cases. You must apply the "Big 5 W" questions: who, what, where, when, and why (plus how).

Keep in mind that your test plan does not need to be limited. You can outline features that are not being tested, and look at issues such as security and globalization. You can also apply edge cases to your application. That is one of the core advantages of manual testing — there are no constraints per se. The final step is creating a checklist, which enables you or another developer/tester to reproduce the errors.

Using Team System, you can classify bugs and defects using a variety of scales that reflect real-world test outcomes. In fact, prioritization is key if you want to lower your development costs and focus on bugs that affect the most important features in your software. Here is a prioritization scale listed in order of severity. Please note that this list is not the "be all, end all" solution — you can flexibly add and remove prioritization levels according to your needs. As you can see, the time frames reflect a formal methodology-style approach. If you prefer a more Agile approach, you can adapt this scale by modifying the requirements and escalation:

• Critical: This is literally a showstopper. Bugs that are classified "critical" should be handled right away. Usually, critical bugs affect important and commonly used features in your software. You must repair the bug before reintroducing your code into the daily build process.

• Severe: This is an important bug that affects the secondary features in your software. This bug or defect should be corrected before the next weekly build.

• Medium: This bug needs to be fixed before the next milestone. It affects a tertiary feature in your software. The problem must be repaired by month's end.

• Minor: This error should be fixed before the next release of the product. The error affects a noncritical portion of your application.

• Cosmetic: This is a minor bug affecting a visual element or nonfunctional element of the application. These cosmetic bugs are the lowest priority and should be corrected before the next release of your product.