Professional Documents
Culture Documents
Post Mortem
Post Mortem
Post Mortem
Deliver software solutions to specification, on time and on budget with Software Planner. Tracks
customer requirements, test cases, defects, project deliverables, and your schedule
(appointments and to-do lists) via the web.
Discussion forums and contact management also built in. FREE 2 WEEK TRIAL
Software Planner Guided Tour Pricing Brochure Free Trial Software Planner Details
Signoffs
Phase Name Date Signature
Post Mortem John Doe, PM/DM xx/xx/xx
Jane ProdSupport,
Production Support Mgr
_____________________________________________________________________________
Developed by Pragmatic Software Co., Inc. http://www.PragmaticSW.com
Post Mortem Report Page 2 of 5
Revision History
Table of Contents
_____________________________________________________________________________
Developed by Pragmatic Software Co., Inc. http://www.PragmaticSW.com
Post Mortem Report Page 3 of 5
1. Introduction
The purpose of the Post Mortem Report is to describe in detail the specific activities that were
most effective and those that need adjustments prior to the next test project. A goal of the
document is to inform future project teams of the obstacles encountered during this release.
These activities will focus upon identifying the following:
1.1 Background
1.2 References
2. Processes
_____________________________________________________________________________
Developed by Pragmatic Software Co., Inc. http://www.PragmaticSW.com
Post Mortem Report Page 4 of 5
3. Action Items
The action items themselves must be concrete and objective, that is: dates must be assigned,
assignees identified, and a form of “measurement” determined so as to assess the
performance towards the action item’s end objective.
Ref # 2.1.1 Continue to be polite and nice. Do not be-little or condescend someone or his or
her input.
Ref # 2.1.2 Educate the value of a solid testing methodology and process.
Ref # 2.2.2 Project Plan should have ample setup time for hardware.
The new test plan templates will prompt the test lead to ask certain questions
about hardware/software requirements during the planning stage. This will allow
better planning for configuration management.
Ref # 2.2.3 Notify Project Management upon completion of each project deliverable.
Our current methodology would have prevented this. Weekly status reports
would indicate what tasks need to be completed and what tasks have been
completed. These reports would indicate when a review is required by PM.
Ref # 2.2.5 Draft form of functional specification will need to be used in preliminary test
planning. The test plan should refer to sections of the functional spec.
This is a common practice and it should be noted in our risks and critical dates
_____________________________________________________________________________
Developed by Pragmatic Software Co., Inc. http://www.PragmaticSW.com
Post Mortem Report Page 5 of 5
Ref # 2.2.6 During test case creation, periodic peer reviews need to be conducted by the test
lead. After adjustments have been made to existing test cases, the PM should
review the test cases. With our new test methodology, this should no longer be
a problem. During the planning phase, a weekly status report will keep all team
members informed of progress and slippage.
Ref # 2.2.8 The quality of testing can be improved when feedback from the team is
documented and analyzed. This feedback can only be communicated by
participation in the post-mortem process. Solicit feedback during the project in
the form of reviews, stopping by, a phone call, and triage meetings. Keep notes
for the post-mortem report.
Software Planner Guided Tour Pricing Brochure Free Trial Software Planner Details
_____________________________________________________________________________
Developed by Pragmatic Software Co., Inc. http://www.PragmaticSW.com