Free Root Cause Analysis Template

Well there's your problem!

When something gets released to Production which adversely affects a customer, we sometimes write up a formal Root Cause Analysis to send to the customer. It basically explains what happened, and how we intend to prevent it from happening again.

Here's a free template for what we send.



{Company Logo goes here}

Root Cause Analysis (INTERNAL)

Incident Date: {the date the incident occurred}
Root Cause Analysis Author: {the author of this RCA}
Client: {the client to whom this RCA is sent}
Product: {the product impacted by this incident}


Synopsis of events:
Include a summary paragraph describing what happened. copyrightjoestrazzere

Timeline:  
Describe the timeline of events – what happened, when. Note the time of the first action leading up to the incident, the time when it first impacted clients, the time when it was resolved, and the time of any other significant events.

Root cause:
Describe the root cause which led to the incident.

Resolution:
Describe the actions which resolved the incident.

Corrective Actions to Prevent Re-occurrence: 
Describe what is being done (or what will be done) to prevent similar incidents from occurring in the future.

And here's a doc file you can use:
https://docs.google.com/file/d/0B1X3i44SoVGlR2xxWUtjUlY1aHc/edit


Image courtesy of Just2shutter / FreeDigitalPhotos.net

---

This article originally appeared in my blog: All Things Quality

	My name is Joe Strazzere and I'm currently a Director of Quality Assurance. I like to lead, to test, and occasionally to write about leading and testing. Find me at http://AllThingsQuality.com/.

Free Release Tracking Template

Release Tracking Template

In my shop, we each have official "Goals" which help form the basis of our annual bonuses.

All of the folks on my QA Team, have one Goal related to successful releases. Here, "successful" basically equates to "Released to Production with no issues requiring an emergency fix". copyrightjoestrazzere

In order to track these release events, I just use a simple spreadsheet. Nothing fancy here, but it allows me to quickly review a year's worth of releases when completing the annual Performance Appraisal forms.

You can access the free template I use here:

https://docs.google.com/spreadsheet/ccc?key=0AlX3i44SoVGldERicE5IT1Rxb2NucnY4YkU4aTU2QWc#gid=0

---

This article originally appeared in my blog: All Things Quality

	My name is Joe Strazzere and I'm currently a Director of Quality Assurance. I like to lead, to test, and occasionally to write about leading and testing. Find me at http://AllThingsQuality.com/.

My Free Status Report Template

My Status Report

When reporting status to my boss, we have worked out a format that works well for both of us. It conveys an entire year's worth of information, yet lets us focus on just the past few weeks as we discuss it in our weekly one-on-one meeting. I can also print just the currently-relevant portion easily, and bring it with me.

This excel-based report shows all the projects currently in process, along with projects that have recently been completed. The Status column is green if the project is doing well, yellow if it is in danger, and red if it has already gone beyond the expected completion date. This column also shows the initials of the currently assigned tester(s). copyrightjoestrazzere

The Dates column typically shows the expected release date for the project. Sometimes the next milestone date is used instead.

The Comments column is where I put important information about the then-current state of the project. If something significant has changed in the past week, it is bolded.

Each week, I hide the oldest visible Status-Date-Comments columns (note how columns B,C,D are hidden) and insert a new group to the right. Then I update the status of each project row.

If a project has been released to Production, I move it into the "Completed Projects" group. After two weeks, that row will be hidden (note how row 15 is hidden).

The bottom portion of the report lists vacations and important scheduling issues, such as new hires arriving, contractors leaving, etc.

I update this report throughout the week as events occur. I finish it up on Friday, then email it to my boss before I leave for the weekend.  We use it during our Monday discussion.

I also use this report to help me prepare quarter-end and year-end reviews.

Check it out at:
https://docs.google.com/leaf?id=0B1X3i44SoVGlODdkODdlNTAtNTQyMy00N2NkLTk2ZTUtMjBkOGRmZjY3OTg1&hl=en_US

---

