CS130 Spring 2009 Project Assignment 5

CS 130: Software Engineering, Spring 2009: Project Assignment 5

Project Name

For the purposes of this assignment, we number the projects as follows:

Group 0: uKuda
Group 1: FlowersExpress
Group 2: WebSurvey
Group 3: iCycle
Group 4: OpenArenaConfig
Group 5: Hancock
Group 6: Pipeline
Group 7: YourCoolFriend

List updated according to Chuong's list.

Assignments: Project i reviews the project i+1 (mod 8)

Instructions

This is a testing report template for CS130. Each team must submit a copy of this completed document by 11:59pm on 6/2/2009. Your group has been assigned to perform testing for one of the other projects (the same team for which you reviewed the design documents - look above). 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 quarter. These assignments are repeated at the top 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 an email by 6:00pm on May 27 to the team who has reviewed your project (cc the TAs) with complete instructions on how to download/install/run the code. (This could for example, be a special account on your server.) Teams that do not provide access to their code in a timely manner will be penalized. If your requirements and design documents have changed since the design review, send them too to your testing team.

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 help and user manuals), the user interface, performance, (mis)behavior of various kinds of inputs 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
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, do not bother suggesting "implement the feature").