Hey Michael, In Project Acceptance test there is a section called test analysis report. "The Test Analysis Report lists the functions and performance characteristics that were to be demonstrated, and describes the actual test results". Does this mean we do this part after conducting the tests or make prediction of the test results. Cheers

I have a similar, related question - for the test description part, do we need to have all the information regarding input data, output data, procedures (i.e. a test script) in there as well? Or can we just have a description of what the test will cover, and then update the extra information in a later sprint?

"Devarsh Patel" <22*6*4*3@s*u*e*t*u*a*e*u*a*> wrote: That is at the end looking back; what you need now are those Acceptance Tests, agreed between the Team and the Client, that will form the basis of "accepting" the product (in this case the mark for the tests passed - see Sprint 3 description). Cheers MichaelW 👨‍🎨

"Mitchell Otley" <23*7*7*5@s*u*e*t*u*a*e*u*a*> wrote: Hi Mitchell, Rephrasing what I said in reply to Devarsh's question, the set of tests should be what the client wants to see to convince themselves that that system does what they requested it to do. BTW, the Team should, independently, put in place systematic lower level (ie module level) testing as well. The client may, or may not, be interested in that level of detail, but it will make it more certain that everything will work, and the embarassing, "hold it while we fix this" moments are avoided. Cheers MichaelW 👨‍🎨 Cheers MichaelW

Hey Michael, Does this mean I should leave the test analysis report till sprint 3 or do it now? Thanks

"Devarsh Patel" <22*6*4*3@s*u*e*t*u*a*e*u*a*> wrote: Hi Devarsh, Literally, Yes; The report can only be about how tests went once the product has been delivered. However, the structure of the report, and the tests it is to cover, need to be agreed with the Client now. Cheers MichaelW 👨‍🎨