This article originally appeared in my blog: All Things Quality

	My name is Joe Strazzere and I'm currently a Director of Quality Assurance. I like to lead, to test, and occasionally to write about leading and testing. Find me at http://strazzere.blogspot.com/.

An Old Test Plan Template

Last night, I was digging through some old documents, when I stumbled across a diskette containing this Test Plan Template.  It was given out as part of a presentation I did during a Users Conference back in 1994.

These days, I generally use a less-formal Test Plan format, although I still occasionally use something like this when warranted.

An oldie but goodie?

---

Test Plan Template

Test Suite Name

Application:                                                 Name of the Application

Version:                                                        Version of the Application

Developers:                                                 Developer Name

Test Plan Author:                                       Plan Author Name

Date of the Original Test Plan:                Month dd, 19xx

Current Revision Date:                             Month dd, 19xx

Document File Name:                               TESTPLAN.DOC

---

Related Documentation for this Test Suite:

Requirements Specifications:                           Title                 

            Author:                                                 Author name

            Revision Date:                                      Revision date

            Relevant Pages:                                    Relevant pages

Design Specifications:                                    

            Author:

            Revision Date:

            Relevant Pages:

Development Plan:

            Author:

            Revision Date:

            Relevant Pages:

User Documentation:

            Author:

            Revision Date:

            Relevant Pages:

Standards Manual:

            Author:

            Revision Date:

            Relevant Pages:

Other:

            Source:

            Revision Date:

            Relevant Pages:

---

Application Overview

Overview of Component Functionality

An overview of the relevant application components and their functionality is described here.  This helps to guide the thought process and place this test suite in the correct application context.     copyrightjoestrazzere

Other Applications/Components Impacted

Any other applications and/or components that may be directly or indirectly affected are discussed here.  The Test Suites which will be used to perform testing on those components may also be referenced.

Standards Requirements

When the testing process requires checking the application against any pre-defined standards, those standards are described here.     

Performance Requirements

The performance requirements against which this application will be measured are described here.

Defect Tracking System Codes

When defects in the application are found, this section describes how they will be categorized and entered into the defect tracking system.     

Scheduled Availabilities

Application Version:                                          The version to be tested.

Build Date:                                                        The expected date for the following features.

Features to be included in this build:                  The features delivered on this date.

Build Date:                                                        The expected date for the following features.

Features to be included in this build:                  The features delivered on this date.

Build Date:                                                        The expected date for the following features.

Features to be included in this build:                  The features delivered on this date.

---

Test Suite Overview

General Testing Strategy

The overall approach to implementing this test suite is described here.  

Test Environment:

Hardware

The hardware environment in which the tests will be executed is described here.

System Software

The system software environment in which the tests will be executed is described here.

Databases/Files

Any databases and files required to execute this test suite are described here.

Utilities/Tools

Any utility programs required to execute this test suite are described here.

---

Test Suite Summary

It is often useful to have a naming convention to use when naming test cases.

Name of Test Case                        Brief Description

1.  Name of test case here                     Description of test case here.                                        

2.

3.

4.

5.

---

Test Case Specification - 1. Name of Test Case One

Overview:

This section describes, in some detail, what is to be accomplished with this test case (i.e., what particular assertion will be tested).

Prerequisites

Any prior tasks which must be accomplished before this test case can be executed are detailed here.

Any advance preparation of the hardware or software environment is detailed.

Utilities and Files used:

Any utilities, database, and files required to execute or validate this test case are detailed here.  In addition, their version and location is described.

Test Sequence:

The high-level steps required to execute this test case are described here.  This is often the longest portion of the individual Test Case.

Expected Results:

This section describes what results are expected when the above test sequence is executed.

Verification Procedure:

The process for determining if the expected results were achieved is described here.

Script(s):

Any scripts (either written or automated) which aid in execution of this Test Case are listed here.

Time Estimates:

Preparation:                                                      The expected amount of prep time required.

Execution:                                                        The expected amount of execution time. 

Verification:                                                      The expected amount of verification time.

---

My name is Joe Strazzere and I'm currently a Director of Quality Assurance. I like to lead, to test, and occasionally to write about leading and testing. Find me at http://strazzere.blogspot.com/.

