I'm doing a school project which requires us to create a computer application and then write documentation; therefore I have to write testing documentation, I already have a of test plan (Validate all input and test all features) but how do I present the testing results in my project (e.g. table etc.)?

  • How are you performing your testing? Is it manual or automated? – Bernard Feb 11 '12 at 14:59
  • 2
    I think it would help if you shared your test plan with us. – yannis Feb 11 '12 at 15:00
  • I'm doing manual testing, the test plan is very simple try all features & test validation of all data input – Samantha Catania Feb 11 '12 at 15:02
  • Samantha edit your question, and add all relevant clarifications there, not in comments. Also since this is a school project, you should tell us a bit about how you are thinking of presenting the test results, so people won't misunderstand your question as asking us to do your homework for you. – yannis Feb 11 '12 at 15:11
  • 3
    This question might be a better fit for the Software QA & Testing SE site. – Bernard Feb 11 '12 at 15:20

I would consider reporting various test coverage metrics. This will show that your tests are correctly exercising the full functionality of your application. Although, coverage metrics are like any statistics - they need to be clearly explained as they can be reported in mis-leading ways.

See types of coverage metrics on Wikipedia.

You can gather coverage metrics for applications that are tested both my manual and automated testing techniques.


The information that should be included in a test report includes:

  • a summary of test results
  • the test ID number and the result of that particular test
  • any problems encountered in testing
  • times when the test procedure was deviated from

Since you are performing manual tests, each of your tests should be documented somehow, even if it's as simple as a numbered list of steps and what is expected to happen after each result. Every test should have a unique identifier that you can use to refer to it.

A test report that covers an entire suite of tests typically summarizes the results, including information such as the number of tests run, perhaps even identifying the name of the test suite or a listing of the tests executed. If there is only one test executed, then this often isn't needed as it's not necessary to summarize a single test.

For every test executed, identify the test by its identifier, note any problems or deficiencies in your testing plan (useful for identifying key problems that lead to changes in the test plan), and the final result of each test as a pass/fail. Depending on the specifics of the test, it might be useful to also note what caused the failure - what was the actual output, what error occurred, and so on.

How you format it depends on the nature of the data. A summary is best represented textually, but it could be represented by a pie or bar chart that shows the end result of various tests in terms of passing or failing. Specific test results are typically binary (pass/fail), but it's also useful to capture some kind of notes about why they failed. The testing reports that I've seen are typically in document format, but often contain tables. If you have large numbers of tests and need to easily produce graphs and charts, spreadsheets might be more useful.


Metrics are your friend here.

How many passes or cycles of tests did you do? What percent of tests passed or failed? Track defects by severity over time. How many defects were found in the wrong phase? (UAT finding defects that should be caught on unit testing) how many design or requirements changes were found in each phase?


Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.