5

I've worked in QA for a number of years now and not once have I (personally) created/generated any sort of report, maybe its just where I've worked has never required it. Browsing the market I notice often references to quite a generic "Provide reports on testing etc".

My question is, what exactly are the reports that tend to be generated? # of defects? # of defects closed? etc because this to me seems handled more so by the QA Lead

Looking for some understanding on this

5

This one seems to have two parts so I'll break it out like that.

Test Leadership/Management Reports:

  1. Functional Test Report (RTM*)
  2. Regression Test Report (RTM* sometimes combined with functional report)
  3. Interface Test Report (RTM* optional depending on interfaces)
  4. Security Test Report (RTM* optional depending on security requirements)
  5. Performance Test Report (RTM* optional depending on performance requirements/needs)
  6. Failure/Defect Report (Often embedded inside the corresponding report listed above but delineates failures and fixes including defects and during which type of test it occurred.
  7. Test Readiness Review Package (functional/regression/boundary/interface/performance/security/etc...) usually to justify software is ready to release. This takes many different forms, but it usually entails all the test reports summary rollup into the big picture as is the minimal test deliverable to accompany software releases. The nuances often depend on the management processes, the application under test, and the quality needs.

Individual Testers Reports/Expectations:

  1. Test Execution runs including pass/fail and any defects found. This is for any test type being executed.
  2. Full defect articulation in approved ticketing system
  3. Test Case Reviews by peers with audit trail for the review taking place
  4. RTM* to test case mapping to ensure that all requirements are met via test cases

*Requirement Traceability Matrix - Requirement definition varies depending on the Development Methodology (waterfall - traditional requirement text, SCRUM - backlog items with acceptance criteria, Kanban - ticket description, etc...)

In Summary: Follow your leadership/management direction, but every good QA engineer keeps track of his or her work, results, and logs defects accordingly. Whatever format the tracking takes place a manager should be able to get the update on the software test status with enough details to meet the expectations of assigned work. Don't be caught in the "I think I did that" or "I think I may have tested that enough" situation. If your project company is really lax in this fine, but it would be good for a career point to be aware of the goal of the reports in the industry.

  • 1
    To add to this great response, it really depends on the type of environment you're involved with. For example, being in an Agile one you wont have the time dedicated to all of the above. Thus from the perspective of a Tester(not Lead/Management) you'll only be required to do the Sprint Release notes and or prepare a document for the Review/Show'n'Tell part that might as well be a bunch of Videos displaying the work done on the product. Also at the end of a project you will most likely be asked to add/review the Hand-over documentation. – AndreiT Mar 22 '17 at 8:24
  • Thanks, I have actually seen videos done that worked very well in demonstrating the work with SCRUM reviews. In general I think the idea is to "demonstrate" instead of video, but I have seen it either way with great success. – mutt Mar 22 '17 at 14:51
6

What they mean by "Provide reports on testing" is creating a record of the execution of tests (manual or automatic), what build is being tested and the results of the tests. Any deviations from the test plan should be documented as well as any unexpected behavior.

The specifics of what the report should contain are highly dependent upon the business needs of the company. The idea is to have proof that the approved test plan was executed successfully.

In the case of highly regulated industries like medical or transportation a test plan could require tracking screen captures of every test point regardless of success or failure.

I've also worked places where all that was expected of QC was to report bugs and sign off on builds before release.

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.