Your Project Name

Testing for Name of Project You are Testing

??/??/04, Version major.minor

Instructions

This is a testing report template for CS169. Each team must send a copy of this completed document to cs169@cory.eecs.berkeley.edu by 5pm on the due date. The subject line of the email message must contain only the word “proj7”.

Your group has been assigned to perform testing for one of the other projects (the same team for which you reviewed the design documents). The purpose of this assignment is twofold:

· To give you the experience of being a tester on code you do not fully understand and cannot change. This can be a frustrating and challenging job, and not enough software developers appreciate it.

· To give concrete feedback to the group you are testing for, at a time when it may still have some effect on the final version of their project.

You will be testing the same project for which you did the design review earlier in the semester. These assignments are repeated at the bottom of this page. It is up to you to contact the group you are testing for and arrange to get access to their system. We do not expect you to do more than manual testing. The group developing the project is responsible for doing any automated testing of their project. Your role is to be a proxy for an actual user. You should use the system and report any problems; your grade for this assignment will be based in part on how thoroughly you managed to manually test the project.

At your turn, you must give access to your code to the group who is doing the testing for you. You must send email on Wednesday November 24 to the TA in charge of your project with complete instructions on how to download/install/run the code. The TA will then forward this email to the team that will test your code. Teams that do not provide access to their code in a timely manner will be penalized.

Summary

Here you should give a summary of your findings. The most serious problems you discovered, or the fact that there were none, goes here.

Findings

Here you should give the detailed list of your findings. A “finding” can be a bug, something that is unclear, inconsistencies, features that appear to be unimplemented, or any other aspect of the system that affects usability for the purpose for which it is being built. For example, you may wish to comment on installation, the documentation (including on-line “help”), the user interface, performance, (mis)behavior on various kinds of input or user actions, scalability, etc. This list of areas is a guide; you may add or change the areas if they seem more appropriate for the project you are testing.

Each finding should contain three things: a description of the problem, the severity level, and any suggestions or comments. Use the three severity levels: severe (fatal problem), moderate (much better if this is fixed than not in the current version), minor (worth fixing eventually, but probably not now). Suggestions are for conveying information beyond the description that may not be immediately apparent to someone reading the document. For example, if you suspect that a particular problem is the result of a race condition, you would put that hypothesis in the suggestions section of the finding. Your suggestions can be empty and should not restate the obvious (e.g., if you report that a feature is unimplemented, please don’t bother to suggest “implement the feature”).

Check out http://inst.eecs.berkeley.edu/~cs169/handouts/teams.txt to get contact info for a team.