Templates and Samples

Home  About

Template - 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 project. 

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 Checklist:
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 & Responsibilities:
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.

Sample Design Specification:
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.

Template - Post Mortem:
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 appropriate text.

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 more detail.

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 and tracking.

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.