Posted on

NEW: 39-page Quality Assurance Plan Template in MS Word/Excel

Looking for a Quality Assurance Plan template? We’ve spent most of the week polishing this fella and now he’s ready for prime time. See what you think.

Quality Assurance Plan Template

This template pack includes a 39-page Quality Assurance Plan Template in MS Word, an Audit checklist and Schedule Forms, and 7 Excel spreadsheets. You can use this template to write your first QA plan. It includes helpful explanatory text that walks you through the process of setting up your first QA project. You can change everything in the document – text, images, and tables. There are no special plug-ins, macros, or installation files. Just download the templates and get started.


Business Case Template - Download Here

Quality Assurance Plan Definition

The Quality Assurance Plan describes the approach to ensuring that software is delivered according to a set of agreed quality guidelines. It ensures that the:

  1. Project is managed, developed, and deployed correctly.
  2. Deliverables are of acceptable quality before delivered to clients.


In the Quality Milestones chapter, we’ve added a nice Note to the text to display some instructional text.


Here in the Documentation section, you can see how the chapter numbering, fonts, text, and tables are presented.

Why do you need a Quality Assurance Plan?

The Quality Assurance Plan ensures the project provides quality within the allocated resources, schedule, and budget.

How to use the Quality Assurance Plan

  • Address specific project processes and deliverables.
  • Establish criteria that defines the quality at each checkpoint or deliverable.
  • Identify roles and responsibilities for the quality assurance reviewers.
  • Define who, where and when quality reviews are performed.
  • Apply the Styles, such as those shown in the following screenshots, to ensure a consistent look and feel through-out the document.


Examples of Styles for the Body, Bullet lists, Notes, Table text and headers

Quality Assurance Plan Purpose

Use this Software Quality Assurance Plan to document the process, methods, standards, and procedures for your next software testing project. Use this document as a foundation for managing software quality assurance activities and project activities as documented in the Project Plan.

This Quality Assurance Plan will help you:

  • Identify the SQA responsibilities of the project team and the SQA consultants
  • Define reviews and audits and how they will be conducted
  • List the activities, processes, and work products to be reviewed
  • Identify SQA work products


Examples of different notes, message, and warning styles you might want to add to your Quality Plan

Who is this template for?

This template was written for QA Managers, especially those who may be new to this area and are looking for a little direction on how to get started. The forms, checklists, and spreadsheets will also help you get up to speed fast.


Learn more about the template pack here.

Posted on

Proof-reading Checklist for Technical Documents

Is there anything worse than sending out an important document and then, just when it’s gone, finding a typo?

Always leave some time to check your documents before you send them out. Here’s a checklist to get you started.

crone-park (65)

Proof-reading Checklist

  1. Select the entire document – CTRL+A – then click the Language option at the bottomrof the screen. It might say English (United States).
  2. Mark the selected text as the language it should be set to. Click Set as Default.
  3. Press F7 to start the spellchecker.
  4. In the spelling results, click ignore all to ignore the same issue throughout the document. Click Add if you want to intentionally add this word to the dictionary. Be careful if your dictionary is networked as this will be added to their shared dictionary.
  5. Watch for phrasing consistency, e.g. Note and NOTE, iOS and IOS.
  6. Careful making global changes, for example, don’t change IOS to iOS across the document as, fro example, in the code samples, we use IOS all uppercase, not mixed case.
  7. You select and clear check boxes, not untick or deselect. Note it’s check box, not checkbox.
  8. Rephrase text such as you are checking to check, or when you are installing the printer, write install the printer.
  9. When writing file formats, use lowercase. So, it’s an .ipa file not IPA file. An .ipa file is an App Store Package.
  10. Remove abbreviations. Change P4 to Perforce.
  11. Remove rogue double spaces.
  12. Number tasks if they must be performed in a specific order. So, instead of writing, Build the solution in the following order and use bullet points, number each step in relation to the sequence it should be performed. Likewise, avoid using a, b, and c. One tip: select the letter so it turns grey. Then type the number. This instantly changes the letter to a number.
  13. Remove & characters that have crept into the document, for example, find&replace. Instead write Find and Replace. The exception are terms where is should be used, such as R&D, or where it is at least acceptable.
  14. File, Info tab, then update the Properties. Click Show All Properties to see all fields which need to be updated. Remove any legacy text if you’ve copied your working document on another document.
  15. Full stops. If you finish bullet points with a full stop aka period, then check that are all applied.
  16. Ignore text during spell checks.
  17. When everything is finished, Right-click on the Table of Contents, then select Update Entire table. This updates the entries in the TOC and also the page numbers.

