How to Become a Software Tester (QA Engineer)

Lecture 9. Test Execution: New Feature Testing -> Quick Intro -> Test Estimates -> Entry/Exit Criteria -> Test Plan -> Aggressive Testing From Jason Fisher

The test plan is the master document about the activities regarding the testing of a certain feature (or another possible subject of testing, e.g., how the system handles a load).

Let’s forget about software for a minute.

Below are two situations:

1. You have to drive to the nearest supermarket to buy some milk.

2. You have a wedding coming soon.

Does it make sense to sit and write down a plan…

– …in the first case? No, it’s absurd. Just go out and get the milk.

– …in the second case? Absolutely, because a wedding involves a large number of activities and people, and it has a significant meaning. (Of course, I’m talking about a traditional wedding, not a “let’s get married NOW” thing in Las Vegas.)

The two situations above are different from a planning perspective because they provide different answers to the following questions:

– How quickly must the project be completed?

– How many people and activities are involved in the project?

– What is the significance of the project?

Let’s get back to our start-up business. Consider the following:

– New features in start-ups are usually developed (and tested) very quickly (taking just days or weeks).

– There is usually one PM, one developer, and one tester per each feature.

– Any feature can be changed, removed, or deprecated overnight.

So, as a rule, in the start-up environment there is no need to create a test plan.

To be fair, there are situations when a separate test plan is needed; e.g., for long-term projects, or for projects that include integration with a vendor’s software.

Test plans come in many shapes and forms, but the majority of them have their roots in the test plan document introduced by ANSI/IEEE Standard 829-1983. For my projects I use a simplified version of this. You can find it in Downloads on QATutor.com. Let’s look at the main sections.

General info

Introduction

Schedule

Feature documentation

Test documentation

Things to be tested

Things not to be tested

Entry/Exit criteria

Suspension/Resumption criteria

Other things

GENERAL INFO

INTRODUCTION

This is a short intro to the feature that is going to be tested*.

*For simplicity, I assume that we are testing a certain feature, but you should remember that we can also test other things – site performance, for example.

SCHEDULE

Here you specify detailed info about things that should happen, when they should happen, and who is responsible.

Example:

FEATURE DOCUMENTATION

Here you list and provide links to all relevant documents that specify how a feature should work. Usually those documents are specs.

Example:

TEST DOCUMENTATION

Here you list provide links to the test documentation needed to test this feature. Usually these documents are test suites.

Example:

THINGS TO BE TESTED

Here you describe what you are going to test and how.

Example:

THINGS NOT TO BE TESTED

Here you specify which things are not going to be tested.

Example:

ENTRY/EXIT CRITERIA

Here we specify the entry/exit criteria for the NFT of the feature.

Example:

SUSPENSION/RESUMPTION CRITERIA

Suspension criteria are certain conditions upon which testing must be suspended.

Resumption criteria are certain conditions upon which testing must be resumed after suspension.

Example:

OTHER THINGS

Here you specify whatever else you want included in your test plan (e.g., training, hardware/software requirements, contact info, sign-off procedure, etc.) Next ->

Lecture 9. Test Execution: New Feature Testing -> Quick Intro -> Test Estimates -> Entry/Exit Criteria -> Test Plan -> Aggressive Testing From Jason Fisher