how to write an engineering test report

• How to Join
• ProComm Leadership Team
• Our Vision and Mission
• Membership Information
• Constitution
• ProComm Conferences
• ProComm 2024
• Past Conferences
• Future Conference Locations
• About the Journal
• Submitting a Manuscript
• Search Articles on IEEE Xplore
• Videos for Transactions Peer Reviewers
• English, Chinese, and Spanish Abstracts
• IEEE Transactions on Professional Communication Editorial Staff
• Classics in Communication
• The Wiley-IEEE PCS Book Series
• IPCC Proceedings (IEEE Xplore)
• About the Communication Resources
• Interpersonal
• Style and Grammar
• Written Reporting
• Oral Presentation
• Career Development
• Rhetorical Strategies
• Become a ProComm Expert
• ProComm Network Events
• Find a ProComm Expert
• About Division VI
• IEEE Education Society
• IEEE Industrial Electronics Society
• IEEE Product Safety Engineering Society
• IEEE Reliability Society
• IEEE Society on Social Implications of Technology
• IEEE Technology and Engineering Management Society

As a professional engineer, you have myriad experiences solving problems. Your reports, both formal and informal, help your client, supervisor, or other stakeholders make actionable decisions about those problems. Explore these resources to learn how to write more effective reports for greater project and career success:

• How do I write an effective report?

How do I use Microsoft Word to my advantage?

• Where can I find more information about writing reports?

Whether formal or informal, interim or final, your report is an essential part of the problem-solving process. Begin by analyzing your communication situation (note: link to Communication Situation) and reviewing communication basics?? (note: link to Communication Basics), then find out how to structure and format your report as effectively as possible:

What elements should my report contain?

What is the best way to present those elements.

Whether you’re writing for a client, your supervisor, or some other project stakeholder, your audience will likely want to know [adapted from P.V. Anderson’s Technical Communication (1)]:

• What will we gain?
• Are your facts reliable?
• What do you know that is useful to us?
• How do you interpret those facts from our point of view?
• How are those facts significant to us?
• What do you think we should do?

An effective report will be structured to answer these questions clearly and specifically. Depending on its level of formality, your report structure will include all or some of these elements [adapted from the Purdue Online Writing Lab (2)]:

• Front matter This report element includes the title or cover page, letter of transmittal, acknowledgments, table of contents, and lists of figures and tables.
• Executive summary and abstract These report elements provide an overview of what you’ll discuss in the body of the report.
• Body This report element includes the introduction, summary/background, methods/procedures, results, discussion of results, conclusion, and recommendations.
• Back matter This report element includes references, appendices, and attachments.

Front matter refers to the preliminary, supporting components of a report. It appears where you might expect: at the front of the report. You will typically attend to this element last and in conjunction with back matter, after you have written the body and executive summary and abstract.

Your report’s front matter includes [adapted from the Purdue Online Writing Lab (3)]:

• Title or cover page Include a title, the name of the person authorizing the report, your name, your company’s name and contact information, and the date you submit the report.
• Letter of transmittal Describe the problem you’re solving for, the purpose of the work you’ve done, the time period for the work, and your results and recommendations.
• Acknowledgments Credit anyone who contributed substantially to the project, and include any permissions for copyrighted materials use.
• Table of contents Provide a guide that includes every report element and the page on which it occurs. Page number front matter with lower-case Roman numerals (i, ii, iii, etc.); page number the rest of the report with Arabic numerals (1, 2, 3, etc.). You can use Word to automatically generate your table of contents.
• Lists of figures and tables Provide a separate guide, like a secondary table of contents, that includes the name and page location of every figure in your report, and another for tables.

Formal reports include every component listed above; an informal report may only include some of them. In some cases, your company may specify which of these components to use and how.

Executive summary and abstract

Your engineering report may include both an executive summary and an abstract, or it may only include one or the other. These elements appear between the front matter and the report body. Write these after you have written and revised the report body.

What is an executive summary?

An executive summary is an overview of the key points in your report. It should summarize the purpose and scope of your work, the methods you used, and your key findings, conclusions, and recommendations [4].

What is an abstract?

An abstract is a short but specific summary of the details you cover in the report’s body. It should briefly mention the purpose and scope of your work, the methods you used, and your key findings, conclusions, and recommendations [5].

What’s the difference between the two?

The difference lies primarily in their purpose and length. The abstract provides a preview of the report’s content meant to entice readers to read the entire report. It is typically less than a page long. The executive summary, on the other hand, provides enough information to allow stakeholders to make a decision without reading the full report. It is typically as long as 10% of the full report [6].

The body of your report is where you provide the details of your work. It is the longest part of your report and falls after the front matter and executive summary and abstract. You will produce the body before any other element of your report, with the possible exception of graphics, like figures and tables.

Your report’s body includes [1] [7]:

• Introduction Summarize your major conclusions and recommendations. Also describe the organization of your report and its scope.
• Summary/background Describe the existing research or activity you relied on to guide your work.
• Methods/procedures Describe what you did and how you did it. Include the equipment you used.
• Results Reveal your research findings. This report component may be combined with the discussion of results.
• Discussion of results Describe what your results demonstrate and why that is important to your audience. Highlight notable trends the results reveal, as well as the limitations and assumptions in your work. This report component may be combined with the results.
• Conclusion Make meaningful statements based on the discussion of results. This report component may be combined with the recommendations.
• Recommendations Provide actionable recommendations based on your conclusions. This report component may be combined with the conclusion.

Back matter

The back matter of a report is its succeeding, supporting components. As its name implies, it appears at the back of the report. You will typically attend to this element last and in conjunction with front matter , after you have written the body and executive summary and abstract .

Your report’s back matter includes [1]:

• References List the references you cited throughout your report. Use your company’s or engineering field’s style guide (note: link to What is a style guide? Which one should I use?) to determine the appropriate format for your reference list.
• Appendices Present detailed information related, but not essential, to your report in the appendices. Some examples of materials appropriate for the appendices, includes data, analysis methods, and equipment details [3]. In some cases, you’ll include all your tables and figures here rather than in the body of the report. Put the appendices in order by their mention in the body of the report.
• Attachments Attach materials appropriate for the appendices that are too large in size to fit the report format. For instance, you may have oversize blueprints that would be unreadable if reduced to the typical 8.5×11 size of a report.

According to Paul Anderson in his book Technical Communication: A Reader-Centered Approach , “Good [formatting] helps readers understand your information, locate information, and notice highly important content” [8]. A successful report is formatted well.

What components should I consider while formatting?

When formatting your report, pay attention to these common components [8]:

• Body text Sentences and paragraphs
• Headings Titles, headings, subheadings
• Headers and footers Recurring components at the top and/or bottom of every page, like page numbers and report title
• Graphics Tables, figures, photos
• Space Empty areas between headers, paragraphs, graphics, and captions

How do I format those components?

Consider these basic principles adapted from graphic design theory when formatting your report [9]. Scroll to the bottom of this page for a rough example of these principles applied to the above components:

• Contrast Use contrasting size, weight, and typeface to establish focus and hierarchy on your pages. For instance, set your top-level headings in a bold, sans-serif, 14 point typeface like Arial; set your body text in a regular weight, serif, 10 to 12 point typeface like Times New Roman.
• Repetition Use the same formatting for every page and similar components on that page. For instance, include page numbers in the same place, with the same formatting on every page (10 point, bold, Arial, at the bottom, center of the pages, for example). Style your body text and headings the same throughout the report (Microsoft Word styles can help you do this easily).
• Alignment Connect every component on a page with a strong visual alignment. For instance, place graphics, like tables or figures, on the left side of the page in alignment with the left edge of the text. Align headings to the left like the body text.
• Proximity Use space to group related items together and separate unrelated items. For instance, place graphics near their mention in the body text. Put less space between a subhead and its related body text; put more space between the bottom of body text and the next, unrelated subhead.

