I would like to propose that you consider what is needed to support an opinion that the quality of what is being delivered is "Good Enough".
In as much as we try to develop systems in general with the end user in mind, asking this question helps you to design the type of data you need to collect.
I have found that the generic answers that we would typically get can't really be answered. Questions like "How's the testing going?", "How much testing is left to do?", "Why does it take so long to test a website for God's sake???" aren't entirely helpful.
I try to help the person posing the question to better understand what it is they want. How much testing is left to do can become, "Have we covered all of the features in the software?", "How many tests are left to run?", "How much regression testing do we need to do before we can ship?", "Have all of the bugs that were fixed for the release been closed as a result of testing?"
Answering those type of questions means we cannot get away with saying things like "Testing is going well", "We're nearly finished", "Well if they didn't deliver the code so late we'd be able to get home on time for my Son's birthday party and I wouldn't be here waiting to find out if the build will even work.....".
Instead we can say, "Of the 10 stories, 4 have met their acceptance criteria, although we have to execute a performance test run on those stories, we expect it to take 2 working days to have the results. The 6 other stories have not met their acceptance criteria and we are currently reviewing that with the Product Owner. We have identified 20 additional tests across those 6 stories that should be executed based on our understanding of unspecified integration requirements that arose as the we tested the stories. All of this data is present in Jira, attached to each Story as a Testing sub-task."
AS I said at the start, it is more important to know how you want to tell the story and how the Product Owner wants to hear it. That will determine the data you need to capture.
At the very least your data needs are simply:
- Story
- Acceptance Criteria
- Test Executed
- Test Type
- Status of Test
- Bugs Found
After that you start to add elements that allow you to extend your reporting:
- Product Feature
- Risk
- Priority
- Log Data
- Environment
- ..... You get the picture :)
When you can break down the various activities that are carried out while testing the product, you will see what are the most important type of testing you need to execute.
Please note: I have studiously avoided referring to test cases, scenarios, scripts etc. The reason is simple. Knowing what you need to collect, when you collect it and how you collate it will dictate the form of the testing documentation you need.
Apologies if I meandered a bit.