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:
{{infobox4
|list1=
<ul>
<li>[[Internal benchmarking]]</li>
<li>[[Project status report]]</li>
<li>[[Quality plan]]</li>
<li>[[Stages of project]]</li>
<li>[[Feature-driven development]]</li>
<li>[[Project cycle management]]</li>
<li>[[Management by exceptions]]</li>
<li>[[PMBOK framework]]</li>
<li>[[Managerial controlling]]</li>
</ul>
}}
'''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]]}} &mdash; {{i5link|a=[[Project status report]]}} &mdash; {{i5link|a=[[Quality plan]]}} &mdash; {{i5link|a=[[Stages of project]]}} &mdash; {{i5link|a=[[Feature-driven development]]}} &mdash; {{i5link|a=[[Project cycle management]]}} &mdash; {{i5link|a=[[Management by exceptions]]}} &mdash; {{i5link|a=[[PMBOK framework]]}} &mdash; {{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 06: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]:

  1. General information,
  2. Aim of the document
  3. Test scope
    1. Performed activities
    2. Test goals and focus
  4. Test results
    1. Applied methods and procedures
    2. Assessment of test results
    3. Anticipated risks
  5. Enclosures
    1. Test minutes
    2. Test specification
    3. Test procedures

Author: Anita Bernacka

Footnotes

  1. Limaye M. G. (2009), p.406-407
  2. Limaye M. G. (2009), p.407
  3. Limaye M. G. (2009), p.406-408
  4. Drabick R. (2013), p.157-159
  5. Limaye M. G. (2009), p.408
  6. Lent B. (2014), p.137


Test reportrecommended articles
Internal benchmarkingProject status reportQuality planStages of projectFeature-driven developmentProject cycle managementManagement by exceptionsPMBOK frameworkManagerial controlling

References