Reference Report examples

Your company likely has numerous examples of reports that include some or all of these elements and their individual components. In addition, examples of formal reports abound in professional journals in your field.

Microsoft Word includes numerous tools and functions that will save you time and hassle, and allow you to consistently format your reports. Visit the links from Where can I find more information about writing effective reports? to learn how to use these time-saving tools and functions:

• Styles Rather than manually styling text, use styles to change the formatting of the same type of text (body, headings, captions, etc.) from one formatting dialog at one time.
• Page numbering and sectioning Instead of manually numbering your pages one at a time, use automatic page numbering and sectioning to organize your report.
• Table of contents creation Instead of manually creating and numbering your report’s table of contents, use automatic table of contents creation to provide access to the organization and contents of your report.
• Graphics Place and resize graphics from programs like Excel or from other text documents to fit your report’s format.

Where can I find more information about writing effective reports?

The IEEE Professional Communication Society’s site provides you with a basic understanding of writing effective reports. Explore other resources to gain more knowledge about this topic.

• Writing an executive summary for engineering reports (vidcast) Watch this 6-minute video that demonstrates how to write an effective executive summary for an engineering report.
• Writing a title page for engineering reports (vidcast) Watch this 4-minute video that demonstrates how to put together an effective title page for engineering reports.
• Report checklist Use this checklist to make sure you’ve addressed every element in your engineering report.
• How to use styles in Microsoft Word to save a lot of work Read this resource that teaches you how to use styles in Word to make your report formatting consistent and efficient.
• Create an automatic table of contents in Word (video) Watch this 4-minute video to learn how to generate an automatic table of contents using styles in Word.
• How to create a table of contents in Microsoft Word Read this thorough resource that shows you how to automatically create a table of contents in Word.
• Table of Contents tips Consult this source that points out some fine points of creating and modifying tables of contents in Word.
• Add page numbers to documents in Word 2007 and 2010 Read this resource that shows you how to add page numbers in both Word 2007 and 2010.
• Word 2003 page numbers Watch this 3-minute video to learn how to insert page numbers in Word 2003.
• How to insert page numbers in Microsoft Word 2003 Read this quick set of instructions for inserting page numbers in Word 2003.
• How to restart page numbers in a Word document section Read this quick set of instructions for sectioning Word documents and page numbering each section differently.
• How to copy a chart from Excel into a Word document Consult this resource to learn how to place and modify Excel charts in Word documents.
• Move Excel graph to Word tutorial (video) Watch this 13-minute tutorial to learn how to place and modify Excel charts in Word documents.
• How to crop and resize an image in Word 2010 (video) Watch this 2-minute video to learn how to crop and resize images in Word.
• Insert and position graphics in Word documents Read this resource to learn how to insert and position graphics in Word.

[1] P.V. Anderson, “Writing reader-centered reports,” in Technical Communication: A Reader-Centered Approach. Boston, MA: Thomson Wadsworth, 2007, pp. 539-556.

[2] E. Cember, A. Heavilon, M. Seip, L. Shi, and A. Brizee. Sections of reports. Purdue Online Writing Lab. [Online]. Available: http://owl.english.purdue.edu/owl/resource/726/05

[3] E. Cember, A. Heavilon, M. Seip, L. Shi, and A. Brizee. Mechanical elements of reports.  Purdue Online Writing Lab.  [Online]. Available: http://owl.english.purdue.edu/owl/resource/726/0 8

[4] Processes for writing an executive summary.  Writing at Colorado State University.  [Online]. Available: http://writing.colostate.edu/guides/page.cfm?pageid=1508

[5] E. Cember, A. Heavilon, M. Seip, L. Shi, and A. Brizee. The report abstract and executive summary.  Purdue Online Writing Lab . [Online]. Available: http://owl.english.purdue.edu/owl/resource/726/07

[6] K. Khan. (2008, Sept. 19). Difference between executive summary, abstract and synopsis. University of Balochistan. [Online]. Available: http://www.scribd.com/doc/55954574/Difference-Between-Executive-Summary-Abstract-and-Synopsis

[7] E. Cember, A. Heavilon, M. Seip, L. Shi, and A. Brizee. The report body.  Purdue Online Writing Lab.  [Online]. Available: http://owl.english.purdue.edu/owl/resource/726/06

[8] P.V. Anderson, “Designing reader-centered pages and documents,” in  Technical Communication: A Reader-Centered Approach.  Boston, MA: Thomson Wadsworth, 2007, pp. 372-398.

[9] R. Williams,  The Non-Designer’s Design Book.  Berkeley, CA: Peachpit Press, 2004.

Purdue Online Writing Lab Purdue OWL® College of Liberal Arts

Informal Lab Reports, Short Memo or Letter Reports

Welcome to the Purdue OWL

This page is brought to you by the OWL at Purdue University. When printing this page, you must include the entire legal notice.

Copyright ©1995-2018 by The Writing Lab & The OWL at Purdue and Purdue University. All rights reserved. This material may not be published, reproduced, broadcast, rewritten, or redistributed without permission. Use of this site constitutes acceptance of our terms and conditions of fair use.

This resource provides guidance on reporting tests and experiments conducted in a variety of lab settings.

In Academic Settings

Short reports are written for teachers who want to evaluate the accuracy and completeness of your work. You may be asked to include some or all of these parts or others not included here:

• Introduction: the purpose, problem, and scope
• Apparatus: the equipment and/or tools used (This section is included only when needed because something beyond the usual apparatus is required.)
• Procedures: the methods (These are described in detail only if asked for or if unusual.)
• Body: the data obtained, discussed and evaluated
• Conclusions and recommendations

In Industry and Government

Short reports are written for readers who need to know the results of your work so that they can make a decision. Include your conclusions and recommendations only if they are specifically asked for. Be as brief as possible, preferably one page or less.

Short Memo or Letter Reports

Use either stationery with the company letterhead or printed forms with standard headings such as To, From, Subject, Date, and other information that a company may wish to include, for example, reference numbers, names of people who receive carbon copies (cc:), and so on. State the subject clearly and concisely, and put the most important words at the beginning of the subject line in the heading.

Introductory statement:

State the general problem first to give the reader a context or “big picture.” Then explain the specific question or task arising from that problem that you will be dealing with. Finally, explain why the report is being submitted or what it is intended to do. This brief, but crucially important overview should usually be no longer than two or three sentences.

Findings or results:

Present your findings clearly and concisely, in whatever method is most appropriate (a list, a table, and so on, with adequate explanation). Arrange your results so that the ones most important to the project or the reader are placed first. Present the rest of your results in descending order of importance. Since your findings are usually the major reason for the memo, this section may be the longest part of the report.

Conclusions and recommendations:

Determine and present the most significant implications or recommendations for action. You may need to put this section before the findings, or you may not need to include this section at all unless it is requested. Company policy usually dictates whether or not this section is included.

Format considerations:

• Use headings and mark your key points so that your readers can survey the contents and can quickly find what they want.
• Place your strongest arguments first when your purpose is to persuade.

Evaluating a Short Memo Report

When evaluating a short memo, the writer should follow a very specific format to keep their document standard. This format includes questions that the writer should ask themselves, the different parts of the memo, headings that should be used as wells as arguments to add. These aspects allow the creation of a short memo to be easy as the formatting will eventually become second nature.

Listed below are the basic questions every report writer should ask himself or herself before writing the report:

• Who will read the report?
• What do they want to know?
• How should the report be structured?

Heading : Lists information such as To, From, Subject, Date, and so on, and states the subject clearly and concisely with the most important words at the beginning of the subject line.

• Is all the relevant information included?
• Is the subject stated clearly and concisely?
• Are the important words first?

Introductory Statement : States the general problem first, then explains the specific question or task being dealt with in the memo, and then explains why the report is being submitted or what it is intended to do.

