Postmortem
This document was uploaded by user and they confirmed that they have the permission to share it. If you are author or own the copyright of this book, please report to us by using this DMCA report form. Report DMCA
Overview
Download & View Postmortem as PDF for free.
More details
- Words: 1,148
- Pages: 5
Post Mortem Report
Page 1 of 5
Brought to you by Software Planner (www.SoftwarePlanner.com). 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 Interested in learning more? Call us at 800-773-7785 or click here. Software Planner Guided Tour
Pricing
Brochure
Free Trial
Software Planner Details
Post Mortem Report
Owners and List of Contacts Name
Email
Phone
Role
John Doe
[email protected]
303-894-7315 W 303-471-8344 H 303-203-5567 Pgr
Project Manager Development Lead
Joe Tester Jane ProdSupport Joe UserMgr Joe Tester Jane Tester Joe Customer Jane Customer Josey Customer
System Test Lead Production Support Mgr User Test Lead Tester Tester Department VP Department Mgr Product Support
Signoffs Phase
Name
Date
Post Mortem
John Doe, PM/DM
xx/xx/xx
Signature
Joe Tester, System Test Lead Jane ProdSupport, Production Support Mgr
_____________________________________________________________________________ Developed by Pragmatic Software Co., Inc. http://www.PragmaticSW.com
Post Mortem Report
Page 2 of 5
Joe User Mgr, UM Joe Customer, Customer
Revision History Date
Reason for change(s)
Author( s)
09/15/198 8
First Draft
John Doe
Table of Contents OWNERS AND LIST OF CONTACTS...................ERROR: REFERENCE SOURCE NOT FOUND SIGNOFFS............................................................ERROR: REFERENCE SOURCE NOT FOUND REVISION HISTORY............................................ERROR: REFERENCE SOURCE NOT FOUND 1. INTRODUCTION........................................................................................................................3 1.1
Background......................................................................................................................3
1.2 References............................................................................................................................3 2. Processes...................................................................................................................................3 2.1 Processes that were most effective.......................................................................................3 2.2 Processes that had a negative effect on the project..............................................................3 3. Action Items................................................................................................................................4 3.1
How to continue doing what was done “Right”..................................................................4
3.2
How to correct what “Needs Improvement”......................................................................4
_____________________________________________________________________________ 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: • • •
Processes which need adjustment Most effective Processes Providing Action items
1.1 Background Describe the project in detail here.
1.2 References List all reference material used to create this report: 1. PostMortemAnalysis.Doc , dated xx/xx/xx 2. [ProductName] Functional Specification, xx/xx/xx 3. [ProductName] Test Plan, xx/xx/xx
2. Processes 2.1 Processes that were most effective The following processes were described as positive to the project. Ref # 2.1.1
Category Team Work
# of Votes 6
“Good Statements” Good/Responsive Communication
2.1.2 2.1.3 2.1.4
Team Work Risk mgmt. Document
5 2 2
Cooperation from Program Management Testers stuck to project schedule Test Plan
2.2 Processes that had a negative effect on the project
Ref # 2.2.1 2.2.2
Category Planning Planning
# of Votes 4 3
“Need Improvement” Tester turnover Setup delay
_____________________________________________________________________________ Developed by Pragmatic Software Co., Inc. http://www.PragmaticSW.com
Post Mortem Report
2.2.3
Team Work
2.2.4 2.2.5 2.2.6 2.2.7 2.2.8
Risk mgmt. Planning Team Work Planning Team Work
Page 4 of 5 3 2 2 1 1 1
Project Manager (PM) should be able to review the detail test plan & test cases Incomplete testing as per the test plan Functional specification is almost close to final Test Case review with PM Option to start testing sooner – needed more info Commitment from everyone who is/was involved
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.
3.1 How to continue doing what was done “Right” 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.1.3 Continue to manage risk. Ref # 2.1.4 Continue to review plans.
3.2
How to correct what “Needs Improvement”
Ref # 2.2.1 Resource planning from management. Currently researching several programs to retain QA employees. This will require a considerable amount of effort from the team. 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.4 Review and Prioritize Test Tasks. Manage risks associated with slippage. Many times the project plan is under estimated which causes missed due dates. One way to mitigate this risk is to stack-rank the importance of each test case. Also, on larger projects the business should drive an effort to coordinate the dependencies on deliverables. 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
section. It needs to be clear to the PM that if the functional specifications change, it may have an impact on the test schedule. One tool that would help is the Defect Tracker software (http://www.DefectTracker.com ). When requirements change e-mail should be sent to all related parties. 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.7 Start dates for resources need to be flexible. Test needs to have accurate project forecasts. Also inform the PM (set expectations) that we do not have a solution for this one. 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. Brought to you by Software Planner (www.SoftwarePlanner.com). 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
_____________________________________________________________________________ Developed by Pragmatic Software Co., Inc. http://www.PragmaticSW.com
Page 1 of 5
Brought to you by Software Planner (www.SoftwarePlanner.com). 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 Interested in learning more? Call us at 800-773-7785 or click here. Software Planner Guided Tour
Pricing
Brochure
Free Trial
Software Planner Details
Post Mortem Report
Owners and List of Contacts Name
Phone
Role
John Doe
[email protected]
303-894-7315 W 303-471-8344 H 303-203-5567 Pgr
Project Manager Development Lead
Joe Tester Jane ProdSupport Joe UserMgr Joe Tester Jane Tester Joe Customer Jane Customer Josey Customer
System Test Lead Production Support Mgr User Test Lead Tester Tester Department VP Department Mgr Product Support
Signoffs Phase
Name
Date
Post Mortem
John Doe, PM/DM
xx/xx/xx
Signature
Joe Tester, System Test Lead Jane ProdSupport, Production Support Mgr
_____________________________________________________________________________ Developed by Pragmatic Software Co., Inc. http://www.PragmaticSW.com
Post Mortem Report
Page 2 of 5
Joe User Mgr, UM Joe Customer, Customer
Revision History Date
Reason for change(s)
Author( s)
09/15/198 8
First Draft
John Doe
Table of Contents OWNERS AND LIST OF CONTACTS...................ERROR: REFERENCE SOURCE NOT FOUND SIGNOFFS............................................................ERROR: REFERENCE SOURCE NOT FOUND REVISION HISTORY............................................ERROR: REFERENCE SOURCE NOT FOUND 1. INTRODUCTION........................................................................................................................3 1.1
Background......................................................................................................................3
1.2 References............................................................................................................................3 2. Processes...................................................................................................................................3 2.1 Processes that were most effective.......................................................................................3 2.2 Processes that had a negative effect on the project..............................................................3 3. Action Items................................................................................................................................4 3.1
How to continue doing what was done “Right”..................................................................4
3.2
How to correct what “Needs Improvement”......................................................................4
_____________________________________________________________________________ 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: • • •
Processes which need adjustment Most effective Processes Providing Action items
1.1 Background Describe the project in detail here.
1.2 References List all reference material used to create this report: 1. PostMortemAnalysis.Doc , dated xx/xx/xx 2. [ProductName] Functional Specification, xx/xx/xx 3. [ProductName] Test Plan, xx/xx/xx
2. Processes 2.1 Processes that were most effective The following processes were described as positive to the project. Ref # 2.1.1
Category Team Work
# of Votes 6
“Good Statements” Good/Responsive Communication
2.1.2 2.1.3 2.1.4
Team Work Risk mgmt. Document
5 2 2
Cooperation from Program Management Testers stuck to project schedule Test Plan
2.2 Processes that had a negative effect on the project
Ref # 2.2.1 2.2.2
Category Planning Planning
# of Votes 4 3
“Need Improvement” Tester turnover Setup delay
_____________________________________________________________________________ Developed by Pragmatic Software Co., Inc. http://www.PragmaticSW.com
Post Mortem Report
2.2.3
Team Work
2.2.4 2.2.5 2.2.6 2.2.7 2.2.8
Risk mgmt. Planning Team Work Planning Team Work
Page 4 of 5 3 2 2 1 1 1
Project Manager (PM) should be able to review the detail test plan & test cases Incomplete testing as per the test plan Functional specification is almost close to final Test Case review with PM Option to start testing sooner – needed more info Commitment from everyone who is/was involved
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.
3.1 How to continue doing what was done “Right” 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.1.3 Continue to manage risk. Ref # 2.1.4 Continue to review plans.
3.2
How to correct what “Needs Improvement”
Ref # 2.2.1 Resource planning from management. Currently researching several programs to retain QA employees. This will require a considerable amount of effort from the team. 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.4 Review and Prioritize Test Tasks. Manage risks associated with slippage. Many times the project plan is under estimated which causes missed due dates. One way to mitigate this risk is to stack-rank the importance of each test case. Also, on larger projects the business should drive an effort to coordinate the dependencies on deliverables. 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
section. It needs to be clear to the PM that if the functional specifications change, it may have an impact on the test schedule. One tool that would help is the Defect Tracker software (http://www.DefectTracker.com ). When requirements change e-mail should be sent to all related parties. 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.7 Start dates for resources need to be flexible. Test needs to have accurate project forecasts. Also inform the PM (set expectations) that we do not have a solution for this one. 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. Brought to you by Software Planner (www.SoftwarePlanner.com). 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
_____________________________________________________________________________ Developed by Pragmatic Software Co., Inc. http://www.PragmaticSW.com
