Skip to content

Latest commit

 

History

History
29 lines (25 loc) · 3.94 KB

TestRail_Navigation_C+.md

File metadata and controls

29 lines (25 loc) · 3.94 KB

TestRail Navigation and Process for Contributor Plus (C+)

Context

C+ are responsible for finding the appropriate location for new or updated regression test cases when NewDot bugs are fixed. Contributors working on fixing these bugs will then propose test steps to be added to TestRail. This document is intended to give a short overview on how to navigate TestRail and best practices on choosing the correct location for the proposed steps.

As a C+ member, you will have view-only access to Expensify's TestRail account in order to complete this task.

Navigating TestRail

  • Expensify's TestRail account is broken down into four projects. For the purpose of this document, we will focus on the project titled NewDot - New Expensify (New Format). Click on this project.
    • Screenshot 2023-02-24 at 12 02 28 PM
  • Within the project, you will find six headers that showcase the sub-categories of this project. Here, click on Test Suites and Cases.
    • Screenshot 2023-02-24 at 12 04 30 PM
  • You will then be showed the various Test Suites and Cases available. Click on New Expensify.
  • You now will have the overview of our various test cases that our outsourced QA team, Applause, run every day. On the right hand side, you will see a list of folders that detail different scenarios we house tests under. Clicking on one of these folders will then bring you to the list of specific test cases we currently have for the scenario in question.
  • Clicking on one of the test cases will then take you to the overview of the steps taken by Applause to ensure everything works as expected for that specific test. You will notice the expected behaviors are identified by the action word Verify.

Process for adding or updating TestRail Cases

  • Before proposing regression test steps, the C+ should first open TestRail and identify which existing scenario the bug in question best belongs in (e.g. A bug identified in the flow for updating preferred pronouns would fall under Account Settings).
  • Following, the C+ will then determine if there's an existing test case under the scenario that we can update to encompass the new steps that will be proposed OR if we need to create a new test case to accommodate the proposed steps.
  • Once determined, the C+ will post a comment in the original GH issue, mentioning which scenario the bug belongs under, why they think it belongs there, and if the new / updated test steps can fall under a current test case or if a new test case needs to be created. Please provide your reasoning for your decision in the comment and tag the BZ member to gut-check.
    • If the BZ member agrees with the C+'s recommendation, we can move forward. If not, a discussion will be held on where they think it might fit better and why.
    • There's a chance we will agree to not update/create a test case for the bug in question, depending on the bug.
  • Once we know where the test will live, the C+ will then propose the appropriate test steps to either add to an existing case or for a new test case.
  • Once the C+ has provided proposed test steps, the BZ will review to ensure:
    • The language style matches the language style in TestRail (e.g. action items use the term Verify)
    • The steps are clear, logical, concise, and void of any assumed knowledge
    • (For updating a current test case) the steps are logically placed in the test case
    • If changes are needed, the BZ member and C+ will discuss what changes should be done in order to make them appropriate
  • The BZ member will then create a GH for Applause to update the TestRail steps, link it in the original bug GH, and move forward with payment.