• Are all three parts of the introductory statement included and stated clearly?

Findings or Results : Presents the findings clearly and concisely with the most important results first. Tables and other information not needed by all readers are, of course, attached separately.

• Are the findings or results clearly indicated and easy to locate on the page?

Conclusions and Recommendations : Presents the significant implications and recommendations for action (if—and only if—conclusions and recommendations have been asked for).

• If the report contains conclusions and recommendations, are they clearly presented and easily located on the page?

Format Considerations: Make headings and mark your key points so that your readers can quickly survey the contents and find what they want.

• Are the headings throughout the report adequate?
• Are key points marked?
• Are your strongest arguments first when writing a persuasive document?

Next-Gen App & Browser Testing Cloud

Trusted by 2 Mn+ QAs & Devs to accelerate their release cycles

• Testing Basics
• Learning Hub
• Test Reports Tutorial
• December 18 2023

What Are Test Reports: With Examples And Best Practices

A complete tutorial that explores test reports, their types and sections, and how to create an effective test report.

Test reports are documents containing a summary of all the test details of software projects, like the environments where QA teams validate the test code, who performs the test, and when and how the test was performed. During testing, it acts as a physical log that records what code was tested, in what configuration, and what bugs were found.

Every software development organization aims to retain customers. For this, it is mandatory to render the best software services and products. In this stage, one realizes the significance of software testing .

In the software testing process, test reporting is a critical phase. If the team implements this phase diligently within the timelines, the test analysis report and feedback will be handy in the entire Software Development Life Cycle (SDLC).

• What are Test Reports?

A software testing report is like a summary of all the tests we did, what we wanted to achieve with them, and what happened during the testing project. It helps us see how well the testing went and figure out why some tests didn't work as expected.

After the software testing team accomplishes the testing work, the team generates the test reports containing information like the details of the testing procedures, the overall quality of the application, the test results, and the identified defects. It is a consolidated document of the summary of all the testing activities.

The other term for a test reporting document is the test closure report. The various project stakeholders read this document. You can generate a test report by ensuring that it has the following features:

• Detailed information: You should include all the details of the testing activities. Although you should concisely mention these details, you should not write an abstract. A detailed yet concise test report enables the stakeholders to form a clear picture of the testing activities in their minds.
• Clarity: When you include information in this document, you should confirm clarity in all aspects of the testing process.
• Format: You should adhere to a standard template for the test report. When it is in a standard format, the stakeholders can quickly review and understand.
• Specifications: You should include all test result specifications with brevity. These specifications should be to the point.

When to Create a Test Summary Report?

The Test Summary Report plays a crucial role in documenting the entire testing process. It's crucial that this report encompasses all vital information and outcomes from each phase of testing. The ideal approach is to compile this report once all testing activities have completed. This ensures that the report serves as a thorough and precise record of the entire testing journey, capturing every significant event and result.

Why are Test Summary Reports Important?

Test reports enable the stakeholders to estimate the efficiency of the testing and detect the causes that led to a failed or negative test report. The stakeholders can evaluate the testing process and the quality of the specific feature or the entire software application. They can clearly understand how the team dealt with and resolved the defects.

Using all the preceding information, they can make product release decisions. In these ways, the data in the test report proves vital for the business.

Various stakeholders; such as product managers, analysts, developers, and testers; read the test report to determine the origin of each issue and the stage at which it has surfaced. Using this report, they can locate the causes of negative test results and thoroughly analyze the cause for the issues, such as weak implementation, unstable infrastructure, mismanaged back end, and defective automation scripts.

After going through the test reports, one can have adequate information to find answers to the following questions:

• Has the team avoided unnecessary testing?
• How is the stability of the tests?
• Do the testers in the team have adequate skills to identify the issues in an advanced stage?
• What value has the testing team accomplished after all the testing activities?

Test reports are essential because they enable monitoring testing activities, contribute to quality improvement of the software application, and make early product releases feasible.

• Benefits of Test Reports

Test reports are helpful in the following ways:

• The relevant stakeholders can get all the updates about the project's status and the software application's quality.
• Based on these updates, the stakeholders can direct corrective measures and amendments.
• Test reports help stakeholders to decide whether to ship the software application to the customer.
• The report acts as a justification for all the efforts of the testing team. After going through the report, the testing team can learn and apply learnings in the future to make testing even more effective.
• The test reports ensure that only quality software applications are provided a release.

Templates of a Test Report

Here are some possible templates for a Test Report.

Template 1:

Template 2:

• Sections of a Test Report

There are various templates for test summary reports. Out of these, you can choose the template that matches your requirements and customize the sections per your project's nature.

The broad categorization of sections of a report is the following.

Document Control

This section consists of two points: the Revision History and the Distribution List.

• The Revision History consists of information such as the date on which the team created the Test report, the date of the previous update, and the updated sections.
• The Distribution List consists of information such as the resources in the testing process, such as the test engineers, test leads, and test managers. The other information concerns those who have reviewed the test report, such as product managers and other stakeholders.

Project Overview

You need to include the description of the project with details, such as the name of the project, the type of the project, the duration of the project, the version of the product, and the description of the product.

Test Objective

You need to include the purpose of the software testing. This consists of the objectives of each testing stage, such as performance testing , security testing, regression testing , UI testing , functional testing , etc.

Further, you can mention the software testing team's several activities as part of the software testing. This test report section shows that the QA team has clear concepts about the test object and the requirements.

Test Summary

One should include information such as the count of the executed test cases , the pertinent data of passed and failed tests, the pass/fail percentage, and comments. A team can present this information more finely using visual representations such as tables, charts, graphs, and color indications.

Included Areas

This section consists of descriptions of the testing areas of the software application along with its functionalities. It is not essential to include every test scenario in the minutest details. You have to include all the areas at a high level.

Excluded Areas

This section consists of the testing areas of the software application that the testing team did not include. You have to mention every such testing area with the specific reason for exclusion. An example of such a reason is restricted access to device availability. It can happen that when the customers know about the excluded areas, they might raise the alarm. This is the main reason to jot down what the QA team needs to test, along with the expectations relevant to that specific area.

Testing Approach

You have to include information about what the testing team has tested and how this team has tested the specific area. Further, you have to mention the testing approaches of the team and the details of the various steps.

Defect Reports

Generally, the bug report has information about all the defects. However, if you include the defects’ information in the test report, it is advantageous for the utility of the test reports. This report comprises information such as the total count of bugs the team has handled during the testing and the current status of these bugs (such as open, closed, and resolved).

The other details are the bugs marked as ‘Deferred,’ the bugs marked as ‘Not a Bug,’ reopened bugs, open bugs of the previous release, new bugs found, and total open bugs. This is a crucial ingredient of the test report because the metrics in this report are adequate for correct decision-making and product improvement.

Platform Details

Currently, the testing team validates the software application across multiple platforms. Due to this, the team tests across various browsers, devices, and OS. You need to include all the platforms and environments related to testing the software application.

Knowledge Management

This consists of details such as the lessons the team has learned during the current testing cycle and a list of issues that need particular attention. This is followed by information about the work of the testing team in ensuring the application’s quality. Also, it details the list of enhancements the company should implement in future testing cycles. Lastly, there are some suggestions or remarks for all the varied stakeholders.

Gross Summary

In this section, you need to include the feedback of the testing team, which is an overall opinion of the application under test. Through this summary, you communicate the details about the critical issues and those issues that are still open to the customer. After reading the summary, the customer can set expectations about the software application's shipping date.

In the case of larger organizations, the above sections of a test report are inadequate. The team should include additional data such as video recordings, screenshots, network traffic, logs, and other pertinent data, which enable the team to implement data-driven decision-making.

The testing team should generate the test report ideally at the end of the testing cycle. The motive behind this time selection is that the team should be able to include information about the regression tests.

