Computer Science 340 :: Software Design and Testing

Project Overview

Being a Good Teammate

Team Application

Book Club Example

Demo:

	Zip File
	Instructions:     1. Download and extract zip file     2. cd to the "inventory-tracker/demo" directory     3. Run "java -jar inventory-tracker.jar"     4. An error message will appear in the console the first time you run the demo. Ignore it.
	[NOTE: After extracting the zip file, the inventory-tracker/demo/ folder should contain inventory-tracker.jar and 4 subfolders named: "images", "lib", "labels", and "reports". The "labels" and "reports" subfolders are initially empty. Even though many zip tools don't display them, these empty subfolders are in the original zip file, but, depending on how you unzip, they may or may not be created. If you have trouble running Inventory Tracker, make sure the "labels" and "reports" subfolders exist. If they don't exist, create them manually.]

Specifications:
    Functional Specification

    Phase 1
    Phase 2
    Phase 3
    Phase 4

Source Tree:

	Zip File
	Instructions:     1. Download and extract zip file     2. cd to the "inventory-tracker" directory     3. Run "ant run" on Linux, or "ant.bat run" on Windows     4. This will compile and run the provided GUI code

Exams:
    Phase 1
    Phase 2
    Phase 3
    Phase 4

---

Intructions for submitting implementations:

1. Zip up all the files needed to run your implementation
   • Don't include your code
   • You'll find a pre-packaged jar in dist/lib/
   • Make sure that any and all needed files, such as library jar files, or anything like that (only if they are needed and not already packaged into the jar) get included.
2. It always helps to test your zip file to make sure that it can be unzipped successfully and run the implementation jar without having to do anything special.
3. Go to BYU's Digital Dialog website and get into the forum for this class.
4. You should see two conversations underneath your team: one where another team will give you their implementation, and another where you need to post yours.
   • I tried to make this as easy as possible for you, and I think this might be better than the headache of trying to send .zip files in emails through Blackboard. If you have any questions or it's worded in a way that you don't understand, feel free to ask me (Wayne) for clarification.
5. Post the zip file of your implementation on the correct Digital Dialog conversation by the due date.
   • Make sure to check Digital Dialog often to make sure there weren't any problems with the team getting the file or running it. You can communicate with the other team (and with your own) through Digital Dialog.

We will be using Google Code to report and handle bugs this semester. We have a project set up with the Issue Tracker, and we'll add your email addresses as contributors to the project so you can log issues (bugs).

To log bugs that you find in the other team's implementation:

1. Click on the New issue button.
2. Enter a short, but descriptive summary for the bug.
3. Write a good description of the bug that explains what went wrong.
   • Provide clear steps to reproduce the bug. If a bug can't be reproduced, then it won't count as a bug and is just wasting everyone's time.
   • Explain the expected output and what actually happened.
   • Provide a reference to a page in the Project Specifications or the HIT Functional Specifications that explains why this is a bug. (You could also explain major inconsistencies with the demo's functionality).
   • You can put as much explanation in the Description as you feel is necessary to precisely explain the issue.
4. Attach any files that will help in identifying and tracking down the bug.
   • Screenshots of the bad behavior are sometimes good and easier to provide than a book of text.
   • An xml file to import might be useful in showing the state of the inventory when the bug happened.
5. Leave the status as New for now.
6. Set the Label to the appropriate team. You can also set a priority if you want, and/or specify another label about which Operating System the error occurred in.
7. Click on Submit Issue to enter the bug in the database.

When fixing bugs with your team, please adhere to the following guidelines:

• To get a list of all of the bugs that have been logged for your team, you can use the Advanced Search option and search for all issues with your team's tag, which is of the form Team-#, where # is your team's number.
• You can (and probably should) set the status appropriately as each issue moves through its lifecycle.
  • When one of your team members can reproduce a bug, they can set it as Accepted along with a comment as to what they think might be causing it, etc.
  • When you start working on a fix, you can set the status to Started if you want.
  • When the bug is actually fixed to your satisfaction, mark it as Fixed, NOT as Verified. The TA will "Verify" that the bugs are fixed at passoff.
  • If you determine with reasonable certainty that a reported issue is not a bug and/or cannot be reproduced, you can mark it as Invalid. Be aware, however, that Dr. Rodham and the passoff TA will have to agree with you that it's not a valid bug.
  • There's always at least one duplicate bug logged for one reason or another. Mark the extraneous bugs as Duplicate.

• Other than that, Happy Testing! Be thorough—you can expect nothing less from the team testing your implementation.

• Oh, and remember that you do get docked for having bugs in the first place. Make sure you do your own testing before turning it in and handing it over to the wolves.