This is a group assignment. READ THIS ENTIRE ASSIGNMENT OVER CAREFULLY BEFORE MEETING WITH YOUR GROUP!.
Each group in the class is to hand in one separate assignment. You can delegate the individual parts of the assignment to a subset of the group members, but it is a good idea for all group members to read over the entire completed assignment before one of the members hands it in to webct.
In this assignment, your group will prepare for coding by thinking about unit testing and taking one last look at the UML Class Diagram. Your project report must be of high quality and typed. The entire assignment, i.e. the report, must be submitted as one pdf file. If you do not have pdf writer software, there is a good free one called CutePDF at: http://www.cutepdf.com. Join the pdf files for the title page, class diagram, sample test cases, test driver and test stub and gantt chart together into one large, neatly organized pdf that the teaching assistant can print off in order to grade your report.
Your hand-in should consist of the following things (see below for more details):
This section should include a revised and updated version of the UML class diagram submitted for group assignment 2. Your diagram should capture ALL the systems functionality as specified in the requirements specification document. In addition, your diagram should include details such as attribute type, method parameter and return type, as well as identify which attributes and methods are public, private, etc. In order to make it easier for your teaching assistant to evaluate your new UML class diagram, make sure to use a different colour and/or font and/or weight in your diagram to distinguish all the updates you have made to the new class diagram versus the class diagram you submitted for group assignment 2.
This testing section consists of 2 parts:
PART 1:
In part 1, you should create a test plan consisting of a set of test cases need to completely test the system in response to users performing the following tasks (NOTE, make sure your test plan is clear, easy to read and well organized):
- An administrative user adding a bonus question
- A administrative user user indicating who was eliminated for a given round
- A player (blackberry user), in the first week, picking which contestant will win the whole game
Each of the above tasks will likely require more than one test case in order to adequately test the task. Each test case must have the following layout:
- A unique ID
- A descriptive title that indicates its purpose
- A reference to the related requirement(s) in the requirements documentation
- A description of steps need to carry out the test including a sample input.
- Expected output which tells the tester how the system should behave in response to the instructions.
- Click here for a sample test script we used in 2003, to see some sample test cases but remember that your test cases MUST also include a reference to the related requirement, so a sample test case SHOULD look like this:
ID: 1
TESTING: Admin User adding a new user, invalid user id
REFERENCES: Requirement 4.c.1.1
TEST CASE:
1. At unix prompt type: java UWOBoggle -admin
2. Select Add user
3. Enter abcde for user id
EXPECTED OUTPUT:
Error --> Message: Invalid user id, user id is too long
ID: 2
TESTING: Admin User adding a new user, invalid user id
REFERENCES: Requirement 4.c.1.1.
TEST CASE:
1. Enter ab for user id
EXPECTED OUTPUT:
Error --> Message: Invalid user id, user id is too shortID: 2
TESTING: Admin User adding a new user, invalid user id
REFERENCES: Requirement 4.c.1.1.
TEST CASE:
1. Enter Pabc for user id
EXPECTED OUTPUT:
Error --> Message: Invalid user id, user id should start with a U
Note: if there is a test case that is not possible to test because of the way you designed your GUI, for example: If a name is limited to 20 characters and you have designed your GUI so that they can't enter more than 20 characters, still put that test case in but you can indicate that the GUI will not let this happen.
PART 2:
In a neat, well organized manner (consider a table of contents to help the teaching assistant figure out what is being included in this part), print out the code for one test drivers and one test stubs that your group has written so far for individual classes or subsystems within your project. The driver and stub should be documented so that it is clear why they were being used. (If test cases are "hard-wired" into the driver, documentation can be given via comments in the code, otherwise include a separate test plan documentation for the driver and the stub that indicates what it was testing.)
This section should be an update of the project plan in the second report. In particular, your group should provide a list of tasks to be accomplished between milestone 3 and milestone 4 and between milestone 4 and milestone 5. Indicate all the information for each task that was required in assignment 1. Remember to update the percentage of completion of any previous tasks and any upcoming tasks that you have already started. Make sure your Gantt chart correctly indicates who is/was assigned each task and who actually completed each task so that we know that the work is being fairly distributed.
For the rest of the project, you must have now written the code to complete at least 50% of the requirements from the list that are numbered 4.c, 4.d or 4.e
You must name the jar files as follows:
NOTE: For data persistence, you can do one or more of the following:
NOTE: for the .jar files, the t.a. will not test all of your screens so the screens do not have to all be connected yet (i.e. the button to display one screen doesn't have to make the screen display at this point) but the t.a.s must be able to get to/use the screen that will be necessary to test the functional requirements that you have implemented.
NOTE: the t.a. will take a quick peek at your code and make sure that you have included "some" javadoc comments for each method and class.
Your Group?readme.txt file must contain:
The marks will be tentatively assigned as follows.
Within four days immediately after this assignment's due date, complete the following peer evaluations for each individual (including yourself) in your group. For each peer evaluations that you fail to submit within four days of the due date, you will individually lose 0.5% off of your final course mark (up to a total of 2% for the 4 peer evaluations you must submit).
Click here to submit a peer evaluation (remember to also evaluate your own performance as well as ALL your other group members)
Note: Peer evaluations can affect the final mark given to an individual so please complete these peer evaluations CONSTRUCTIVELY.