However, the team should arrange for an adequate time interval between the date of submission of the test report and the date of shipping the software application to the customer. The reason for having this time interval is to enable the customer and the stakeholders to understand the overall health of the software application and the testing cycle so that the pertinent teams can make the necessary amendments.

After the test report generation, the testing team should share it with stakeholders, the customer, and all the team members. Due to this step, all members can get an overview of the testing cycle, which enables them to conclude about the ways to improve further. This report serves as an explanatory text for the novices on the team.

• Types of Test Reports

Test reports are of the following three types.

Test Incident Report

During the testing cycle, the team enters the defect repository whenever they encounter a defect. This is termed the Test Incident Report . In this report, every defect is associated with a unique ID to facilitate the identification of the incident. Further, the team highlights the high-impact test incidents in the test reports.

Test Cycle Report

In every test cycle, the team plans and runs specific test cases. For each test cycle, the team uses a different software application build. The motive for doing so is that the team expects the software application to stabilize as it passes through the various test cycles.

The team creates the Test Cycle Report, which consists of the following information:

• A summary of all the steps the team has implemented in the test cycle.
• The defects the team detected during the specific test cycle based on impact and severity.
• The progress of the team in terms of the fixed defects from the previous cycle to the current cycle.
• The defects that the team has not fixed in the cycle.
• The observed variations in the schedule or efforts.

Test Summary Report

In the last step of the test cycle, the team recommends whether the product is suitable for release. The team creates the Test Summary Report, which consists of the summary of the outcome of a test cycle. This report includes the following sections:

• The Test Summary Report ID.
• Identification of the test items included in the report with the Test ID.
• The deviations from the test plans and the test procedures, if any.
• The result summary includes all the results with their resolved incidents and solutions.
• A well-rounded assessment and recommendation for the release, including the fit-for-release assessment and release recommendations.

The Test Summary report is of two types:

• The report generated at the end of every phase is known as the Phase-wise Test Summary.
• The final Test Summary Report.

• How to write a good Test Summary Report?

To learn how we can write a good test summary report, let us consider that AB is an online travel agency for which an organization is developing an ABC software application. The software testing team does the following while generating a test summary report.

The team notes all the activities it has done during the testing of the ABC application. Then, it documents the overview of the application.

The ABC application provides services to book bus tickets, railway tickets, hotel reservations, domestic and international holiday packages, and airline tickets. To do all these services, the application has modules such as Registration, Booking, Payment, etc. The team includes all such information in the testing report document.

Now let’s see the steps to create a test summary report for an online travel agency.

Step 1: Create a Testing Scope

The team mentions those modules or areas that are in scope, out of scope, and untested owing to dependencies or constraints.

• In-scope: We completed the functional testing of the following modules:
• User registration
• Registration confirmation
• Ticket booking
• Hotel package booking
• Out of scope:
• Multi-tenant user testing
• Concurrency
• Untested modules:
• The User Registration page that has the field values in mixed cases

Step 2: Test Metrics

Test metrics include the following:

• The count of planned test cases
• The count of executed test cases
• The count of passed test cases
• The count of failed test cases

The usage of test metrics is to analyze test execution results, the status of the cases, and the status of the defects, among others. The testing team can also generate charts or graphs to represent the distribution of defects: function-wise, severity-wise, or module-wise.

Step 3: Implemented Testing Type

The team includes all the types of testing it has implemented on the ABC application. The motive for doing so is to convey to the readers that the team has tested the application properly.

When the QA team receives the build, the team implements smoke testing to confirm whether the crucial functionalities are working as expected. The team accepts the build and commences testing. After the software application passes the smoke testing, the testing team gets the confirmation to continue with the next type of testing.

The team conducts testing not on a particular feature or defect fix but on the entire software application. It consists of defect fixes and new enhancements. This testing confirms that after these defect fixes and new enhancements exist in the software application, the application has rich functionality. The team adds and executes new test cases to the new features.

The team performs system integration testing to ensure that the software application is functioning as per the requirements.

Step 4: Test Environment and Tools

The team notes all the details of the test environment used for the testing activities (such as Application URL, Database version, and the tools used).

The team can create tables in the following format.

Step 5: Learnings during the Testing Process

The team includes information such as the critical issues they faced while testing the application and the solutions devised to overcome these issues. The intention of documenting this information is for the team to leverage it in future testing activities.

The team can represent this information in the following format.

Step 6: Suggestions or Recommendations

The team notes suggestions or recommendations while keeping the pertinent stakeholders in mind. These suggestions and recommendations serve as guidance during the next testing cycle.

Step 7: Exit Criteria

When the team defines the exit criteria, it indicates test completion on the fulfillment of specific conditions, such as the following:

• The team has successfully executed all its planned test cases.
• The team has closed all the critical issues.
• The team has planned the actions for all open issues, which it will address in the next release cycle.

Step 8: Sign-off

If the team has fulfilled the exit criteria, the team can provide the go-ahead for the application to ‘go live.’ If the team has not fulfilled the exit criteria, the team should highlight the specific areas of concern. Further, the team should leave the decision about the application going live with the senior management and other top-level stakeholders.

We have provided a free and easy-to-use Test Report Templates . Check it out now.

Challenges Faced in Creating Test Reports

In the past, the organization used the Waterfall Model of software development, which was relatively simple to create a test report. Organizations use Agile, DevOps, and CI/CD, which have modified the requirements of an efficient test report.

The software testing team faces the following challenges while generating a test report.

Quick release rhythms

During the phase of the Waterfall development cycle, the QA team compiles and summarizes the test report using spreadsheets during the final stages of the development cycle. In those days, there was ample time between two releases. The team could use this time for result compilation, report generation, and decision-making.

After the advent of Agile development and DevOps , this scenario has altered considerably. The team must complete testing at a higher speed. Organizations have to make decisions about quality not in a matter of months but often within some weeks, days, or even hours.

If the stakeholders do not get the feedback in such a timeframe, the organization has to postpone the release or ship it with debatable quality. Here, the challenge is to render feedback about the quality of the software application at a pace that matches the speed of quick-release rhythms.

High-volume, irrelevant data

In the current software testing scenario, test automation enables the QA team to perform more testing. Due to browser and device proliferation, the team can use more devices on more browsers to test multiple software application versions.

The cumulative effect of test automation and device proliferation is an enormous volume of test data . If this high-volume data is actionable, it is useful data. However, the section of this data that is non-actionable is a waste. Another term for this wasted data is ‘noise.’

Nowadays, organizations have colossal testing data. Therefore, they have to decide on valuable and noisy data. The causes of generating noise data are environmental instability, flaky test cases, and other reasons that lead to false negatives, of which the team cannot determine the root cause.

Digital enterprises have to spend time on every failure in the test report. The challenge here is dealing with a high volume of irrelevant testing data while generating the report.

Data from disparate sources

Organizations, specifically large organizations, have a colossal volume of testing data associated with a large count and variety of frameworks, tools, and teams. The sources of this enormous data are disparate, such as from various teams and resources.

This data can be associated with frameworks such as Appium and Selenium . Generating the test report by leveraging such disparate data is the challenge. The only solution, in this case, is to come up with a consistent method to capture and sort this data.

Regardless of the evolution from the Waterfall model to the Agile model, the end goal of creating a test report has remained the same: to procure actionable feedback. The knack is to filter out the false negatives and noise data and concentrate on the authentic issues to eventually ensure a quick mean time to resolution (MTTR).

Subscribe to the LambdaTest YouTube Channel for test automation tutorials around Selenium testing , Playwright , CI/CD, and more

Best Practices for Writing Effective Test Reports

Here are some best practices to follow while creating test reports.

