Changes for content/handbook/eta/css/gitlab/issues/working-issues.md: 1 added line, 77 removed lines.
Original line number
Diff line number
Diff line
@@ -377,83 +377,7 @@ In this stage the DRI will perform any needed setup to enable testing and valida
```
Once you have done all the needed setup, you need to generate task items on the issue containing the test suite you need to perform. For each test that needs to be done, you should create a child task item.
For each child task item:
- the subject/title should be the name of the thing being tested (as an example, if testing the SLA policy `Priority Support - FRT`, the subject/title should be `Priority Support - FRT`)
- the body/description should contain three sections:
-`Prerequisites`: any prerequisites for performing the test
-`Steps`: the exact steps to do the test
-`Expected Result`: details on what the expected result of the test would be
<details>
<summary>Example test item using "Support Readiness SLA"</summary>
```plaintext
## Prerequisites
- A test ticket must exist that is open
- A test ticket must use the `Support Ops` form
## Steps
1. Login to [Zendesk Global's Sandbox](https://gitlab1707170878.zendesk.com/) using the end-user `will@example.com` (login details can be found [here](https://docs.google.com/spreadsheets/d/1g6lJ3AUS4EYqoBYzAdExp4v1dkzOb3GWKaMIoZikjts/edit?usp=sharing))
2. Create a new ticket using the [Support Ops form](https://gitlab1707170878.zendesk.com/hc/en-us/requests/new?ticket_form_id=12510630404508) with the following information
- Subject: `Test from issue xxx`
- Description: `Testing`
- What type of product are you using: `GitLab.com`
- Email associated with your subscription: `will@example.com`
- Subscription number: `A-S123456789`
3. Note the ticket ID to help locate it later
4. Logout of [Zendesk Global's Sandbox](https://gitlab1707170878.zendesk.com/)
5. Login to [Zendesk Global's Sandbox](https://gitlab1707170878.zendesk.com/) as an agent account. If you do not have your own agent account, you can use `agent@example.com` (login details can be found [here](https://docs.google.com/spreadsheets/d/1g6lJ3AUS4EYqoBYzAdExp4v1dkzOb3GWKaMIoZikjts/edit?usp=sharing))
6. Locate the previously created ticket in Zendesk
7. Check the events of the ticket to confirm the SLA policy is set to `Support Readiness SLA`
## Expected Result
The ticket is using the SLA policy `Support Readiness SLA`
```
</details>
Once you have generated all child task items for your test suite, add a comment on the parent issue summarizing it. Something along the lines of:
```plaintext
## QA Test Plan
The following child test issues were created for this MR:
- LINK_TO_CHILD_TASK_ITEM
- LINK_TO_CHILD_TASK_ITEM
- LINK_TO_CHILD_TASK_ITEM
- LINK_TO_CHILD_TASK_ITEM
- LINK_TO_CHILD_TASK_ITEM
```
{{% alert title="Using our GitLab Duo agent" color="primary" %}}
We have developed a GitLab Duo agent named `CustSuppOps Zendesk Test Suite Generator`. This agent will use the merge request you are working out of (and the linked issue) to generate the test suite for you.
To use it:
1. Create your merge request (ensuring you have the description contain a link to the parent issue)
1. Click the `Add new chat` at the top-right of the page (below your profile icon)
1. Locate the agent `CustSuppOps Zendesk Test Suite Generator` and click on it
1. Ask the agent via chat to generate a test suite
As the agent runs, it will:
- State what it is doing and checking (and the logic it is using)
- Ask for approval on child task item content
- Ask for approval on adding a summary comment on the parent issue
- Summarize all actions taken
To determine if `CustSuppOps Zendesk Test Suite Generator` can run on the project you are working from, please see the corresponding handbook page for the item in question.
{{% /alert %}}
Once development has completed, you will need to do testing. For information on testing, see [CSS Testing documentation](/handbook/eta/css/testing/)
After generating the full test suite, you need to perform the tests (or ask for assistance from the SIG team in performing testing).
Changes for content/handbook/eta/css/testing/_index.md: 8 added lines, 0 removed lines.
Original line number
Diff line number
Diff line
---
title:'Testing'
description:'Documentationontesting'
---
Once you have done all the development for a change, you need to generate task items on the issue containing the test suite you need to perform. For each test that needs to be done, you should create a child task item.
You should also make a summary comment on the parent issue that links to all the child task items.
Changes for content/handbook/eta/css/testing/zendesk/_index.md: 65 added lines, 0 removed lines.
Original line number
Diff line number
Diff line
---
title:'ZendeskTesting'
description:'DocumentationontestingZendeskitems'
---
{{% alert title="This is a work in progress" color="warning" %}}
This page and the underlying pages are a work in progress. If you do not find the information you need, please speak with other members of the CSS team.
{{% /alert %}}
Testing can vary based on what is being tested. For information on testing specific items within Zendesk, please see the matching documentation.
## Manual testing
This is the default if no other mechanism is in place. This will vary based on the item being tested, so see underlying documentation for more information.
## CustSuppOps Zendesk Test Suite Generator
This is a GitLab Duo agent we have configured (located [here](https://gitlab.com/gitlab-support-readiness/duo-agents/-/automate/agents/1009244)). The agent will use the merge request you are working out of (and the linked issue) to generate the test suite for you. As the agent runs, it will:
- State what it is doing and checking (and the logic it is using)
- Ask for approval on child task item content
- Ask for approval on adding a summary comment on the parent issue
- Summarize all actions taken
To use this on projects where it is enabled, navigate to the merge request you have created, open a GitLab Duo chat, select the agent `CustSuppOps Zendesk Test Suite Generator`, and ask it to perform its task (the exact wording does not really matter).
This is a very new beta feature we are implementing. As such, it is not live in all projects and may encounter issues in running. See [gitlab-com/eta/css&28](https://gitlab.com/groups/gitlab-com/eta/css/-/work_items/28) for more information on releases and development.
Should you encounter problems using this method, please file a [Bug issue](https://gitlab.com/gitlab-com/eta/css/issue-tracker/-/issues/new?issuable_template=Bug) and assign it to `@jcolyer`. After doing so, please use an alternative method of testing.
{{% /alert %}}
### Presetup
For all items, the test suite will check to ensure all presetup has been done. At a minimum, you need the following done to run the test suite:
-`GITLAB_TOKEN` is defined in your environment
-`SB_ZD_SECRET` is defined in your environment (for Zendesk Global testing)
-`SB_ZD_CLIENT_NAME` is defined in your environment (for Zendesk Global testing)
-`US_SB_ZD_CLIENT_NAME` is defined in your environment (for Zendesk US Government testing)
-`US_SB_ZD_SECRET` is defined in your environment (for Zendesk US Government testing)
- Your local repo is in a branch that is not `master` or `main`
- An open merge request exists for your branch (and only one)
- The parent issue can be located from your branch's name (should be the numbers after the last hyphen)
It is also recommended you are prepared to generate recovery codes if the testing will require logging in as an agent.
This can vary slightly from item to item, so please check corresponding documentation for more specific needs.
### Using the tool
To use the tool:
1. Create the merge request for your changes
1. Navigate to the repo on your local computer via CLI
1. Ensure you are in the branch for your MR (example: If your branch was `jcolyer-issue-tracker-123`, you should go to the repo and run `git checkout jcolyer-issue-tracker-123`).
1. Ensure you have all needed ruby gems by running bundler (`bundle install`)
- Don't forget to remove the `Gemfile.lock` file, as it could block getting updated gems
1. Run the script using the command `./bin/perform_test_suite`
-[CustSuppOps Zendesk Test Suite Generator](./#custsuppops-zendesk-test-suite-generator)
- Zendesk US Government test mechanisms enabled:
-[CustSuppOps Zendesk Test Suite Generator](./#custsuppops-zendesk-test-suite-generator)
-[Test Suite Script](./#test-suite-script)
{{% /alert %}}
## Manual Testing Protocol
When testing group changes, there are two areas we need to confirm:
- The group exists in the sandbox after the merge request is created
- A comparable JSON object from the API matches what is in the YAML file
### The group exists in the sandbox
This is a test the Sandbox sync from the merge request created the group properly. To do this test, login to the Sandbox (as an admin), and navigate to `People > Team > Groups` in the admin panel. If the group you are creating/updating is listed there, the test passes.
### API object matches YAML object
This requires reviewing the API object from the Zendesk Sandbox and the YAML object from the file you are editing. Ensure the values of the following keys match:
-`name`
-`description`
-`default`
-`deleted`
-`is_public`
The test passes if the values between the two objects match _exactly_.
## Test Suite Script
### Presetup
Before running the script, ensure the following has been done:
-`GITLAB_TOKEN` is defined in your environment
-`SB_ZD_SECRET` is defined in your environment (for Zendesk Global testing)
-`SB_ZD_CLIENT_NAME` is defined in your environment (for Zendesk Global testing)
-`SB_ADMIN_EMAIL` is defined in your environment (for Zendesk Global testing)
-`SB_ADMIN_PASSWORD` is defined in your environment (for Zendesk Global testing)
-`US_SB_ZD_CLIENT_NAME` is defined in your environment (for Zendesk US Government testing)
-`US_SB_ZD_SECRET` is defined in your environment (for Zendesk US Government testing)
-`US_SB_ADMIN_EMAIL` is defined in your environment (for Zendesk US Government testing)
-`US_SB_ADMIN_PASSWORD` is defined in your environment (for Zendesk US Government testing)
As this will involve a login as an admin/agent, you should also have the admin page for that user ready to generate generate recovery codes.
### How it works
The script runs in "stages":
- Pre setup
- This stage defines various core functions for the script to use (various Faraday connections primarily)
- Pre tests
- This stage checks to ensure [Presetup](#presetup) has been done correctly. It will check for
- the environment variables it needs to run
- the current branch you are in is not `master` or `main`
- Defintions
- This stage defines various variables that are needed for the script to use
- GitLab Info
- This stage locates the merge request for your git branch, the corresponding parent issue, and the group changes that have been made within the merge request.
- Group tests
- This stage defines the tests to do and performs them
- For each group change detected previously, a child task item is created (linked to the parent item)
- As the tests are performed, it will add comments to the corresponding child task item with the details of the test and the results
- If browser testing was done, screenshots should be provided on the comments made
- Postrun instructions
- This stage adds a summary comment on the parent issue (linking to all child task items)
- It will also point to the location of all screenshots created in case the upload failed for any tests
For a more detailed explaination, please see the [corresponding recording](https://drive.google.com/drive/folders/1NaVVlblqe_erqNXhBmQnRsK_epb3sbSR?usp=sharing) (internal link).