Challenge Overview
Challenge Objectives
- Bug Hunts on Functionalities and layout issues HAL Risk Management App
About the Application
BACKGROUND OVERVIEW
- When designing a Well, decisions made during the planning of the Well will generate specific design risks. These are normally controlled/mitigated by changing the design parameters (change trajectory, casing points, type of casing, fluid selection, etc.)
- There are inherited risks just with deciding to drill the Well in a specific location, or choosing to target a formation above a dome salt. For example, a subsea well location might have a residual risk with locating the Wellhead at the sea level. This is because any minor earthquake at the mudline can cause the Wellhead to change its altitude. These inherited risks are known as generic risks, and they can be overcome only by taking additional precautions to mitigate their impact or probability of occurrence
- By incorporating a Risk Register in the Well program, the engineer is making sure to pass the inherited and design specific risks to the execution team, so they know how to mitigate them when drilling the Well
PROJECT GOAL
- Create a Risk Matrix: Build a flexible risk matrix generator, customized by the user, so the component can be used by any customers.
- Create a Risk Register at any level inside the workflow: When the user identifies a known inherited or design risk, they can access the Risk Register and add the risk as the design is built. At the end of the process, the user will be able to go to the Final Risk assessment table and add control measures to mitigate the risks before sending the design for approval.
- Ability to create a Library of known risks (reading from an excel sheet as MVP): when the user creates a Well program, the service auto-picks the location, formation, etc. filters and adds known risks to the matrix as generic risks. (Not in scope for this challenge)
- Ability to create a Final Risk Assessment table: for each well, have a final risk assessment table that the manager can see if all identified risks have been mitigated and residual risks are acceptable according to company policy. (Not in scope for this challenge)
Let’s discuss any questions you have on the challenge forum.
Technology Stack
Frontend:
- Angular 10.2.0
Backend:
- Java 11
- Maven 3.6
- PostgreSQL 10
Assets
- Use frontend repo: https://gitlab.com/hal-risk-analysis/frontend > master branch
- Use backend repo: https://gitlab.com/hal-risk-analysis/backend > master branch
- Gitlab Self Registration Link (Note: use Chrome Incognito or Firefox Private Window) https://x.topcoder.com/api/v1/gitlab/groups/registration/eea98693-9b83-4bad-b27e-cb61301b8c1e-1610352062634
- Or post your gitlab username in challenge forum to get the repo access
Storyboard Design:
MarvelApp flow: https://marvelapp.com/prototype/bd72688Downloadable Screen: Google Drive Link
App Demo:
URL: http://13.58.198.89:4201/landing
Current Application Functionalities:
To understand current applications flow. Please read details from previous challenge page:UI Design Challenge: http://www.topcoder.com/challenges/30146579
UI Prototype Challenge Part 1: http://www.topcoder.com/challenges/30150093
API Design Challenge: http://www.topcoder.com/challenges/30148640
What to Test (Scope)
In this challenge, we need to find any performances/functionalities/layout issues of the application across required browsers
- Primary target device(s): Desktop only with min 1440px width
- Browser requirements:
- Latest Google Chrome,
- Firefox,
- Safari
- Microsoft Edge
- IE11
- Bugs are IN SCOPE:
- Functionalities,
- Layout
- Please label the issue type:
- Frontend
- Backend
- Bugs are OUT OF SCOPE:
- Spelling and Grammar,
- Text spacing issues inside a paragraph,
- Tooltips,
- Missing/Broken Images
- Font mismatch,
- Broken links
- Also other minor UI, Usability, Content issues, Tooltip, Broken Link issues that are not affecting the core functionality of the application are likely to be REJECTED.
- DON'T test the functions in the Login menu and also functionality of the login and registration. They are out of scope.
- Bugs MUST not DUPLICATE of existing issues created from client:
- Check complete issues here: https://gitlab.com/hal-risk-analysis/frontend/-/issues
- An edge case would be anything that does not reflect typical user behavior. They are accepted according to the impact to the end-user and based on the workarounds available.
How to Create New Bug Report
- Create an account on GitLab (if you do not already have one): https://gitlab.com
- You can get access to the GitLab repo using ‘Ragnar’ tool specified in the challenge forum thread to create new bugs OR If you are still getting 404 error, request access to the repo using correct forum thread.
- There is an issue template whenever you click New Issue in GitLab. Please use these templates to report your issues.
- Issues/Bugs found in this application/App must create here: (URL for creating Bugs) https://gitlab.com/hal-risk-analysis/backend/-/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.
- Please label issues with the appropriate browser type and mode, bug type, and platform type. The labels can be viewed here: https://gitlab.com/hal-risk-analysis/backend/-/labels
Issue Reporting Guidelines
For each report of a limitation or bug, we need the following information:
- 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)
- Current results before the bug is fixed
- Expected results, after the bug, is fixed
- If it is a UI bug attach a Screenshots (Mark the area where the bug is) | Functional Bug - 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) | Crash - Console/Crash Logs.
- 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. [Eg: If you select labels Browser: Safari, Chrome, Firefox, etc you have to provide screenshots of all the device types you have selected]. Same applies to Platform
- Attach detailed version, 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.
- 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 the 'Steps to Reproduce' section. Sometimes the Provided URL with parameters won't load the page to the reviewer and the bug may 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 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/UI testing based on the requirements, all bug reports based on your own assumptions will be rejected.
- Functionalities Issues - 5 Points
- Layout Issues - 2 Point
Final Submission Guidelines
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 to Topcoder Online Review using the Submit to this Challenge button BEFORE the Submission phase ends. In this file include:- Your name
- 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 a document, they won't count and won't be paid.