• Close each test execution cycle and then publish the test report.
• Adhere to the standard test report template.
• Include information about all testing cycles to ensure that the stakeholders get a proper and clear picture of the efforts of the testing team.
• Ensure that the information is to the point and can be easily digested.
• Include evaluation metrics, such as schedule slippage, test efficiency, effort ratio, schedule variance, expenses of defect identification, test case adequacy, test case effectiveness, etc.
• Exclude complex technical jargon as several stakeholders need to understand the report.
• Save the test report in a document repository system to ensure its proper maintenance.

Once you generate the test reports, it’s important to share them with stakeholders, customers, and the team to get them an overview of the entire test execution cycle, enhancing their learning and improving further.

Continuous quality cloud testing platforms like LambdaTest have made test reporting much easier. With the LambdaTest Test Analytics platform, all your test execution data can be displayed on one dashboard, allowing you to make informed decisions. By building custom dashboards, you can share metrics specific to your stakeholders, customers, and team and make your dashboards more useful with widgets and modules.

LambdaTest Test Analytics and Observability platform allow users to customize their analytics dashboard according to their testing needs. Additionally, they can now share real-time test execution data within the team with just a click of a button. Doing so will help them close the gap between data, insight, and action, enabling you to make better and faster decisions.

Test reports show what the tester thinks of a product. The test analysis report informs stakeholders about the product's current status and possible risks. It enables teams to identify ways to improve the product through valuable insights and feedback.

Removing irrelevant noisy data is necessary to find bugs quickly and get quality results out of the test report. This will help your team to focus and resolve critical issues that need attention.

On this page

• When to create a Test Summary Report?
• Why Test Reports?
• Test Summary Report Templates
• Challenges in creating Test Reports
• Best Practices
• Frequently Asked Questions (FAQs)

Frequently asked questions

Did you find this page helpful?

Author's Profile

Irshad Ahamed

Irshad Ahamed is an optimistic and versatile software professional and a technical writer who brings to the table around four years of robust working experience in various companies. Deliver excellence at work and implement expertise and skills appropriately required whenever. Adaptive towards changing technology and upgrading necessary skills needed in the profession.

Reviewer's Profile

Salman Khan

Salman works as a Digital Marketing Manager at LambdaTest. With over four years in the software testing domain, he brings a wealth of experience to his role of reviewing blogs, learning hubs, product updates, and documentation write-ups. Holding a Master's degree (M.Tech) in Computer Science, Salman's expertise extends to various areas including web development, software testing (including automation testing and mobile app testing), CSS, and more.

14 Chapters

Automation Testing

The quintessential guide to Automation Testing. This is an in-depth resource covering all aspects of testing.

27 Chapters

Selenium Python

Want to learn automation testing with Python? Check out our step-by-step tutorial on Python with examples!

12 Chapters

Selenium Locators

Here we explore different types of Selenium locators and learn how they are used with different automation testing.

Selenium NUnit

Isn’t it better to use an effective test framework like NUnit on a powerful and scalable Selenium Grid?

10 Chapters

Selenium WebdriverIO

Through this guide, we will learn how to use WebdriverIO, a next-gen test automation framework for Node.js.

Selenium C#

This tutorial will teach how to master Selenium, making your test automation more streamlined and efficient.

Try LambdaTest Now !!

Get 100 minutes of automation test minutes FREE!!

Join our team

View our current job opportunities.

System Integration Partner

Vista Projects specializes in the implementation, configuration, administration, and support of AVEVA’s Asset Information Management suite.

Long-Term Success

We approach each project with the same outlook. Our goal is always to help clients meet their short-term project objectives while also preparing the asset for long-term success.

Intelligent Data Starts with Engineering

Download our brochure about Data-Centric Execution Architecture to learn more.

Media Contact

Are you interested in interviewing someone from Vista, using our logo, or talking to us about speaking opportunities?

Latest Post

How to Write an Engineering Report

• Adam Singfield
• Last Updated August 18, 2016
• Category Technical Writing

No matter what kind of engineer you are, you will eventually need to write an engineering report. This type of technical writing means knowing how to share information about research and analysis and then present it clearly in writing.

Writing a report about engineering services, like those we provide at Vista Projects, means communicating ideas in addition to furthering innovation and improvements. This skill makes you an even more significant asset to your company and allows you to solve problems and create solutions.

What Is an Engineering Report?

An engineering report is a type of technical editing that presents a problem, analyzes it, and offers solutions. It involves collecting and compiling data and ideas, conducting testing, and organizing the information you gained into comprehensible results for the reader.

Students learn to write these reports when they go through their education program, but writing them well involves knowing why you’re writing the technical report. While your purpose for writing technical reports will vary based on your specific field, the structure of all engineering reports remains the same: a summary, the body, and your conclusions.

Writing a report involves communicating a process for fixing a problem to a customer, community, business, or investor. Some engineers copyright their processes. Above all, your report should convey information clearly, offer information backed by evidence, and show why your solution stands out from the competition.

Why Write an Engineering Report?

Engineering report-writing should always focus on helping your firm achieve an objective. That may mean convincing a client to take action based on your solution or showing them how a project will benefit the public.

It may also help persuade your client to choose your company’s design or solution, get funding from investors, or encourage another business to partner with your firm on a project.

Other times, you may only want to inform your audience. For example, you may give your government the information it needs to decide on implementing a policy, show other engineers how to work from your proposed plan, or illustrate project outcomes for stakeholders.

Many students make the mistake of writing reports to show their personal knowledge. You do not want to teach your reader but instead, to offer a summary in writing to help them choose between two companies or engineers.

The body of technical reports should show your reader how your process affects them, include evidence to support your conclusions, and make a case for why your reader should support your ideas.

Do You Write an Engineering Report?

Before you start writing your report, consider the information you want to convey. Are you writing a trend report, an analytical report, or a trip report? Knowing the best way to share your information will help your audience understand your objectives.

Engineering students typically learn to write technical reports in their program, but different types of reports have different approaches. When it comes to report writing, remember these factors:

• Consider your audience
• Keep the proper structure and organization
• Make your writing easy to skim
• Only include pertinent information

The information and sources that you’ll need to compile your technical report will change based on the project. For example, a research report requires detailed information about your topic and the theory surrounding it. It involves citing textbooks, journals, and similar documents.

On the other hand, a site visit report should include the company history and operations, citing annual reports and the company prospectus. Fault reports also have different requirements, as they involve looking into a problem, determining the cause, and recommending an action to fix it.

Report writing means doing research, conducting tests, compiling evidence, and using that information to draw conclusions based on each previous section. Additionally, a strong introduction and summary will draw in your reader, and let them know what to expect.

Engineering reports should allow for selective reading and effective communication. Use headers, numbered lists, bullet points, and figures and tables to do more than explain your points in words. Readers will skim your writing, so make the important parts easy for them to find, such as in these technical report examples .

The Structure of Engineering Reports

Engineering reports follow the same structure. Your technical report should have these components:

• Executive Summary
• Table of contents
• Introduction
• Conclusions and recommendations
• References and appendices

The first few pages of your report are some of the most critical. They show your reader where they can find information throughout the document. Remember, some investors will not read past your executive summary .

Title pages should clearly state the purpose of your writing. Your executive summary should be no longer than two pages, and it acts as a condensed version of your research, conclusions, and recommendations. If your reader wants more information, the table of contents should allow them to find the correct section in seconds.

You have some freedom in structuring the body, but it must make sense and inform the reader while justifying your claims and ensuring that your reader understands the purpose of the writing. By sticking to this structure, you make writing reports simpler and focus on the following content.

Technical Report Overview

Technical reports always contain an introduction that states your report’s purpose and the leading question your research answers. Does it offer information about why your city needs a new bridge or highway? Are you showing an investor why they should put money into your project?

Your technical report overview should also hook your reader. Tell your audience what you investigate and why it’s important. Refer to your client’s request and scope of work in your writing, and relate the information back to the needs of your client, stakeholder, or executive.

Methodology

Your methodology section is often the most involved piece of writing in your report. Here, you talk about how you performed your study and why you approached it the way you did.

