Holdings Cross Reference Re-Skin Unstructured Bug Hunt Challenge

Challenge Objectives

• Exploratory or unstructured testing and reporting
• Chrome and IE11 browser testing

This challenge will have 24hr for the registration (during this phase no one will see details) and 2 days for bug hunting. Details will be posted on Nov 17, 15:00 EST
 

About the Application 

In the process of this demo preparation we used an intermediate proxy that cached all responses from our backend servers. 

When the same request is sent to the backend 2nd time the cached result is returned back to the browser.

The application is a result of recording of some basic scenarios from the real application.

All client related data was removed or obfuscated.

The Holdings Cross Reference python app has been re-skinned. We didn’t have design files but we have specific instructions on what needs to be done. These instructions are in the provided documents.

 

Assets

• Demo App
• ���Instruction documents

 

What to Test (Scope)

In this challenge you have to do exploratory testing of the Holdings Cross Reference re-skin app for the following:

1. If the design instruction has been followed

2. If correct font is used, the default font should be Frutiger, and if that isn't available then Istok Web is secondary and should be used

3. If the site is compatible with Chrome and IE11 desktop browsers

• Test app: you need to install the demo app using Python version 3, the instruction is in the provided files

• Accepted types of bugs: UI and JS Functionality issues

• Primary target device(s): Desktop 

• Browser requirements: Latest Google Chrome and IE11  only.

 

How to Create New Bug Report

1. Create an account on GitLab (if you do not already have one): https://gitlab.com.
2. You can request access to the GitLab repo in the challenge forum.
3. Please use the provided template to report your issues.
4. Issues/Bugs found in this site must create here. DON'T use any other link to create new issues OR submit a document, they won't be counted and won't be paid.
5. Please label issues with the appropriate browser type and mode, bug type, and platform type.  The labels can be viewed here.

 

Issue Reporting Guidelines

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

1. Steps to reproduce, including any needed information (Must list all the steps that need to reproduce the bug, DON'T list only the URL without test data)

2. Current result(s) before the bug is fixed

3. Expected result(s), after the bug is fixed

4. Attach a Screenshots (Mark the area where the bug is) or Videos (You can attach videos directly on GitLab, if not use services like www.screencast.com Don’t use www.youtube.com to host the videos) 

5. Attach detailed browser version, operating system (Window 7 64 bit, Mac), Frequency in the issue detail.  The high-level labels aren’t sufficient for issue replication and diagnosis.  

6. If it is a comparison, you must provide the URL and Screenshot/video of that location.

IMPORTANT NOTE:

Missing or Incorrect details to ANY of the above fields will mark the bug report as INCOMPLETE. 

For example, Incorrect Steps, Missing Screenshot/Screencast (If it is a UI issue, you have to mark it on the screenshot), Incorrect Actual and Expected results etc.

Be careful when you are providing only the direct URL and not listing the steps to go to that particular page in 'Steps to reproduce' section. Sometimes the Provided URL with parameters won't load the page to the reviewer and the bug may be get closed as 'CAN'T REPRODUCE'. So better to list all the steps till the end or double check the URL is loading or not.

 

Issue Weights and Scoring

• Scoring will be based on the number of bugs by weight.  Be sure to correctly attach a weight to your bug.  The delivery team has the right to change a severity at their discretion.

• Only verified issues will be counted.  Tickets created for enhancements or that are not bugs will not be counted. Duplicate issues will be closed and not counted. Log issues according to the guidelines above issues that do not follow these guidelines may reject due to lack of information.

• For challenge scoring, the user with the most verified issues/points will be selected as the winner. If two users submit the same issue, the user that submitted the issue first will receive credit.

• Please focus on UI testing based on the requirements, all bug reports based on your own assumptions will be rejected.

• User Interface Issues     - 5 Points

• JS Functionality issues     - 5 Points

Submitters that do not take 1st and 2nd place will be paid $5 for each non-duplicate and verified issue up to a maximum of the 2nd place prize. 

 

Important Notice

• Follow the standard topcoder Bug Hunt Rules.

• If you do not properly document your bug reports, they will likely be rejected due to lack of information or documentation. If you submit the same bug in multiple areas/pages, (for instance, Same validation issue of a form can be found in different pages/sections) you will likely get credit for the original bug report only. The others will all be closed as duplicates.

• If you duplicate an issue on a platform or browser that hasn’t been tested yet, you should create a new issue and add a link/reference in the issue description to the existing issue number. Our copilot will review these items and consolidate them later. Please don’t make adjustments or change labels of existing issues logged by other competitors.

• DON'T RE-OPEN the issues in the review phase and anyone who RE-OPENS a ticket will be disqualified from the challenge.

• If Mobile and Tablet testing are available DON'T create the same issue on different platforms; instead, merge them into one; All the others will be marked as Duplicate.

• If you see multiple broken links on the same page combine them into one ticket. Others will be marked as DUPLICATE.

• You must not edit the bug report once created, so make sure you enter all the details at the time you create the issue, otherwise, your issue will be moved to the end of the queue. If you really need to edit an issue you must use the comments section for this (i.e. add a comment to describe any changes you want to make to the issue), and we'll decide whether the changes are major enough to move the issue to the end of the queue. You are allowed to add screen shots in the comments section though, assuming your issue report contains all the details when created.

• You must specify the test data you have used in the 'Reproduction Steps', All the issues will be marked as 'Incomplete', if the correct test data is not provided.

• Keep an eye on the issues being submitted by other participants 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.

• There will be no appeals phase. The decision of PM/Copilot for validity and severity of each filled issue will be final.

 

Final Deliverables

Submit all your bugs directly to GitLab. When you are done with your submissions please submit a .txt file using the “Submit” button before the submission phase ends. In this file include:

• topcoder handle (The one displayed in the top right corner near the Profile picture)

• GitLab handle used to raise the issues. (Login to GitLab and click on the Profile picture > Your Profile. Check the URL https://gitlab.com/[Your Username]

- ALL THE SUBMISSIONS WITHOUT ABOVE INFORMATION WILL BE REJECTED AND WON’T BE PAID.

- IMPORTANT: Submit the above details before the Submission Phase ends. If you can't submit due to technical difficulties within the Submission Phase please email your submission with above details to support@topcoder.com.

- Participants who haven't submitted will not be paid.

- DON'T use any other link to create new issues OR submit as document, they won't count and won't be paid.

Final Submission Guidelines

Submissions will be done in the form of pull requests to the relevant repositories. Please clearly mention in the title of your commits and MRs the ID of issues they are fixing, and briefly tell in body of commit/MR comments, what exactly have been done, and how it can be tested.

IMPORTANT NOTE:  In order for your fixes to be counted, you must upload a dummy submission to this challenge.  Please submit a zipped up txt file that contains your Gitlab username.