- Generic Test Checklist:
This document is a wonderful checklist for guiding your adhoc testing efforts.
When you do not have the time for creating a formal test plan, then you should at
least have a generic test checklist for which testers can walk the app under test against.
You can modify the document yourself by capturing and analyzing common bugs and
inserting the appropriate brief test cases into this checklist. If you use only one
document from all the templates and samples here, this would be the one to use.
Template - Standard Test Plan:
This document is an overall summary of a test lead's plan of execution for a given
project. Major sections of this template include: goals and objectives, scope (areas
included or excluded from test), test schedule (milestone list, risks and assumptions),
test deliverables, test methodology (similar to Standard Test Approach doc), criteria for
acceptance into testing, and an overview of testing tools that will be used for the
Template - Standard Test Approach:
This document is an overall summary of a testing group's approach towards testing
an application. It is a great starting place if you are just setting up a testing
group in your development department. It is also a great document to hand to
entry-level or new testers as an orientation as to how your testing group does business.
Template - Final Release Report:
This zip file contains a template used to summarize testing efforts at the end of a
project cycle when the application under test is about to be released. The document
identifies all testing resources involved, the build number and date of final release, a
simple sign-off (yes or no) on release to production, bug status matrix, test case status
matrix, and a risk/issues list. The last section is a list of all test case names
that failed plus those that remain untested. This is a great way to communicate the
exact status of the application at release.
Template - Test Lead Project Setup
This zip file contains a checklist for test leads to manage a new project's setup.
The checklist is a great way to capture all steps necessary to setup new projects
or new releases.
Sample Test Script:
This zip file contains a sample test script. A test script is basically a
script of test cases linked together to walk the critical pathways through an application
under test. These scripts are broken down into a series of user scenarios.
Each scenario contains specific instructions for the tester to carry out, including the
expected results along the way.
Sample Acceptance Criteria:
This zip file contains three sample files that are the acceptance criteria for
three sample software projects. These are rather crude, but when you do not have
sufficient time to write out test cases, this format is a good minimum threshold.
Each spreadsheet is broken down into components, and each component into specific criteria
(i.e.: test cases without the details). Each criteria has a pass or fail column
which is totalled at the bottom of the sheet.
Sample Unit Test Matrix:
This zip file contains a sample document used by a developer to unit test one
module of his application. Organizing unit tests into a matrix gives the developer a
hand off to the tester thereby clearly defining the most important elements to test.
If there is no time for formal specs, then the developer should at a minimum document his
unit testing in a matrix such as this while s/he unit tests and then hand them off to
testing with the new build.
Template - Testing Roles &
This zip file contains a template for explicitly defining the roles and
responsibilities that testers, test leads, and senior test leads are expected to perform.
This zip file contains a sample design specification created by a developer.
The sample file is broken down into several categories. The document was roughed out
prior to development, and then re-worked at various milestones throughout the development
process. At the close of the project, the design spec was finished off as an
"As-Built" copy of the design spec for future revisions. The sections of
the design spec include: Overview, As-Built Parameters, Milestone Schedule, Risks and
Assumptions, Schema Specification, INI-File Specification, Business Rule Specification,
Process Flow Diagram, CommandLine Parameter Specification, Setup Configuration
Specification, and the Interface Specification.
Sample Data Model:
This zip file contains a sample Data Model built in Excel 97. Sure you can go
buy fancy E-R diagramming tools that do a fantastic job. You could find shareware or
even freeware to draw up your database schema. But, you can use Excel to do a fair
job of diagramming your schema as was done in this sample. It is kind of fun to see
Excel used in this way as a communication tool, a la Visio.
This zip file contains a template for conducting a project post-mortem. The purpose of a postmortem is to "learn from past
experience." Another purpose is to carefully analyze a project once it has ended and
identify what went well and what went poorly so you can do better on subsequent projects.
Another purpose of a postmortem is to give closure to a project.
This boilerplate template allows you to just click into input fields and enter the
Template - Feature Breakdown Sheet:
This zip file contains a template to assist with scheduling. The project manager
can hand out several copies of the Feature Breakdown sheet to developers and testers.
They can then breakdown the work they will perform, one feature breakdown sheet per
module (form, applet, or whatever makes sense), with multiple tasks (lines) in the
mini-gannt chart at the bottom. The entire form, including the mini-gannt chart
should be hand-drawn in. The project manager then compiles all of the information
into an overall project schedule. This form is an efficient way to extract more
accurate scheduling information from the project team members. Team members are
forced to think about their work in advance by doing the breakdown; thereby flushing out
Sample Weekly Status Report:
This zip file contains a sample Weekly Status Reports for two projects. The
report is broken down into six high level categories spanning one to two pages. The
first category is a summary of all project milestones based upon the project
schedule. Notice that the table contains three important date reference points for
each milestone: baseline (original) estimated date completion, last week's estimated date
completion, and this week's estimated date of completion. Comparing the three
columns gives you a good idea of how much and where the project is slipping. The
next two sections are summary tables for testing: acceptance criteria status (or test case
status depending on the test approach), and bug summary. The remaining three
sections are text summaries of: project issues, project tasks completed last week, and
project tasks planned for next week. Testing, development, and project management
can all build weekly status reports similar to this sample.
(Note that the document comes unprotected so that you can change the layout and
contents. However, once you get the template laid out according to your needs, go
ahead and protect it with no password so that you can use it like a template; e.g.:
single-click checkboxes to toggle them, etc.)
Sample MS Project Schedules:
This zip file contains sample MS-Project 95 schedules. Note
the use of milestones to close-out every frag-net (manage by the milestones). Note
that the current data date line is red-dashed so that it stands out during the tracking
phase of a project life. Notice that even though percent complete exists, it is not
really used other than to indicate not done, or done. Project granularity should be broken
down to the point that either a task is completed, or it is not yet started. If your task
is greater than 5-10 days it is too large and needs to be broken down for better control
Sample CRUD Diagram:
This zip file contains a sample CRUD diagram. A CRUD diagram is a syntactic
(as opposed to schematic) process flow diagram. The matrix consists of five columns.
The first column is a unique numbering identifying a process (row) in the matrix.
The next column identifies what type of process this row is, for example: To Be Determined
(TBD), Stored Procedure (SP), Form (F), Subroutine (S), or Event (E). The final
three columns identify the process name, the process user/owner, and the process
description. A CRUD diagram is useful in summarizing what the application is
supposed to do. Opinion: these are seem to be most useful if you have the need to
document an app after the fact.