This section should show that you have done thorough research and should present your research protocol clearly. Your writing should detail how you got your information and how your methods offer something new to your field. This section should convey confidence in your company’s work so that your reader will, too.

If you used unique or original methods to gain your information and conclusions, you might  consider copyrigh t  for your work. That way, you keep your methods your own, which may help you in future reports and persuade other professionals to work with you.

When writing up the findings and results of technical reports, make sure not to make this section your conclusion. At this point, you should only state the outcome of your research, analyses, and tests. Include graphics to illustrate your results,

Your writing and structure should offer results conducive to the type of report. For example, design reports may evaluate the design of a new building and why it proves more stable than others. Other types of engineering reports, like proposals, will not require you to write a results section, as you are only offering a potential solution at this point.

Your writing will show the reader how you arrived at your final solution to their problem. Technical reports often require you to communicate dense information, so you should use similar language to that which you used in the technical report overview. That allows readers to make connections in your writing and understand how they relate to your report.

Recommendations and Conclusions

Your final section before writing your references and appendices includes your recommendations and conclusions . Here, you expand upon your results and tell the reader what they mean, how they affect the audience or community, and their benefits.

Align this section with your introduction, so your writing allows the reader to again make connections throughout your report. Let your reader know what you plan to do with the new information, and show them why they should care. Your writing may enlighten them to potential benefits like a greater profit, more convenience, higher productivity, or increased efficiency.

Above all, your writing sets out to answer a question. Your recommendations and conclusions are the final pieces in answering that question through research, allowing you to present how your client should respond to the situation.

Check out more  technical writing tips  in our resources section.

Vista Projects is an integrated engineering The process of integrated engineering involves multiple engineering disciplines working in conjunction with other project disciplines to e… services firm able to assist with your pipeline projects. With offices in Calgary, Alberta, Houston, Texas and Muscat, Oman, we help clients with customized system integration and engineering consulting across all core disciplines.

Data-centric Execution

Test Summary Reports Tutorial: Learn with Example & Template

Test Report

Test Report is a document which contains a summary of all test activities and final test results of a testing project. Test report is an assessment of how well the Testing is performed. Based on the test report, stakeholders can evaluate the quality of the tested product and make a decision on the software release.

For example, if the test report informs that there are many defects remaining in the product, stakeholders can delay the release until all the defects are fixed.

Test Report Example

Why Test Report?

The following scenario will show you why we do need the Test Report

Do you know the root cause of this problem? Why does the website still has defects even when your Team has already tested it?

The problem is you ignored the reporting & evaluation phase in Test Management. The boss has no information to evaluate the quality of this website. They just trusted what you said and released the website without knowing its testing performance.

The typical benefits of a test report include:

How to make a good Test Report?

To answer this, you must know –

What does a test report contain?

Project Information

All information of the project such as the project name, product name, and version should be described in the test report. For example, the information of Guru99Bank project will be as follows

Test Objective

As mentioned in Test Planning tutorial, Test Report should include the objective of each round of testing, such as Unit Test, Performance Test, System Test …Etc.

Test Summary

This section includes the summary of testing activity in general. Information detailed here includes

• The number of test cases executed
• The numbers of test cases pass
• The numbers of test cases fail
• Pass percentage
• Fail percentage

This information should be displayed visually by using color indicator , graph, and highlighted table .

Take a look at Test Report of the website Guru99 Bank to know more detail about Test report

One of the most important information in Test Report is defect. The report should contain following information

• Total number of bugs
• Status of bugs (open, closed, responding)
• Number of bugs open, resolved, closed
• Breakdown by severity and priority

Like test summary, you can include some simple metrics like Defect density, % of fixed defects.

The project team sent you the Defect information as following

• Defect density is 20 defects/1000 lines of code average
• 90% defects fixed in total
• The detail of the bugs are described in this Defect tracker here

You can represent the data as following graph

Tips to write a good test report

Test report is a communication tool between the Test Manager and the stakeholder. Through the test report, the stakeholder can understand the project situation, the quality of product and other things.

The following scenario shows you why we need a good Test Report

You co-operate with outsourcing company, its tester after having performed Performance Testing of the website Guru99 Bank, sends you a test report like this

The information of that report is too abstract . It does not have any detailed information. The stakeholder who will read it might be slightly puzzled when they get it. They might ask or have following sets of questions: –

• Why did they not execute 30 TCs that remains
• What are these failed Test Cases
• Doesn’t have any bugs description

To solve that problem, a good Test Report should be:

• Detail : You should provide a detailed description of the testing activity, show which testing you have performed. Do not put the abstract information into the report, because the reader will not understand what you said.
• Clear: All information in the test report should be short and clearly understandable.
• Standard: The Test Report should follow the standard template. It is easy for stakeholder to review and ensure the consistency between test reports in many projects.
• Specific: Do not write an essay about the project activity. Describe and summarize the test result specification and focus on the main point.

For example, to correct the above Test Report, the tester should provide more information such as:

• Project information
• Test cycle: (System Test, Integration Test…etc.)
• Which functions have already tested (% TCs executed, % TCs passed or fail…)
• Defect report (Defect description, Priority or status…)
• Defect Management Process in Software Testing
• 5 Steps to Master Team Management Skills
• TEST Management Tutorials: Complete Training Course
• TestLink Tutorial: A Complete Guide
• 16 BEST Test Management Tools (2024)
• Top 20 QA Manager / Test Lead Interview Questions (2024)
• Test Management in Software Testing PDF for Beginners
• 10 Best Test Management Tools For Jira (2024)

• Testing Docs Templates

Test Report

• Software Testing
• Testing, QA and QC
• Testing vs Debugging
• Verification vs Validation
• Testing Documentation
• Myths about QA
• Functional Testing
• Load Testing
• Stress Testing
• Stability Testing
• Video & Screencasts
• Test Design
• Test Scenario
• Test Strategy
• Traceability Matrix
• Top Reasons being QA
• Myths Breaker
• How to write a good CV
• At the Interview
• Interview Tips
• General Questions
• Ideal Tester
• Technical Direction
• Management Direction

Test Report is needed to reflect testing results in a formal way, which gives an opportunity to estimate testing results quickly. It is a document that records data obtained from an evaluation experiment in an organized manner, describes the environmental or operating conditions, and shows the comparison of test results with test objectives.

If you want to post your own Test Report version, send email to [email protected]

• U of T Home
• Faculty Home

Engineering Communication Program

Results and Discussions

The Results and Discussion sections are the “meat” of most engineering reports. The role that they play in a lab report is obvious; in other types of reports, they can fulfill different purposes. In a design report, the results and discussion may involve an evaluation of the design or method used. In a feasibility or case study, the results and discussion section would involve measuring the feasibility or evaluating the success of one or more solutions. Not all reports, however, will include these components – proposals, for example, will likely not have any results to discuss, since it looks forward to action to be done in the future. A final report, however, might discuss whether or not the project lived up to the objectives, budget and timeline laid out in the proposal.

1. Together or Separate: In writing these components of your report, you are faced with one major decision with significant implications: i) combine the results and the discussion sections, or ii) keep them separate? Both require attention to the organization and division into topics and subtopics.

i. Combining the results and discussion section allows for more coherence, because it allows you to discuss results of a particular test or method immediately after presenting them. However, if you decide to forego the distinction between results and discussion, you will need to divide your section into appropriate subsections, potentially into different topics or tests: for example,

3.1 Composition of Samples A – D from SEM analysis 3.2 Strength of Samples A – D 3.3 Flexibility of Samples A – D

ii. Keeping results and discussion separate , on the other hand, allows you to discuss all of the results at one time. In the above example, it may be more important to discuss the relationships between composition, strength and flexibility of individual samples than it is to compare the features of all four samples. In this case, you may want to hold off on discussing the results until you have presented all of them. The headings for the discussion section, then, may look like this example:

