Challenge Overview
Welcome to SEC Yield - Bug Hunt Challenge!
The goal of this challenge is to find issues in the code and related to the test data provided.
A Bug Hunt challenge is a program that will pay community members to find bugs to be fixed in a Bug Bounty challenge.
This Bug Hunt is to focus on the code quality and execution. This code is to be handed off to the client development team, and also used in subsequent phases of development. Please help us make it as close to perfect as possible!
After you join the gitlab group (see instructions below), the Architecture for the project is visible here:
https://gitlab.com/sancus-community/architecture
What to Test
- Use features/F2F-30055109 to review the code.- Calculation Validity
- Code Quality (using SonarQube)
- Consistency of Naming
- Spelling
- Curly Braces, Spacing and Alignment
- Any other recommended check from SonarQuba
- Test Run (mainly against the calculations logic)
- Run Tests using the Original Test Data
- Run Tests using New Test Data
- You are provided with 3 sample excel sheets you can use for testing
Please note! The UI that was created was purely to show to non-technical people within the client, so they can see the values returned by the calculation. Do not critique the UI in this bug hunt unless it’s a functional issue. Layout, spelling, colors, alignment, browser issues will all be ignored as submitted bugs and you will not get credit for them.
Submission Guidelines
How to Log Tickets
1. Create an account on GitLab: http://www.gitlab.com
2. Go to this URL to join the project group (link is shared in forums)
3. Search for and register your GitLab handle to join the project
4. Log issues in the correct place:
1. https://gitlab.com/sancus-community/backend/issues
2. https://gitlab.com/sancus-community/frontend/issues
i. REMEMBER: UI Issues must be functionality only! No UI/Browser critique please!
5. View and Submit Issues
Issue Requirements
For each report of a limitation or bug, we need the following information:
1. Steps to reproduce, including any needed information
2. If you’re critiquing code itself, link to the line in git
3. Expected results after the bug is fixed
4. Current results, before the bug is fixed
5. Assign the BUG HUNT label
6. Assign your guess at a weight for the severity of the problem.
7. Screenshots (if applicable)
Issue Weight Examples
1. Code esthetics - comments should be better, spacing is off
2. Code clarity - spelling, curly bracket placement
3. Code semantics - function and variable names are bad, unclear
4. Should be fixed
5. Issue exists, but won’t cause a failure
6. Needs to be fixed
7. I Could Break It Consistently
8. Potential Failure
a. Memory Leak
b. Incorrect accuracy (ie: variable size too small (Int instead of BigInt))
9. Catastrophic Failure
a. Invalid Calculation
b. Tests Fail (please identify the test and if possible, the test value)
c. Code crash, Full halt of execution
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 in multiple areas, for instance, you will likely only get credit for the original bug report. The others will all be closed as duplicates.
Scoring
- Scoring will be based on the number of bugs, by weight. Be sure to correctly attach a weight to your bug. The co-pilot has the right to change a severity at their discretion.
- Scoring is directly proportional to weight: Weight 1 = 1 point, Weight 9 = 9 points.
- The member with the highest score will win 1st place. The member who gets the 2nd most points will win $100.
- Only verified issues will be counted. Tickets logged for enhancements or non-bug issues 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 be rejected due to lack of information.
- For challenge scoring, the user with the most verified issues will be selected as the winner. Submitters that do not take 1st place will be paid $5 for each non-duplicate and verified issue up to a maximum of the 1st place prize. If two users submit the same issue, the user that submitted the issue first will receive credit.
Submission Deliverable
When the Bug Hunt is over, upload a txt file with the links to the issues you’ve submitted.
Tips
Some of the tips helpful for the contest:
- 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.
- Keep 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.