Key Information

Register
Submit
The challenge is finished.

Challenge Overview

Project Overview

SRT is a web application used to manage service requests, it's simple in that it's purely about collecting data and then submitting that to the server (which will also result an email being sent to the person).

You may also feel it's a complex app because it has quite a few pages / tabs and some of them depend on the others.

Contest Objective

The purpose of this bug hunt is to do general functional testing for the app.

Notes:

  • This bug hunt will focus on the paths that have Estimates and Project Staffing tabs (there should be 3 different work flows, see SRT process flow.pdf)
  • Please focus on functionality testing and don't spend your time trying to find spelling errors, typos or trivial UI issues, below are the things you should focus on in this bug hunt:
    • In Estimates tab, add multiple roles, multiple material codes, filling in many of the additional fields
    • Move to Project Staffing tab, also fill in multiple fields (try both manually entering values and copy / paste), save as draft
    • Now try to copy the request several times and test how well this works
    • Check if formatting get broken when field values get carried over to next pages or copied requests
    • Test this in both online and offline modes
    • Check if all these fields get carried over to review page and get exported to PDF / XML, and whether formatting is broken
  • You must take screenshots for the issues you log
  • Focus on obvious functional bugs, we will reject all issues based on your own assumptions
  • Offline mode doesn't support the following functions, so they are not bugs:
    • Export request - This can be done only in server
    • Submit Request - This requires sending email which can be done only in server
    • Upload Attachments - Attachments need to be stored in server and we can’t save them in browser to sync it later. Also there is complexity involved in generating unique id for attachment and map it to the request.

Browser Requirements

The given application must be tested in Chrome latest and in Firefox latest.

Testing on Safari latest is optional. No need to test in IE.

Users

When asked to login, use your own handle for the "User identifier" field. Note you must also enter all other fields in order to login.

Contest Guidelines

The guidelines for this contest are given below:

  • As issues are identified they need to be logged in JIRA.
  • 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.

Technologies

  • Java
  • JSP
  • HTML / HTML5
  • Angular.js
  • H2
  • Javascript
  • PostgreSQL / Oracle
  • Maven

Provided Resources

Documentation Provided

  • Source code

Contest Prize Eligibility

The submitter with the most accepted bugs will win the contest.



Final Submission Guidelines

Bug Report Process

Bug Report Format

For each report of a limitation or bug, we need the following information:

  • Steps to reproduce, including any needed information
  • Screen shots (REQUIRED), if you don't provide a screenshot your ticket may be rejected
  • Expected results after the bug is fixed
  • Current results, before the bug is fixed
  • Browser version

 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/ESTIMATIONTOOL and when creating a bug you MUST select the SRT HTML5 Estimates / Staffing Fields Bug Hunt component. Bugs will not be counted if a selection is not made.

Scoring

The Scoring guidelines followed for the contest are given below:

  • For scoring, the submitter with the most accepted bugs will win.
  • For submitters who submit but don't take first, if they submit bugs that aren't covered in the first place submission, they will receive $5 for each unique bug reported up to a maximum of half of the 1st place prize

 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 of the 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.
  • Do not report trivial issues like typo / grammar issues / color issues / etc... these will all be rejected

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 via the challenge detail page on topcoder.com.
  • 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.

REVIEW STYLE:

Final Review:

Community Review Board

Approval:

User Sign-Off

SHARE:

ID: 30051148