4.1 Relationship between Composition, Strength and Flexibility in Sample A 4.2 Relationship between Composition, Strength and Flexibility in Sample B . . .

2. Presenting Results: involves using a combination of visual aids and prose. Whenever possible, use visual aids such as tables, charts, or graphs to represent results in an easy to read and understand format (See also Components of Reports / Using Visuals in Reports). When using visuals to present results, however, be sure that you do the following:

• Label and title all graphs, charts, and visuals clearly and precisely (Table 1.1: Composition and Strength of Samples A – D)
• Introduce the results and visuals in the body of the report (Table 1.1 (below) presents the composition and strength of the samples as determined by the SEM).
• Use sentences to highlight the key result (As seen in Table 1.1, Sample A showed the highest carbon content, and was also the strongest)

In-text or Appendices? In presenting results, you also need to be selective: some material may be more suited to an appendix than the body of the report itself. When making the decision to include results in the body of the paper or to place them in the appendix, you should ask yourself whether or not the information is pivotal to the discussion and understanding of the conclusions of the report. In the above example, the calculations used to determine strength and flexibility numbers may not play a significant role in the discussion; in that case, they can be placed in the appendix, with possibly one sample calculation placed in the body of the report. If you do include appendices in your report, be sure to refer to them in the body of the report: for example, “(See Appendix 3.1.1 for derivation of strength numbers for samples B-D.)”

3. Conducting Discussion: There are two key elements to discussion: analysis and interpretation. The difference between these two elements is subtle, but both aspects are essential for a complete understanding of the material (See also Types of Documents / Lab Report for genre specific instruction on results / discussion and particularly (on page 3, questions you might ask to fill out your discussion section).

Both analysis and interpretation involve drawing conclusions from the data presented in results. In doing either, be sure to clearly link your claims to specific sets of data, and logically explain how the data supports your claim.

Analysis involves explaining the results and identifying the conclusions you can draw from them. This can involve highlight key results and placing them in the context of other results, as in the below example.

The results for Sample A are as expected, given its composition (75% poly para-phenylenetere-phthalamide, as seen in Figure 3.1. As shown in Tables 3.2 and 3.3, Sample A was both the strongest and most flexible material. These features are typical of a composite with a high level of poly para-phenyleneterephthalamide content [1].

In the above example, the claim is that the results for Sample A are expected, given its composition. The data that supports that claim (from Figure 3.1) is that Sample A is the strongest and most flexible material, and that Sample A is made up of 75% poly para-phenyleneterephthalamide. The logical explanation is that this composite material is known to be flexible and strong (from source [1]).

Interpretation involves explaining the significance of these conclusions, identifying the potential limitations of the experimental method and their effect on the results, and accounting for any potential errors. The below example identifies what the results and the conclusions drawn from them might mean in a wider context:

Of the four samples, Sample A is best suited for use in protective clothing applications. Its high strength allows it to provide sufficient protection while its malleability allows it to be shaped to the contours of the human body.

This second example, below, identifies a potential limitation of the method, and how they might cast the above conclusion into doubt. Finally, it proposes future work that might help remove this limitation.

However, the way that we evaluated flexibility -measuring the amount of rotational stress before breakage – may not accurately reflect the manufacturing process for the protective clothing or usage patterns. Accounting for this application would involve measuring more and different types of stresses and their impact on the material.

Reporting potential sources of error is an important part of labs and research projects. However, students often include a list of possible errors without a sense of a) their potential impact on the results b) the likelihood that they played a role in the results, and c) how to avoid them in future studies, as in the below example:

Some potential sources of error are: human error, precision of measurements, testing the same sample for strength and flexibility, etc.

A better account of potential sources of error in this experiment might state the following:

Errors in the measurement of material flexibility may have resulted from our testing method. In all but one case, we tested strength and flexibility on the same sample of the materials. Both tests involved applying stress to the samples. Our measures of flexibility in samples B, C, and D may be lower than actual because of the stress applied to sample beforehand. We were able to obtain two pieces of samples A, and tested strength on one and flexibility on the other. While the effect of testing both properties on one sample is unknown, it is likely that applying strength testing may have reduced the flexibility of the material or made breakage more likely. Unfortunately, we only had access to one sample of B-D.

© 2024 Faculty of Applied Science and Engineering

• Accessibility
• Student Data Practices
• Website Feedback

How to Write Engineering Report

• First Online: 11 November 2021

Cite this chapter

• Yongsheng Ma 3 &
• Yiming Rong 3  

777 Accesses

An engineer’s work requires their mastery of the art of effective technical communication. An engineering report is a key form of written communication that is a direct reflection of the engineer’s knowledge of a particular subject. A well written report cannot cover up poor engineering; however, a poorly written report can be detrimental to otherwise excellent engineering work.

Technical writing is a continuous process of learning, carefully gathering, sifting, organizing, and assessing, all while trying to craft something that makes sense for a user. —Krista Van Laan, The Insider’s Guide to Technical Writing [Goodreads 2020] Contextualization lies in bringing out the right messages from the abundant content; in sandwiching the subject between the background of information and the foreground of its utility. —Suyog Ketkar, The Write Stride [Goodreads 2020]

This is a preview of subscription content, log in via an institution to check access.

Access this chapter

• Available as PDF
• Read on any device
• Instant download
• Own it forever
• Available as EPUB and PDF
• Compact, lightweight edition
• Dispatched in 3 to 5 business days
• Free shipping worldwide - see info
• Durable hardcover edition

Tax calculation will be finalised at checkout

Purchases are for personal use only

Institutional subscriptions

Author information

Authors and affiliations.

Department of Mechanical and Energy Engineering, Southern University of Science and Technology, Shenzhen, Guangdong, China

Yongsheng Ma & Yiming Rong

You can also search for this author in PubMed   Google Scholar

Corresponding author

Correspondence to Yongsheng Ma .

Rights and permissions

Reprints and permissions

Copyright information

© 2022 The Author(s), under exclusive license to Springer Nature Switzerland AG

About this chapter

Ma, Y., Rong, Y. (2022). How to Write Engineering Report. In: Senior Design Projects in Mechanical Engineering. Springer, Cham. https://doi.org/10.1007/978-3-030-85390-7_15

Download citation

DOI : https://doi.org/10.1007/978-3-030-85390-7_15

Published : 11 November 2021

Publisher Name : Springer, Cham

Print ISBN : 978-3-030-85389-1

Online ISBN : 978-3-030-85390-7

eBook Packages : Engineering Engineering (R0)

Share this chapter

Anyone you share the following link with will be able to read this content:

Sorry, a shareable link is not currently available for this article.

Provided by the Springer Nature SharedIt content-sharing initiative

• Publish with us

Policies and ethics

• Find a journal
• Track your research

Traffic engineers build roads that invite crashes because they rely on outdated research and faulty data

Professor of Civil Engineering, University of Colorado Denver

Disclosure statement

Wes Marshall receives funding from the US Department of Transportation's University Transportation Centers program and various state transportation departments.

View all partners

“Can you name the truck with four-wheel drive, smells like a steak, and seats 35?”

Back in 1998, “The Simpsons” joked about the Canyonero, an SUV so big that they were obviously kidding. At that time, it was preposterous to think anyone would drive something that was “12 yards long, two lanes wide, 65 tons of American Pride.”

In 2024, that joke isn’t far from reality.

And our reality is one where more pedestrians and bicyclists are getting killed on U.S. streets than at any time in the past 45 years – over 1,000 bicyclists and 7,500 pedestrians in 2022 alone.

Vehicle size is a big part of this problem. A recent paper by urban economist Justin Tyndall found that increasing the front-end height of a vehicle by roughly 4 inches (10 centimeters) increases the chance of a pedestrian fatality by 22% . The risk increases by 31% for female pedestrians or those over 65 years, and by 81% for children.

