Challenge Overview
Project Overview
Welcome to the OPM - ARS Document Bug Hunt - Part 4! In this contest, you will need to verify the App & Roles ARS (Specification) document for the new SCRD web application to make sure it includes all the required functionality from the existing legacy system. Basically, we need your help to determine if there are any holes or discrepancies in the ARS document.
In this Part 4 Bug Hunt, you should verify the App and Role ARS document against the User Guide for the current legacy application.
Project Background:
The Office of Personnel Management (OPM) has an existing legacy application called the Service Credit Redeposit/Deposit System (SCRD). The mission of the Service Credit Redeposit/Deposit System (SCRD) is to compute deposits and redeposits, create an initial bill, post payments, and send out receipts to federal employees for periods of federal employment service that were either not covered by retirement deductions (deposits), or were covered and later refunded by the federal government (redeposits).
For this project, OPM will be building a new web application to replace the existing legacy SCRD system.
Contest Objective
With this contest, we need to determine if there are any holes or discrepancies in the ARS (Specification) doc. The most important task for this bug hunt is to figure out where the ARS is missing functionality, or contains incorrect or insufficient details. In other words, places where the ARS does not provide definition or detail for functionality that is currently included in the legacy application and should be in the new SCRD web application – e.g. functionality, data validation, error processing, etc.
The two challenges for this Bug Hunt are to determine if the App and Role ARS document includes either of the following:
1. The current uses cases are incorrect or lack sufficient detail to implement them.
2. The ARS document is missing use cases or requirements.
Valid Bug Definition
For this contest, only bugs that meet one of the following 2 conditions will be considered a valid bug:
1. Any ticket that accurately describes a current use case that is not sufficiently detailed (for example, something that is inferred, but not backed up with information).
2. Any ticket that cites a section/functionality within one of the source documents, and then explains that no current use case addresses that section/functionality from the source document.
To do this, we'll need you to look for items in the current documentation and compare it to the App & Role ARS document. Specifically, for Part 4 you should look for missing functionality or incorrect / insufficient details between the ARS document and the User Guide document for the current legacy application.
For this contest, ask yourself: "If I am user of the current SCRD today, and I start using the new SCRD tomorrow, will everything I do in the current system be available in the new system?" You can check this using the User Guide for the current legacy application.
PART 4 SCOPE: Please note, this is Part 4 in a series of similar bug hunts.
In Part 4, you should verify the App and Role ARS document against the User Guide document for the current legacy application. Any bugs reported for this contest but based on other verification sources will NOT count towards your total for this contest.
Contest Guidelines
The guidelines for this contest are given below:
- As issues are identified they need to be logged in JIRA: https://apps.topcoder.com/bugs/browse/OPMBH (when creating a bug you MUST select the "ARS Bug Hunt - Part 4" component)
- Issues must include clear descriptions, test cases and steps to reproduce and expected vs. actual results in order to be counted.
- First competitor to find an issue gets credit, duplicates will not be counted.
- Reviewers will accept, reject or mark the issues as duplicate.
- Please DO take a look at the reported bugs, duplicated bugs cost your work time and the reviewer's time.
Important Notice:
You must also be the first person to report the issue and submit it while submission phase is open. JIRA will allow you to file issues before and after the submission phase, but these will NOT be counted.
Provided Resources
Documentation Provided
The following documentation will be available for you for this contest:
- App and Role ARS - The document you need to verify if any functionality is missing, incorrect or insufficiently detailed.
- The User Guide
- Finally, additional project documentation is available on the OPM Project Wiki if needed: http://apps.topcoder.com/wiki/display/projects/OPM
Additional Resources
Some of the additional resources helpful for the project are
Bug Report Process / Format
For each report of a limitation or bug, we need the following information:
- For each bug, you should reference the ARS use case number (e.g. "2.10 Search Account") where incorrect or insufficient details are found as well as the source document name / page number where you found the incorrect or insufficient details. If specific functionality is missing, you MUST provide a detailed description of what the functionality is and where you would have expected it to be included in the ARS (including which existing use case the functionality should be a part of or should be related to).
- Steps to reproduce, including any needed information
- Screen shots (if applicable)
- Expected results after the bug is fixed
- Current results, before the bug is fixed
- The UI for the new SCRD (wireframe) has been improved from the current legacy version. Changes in the UI, or functionality that is still covered but in a slightly different way, will NOT be counted as a bug and should NOT be reported.
- Any functionality related to the Business Rules Engine will NOT be counted as a bug and should NOT be reported. There is a seperate ARS for the Business Rules Engine that coveres this functionality.
- Any functionality related to Reporting will NOT be counted as a bug and should NOT be reported. There is a seperate ARS for Reporting that coveres this functionality.
Important Notice:
- If you do not properly document your bug reports, they will likely be rejected due to lack of information or documentation. Also, make sure your bug reports are reasonably general.
- If you submit the same bug that is seen in multiple screens, for instance, you will likely only get credit for the original bug report. The others will all be closed as duplicates.
Ticket Logging
You will log your tickets here: https://apps.topcoder.com/bugs/browse/OPMBH and when creating a bug you MUST select the "ARS Bug Hunt - Part 4" component. Bugs will not be counted if a selection is not made.
Valid Bug Definition
For this contest, only bugs that meet one of the following 2 conditions will be considered a valid bug:
1. Any ticket that accurately describes a current use case that is not sufficiently detailed (for example, something that is inferred, but not backed up with information).
2. Any ticket that cites a section/functionality within one of the source documents, and then explains that no current use case addresses that section/functionality from the source document.
Scoring
- For scoring, the submitter with the most accepted bugs will win. The submitter with the second most accepted bugs will receive second place.
- For submitters who submit but don't take first or second, if they submit bugs that aren't covered in the first or second place submission, they will receive $5 for each unique bug reported up to a maximum of 15 bugs.
Important Notice:
If two submitters submit the same bug report, the submitter who submitted the report first into JIRA will get credit for the bug. The second submitter will not.
Tips:
Some tips helpful for the contest are:
- Submitting what is obviously the same issue multiple times with small variations will only annoy the reviewer that has to sort through all the issues and will only count as one issue anyway. If it's less obvious if it is the same issue or not, use your best judgment and the reviewers will do the same.
- Put an eye on the issues being submitted by other members to minimize the time you may be spending on duplicate efforts. Knowing what has already been reported will allow you to better focus your time on finding yet undiscovered issues.
- Double check your steps to reproduce and test cases to make sure they are clear. Make sure your steps include creation of any necessary data.
Submission Deliverables
You need report your issues in JIRA. Please submit a text file contains the bugs you reported to OR.
Final Submission
- For each member, the final submission should be uploaded to the Online Review Tool.
- You must not include any identifying information, such as your handle, in your submission. Your submission should be anonymous and you will be scored down in screening for not complying.
Final Submission Guidelines
Submission Deliverables
You need report your issues in JIRA. Please submit a text file contains the bugs you reported to OR.
Final Submission
- For each member, the final submission should be uploaded to the Online Review Tool.
- You must not include any identifying information, such as your handle, in your submission. Your submission should be anonymous and you will be scored down in screening for not complying.