Free Test Plan Template

This is a simple Free Test Plan Template.

Please excuse the formatting - this blog makes it hard to preserve the Word Document formatting I used originally.

---

{ProductName} {Version}
Test / Verification Plan

Revision 1.x
Author: Joe Strazzere

---

Control Page

Title:   {ProductName} {Version} – Test / Verification Plan
File:   {ProductName} {Version} Test Verification Plan.doc
Source Template:
Document Owner:  Joe Strazzere
Date of Issue:  {Date}

Abstract:  This document defines the test verification plan for the
{ProductName} {Version} release. copyrightjoestrazzere

Revision History
Revision Date        Initial      Description
1 mmm dd, yyyy    JSS        Initial document created / sent.
1.1 mmm dd, yyyy JSS         Incorporated suggestions from …

Distribution
Name                                  Role
Firstname Lastname             Project Manager
Firstname Lastname             Engineering Manager
Joe Strazzere                       QA Manager
Firstname Lastname             QA Engineer
Firstname Lastname             QA Engineer

---

Table of Contents

Overview                                                            4
Roles                                                                  5
Platforms                                                            6
Test Environment                                                6
Tracking                                                             7
Release Criteria                                                  8
Categories of Tests                                             9
Approximate Count of Test Cases                      10
References                                                         11

---

Overview

This document will outline the test verification plan for {ProcuctName} {Version}, currently scheduled for Q1 yyyy. 

---

Roles

Following are the relevant major Roles assigned to this project:

 • Project Manager  Firstname Lastname
 • Development Manager  Firstname Lastname
 • Developer   Firstname Lastname
 • Developer   Firstname Lastname
 • Developer   Firstname Lastname
 • QA Manager   Firstname Lastname
 • QA Engineer   Firstname Lastname
 • QA Engineer   Firstname Lastname
 • Doc Manager   Firstname Lastname
 • Configuration Engineer Firstname Lastname

---

Platforms

{ProductName} {Version} will be tested on the following Operating Systems:

 • Windows 2000 Professional (for Proxy Server only)
 • Windows 2000 Server
 • Windows 2003
 • Windows XP Professional

Test Environment
{ProductName} {Version} will be tested in the QA Lab environment, using accounts created for testing purposes.  The following equipment will be used, no new equipment is required:

 machinename1                       machinename2
 CPU Dual 2.4 GHz Xeon      CPU Dual 2.4 GHz Xeon
 2GB RAM                            2GB RAM
 Windows 2003                     Windows 2003

 machinename3                       machinename4
 CPU Dual 2.8 GHz Xeon      CPU Dual 2.4 GHz Xeon
 2GB RAM                            2GB RAM
 Windows 2003                     Windows 2000 Server

---

Tracking

All Requirements, Tests, and Issue Reports will be stored in {BugTrackingSystem} as follows:

 • Database {DatabaseName}
 • Project {ProjectName}
 • Target Ver {Version}

---

Release Criteria

The project will be considered ready for Beta when it meets the following criteria:

 • All functionality has been tested
 • All Issues with Priority=High have been Fixed and Verified
 • In the week before Beta, no new Priority=High Issues are found, despite constant testing pressure

The project will be considered ready for GA when it meets the following criteria:

 • All functionality has been tested
 • All Issues reported from Beta sites have been entered into {BugTrackingSystem}
 • All Issues with Priority=High and Priority=Medium have been Fixed and Verified
 • In the two weeks before GA, no new Priority=High or Priority=Medium Issues are found, despite constant testing pressure

---

Categories of Tests

The following major categories of tests must be performed:

 • New Functionality Tests – The majority of these tests will focus on testing each of the specific new features of {ProductName} {Version}:

  o Support for {NewFeature1}
  o Support for {NewFeature2}
  o Support for {NewFeature3}

 • Integration Testing – Integration testing will verify the interoperability of {ProductName} components.

 • Regression Testing – Regression testing will verify that existing features of {ProductName} continue to operate as expected.