It’s hard to argue with physics, so there is a certain logic in blaming cars for rising traffic deaths. In fact, if a bicyclist is hit by a pickup truck instead of a car, Tyndall suggests that they are 291% more likely to die.

Yet automakers have long asserted that if everyone simply followed the rules of the road, nobody would die. Vehicle size is irrelevant to that assertion.

My discipline, traffic engineering , acts similarly. We underestimate our role in perpetuating bad outcomes, as well as the role that better engineering can play in designing safer communities and streets.

Millions of road deaths

How bad are the bad outcomes? The U.S. has been tracking car-related road deaths since 1899. As a country, we hit the threshold of 1 million cumulative deaths in 1953, 2 million in 1975 and 3 million in 1998. While the past several years of data have not yet been released, I estimate that the U.S. topped 4 million total road deaths sometime in the spring of 2024.

How many of those are pedestrians and bicyclists? Analysts didn’t do a great job of separating out the pedestrian and cyclist deaths in the early years , but based on later trends, my estimate is that some 930,000 pedestrians and bicyclists have been killed by automobiles in the U.S.

How many of those deaths do we blame on big cars or bad streets? The answer is, very few.

As I show in my new book, “ Killed by a Traffic Engineer: Shattering the Delusion that Science Underlies our Transportation System ,” the National Highway Traffic Safety Administration calls road user error the “ critical reason” behind 94% of crashes, injuries and deaths .

Crash data backs that up.

Police investigate crashes and inevitably look to see which road users, including drivers, pedestrians and cyclists, are most at fault. It’s easy to do because in almost any crash, road user error appears to be the obvious problem.

This approach helps insurance companies figure out who needs to pay. It also helps automakers and traffic engineers rationalize away all these deaths. Everyone – except the families and friends of these 4 million victims – goes to sleep at night feeling good that bad-behaving road users just need more education or better enforcement.

But road user error only scratches the surface of the problem.

Who creates dangerous streets?

When traffic engineers build an overly wide street that looks more like a freeway , and a speeding driver in a Canyonero crashes, subsequent crash data blames the driver for speeding.

When traffic engineers provide lousy crosswalks separated by long distances , and someone jaywalks and gets hit by that speeding Canyonero driver, one or both of these road users will be blamed in the official crash report.

And when automakers build gargantuan vehicles that can easily go double the speed limit and fill them with distracting touchscreens , crash data will still blame the road users for almost anything bad that happens.

These are the sorts of systemic conditions that lead to many so-called road user errors. Look just below the surface, though, and it becomes clear that many human errors represent the typical, rational behaviors of typical, rational road users given the transportation system and vehicle options we put in front of them.

Look more deeply, and you can start to see how our underlying crash data gives everyone a pass but the road users themselves. Everyone wants a data-driven approach to road safety, but today’s standard view of crash data lets automakers, insurance companies and policymakers who shape vehicle safety standards off the hook for embiggening these ever-larger cars and light-duty trucks.

It also absolves traffic engineers, planners and policymakers of blame for creating a transportation system where for most Americans, the only rational choice for getting around is a car .

Understanding road behavior

Automakers want to sell cars and make money. And if bigger SUVs seem safer to potential customers, while also being much more profitable , it’s easy to see how interactions between road users and car companies – making seemingly rational decisions – have devolved into an SUV arms race.

Even though these same vehicles are less safe for pedestrians, bicyclists and those in opposing vehicles , the current data-driven approach to road safety misses that part of the story.

This can’t all be fixed at once. But by pursuing business as usual, automakers and traffic engineers will continue wasting money on victim-blaming campaigns or billboards placed high over a road telling drivers to pay attention to the road .

A better starting point would be remaking the U.S.’s allegedly data-driven approach to road safety by reinventing our understanding of the crash data that informs it all.

The key is starting to ask why. Why did these road users act as they did? Why didn’t they follow the rules that were laid out for them? Bad road user behavior shouldn’t be excused, but a bit of digging below the surface of crash data unearths a completely different story.

Figuring out which road user is most at fault may be useful for law enforcement and insurance companies, but it doesn’t give transportation engineers, planners, policymakers or automakers much insight into what they can do better. Even worse, it has kept them from realizing that they might be doing anything wrong.

• Urban policy
• Civil engineering
• Pedestrians
• Car accidents
• Sustainable cities
• Transportation policy
• Safe streets
• Bicycle safety
• Motorcycles

Stephen Knight Lecturer in Medieval Literature

Postdoctoral Research Fellowship

Social Media Producer

Dean (Head of School), Indigenous Knowledges

Senior Research Fellow - Curtin Institute for Energy Transition (CIET)

Klay Thompson to join Team Bahamas in Houston for Olympic training camp: Sources

As a decision on his NBA future looms, Klay Thompson will join the Bahamian national basketball team for its training camp in Houston this week, sources briefed on the situation told The Athletic . However, he is not expected to get clearance and compete for the Bahamas in the Olympic qualifier this summer, those sources said.

Advertisement

Thompson, who won a gold medal with Team USA in 2016, would need to receive an official release from USA Basketball and approval from FIBA in order to be cleared to play in the Olympic qualifiers and further competition for Team Bahamas, which isn’t expected to happen.

The timing is also tricky. The Bahamian national team is flying to Greece for two exhibition games against Montenegro on June 25 and Greece (and possibly Giannis Antetokounmpo ) on June 27, followed by the Olympic qualifying tournament in Spain beginning July 2.

Free, daily sports updates direct to your inbox. Sign up

That, of course, is in the heart of NBA free agency, which officially begins June 30. Thompson is one of the most high-profile names on the market and his future with the Golden State Warriors remains unsettled. For the first time in Thompson’s career, he has shown an appetite to explore external options. There remains mutual interest between Thompson and the Orlando Magic , according to league sources. The Warriors have made clear they want to bring Thompson back at the right price and in the right role.

Klay Thompson intends to test free agency, per @ShamsCharania . "Thompson is open to all external options in free agency coming up.” 🎥 @RunItBackFDTV pic.twitter.com/NVF5WvUp6f — The Athletic (@TheAthletic) June 17, 2024

But even Thompson’s presence at training camp is expected to be a symbolic moment at a signature time in the history of Bahamian basketball. It won its way to this stage last summer in Argentina, upsetting the host country behind big performances from Eric Gordon , Buddy Hield and Deandre Ayton .

Thompson, whose father (former NBA player Mychal Thompson) was born in the Bahamas, watched and supported from afar. Additionally, Anta — the sporting goods company that sponsors Thompson — will sponsor the Bahamian team and will also provide gear.

Gordon, Hield and Ayton are expected to compete again this summer. It’s possible Kai Jones , another NBA player and former first-round pick, joins the team. The Bahamians also have a pipeline of young talent. V.J. Edgecombe, a projected 2025 lottery pick, will be at training camp. So will AJ Storr, a guard at Kansas, and Donavan Freeman, a top prospect attending Syracuse next fall.

This is a program built and operated by head coach Chris DeMarco, a longtime Warriors assistant coach who is close to Thompson, and LJ Rose, an executive with the Houston Rockets who serves as the director of operations. Thompson’s brother, Mychel, is part of the coaching staff.

The Bahamians begin Olympic qualifying play against Finland and Poland on July 2 and 3. It’s a six-team bracket with Spain, Angola and Lebanon composing the other pod. The winner of the six-team pool makes the Olympics .

Required reading

• How USA Basketball became a powerhouse, changed the Olympics and sparked the WNBA
• USA men to open 2024 Olympics against Nikola Jokić’s Serbia; American women tip off tournament vs. Japan
• LeBron James, Kevin Durant, Steph Curry headline USA Basketball roster for 2024 Olympics

(Photo: Alex Goodlett / Getty Images)

Get all-access to exclusive stories.

Subscribe to The Athletic for in-depth coverage of your favorite players, teams, leagues and clubs. Try a week on us.