Test report: Difference between revisions
From CEOpedia | Management online
m (Infobox update) |
m (Text cleaning) |
||
(2 intermediate revisions by 2 users not shown) | |||
Line 1: | Line 1: | ||
'''Test report''' has to show what was accomplished and what was not in the [[project]]. Then appropriate actions can take place. The purpose of the test report is to support [[stakeholders]] in making decisions about the project, therefore it have to meet specific expectations. | '''Test report''' has to show what was accomplished and what was not in the [[project]]. Then appropriate actions can take place. The purpose of the test report is to support [[stakeholders]] in making decisions about the project, therefore it have to meet specific expectations. | ||
Typical outcome might be SWOT analyzes with strengths, weeknesses, opportunities of improvements and threats<ref>Limaye M. G. (2009), p.406-407</ref>. | Typical outcome might be SWOT analyzes with strengths, weeknesses, opportunities of improvements and threats<ref>Limaye M. G. (2009), p.406-407</ref>. | ||
== Test report detailes== | ==Test report detailes== | ||
Test report should generally consist of<ref>Limaye M. G. (2009), p.407 </ref>: | Test report should generally consist of<ref>Limaye M. G. (2009), p.407 </ref>: | ||
* Test '''scope'''/ test objectives, | * Test '''scope'''/ test objectives, | ||
Line 28: | Line 11: | ||
* '''General [[information]]''' about the project, | * '''General [[information]]''' about the project, | ||
* Test start '''date''' and test end date, | * Test start '''date''' and test end date, | ||
* '''Status of the project''' with estimation if there is a possibility to meet requirements and deadlines, | * '''[[Status of the project]]''' with estimation if there is a possibility to meet requirements and deadlines, | ||
* Test '''case levels''' with detailed information about phases of the test/project if they were any, | * Test '''case levels''' with detailed information about phases of the test/project if they were any, | ||
* '''Statistics''' abouts errors etc., | * '''Statistics''' abouts errors etc., | ||
Line 42: | Line 25: | ||
* Developing internal baselines to be able to compare and improve tests within the company across the projects for example some unified '''template''', | * Developing internal baselines to be able to compare and improve tests within the company across the projects for example some unified '''template''', | ||
* Using '''check lists''' before sending report (such as spelling mistakes) to make sure all data is correct and clear for stakeholders, | * Using '''check lists''' before sending report (such as spelling mistakes) to make sure all data is correct and clear for stakeholders, | ||
* Including '''facts''' relating to the problems, not blaming any teams and persons, | * Including '''facts''' relating to the problems, not blaming any teams and persons, | ||
* Keeping high '''[[quality]]''' of the report for shareholders for example the same fonts, readable information to avoid mis understandings. | * Keeping high '''[[quality]]''' of the report for shareholders for example the same fonts, readable information to avoid mis understandings. | ||
Line 56: | Line 39: | ||
## Assessment of test results | ## Assessment of test results | ||
## Anticipated risks | ## Anticipated risks | ||
# Enclosures | # Enclosures | ||
## Test minutes | ## Test minutes | ||
## Test specification | ## Test specification | ||
Line 66: | Line 49: | ||
<references /> | <references /> | ||
== References == | {{infobox5|list1={{i5link|a=[[Internal benchmarking]]}} — {{i5link|a=[[Project status report]]}} — {{i5link|a=[[Quality plan]]}} — {{i5link|a=[[Stages of project]]}} — {{i5link|a=[[Feature-driven development]]}} — {{i5link|a=[[Project cycle management]]}} — {{i5link|a=[[Management by exceptions]]}} — {{i5link|a=[[PMBOK framework]]}} — {{i5link|a=[[Managerial controlling]]}} }} | ||
==References== | |||
* Drabick R. (2013), ''Best Practices for the Formal Software Testing Process: A Menu of Testing Tasks'', Addison-Wesley, USA | * Drabick R. (2013), ''Best Practices for the Formal Software Testing Process: A Menu of Testing Tasks'', Addison-Wesley, USA | ||
* Feng Y., Chen Z., Jones J. A., Chunrong F., Xu B. (2015) [http://spideruci.org/papers/feng15sep.pdf ''Test Report Prioritization to Assist Crowdsourced Testing''], Nanjing University, China & University of California, USA | * Feng Y., Chen Z., Jones J. A., Chunrong F., Xu B. (2015) [http://spideruci.org/papers/feng15sep.pdf ''Test Report Prioritization to Assist Crowdsourced Testing''], Nanjing University, China & University of California, USA |
Latest revision as of 05:50, 18 November 2023
Test report has to show what was accomplished and what was not in the project. Then appropriate actions can take place. The purpose of the test report is to support stakeholders in making decisions about the project, therefore it have to meet specific expectations. Typical outcome might be SWOT analyzes with strengths, weeknesses, opportunities of improvements and threats[1].
Test report detailes
Test report should generally consist of[2]:
- Test scope/ test objectives,
- Test results showing differences between results and expectations,
- Identyfication of what worked and what did not work and descriptions of these defects,
- Recommendations of improvements with development process.
Moreover, if there is such an expectation from stakeholders, the test report might be expanded by[3][4]:
- General information about the project,
- Test start date and test end date,
- Status of the project with estimation if there is a possibility to meet requirements and deadlines,
- Test case levels with detailed information about phases of the test/project if they were any,
- Statistics abouts errors etc.,
- Observed performance on the business etc.,
- Problems assosiated with the project for tracking purposes,
- Capabilities and risks,
- Description of data which is analyzed and data itself,
- Detailed status of what is accomplished and what is not for example with RAGs,
- Test logs.
Guidelines for writting test report
Limaye M. G. recommends guidelines for wrtting test report within the company[5]:
- Developing internal baselines to be able to compare and improve tests within the company across the projects for example some unified template,
- Using check lists before sending report (such as spelling mistakes) to make sure all data is correct and clear for stakeholders,
- Including facts relating to the problems, not blaming any teams and persons,
- Keeping high quality of the report for shareholders for example the same fonts, readable information to avoid mis understandings.
Test report scope example
Scope of test report might look as below[6]:
- General information,
- Aim of the document
- Test scope
- Performed activities
- Test goals and focus
- Test results
- Applied methods and procedures
- Assessment of test results
- Anticipated risks
- Enclosures
- Test minutes
- Test specification
- Test procedures
Author: Anita Bernacka
Footnotes
Test report — recommended articles |
Internal benchmarking — Project status report — Quality plan — Stages of project — Feature-driven development — Project cycle management — Management by exceptions — PMBOK framework — Managerial controlling |
References
- Drabick R. (2013), Best Practices for the Formal Software Testing Process: A Menu of Testing Tasks, Addison-Wesley, USA
- Feng Y., Chen Z., Jones J. A., Chunrong F., Xu B. (2015) Test Report Prioritization to Assist Crowdsourced Testing, Nanjing University, China & University of California, USA
- Lent B. (2014), Cybernetic Approach to Project Management, Springer Science & Business Media, Switzerland
- Limaye M. G. (2009), Software Testing, Tata McGraw-Hill Education, India
- Shaheen S., Wright J., Dick D. (2000), Carlink - A Smart Carsharing System Field Test Report, Partners for Advanced Transit and Highways Memorandum of Understanding 380, University of California, USA
- Viking'75 Project. Balloon lauched decelerator test program. Post - flight test report (1972), NASA, USA