Thor DC Starter App Bug Hunts

Challenge Objectives
Bug Hunts on Thor DC Starter App on these aspects:

• Functionalities
• Layout,
• Text Typos and Grammar on Source Code Text or Comments
• Check if use correctly use Material UI existing look with less custom styling.

PROJECT BACKGROUND

• This application is used to configure a set of devices that are included in a particular customer order.
• The user starts by entering the order number.
• The application queries the API and retrieves the order details.
• These details include a list of individual devices that are used to populate the devices list. The details for each device are also fetched from the API.
• Each of these devices needs to be configured before the order is complete.
• Devices are configured by navigating to the device details page and clicking the Configure button.

CHALLENGE ASSETS
Base submission source code: https://gitlab.com/eaton-topcoder/device-config-starter-frontend
Mock API source code: https://gitlab.com/eaton-topcoder/device-config-starter-backend

Technology Stack

• Electron and the Forge: https://electronforge.io/
• ReactJS
• JSON-Server

OS Requirements
IMPORTANT: Test and build as desktop native app on these OS:
Windows 7
Windows 10
Mac

Current Application Functionalities:
To understand about the current applications flow. Please read details below:

1). Login
PXBlue Design Pattern: https://pxblue.github.io/patterns/login

• Create repeated background image on this login page that covered whole browser screen
• Login box need placed centered and using fixed width
• Create tooltip when hover the “?” button next to Sign in title
• Login page need display these fields:
  • Eaton.com Email Address
  • PX White Password
• Create how validation look with PxBlue Design system for error/success message
• This is error validation look (Screenshot: 01 Login - ERROR.png)
• Click x button need clear the values
• Need able to reveal the password when click “eye” button
• Sign in button become enabled once user filled both inputs
• Forgot Password can be dead link

2). General Layout

• This is general page layout after user logged in that applied to all pages.
• Header bar need remain fixed on top
• The navigation menu should match the design and behavior described on https://pxblue.github.io/patterns/navigation under “Icon Navigation Bar / Responsive Navigation”
• These are the sidebar menu navigation content:
  • Locate
  • Print
  • Help
  • Settings
• Logout (Click this need take user back to Login page)
• Create active/inactive menu state
• You can disabled page that is not exist in storyboard
• Use standard icons based on PXBlue Design Pattern

3). Locate Page

• Upon first navigating to the Locate page, the user is presented with a search field
  • The Order Number and Item Number fields should accept any alphanumeric input
  • Order Number should be limited to 10 characters
  • Item Number should be limited to 5 characters
  • Search button should be disabled until a valid Order Number is entered
• “Report an issue here” link can be disabled
• Notice on input focus need use blue colored border
• When searching the order, an API request should be made to retrieve the details for that order.
• Use preloader while retrieve data from API
  • You can use preloader from Material UI: https://material-ui.com/components/progress/

4). Device List

• After retrieving the details for the specified Order Number, the screen shall display a list of devices associated with that order.
• Back button on header bar need take user back to Locate page
• On the right side of header bar display numbers based on device status
• User need able to filter device list data based on Location dropdown and Search input on header bar
• Notice there’s number counter for Location that will be change when change the Location
• Search input need able to change to these options for specific search target
  • By Device Name
  • By Device ID
  • By Device Family
  • By Device Model
  • By Device Compartment
  • By IP Address
  • By Subnet
• Report an Issue can be dead link
• Table device list need able to sort
• Need support to load more rows when user scrolling the table
• Filter area and Table header can use fixed placement, while table body scrolling
• Each device on the UI will have a status field which will contain either a description of any current errors, or a Configuration Button
• Clicking the Device Name will open a device details page

5). Device Detail

• This page shows assorted information about the selected device
• Back button on the header bar need take user back to previous screen
• Content area can remain in center like storyboard look
• Clicking the “Configure this Device” link will trigger the Configure workflow
• Other links can be dead link
• Display configuration details on the bottom

6). Configure Device

• The configuration workflow should open in a modal dialog
• For this sample application, you may use a timer to automate progress through the steps (5 seconds per step)
• This is default screen at first time click Configure button
  • This is screen when connecting
  • This is screen when there’s an error
  • Click Retry need redo the connecting modal
  • Click exit need close modal window
• If no error need auto load the Step 1
• There are 4 steps in the configuration that should be shown in a stepper
  • Step 1
    • Programming PXM2260
    • Do not unplug or power down device...
  • Step 2
    • Validating Firmware
    • Checking for the latest version...
  • Step 3
    • Uploading config file to cloud
    • Loading settings...
  • Step 4
    • Rebooting PXM2260
    • Establishing Communication
• Issue detected
  • This is screen when issue detected during configuration
  • Click exit need close the modal window
  • Device details page need show updated look if there issue found
    • On top device details updated with Issue detected status
    • Update the image with exclamation icon
    • On the right side, there is next steps area that will take the user back to the previous screen or locate new order
    • This is the updated device list page with device with “Issue” status
• Success screen
  • This is screen if all steps successfully configured
  • Device details page need show updated look if there configuration success
    • On top device details updated with Configured status
    • Update the status with green colored label
    • On the right side, there is next steps area that will take the user back to the previous screen or locate new order, or print the queue
    • This is the updated device list page with device with “Configured” status
• Note: On the title area of modal window, you need countdown counts until all steps completed
• For this challenge submission click-flow:
  • Create flow when there’s issue on Configuration flow
  • After that, click the Configure Device again need show the success message
  • Create separated device details based on different error and success message
• Once the configuration process is complete, the configuration button for that device on the Locate page should be replaced with a Configured badge.

 
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 Screen Size only
• OS requirements:
  • Windows 7
  • Windows 10
  • Mac
• Bugs are IN SCOPE:
  • Functionalities Issues
  • Layout Issues
  • Text Spelling and Grammar on Source Code Text or Comments
  • Check if use correctly use Material UI existing look with less custom styling.
  • Put the correct Material UI implementation on your issue
• Please label the issue type:
  • Frontend
  • Backend
• Bugs are OUT OF SCOPE:
  • 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 to the core functionality of the application are likely to be REJECTED.
• An edge case would be anything that does not reflect typical user behavior. They are accepted accordance 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 template to report your issues.
• Issues/Bugs found in this application/App must create here: https://gitlab.com/eaton-topcoder/device-config-starter-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.
• Please label issues with the appropriate browser type and mode, bug type, and platform type. The labels can be viewed here: https://gitlab.com/eaton-topcoder/device-config-starter-frontend/-/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
• Set correct label
• 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 (Windows 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 '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 - 3 Point
  • Material UI Consistency - 2 Point
  • Text Spelling and Grammar - 1 Point
• Prizes:
  • 1st Place: $500
  • 2nd Place: $300
  • 3rd Place: $200

Submitters that do not take 1st, 2nd or 3rd place will be paid $5 for each non-duplicate and verified issue up to a maximum of the 3rd 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 Submission Guidelines

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 WONT 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.