o For {ProductName} {Version}, it will be necessary to perform a full regression testing cycle

 • System Tests – These tests will focus on the {ProductName} product as a whole, single solution in a production-simulated environment.

o Scale, Load and Duration tests will be performed

 • Bug Fix Verification – Throughout the testing cycle, bug fixes will be verified in as timely a manner as possible.


 • Interoperability Testing – These tests will focus on the interoperability of {ProductName} with non-{ProductName} components:

o {OtherProductName1}
o {OtherProductName2}
o {OtherProductName3}
o {OtherProductName4}

---

Approximate Count of Test Cases

Approximately xxx functional Test Cases will be exercised, within the following areas.  More will be added as necessary:

 • {FeatureArea1}   5
 • {FeatureArea2}   35
 • {FeatureArea3}   10
 • {FeatureArea4}   15
 • {FeatureArea5}   20
 • {FeatureArea6}   20
 • {FeatureArea7}   85
 • {FeatureArea8}   5
 • {FeatureArea9}   15
 • {FeatureArea10}   15
 • {FeatureArea11}   25
 • {FeatureArea12}   5

---

References
Version {Version} Requirements

• in {BugTrackingSystem}

{ProductName} {Version} Functional Specification

• In Outlook ({FileNameAndLocation} FunctionalSpec.doc)

{ProductName} {Version} Functional Specification Update (in Outlook)

• In Outlook ({FileNameAndLocation} Functional Specification Update.doc)

{ProductName} {Version} Reference

{ProductName} {Version} Test Developer User Guide

{ProductName} {PriorVersion1} {PriorVersion2} test cases

• in {BugTrackingSystem}

QAer Status Reports

I don't like to burden my QA Team with paperwork.  In general, I prefer just talking over receiving reports.

But, when my team gets too large, or too dispersed geographically, I need to ask for Status Reports, to help me keep track of things over time.

Here's an email I send to all new QAers on my team, asking them to send me weekly Status Reports:

---

I like to receive weekly Status Reports from each QAer.  This helps keep me up to speed on what you are doing, and hopefully keeps me in the loop on issues I need to know.

Please send me the following via email each Friday before you leave.

1) What I worked on this week:

I'm just looking for bullet items here.  The basics of what you have done for the week.
I don't need to know how many hours you spent on things, just what you were doing.

For example:
- Wrote Test Plan for new Zerble Suite 7.0 feature XXX
- Completed testing of Framis 3.2 SR6 using AB&T database
- Attended planning meeting for Zerble Suite 8.0
- etc, etc

2) What I plan to work on next week:

Again, just the basics.
I'm looking to see what is on your plate for the upcoming week.

3) Unplanned Activities:

This will help me better keep track of progress on our schedules versus all the other activities we participate in.

This should include:

- any work not normally part of your weekly routine

- any work on customer or hitlist problems

- any work helping out other teams

- basically anything not directly involved with QA, testing, creating test cases, etc for the upcoming scheduled release(s)

4) Time away next week:

Please tell me if you are expecting to be out of the office during the upcoming week.
I don't need to know too much detail here, just when you won't be here, and a general reason as to why.

For example:
- Vacation day Tuesday, February 10

5) Issues and Concerns

Anything I should know about.
If there's anything getting in the way of your work, here's where you can note it.

For example:
- Memory upgrade on Bigtest server has been delayed.  Without the additional memory, my load testing cannot be completed.

I don't want this to take more than a few minutes to complete.
Some folks find it simpler to keep track of tasks each day, then just paste them into an email at the end of the week.

I will not be sharing the details of your status reports with anyone, although I do pass along a high-level summary of the QA Team in general to the VP of Engineering.

We'll revise this process as we need to going forward, making sure it is simple, not burdensome, but effective.

Thanks,
-joe

Hiring QA Interns

Where I work now, we hire Interns from local colleges to augment our QA Team.  Typically we bring in two students at a time for a 6-month paid internship.

