Key Information

Register
Submit
The challenge is finished.

Challenge Overview

About the Challenge  

 

RCS is an Asset Reliability Centered Business Performance Tool, specifically designed for Power Grids and Substations asset reliability management. For this project, we are going to run a series of challenges to automate the test cases for Web application using Selenium framework to make things easier.

 

Note: The challenge prizes displayed is just the place holder which is total challenge prize amount. The prize money is per test cases basis. The prize money with each test case is tagged into gitlab issue tracker. The prize money will be paid for successful acceptance after review of the test case. The test case wise prize money ranges from $50 - $130.

 

TECHNOLOGY STACK

  • .Net Technology

  • C#

  • Selenium Webdriver

  • SpecFlow - Cucumber for .NET

  • Web App - (Chrome,Firefox, IE11, Safari)

 

Notes on test cases and code structure

You will find in Gitlab repo all details on the tests cases that need to be automated. Each test case in is given with a series of steps and expected results and it’s required to split it into smaller test scenarios. Cucumber (Gherkin) is used to specify the tests in our code base so you will need to convert the test steps into Cucumber scenarios. Use Page Objects, Backgrounds and Scenario Outlines wisely. Parametrize the steps and reuse existing steps wherever possible. SpecFlow has an extension for VisualStudio that will make it easier to develop and run the tests. Also, take a look at the documentation page at https://specflow.org/docs/

 

NOTE: To minimize duplicate code and merge conflicts, we have made some test cases dependent on others - that means that once the parent test case is implemented and merged we will open the dependent ones for pickup. For example: there are test cases to create an entity with different user roles and test cases for all other CRUD actions for that same entity - only one test case is available in the beginning (create entity as user X) and the remaining related cases are opened once the first one is implemented.

 

Base code already contains implementation of scenarios for the first test case (US_1.1.1_TC01) - use the implementation as a model on how to convert the test cases to actual Cucumber scenarios. All the test cases defined in this project have similar structure and test for more than one thing in a test case - that’s why we want a test case to be split into multiple scenarios that each test only one thing. Test scenarios with multiple Given -> Then -> And -> Given sections should be avoided so we don’t end up with spaghetti code. For example, the demo test case has been split into multiple scenarios:
 

  • Verifying the default roles are displayed

  • Verifying the form fields are displayed in create role form

  • Verifying the tabs contain the correct fields

  • Test for back button behavior

  • Test for creating a role

  • Etc

In a nutshell each test scenario should do a series of actions, and verify the results (verifying more than one thing is ok), but we should avoid scenarios that perform user actions, verify something, perform more actions, verify more results etc - split such scenarios where possible.

 

How To Participate

  • Register for the challenge.

  • Step 1 - Create a Gitlab Account if you do not have one already

  • Step 2 - Use the self-registration link and register yourself to get the gitlab project access - SEE CHALLENGE FORUMS FOR THE LINK

  • Step 3 - Then access the GitLab tickets here - https://gitlab.com/abb-testing/rcs-testing/issues

  • Step 4 - Choose the ticket labeled as "tcx_OpenForPickup" and assign yourself to the ticket

  • Step 5 - Remove the "tcx_OpenForPickup" label and add "tcx_Assigned".

  • Step 6 - Work on the chosen ticket and submit your automated test case by creating a new branch for the ticket. Please make sure to name each branch as “issueX” where X is the issue ID in Gitlab. Not following this naming convention will not trigger an automatic build which will delay reviewing your submission

  • Step 7 - Change the ticket status to "tcx_ReadyForReview".

  • Step 8 - Reviewer will review your test results submission by adding "tcx_Review" label, and if accepted the status should be changed to "tcx_FixAccepted" and if not the status should be changed to "tcx_Feedback", and "tcx_Review" label should be removed when the status changed into "tcx_Feedback" status.

  • Step 9 - If the ticket status is "tcx_Feedback", tester has to fix the review feedback before continuing to work on the new chosen ticket, and then repeat step 6 to 9.

  • A participant is not supposed to hold the test case for more than 1 day. Else, it will be unassigned from the participant. Similarly the review feedback needs to be resolved within 1 day, otherwise the ticket submission will be rejected and the ticket will be open for pickup by others.

  • You need to assign yourself the unassigned/open tickets only, please don't work on tickets assigned to others.

  • Once the current assigned ticket is ready for review, then you can work on next open ticket by assigning yourself.

  • For a ticket, if you receive any feedback from reviewer, then work on it and submit quickly to pass review.

  • For a ticket, if it is accepted by reviewer, then you will get paid the prize amount associated with the test case title.

  • You can work as many tickets you can complete within challenge timeline to win more prizes.

Note on automatic builds: each commit to a branch named “issueX” will trigger an automatic build and execution of the entire test suite. See the challenge forums for details on how to get a link to an automatic build output for your branch. Before marking the ticket as ready for review make sure the test cases you added are passing in the automatic build and previous tests aren’t broken by your changes.



 

Final Deliverables

 

When you are done with your tickets, please submit a .txt file in Direct using the "Submit" button before the submission phase ends. In this file please include the following details:

  • TopCoder Handle: <>

  • Gitlab ID: <>

  • Optional: List of accepted issues (GitLab links)

 

IMPORTANT NOTES:

  • Failure to submit a small text document (see ‘Final Deliverables’) to the challenge will result in non-payment.

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

 

Notes on Payments

  • All tickets are assigned a bounty price, depending on their level of complexity.

  • We will add the bounty price of all your completed test cases at the end of the challenge and make a single lump payment to you.



Final Submission Guidelines

When you are done with your tickets, please submit a .txt file in Direct using the "Submit" button before the submission phase ends. In this file please include the following details:

  • TopCoder Handle: <>

  • Gitlab ID: <>

  • Optional: List of accepted issues (GitLab links)

ELIGIBLE EVENTS:

Topcoder Open 2019

REVIEW STYLE:

Final Review:

Community Review Board

Approval:

User Sign-Off

SHARE:

ID: 30087725