> For the complete documentation index, see [llms.txt](https://learning.contextqa.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://learning.contextqa.com/web-testing/finding-and-organizing-test-cases.md). # Finding and Organizing Test Cases ## Quick answer Open **Test Cases** to search by test ID or title, or use **Filter** for creator, lifecycle status, type, priority, completed run result, dates, labels, and linked requirements. Use **Modular** view for folders and **List** view for sorting and comparison. To move a review batch to the same lifecycle stage, select its rows, choose **Change Status**, select the new status, and submit. The ContextQA **Test Cases** page is the searchable inventory for test cases and reusable step groups. Use it to locate coverage, inspect lifecycle state, organize cases with folders and labels, and select cases for list actions. ## Navigate to the test case list 1. Sign in to the required ContextQA workspace. 2. Confirm the intended workspace and version are active. 3. Select **Test Cases** in the left navigation. 4. Confirm the page heading is **Test Cases** and the subtitle reads **Manage and Execute all your Test Cases**. Use the **Test Cases** and **Step Groups** tabs to switch between executable cases and reusable step sequences. ## Understand the list The default **List** view contains these verified columns: | Column | What it shows | | -------------- | ------------------------------------------------------------------------ | | **Test Cases** | Generated `TC-` identifier and title | | **Type** | Platform, such as Browser or Mobile | | **Priority** | Assigned priority or Unassigned | | **Result** | Latest observed result, such as Passed, Failed, Aborted, or Not Executed | | **Status** | Lifecycle status, such as Ready or In Review | | **Labels** | Assigned labels or No labels | | **Created By** | Creator or System | | **Folder** | Folder name or Unorganized | | **Created At** | Creation timestamp | | **Updated At** | Last update timestamp | | **Last Run** | Last run timestamp or `-` | | **Action** | Row-level **More actions** menu | The header also includes **Search**, **Export**, the active/trash selector, **Filter**, column settings, refresh, **New Test Case**, and **List**/**Modular** view controls. ## Search for a test case 1. In **Search by ID or Title**, enter a complete or partial `TC-` identifier or title. 2. Review the matching rows and result count. 3. Open the required case from the result list. 4. Clear the search value to return to the full list. The placeholder explicitly limits the verified search scope to ID or title. Do not rely on this control to search descriptions or steps. ## Filter test cases 1. Select **Filter**. 2. Choose one or more available criteria: **Created By**, **Status**, **Test Type**, **Type**, **Priority**, **Latest Run Result**, **Created Date**, **Updated Date**, **Labels**, or **Requirements**. 3. Select **Apply Filter**. 4. Confirm the returned rows satisfy every visible criterion. 5. Clear the applied filter state before concluding that a case is missing. An empty filtered result means no visible cases match the current criteria; it does not mean the cases were deleted. The **Latest Run Result** filter contains completed outcomes: **Passed**, **Failed**, **Aborted**, and **Not Executed**. **Queued** and **Stopped** are not offered because they describe interrupted or in-flight execution rather than a settled test result. ### Filter by requirement The **Requirements** filter narrows the list to test cases linked to specific requirement files. It appears on the **Test Cases** tab only, not on **Step Groups**. 1. Select **Filter**, then open the **Requirements** filter. 2. In **Select requirement files**, search for a requirement, then select one or more entries. Each entry is labeled by its requirement ID and name, such as `REQ-42: Checkout flow`. A requirement with no name still appears as its ID alone, such as `REQ-42`, so you can always select it. 3. Select **Apply Filter**. To create requirement files and link them to test cases, see [Requirements management](/web-testing/requirements-management.md). ## Sort the list Select a sortable column heading to change its order. The verified sortable headings are **Test Cases**, **Priority**, **Created By**, **Folder**, **Created At**, **Updated At**, and **Last Run**. Select the same heading again to reverse the direction, then verify the first rows follow the selected order. ## Move between result pages 1. At the bottom of the table, open **Rows per page** to choose how many cases appear. 2. Review the displayed range and total, for example `1–10 of 7172`. 3. Use the next or previous page controls. 4. Confirm that the displayed range and rows change. ## Select test cases Use **Select row** to select one case or **Select all rows** to select the rows available to the table selection control. The bulk-action toolbar appears after you select at least one row. ### Change the status of several test cases 1. Select the required test case rows. 2. In the bulk-action toolbar, select **Change Status**. 3. Choose **Draft**, **In Review**, **Ready**, **Obsolete**, **Rework**, or **Approved**. 4. Select **Submit**. 5. Confirm the updated status appears on every selected case. Use bulk status changes when a review batch moves to the same lifecycle stage. Review the selection count before submitting; the change applies to every selected case, including selections retained across result pages. Other bulk actions can include moving cases, editing fields, adding labels, exporting, or deleting, depending on the current view and permissions. Review the displayed action and selection count before proceeding, and use disposable cases when validating a destructive action. ## Use List and Modular views * **List** presents sortable metadata in a table and is best for search, status review, and comparison. * **Modular** presents folder-based organization and is best when browsing the functional structure. The list shows **Unorganized** when a test case has no folder assignment. ## Create a test case folder Folder creation is available in **Modular** view. If you are in **List** view, switch views before looking for the folder action. 1. Open **Test Cases** and select the **Test Cases** tab. 2. Select **Modular**. 3. In the **Folders** panel, select the **+** (**New folder**) action. 4. Enter a folder name. If needed, choose a parent folder and color. 5. Select **Create folder**. ContextQA selects the new folder after creating it. To organize existing cases, select the cases, choose **Move to Folder**, select the destination, and confirm the move. Moving a case changes its location; it does not delete or duplicate the case. ![Test Cases in Modular view with the New folder action in the Folders panel](/files/pUe5ihslmuW6yl61HNnZ) ## Organize cases with folders and labels Folders provide the primary visible hierarchy in the test case inventory. Labels provide cross-cutting classification and filtering. * Use a folder for a stable functional area, such as `Authentication` or `Checkout`. * Use labels for attributes that can span folders, such as `Smoke`, `Security`, or `Integration`. * Use **Status** for workflow state, not functional grouping. * Use **Priority** for business or failure impact, not test type. A case can display a folder and multiple labels in the list. The current list also supports **Unorganized** for cases without a folder. ## Test case, step group, test suite, and test plan | Object | Use it for | | ---------- | ---------------------------------------------------------------------- | | Test case | One independently maintainable scenario and expected outcome | | Step group | A reusable sequence, such as shared sign-in setup | | Folder | Navigating a functional hierarchy in the test inventory | | Label | Filtering cases across folders by a shared attribute | | Test suite | Grouping cases that should be managed or executed together | | Test plan | Defining an execution strategy and configuration for selected coverage | Do not duplicate a test case only to place the same behavior in another execution grouping. Reuse the case through the supported suite or plan relationship instead. ## Practical authentication example Create these cases using the naming pattern `[Area] — [User action] — [Expected outcome]`: * `Authentication — Sign in — Valid credentials` * `Authentication — Sign in — Invalid password` * `Authentication — Reset password — Registered email` For each case, use a fictional test account and add steps that navigate to the sign-in page, perform the named action, and verify the observable result. Place the cases in the `Authentication` folder if that folder exists, and apply `Smoke` only to the minimum release-blocking path. Add the related cases to an authentication suite when they should execute together; configure execution in a test plan rather than encoding browser or environment names in each case title. To verify the organization, search for `Authentication`, filter by the chosen label, open each case to confirm its steps, and inspect its relationships. A common mistake is using `Ready` as a functional category; correct it by using a folder or label and reserve **Status** for review state. ## Organization guidelines for large teams * Name cases after observable behavior and keep one primary outcome per case. * Search before creating a case to avoid duplicate coverage. * Use a step group for genuinely reusable setup. * Keep volatile environment details out of names; use execution configuration. * Create a new suite only for a meaningful reusable grouping. * Create a new plan only when the execution selection or configuration differs. * Move obsolete cases to Trash only after reviewing relationships and history; permanently delete only when retention is not required. ## Troubleshooting | Problem | Likely cause | Resolution | | ---------------------------- | ---------------------------------------------------------------------- | ------------------------------------------------------------------------------------------- | | Search returns no rows | The text is not in the ID or title | Search with a shorter title fragment or the `TC-` identifier. | | An expected case is missing | Search, filters, pagination, workspace/version, or Trash state differs | Clear search and filters, check the workspace/version and result pages, then inspect Trash. | | A case shows **Unorganized** | No folder is assigned | Assign the case to the appropriate functional folder if your process uses folders. | | A sort appears ineffective | Values on the current page are identical or blank | Check the sort indicator and compare a column with distinct values. | ## Limitations and permissions * Search was verified for the UI contract **Search by ID or Title**; description and step search were not verified. * Saved views and reusable saved filters were not present in the tested list. * A separate archive lifecycle was not present; the verified lifecycle uses Trash, Restore, and Delete Forever. * Available bulk actions and selection limits can vary by view and permission. **Change Status** is available on the active Test Cases list. * Permission differences were not verified across multiple roles. ## Related documentation * [Create test cases](/web-testing/creating-test-cases.md) * [Manage test cases](/web-testing/managing-test-cases.md) * [Manage test suites](/web-testing/managing-test-suites.md) * [Create and run test plans](/web-testing/test-plans.md) * [Reuse steps with step groups](/web-testing/step-groups-tutorial.md) ## Frequently asked questions ### How do I find a test case in ContextQA? Open **Test Cases** and search by its `TC-` identifier or title. Clear filters and check Trash if it is not in the active results. ### What is the difference between a folder and a label? A folder provides a navigable functional location; a label provides a cross-cutting filter that can classify cases from different folders. ### Does ContextQA support archive? No separate **Archive** action was present in the verified test case UI. Use recoverable Trash for removal, and reserve **Delete Forever** for irreversible cleanup. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://learning.contextqa.com/web-testing/finding-and-organizing-test-cases.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.