They each work with one of the Senior QAers in a variety of roles - Functional Testing, Scalability Testing, etc.  It works out well for us - we get two more QAers when the budget doesn't allow for full-timers.  And it works out well for them - they get some hands-on experience.

One of the challenges in hiring an Intern is finding two good candidates from the population of applicants.  They are young, inexperienced and most have little in the way of interviewing skills.  Some have done an internship before, but many have not.

We have found that it works best to talk with them once, then make a quick decision.  I usually talk with them first for about a half-hour, followed by a half-hour each with the two Senior QAers.  After we have spoken with a batch of applicants, we get together and discuss the candidates and decide which, if any, deserve offers.

Here are some of the questions I ask when interviewing a potential QA intern.  Most of them are not make-or-break questions themselves, but they help us quickly assess the candidate in very general terms:

Do you have any time off planned during the 6-month period of the internship?
In general, we are looking for people who can devote the full 6 months to the internship.  We don't want someone who is planning a 2-month trip to Europe in the middle of this period, for example.

What’s your current school schedule like?If the student likes to take a bunch of easy courses, then we may not be the right internship home.
I also like to find out if they are scheduling lots of days off in their week, or would prefer to be busy.
Last, I try to see if they are early-risers, or late-sleepers.  We have room for both - it's just nice to know where they fall.

How many hours per week would you like to work?
We try to make it clear in the job posting that we are looking to fill an 8-hours-per-day, 40-hours-per-week position.  But, occasionally we get a candidate who is only looking to work 20 hours or so.

What year are you in? 
Our past experience has shown that the later in their academic career we can get them, the better the internship.
For whatever reason, Juniors and Seniors end up being more serious, more experienced and more hardworking in general than their younger counterparts.

Have you worked an Internship before?Hey, you have to start somewhere.  But, if you've already done an intership before, you'll have a better sense of what is expected, and what is in store for you.
Not everyone likes working in a cubicle.  If you've done it before and want to do it again, that's a good sign.

Do you have reliable transportation?
We work in a suburban area.
There is bus transportation, but it's not the best way to get here - particularly in bad weather.
If the candidate has a car, we have found that they tend to show up on a more regular basis than if they don't.

What do you like to do when you aren’t studying?
If the candidate spends all their free time clubbing, that might be fun for them.
If they spend free time playing with computers and software, that might be a better indicator of potential success.

Do you know anything about testing/QA?
Few Universities teach anything at all about Testing or Quality Assurance.
But, some candidates have still found a way to understand what testing and QA are, and can express it.

What Operating Systems are you familiar with?
Some candidates know how to use only Windows, and perhaps a small bit of Unix.
Other candidates have been installing Windows and mucking around with Linux since they were children.

Have you had a chance to check out our web site?
We'd like to hire interns who have enough inititative to look at our web site and understand what we do.

Do you have any questions for me?
Hopefully, this open-ended question leads to a discussion of what my company does, what we in QA do, and what the intern can expect.

As I've said, none of these are make or break questions.  As much as anything we are looking for someone who is smart, wants to work hard, and is willing to learn.

We've been very lucky to have found some pretty good interns over the years.  Some have come back and become employees.  Others have gone on to positions in other companies.  Most of the time we give them a great recommendation.

Free Issue Tracking Template

Here's a free template of an Issue Tracking system I currently use.

Issue Number: A system-generated number that uniquely identifies the Issue.

Summary: This is a short, one-line statement that summarizes the issue.

Created: This system-generated field displays the date the Issue was created and the name of the person who created it.

Last Modified: This system-generated field displays the date the Issue was most recently modified and the name of the person who modified it. copyrightjoestrazzere

Closed: This system-generated field displays the date the Issue was closed and the name of the person who closed it.

Product: This is the product for which the issue applies. It will typically be selected from a list customized for the particular database and project.

Issue Type: This indicates the type of issue. The choices are:

• Bug: This is a bug in the existing product
• Feature Request: This is a request for a new feature
• Task: This is a new development task
• Hitlist: This is a hitlist (ie, customer-and-time-critical) issue
• Flex: This issue holds anticipated Developer time off
• Other: Anything else

