Project report #3

As with reports #1 & #2, the content of your intermediate reports will depend on your selected development methodology and on the milestones you laid out in your project plan (including any updates you have made to it). Remember that their purpose is to provide visibility to the client and demonstrate whether or not your project is on track. So, the outline of this report will be similar to the previous report #2, but now you should be able to provide more information about the status of your milestones, deliverables, and code development.

Additionally, your third report must document the state of testing in your project. This documentation should include:

• Your test plan. After reading your test plan, your client should understand:
  • What styles and scopes of tests will cover your changes, and how thoroughly you aim for your changes to be covered
  • The extent to which tests may be automated, as well as any infrastructure requirements for “large” tests
  • Where implementing and conducting tests fall in the project’s schedule (hint: “at the very end” is not recommended)
• A summary of the current state of testing in the pre-existing system you are enhancing; for automatable tests, report a coverage metric
• Preliminary results from user testing your UI changes (you did include user testing in your test plan, right?). You should start recruiting users for testing as soon as you have a UI prototype ready, and you should be able to report on the results of at least one round of user testing by the time you submit this report. You should include a summary of your user testing process and results, including any feedback you received from users and how you plan to address that feedback in your development process. Students from other teams can participate as users. Recruit at least 3 users for testing.

Grading: This report will be graded based on the completeness and quality of the above elements, as well as the overall clarity and professionalism of the report. The report should be well-organized, clearly written, and free of spelling and grammatical errors. We will also be looking for evidence of progress towards your milestones and deliverables, as well as a clear plan for how you will continue to make progress in the next phase of the project. You may lose points if your report does not include all of the above elements, if it is poorly organized or written, or if you did not achieve your milestones or deliverables without a clear explanation of why and how you plan to get back on track, or if your code repository contributions do not follow proper software engineering practices (e.g., if they do not include clear commit messages, if they do not demonstrate that all team members are contributing, or if they do not follow the branching strategy outlined in your project plan). You may also lose points if you did not address any client feedback received since the last report, or if you did not update your risk analysis to reflect any new risks that have been identified since the last report.