Apophis Bunker App - Bug Hunt

Challenge Objectives

• Identify and log functionality & usability defects on the provided application.

About the Application 

The intent of this project is to create an MVP web application - Bunker Desk Tool Kit - to manage the activities currently done with a combination of excel tools and manual tasks. Using the new web application, users will be able to:

• Schedule bunker deliveries and resupply movements

• Report and communicate effectively with third-party terminals, barges, and agents

• Provide optimal blend opportunities

• Update Marketers and Traders of the status of inventories and deliveries

The application consists of two projects (frontend & backend) and the code is hosted on a private GitLab group. You will find a self-registration link on the challenge forum that you can use to access the repositories.

 

Although it’s highly recommended to deploy both applications locally, you can also use our hosted instance (details on the forum).

What to Test (Scope)

• Repo: Link on the challenge forum (available after registration).

• Application type: Web Application

• Tech stack: NodeJs, Docker, PostgreSQL, Angular

• Accepted types of bugs: We only target functional and UX (usability) issues for this bug hunt.

• Browsers in scope: Latest versions of Chrome, Firefox, Safari and Edge

 

Should you have any doubt, feel free to ask on the challenge forum!

How to Create New Bug Report

1. Create an account on GitLab (if you do not already have one): https://gitlab.com

2. To access the Gitlab repos, please check for instructions on the challenge forum.

3. Issues/Bugs found in this application must create here: https://gitlab.com/apophis-bunker-app/frontend/-/issues. DON'T use any other link to create new issues OR submit a document, they won't be counted and won't be paid.

4. Please label issues with the appropriate browser type and mode, bug type, and platform type.

Issue Reporting Guidelines

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

1. The bug title must have the following format: “<User Persona> - <Screen> - <Issue title>”

2. 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)

3. Current results before the bug is fixed

4. Expected results, after the bug, is fixed

5. Attach screenshots, videos (You can attach videos directly on GitLab, if not use services like www.screencast.com or https://monosnap.com Don’t use www.youtube.com to host the videos) & Crash - Console/Crash Logs that will be helpful to understand the bug.

6. Attach the high-level labels. If you are selecting multiple labels (Platform/Device); You have to provide screenshots for each and every Device/Platform you have selected; If not Bug will be REJECTED.

7. Attach detailed platform, operating system (Window 7 64 bit, iOS 11, Android 7.0 etc.), Frequency in the issue detail.  The high-level labels aren’t sufficient for issue replication and diagnosis.  

8. 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, 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 maybe gets 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 copilot has the right to change the severity at his 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 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 functionality/UX (usability) testing based on the requirements, all bug reports based on your own assumptions will be rejected.

 

The following points will be awarded as per the issue type:

• (P1 / P2) Functional - Blocker / Critical: 10 Points

• (P3) Functional - Major: 8 Points

• (P4) Functional - Minor: 5 Points

• (P5) Usability: 2 Points

 

P1 - Blocker: This bug causes the app to fail. No workaround exists. E.g. app crashes, app freezes.

P2 - Critical: This bug causes the app to fail for some specific cases. No workaround exists.

P3 - Major: This bug causes the app to fail, but there’s a workaround to prevent that issue.

P4 - Minor: This is an annoyance, but won’t prevent the app from running normally.

P5 - Usability:  Something noticed by testers that have as a result bad user experience.

 

Penalty on Duplicate Bug Reporting: If you log/report any duplicate bug, then you will receive penalty 5 Points per duplicate bug regardless of Bug type.

Penalty on Rejected Bug Reporting: If you log/report any bug without required information (insufficient info on bugs or missing repro steps or missing screenshot or missing video, etc.), then you will receive penalty 5 Points per rejected bug regardless of Bug type

Prizes and winner selection

• The user with the maximum number of points will be selected as the winner.

• The 1st and 2nd place submissions must collect at least total accepted bugs worth 40 points.

• The 3rd place submission must collect at least total accepted bugs worth 25 points

• In case no participant qualifies for the placement prizes as per the above rules, then only one winner will be selected who have scored the highest number of points.

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.

• 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 screenshots 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 Copilot for validity and severity of each filled issue will be final.

What to Submit

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:

 

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

• Your GitLab handle used to raise the issues.

 

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

- IMPORTANT: Submit the above details before the Submission Phase ends.

- 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

Please read above