Priority: This is a measure of the level of importance or urgency connected with this issue. The possible choices are:

• Critical: This is the highest priority and should only be given to issues associated with customers being down, or when testing is blocked. These issues will often be added to the hitlist.
• High: This priority is for serious issues that are causing the user a great amount of pain but can be managed in the short-term with a workaround.
• Medium: This is the priority that should be given to most issues.
• Low: This is for issues that are not very important. Easy workarounds exist for these issues.

Issue Build: This is the version of the product in which the issue was detected. When issues are detected during a development release, the full version-and-build numbers should be used (ex: 2.50.0421).  When the issues are detected in a GA release, just the major and minor version numbers may be used (ex: 5.10).

Target Ver: This is the version of the product in which the issue was (or will be) resolved. All version numbers should have one of the following forms: M.mm where M is the major version number, mm is the minor version number (ex: 2.50), or the code name of the Project in which the issue is to be fixed (ex: Havard).

Work Days: This indicates the Developer’s estimate of the days required to resolve the Issue.  This field typically only exists once the Issue reaches Accepted status.

Fix Build: Once fixed, this field indicates the full version-and-build in which the fix is expected to appear.  Once the fix is verified, this field indicates the full version-and-build number of the build used while verifying the fix.

Status: This describes the current state of the issue. The possible choices are:

• New: This is the status that is given to all newly created issues.
• Accepted: This is the status that is given to an issue that will be worked on for the next release.
• Fixed: This is the status that is given to an issue that has been fixed (or implemented in the case of a feature request) and needs verification.
• Closed: This is the status given to an issue that has been successfully verified.
• Deferred: This is the status given to issues that will be fixed in a future release.

Assigned: This is the name of the person who currently owns the issue. For accepted issues this will be the developer who is responsible for providing the fix. For fixed issues, this will be the person responsible for verifying the fix.

Description: This is a continuous dialog contributed to by each owner of the issue. Typically, it starts with a description of the problem, the steps required to reproduce the problem, the expected results, and the actual results. It continues with a description of the solution entered by the developer who fixed the problem. It may further continue with notes from the verifier (especially in the case where the verification failed).
Each time more description text is added, the system automatically adds a time stamp.

Attachments: All files which help clarify the issue are attached here

Associated Tests: The Test Case associated with this Issue is linked here

Associated Issues: Any duplicate Issues are linked here.  Any other Issues which can help clarify this issue are also linked here.

Here's a sample Issue Report:

Issue Number:	1234
Summary:	Right-Click Menu is Missing the Delete Choice
Created:	2/21/06 at 10:43 AM by Joe Strazzere
Last Modified:	3/1/06 at 8:12 AM by Joe Strazzere
Closed:	3/1/06 at 8:12 AM by Joe Strazzere
Product:	Whiz-Bang
Issue Type:	Bug
Priority:	Medium
Issue Build:	2.50.0401
Target Ver:	2.50
Work Days:	1
Fix Build:	2.50.0406
Status:	Closed
Description:	When I right-click the Zerble object, the menu which appears does not include the "Delete" choice, as it did in prior versions. Nothing unexpected appears in the server.log file. The JavaScript console shows no errors. To Reproduce: - Open the Framis in the Whiz-Bang Editor - Select one of the the Zerble objects which appear - Right-click - Note the choices in the pop-up menu Expected Results: - The pop-up menu choices should be Add, Edit, Delete, Save, Save As, Help, and Exit Actual Results: - Delete is missing, the rest are as expected. - (see attached zerblemenu.jpg) [Joe Strazzere - 2/21/06 10:43 AM] The call to popUpMenuSelections was made without the isItDeleted modifier.  Should be fixed in the next build. [Dee Veloper - 2/28/06 6:22 PM] Verified in build 406 usig IE and Firefox. [Joe Strazzere - 3/1/06 8:12 AM]
Attachments:	zerblemenu.jpg
Associated Tests:	142 - Zerble Object Right-Click Menu Choices
Associated Issues:	(none)