Version 4

     

    Repository

     

    Test Repository

    This list contains all the test cases. The screen is prepared to narrow down the list using several filters. Then test cases can be edited or selected to include in a new Test Plan.

     

    Available Classification / Filters:

     

    Ways to categorize the test cases by functionality: 3 component levels, Test Suite and Functionality:

    Search Test name: search within test name and description 

    ID: looks for internal ID or external ID (when it was coming from an import)

    Component Field behavior:

    • Expands/Suggest a list of all components 1 (same as first category)
    • Also allows searches for any component
    • After one of them is selected, it displays another Component field where it:
    • Expands/Suggest a list of all related components to the selected one
    • Allows search for any component that has a relation with the selected one
    • Test Plans: these are the executions that testers have built in the past. A set of related test cases that made sense to group at some point.
    • Functionality: It is intended to relate test cases while the feature was in development. Typical associations are specific Feature Name or ticket numbers.

     

    Then there are Ways to categorize test by Testing aspects like Priority, Testing technique, Owner, Automation Status, If the test needs update.

    • Priority: P1, P2, etc. How important is the test case.
    • Testing technique: Edge Case, Negative, Positive, Security, etc.
    • Owner: Who create or update the ticket.
    • Automation status: if it was automated or not.
    • Needs Updates: If the test case was flagged that it needs some work.

     

     

    Test Plans

    Like a plan, it contains the dates, assignee and test cases.

     

    Import Test Cases

     

    File Format: The file is an Excel based file that can be obtained using LibreOffice (https://www.libreoffice.org/ ) > LibreOffice Calc > Save as > Format: Excel 2007-2019 (.xmlx)

     

    File Template: Use the attached file

     

    First Row is reserved for column names that is ignored by the importer.

    Required columns should contain values at every row.

    Optional columns may not contain values, but the column should exist.

     

    Test ID will identify the test case being imported. Following lines with the same Test ID will be considered new steps.

     

    Field Explanation

    • Test ID: Required field that identify the test case. If the row specify a test step, it is not required to be completed.
    • Product: Optional. System name that if doesn't exist it will be created.
    • Suite Type: Optional. Some valid values: Smoke, Regression, Integration
    • Test Name: Required. Name of the test case.
    • Requirement: Optional. Text about what is required to execute the test case
    • Step Description: Optional. A step to perform the test case.
    • Expected: Optional. Expected behavior for the test step
    • Extra Data: Optional. Data to be used in the test step
    • Priority: Optional. Some valid values: High, Medium, Low
    • Techniques: Optional. Some valid values: Happy_Path, Exploratory, Boundary, CRUD, Black_box, etc.
    • Components: Optional. Comma separated field, at most 3 components are imported like: component1, component2, component3. Components may or not exist in t-triage.
    • Functionality/Ticket: Optional. Any text that identify why the test was created, sometimes a ticket id.
    • Ready for Automation: Optional. Some valid values: NO, PENDING_MEDIUM, DONE
    • Owner: Optional. Username, if not specified the logged user is assumed.
    • Modifier User: Optional. Another username that is also owner or test modifier.
    • Last update: Optional. It can be a Date (10/09/2018 09:07 or 2009-08-08) or timestamp (1570314279).
    • Notes: Optional. Any text.

     

    Test Runs

     

    Test Plan List

    The list of ongoing test plans.

     

    Test Case Run

    The test cases inside a test plan that can be executed.