If you want to intentionally exclude a block of text, or a specific style, from the spell check:

  1. Select the text that you want the spelling and grammar checker to ignore.
  2. On the Review tab, in the Language group, click Language, and then click Set Proofing Language.
  3. Select the Do not check spelling or grammar check box.

What else would you add?

Posted on

User Guide Checklist

This checklist summarizes the recommended structure and contents for User Guide documents.



In this section, introduce the User Guide and cover the following areas:

– Intended readers – identify the different user types, for example, system operators, home users, and experts. For each, identify the assumed level of experience and highlight the sections of user guide which apply to them.

– Software version – identify the software release the User Guide refers to.

– Purpose – describe the purpose of both the system and User Guide.

– How to use User Guide document – describe the intended use, section contents and relationship between sections.

– Related documents – identify any related documents.

– Conventions – describe symbols, conventions and syntax conventions used in the guide.

– Problem reporting instructions – provide an email address so readers can contact you if they find an error or omission.


Outline how the system works at a high level.

– Identify the key functions

– Inputs and Outputs – identify inputs what you, the reader, need to enter, and outputs, what you expect in response, for example, reports.

– Provide further detailed explanation, if necessary.

– Assumptions on user expertise, for example, experience or proficiency in related areas or previous training.


This is usually the heart of the user guide. For each task, document the following:

– Explain how to get started, for example, specific settings they need to make to use the application, such as installing a plugin or checking that a specific version of Java has been installed.

– Describe the different functions of the system.

– Provide cautions, warnings, and recommendations.

– For each procedures, identify where in the application you perform this task, input operations and expected results. If necessary, include a screenshot that helps the reader understand the task. Avoid pointless eye candy screenshots.

– Required parameters, optional parameters, default options and order/syntax

– Provide examples

– Identify known issue, likely errors, possible causes, and resolutions.


Identify and describe all system capabilities, for example,

– Describe the purpose of different buttons on the menu bars, what happens if they get greyed-out, how to change this, why this occurred, and how to reset window layout.

– Describe the purpose of each field, identify mandatory settings, minimum or maximum settings, recommendations, and data input types.

Error Messages and Recovery Procedures

– Document all error messages.

– Identify root cause.

– Suggest recovery procedures


Provide list of ambiguous terms or terms users may not know to the reader.


This is recommended for any User Guides of 40 pages or more.

Document Control

Ensure there is Document Control, Sign-off and Change Record information.

Document Structure

Ensure that the guide has the following:

– Headers, footers, navigation bars

– Table of contents

– Index

– Glossary with product terminology and industry terms

– Cross-references/links to related procedures/documents

– Is each topic self-contained? In other words, can you perform the task from start to finish without having to go to another page?

– Is there adequate white space?

– Have you avoided large blocks of text?

– Does the document separate conceptual, procedures, and reference materials?

Visual Information

In addition to text information, provide visual cues to help the reader use the manual, understand concepts, and help them digest information faster.

You can achieve this by using some of the following:

– Headings

– Bullets

– Bold

– Arrows

– Illustrations

Different Learning Styles

Where possible, develop content that supports the following methods of learning:

– Visual

– Audio

– Touch

In addition, provide the following types of examples:

– Concrete examples

– Abstract concepts

Document Format

Produce the user guide in a file format the suits the reader. For example, do they want the document in PDF or as Online Help or both?

Other factors to consider include:

– Size – remember to optimize the PDF before publishing.

– Online/print – prepare the document in both formats if necessary.

– Software/hardware environment – will the reader need any special software to view the documents?

– Binding – if delivering a hardcopy, make sure the binding is reliable, so pages don;t fall out after a little use.

– Coating – if the document will be used outdoors, make sure it is weather-proof.