diff --git a/src/pages/docs/FAQs/web-apps/how-to-turnoff-onboarding-tutorial.md b/src/pages/docs/FAQs/web-apps/how-to-turnoff-onboarding-tutorial.md
index 3c830987..9c5db9e9 100644
--- a/src/pages/docs/FAQs/web-apps/how-to-turnoff-onboarding-tutorial.md
+++ b/src/pages/docs/FAQs/web-apps/how-to-turnoff-onboarding-tutorial.md
@@ -24,10 +24,10 @@ Testsigma displays informative tutorials while onboarding new users. By default,
1. From the left navigation bar, go to to **Settings > Preferences**.
- 
+ 
2. Disable the toggle on **Disable Onboarding Tutorials**.
- 
+ 
---
\ No newline at end of file
diff --git a/src/pages/docs/agent/connect-android-local-devices.md b/src/pages/docs/agent/connect-android-local-devices.md
index 06edcc19..6df062d2 100644
--- a/src/pages/docs/agent/connect-android-local-devices.md
+++ b/src/pages/docs/agent/connect-android-local-devices.md
@@ -51,15 +51,15 @@ Testsigma allows you to run tests on your local Android devices in addition to T
6. Navigate to **Agents** page in Testsigma app and click on the registered agent.
-
+
7. Under **Devices**, you can see the device that is connected to the registered agent as shown below.
-
+
8. To execute android tests on this Device, you can select the **Connected Machine** and **Device**.
-
+
[[info | NOTE:]]
diff --git a/src/pages/docs/agent/trigger-tests-locally.md b/src/pages/docs/agent/trigger-tests-locally.md
index a1503d38..65e78b67 100644
--- a/src/pages/docs/agent/trigger-tests-locally.md
+++ b/src/pages/docs/agent/trigger-tests-locally.md
@@ -34,25 +34,25 @@ With Testsigma, you can execute the tests on local devices from another device u
## **Steps to Trigger Tests on Local Devices**
1. Install and register **Testsigma Agent** on the target machine.
-
+
-1. Navigate to **Test Plans** from the **Dashboard** and select the Test Plan where you want to add local machines.
-
+2. Navigate to **Test Plans** from the **Dashboard** and select the Test Plan where you want to add local machines.
+
-1. Click on **Edit**.
-
+3. Click on **Edit**.
+
-1. On the **Add Test Suites & Link Machine Profiles** sections, click on **Link Test Machine**.
-
+4. On the **Add Test Suites & Link Machine Profiles** sections, click on **Link Test Machine**.
+
-1. On **Select test machine profiles** overlay, click on **Add Machine**.
-
+5. On **Select test machine profiles** overlay, click on **Add Machine**.
+
-1. On **Add test machine/device profile** overlay, add **Name**, select **Local Devices**, active agent on **Connected Machine** dropdown, and **Browser**. Click on **Create Profile**.
-
+6. On **Add test machine/device profile** overlay, add **Name**, select **Local Devices**, active agent on **Connected Machine** dropdown, and **Browser**. Click on **Create Profile**.
+
-1. Click on **Save Selection**.
-
+7. Click on **Save Selection**.
+
Now, your test plan is ready for execution from any machine.
@@ -60,13 +60,6 @@ Now, your test plan is ready for execution from any machine.
| You can edit & add the local machines to test suites from any device, provided you have the agent active in the target machine.
8. Navigate to the same test plan from any machine with the same account and click on **Run Now** to execute the Test Plan.
-
-
-
-
-
-
-Here’s a quick GIF demonstrating triggering tests on local devices.
-
+
---
\ No newline at end of file
diff --git a/src/pages/docs/collaboration/manage-execution-stops.md b/src/pages/docs/collaboration/manage-execution-stops.md
index 61220a89..7d8910c7 100644
--- a/src/pages/docs/collaboration/manage-execution-stops.md
+++ b/src/pages/docs/collaboration/manage-execution-stops.md
@@ -41,10 +41,10 @@ Super Admins control the stopping of executions by users in **Usage Details** an
## **Enabling Stop Executions Preference**
1. Navigate to **Settings** > **Preferences**.
-
+
2. Enable the toggle switch for the **Control Who Can Stop Executions** feature flag, which will be toggled off by default.
-
+
[[info | NOTE:]]
diff --git a/src/pages/docs/configuration/manage-access.md b/src/pages/docs/configuration/manage-access.md
index 9bdac806..7ad0feaa 100644
--- a/src/pages/docs/configuration/manage-access.md
+++ b/src/pages/docs/configuration/manage-access.md
@@ -12,9 +12,6 @@ contextual_links:
- type: link
name: "Prerequisites"
url: "#prerequisites"
-- type: link
- name: "Interactive Demo"
- url: "#interactive-demo"
- type: link
name: "Managing Access"
url: "#managing-access"
@@ -41,32 +38,27 @@ Admin in the Testsigma account can grant temporary access to the Testsigma Suppo
---
-## **Interactive Demo**
-
-
-
----
-
## **Managing Access**
1. From the **Dashboard**, go to **Settings > Admin Settings > Manage Access**.
+
2. In the **Manage Access** section, click **Allow Access**.
+
3. Select the **Access Type** from the available options.
+
4. In the **Describe the Issue** field, briefly explain the reason for providing access.
+
5. Select the consent checkbox and click **Submit** to grant access.
+
6. View the **Current Status** and **Access Expiry** information on the same page.
7. Click **Manage** to update or revoke access as needed.
+
---
@@ -85,10 +77,10 @@ Admin in the Testsigma account can grant temporary access to the Testsigma Suppo
## **View Access Logs**
- View access-related logs by clicking **Activity** in the **Utility Panel**. The system stores logs for 3 years.
- 
+ 
- You can also view logs in the relevant test cases, elements, test suites, and test plans for actions performed by **Testsigma Guest**.
- 
+ 
---
\ No newline at end of file
diff --git a/src/pages/docs/continuous-integration/codeship-ci.md b/src/pages/docs/continuous-integration/codeship-ci.md
index b5e521c8..93e6fcd8 100644
--- a/src/pages/docs/continuous-integration/codeship-ci.md
+++ b/src/pages/docs/continuous-integration/codeship-ci.md
@@ -61,11 +61,11 @@ Testsigma offers powerful webhooks for triggering Testsigma executions remotely
-1. Go to the Testsigma Executions page to get the execution ID. Refer to the [documentation on getting the execution ID](https://testsigma.com/docs/continuous-integration/get-test-plan-details/) and [documentation on generating API keys](https://testsigma.com/docs/configuration/api-keys/) as shown below:
-
+6. Go to the Testsigma Executions page to get the execution ID. Refer to the [documentation on getting the execution ID](https://testsigma.com/docs/continuous-integration/get-test-plan-details/) and [documentation on generating API keys](https://testsigma.com/docs/configuration/api-keys/) as shown below:
+
-1. Replace the **<execution-ID>**, **<Username>** and **<Password>** in the following script:
+7. Replace the **<execution-ID>**, **<Username>** and **<Password>** in the following script:
Perl
diff --git a/src/pages/docs/elements/android-apps/record-multiple-elements.md b/src/pages/docs/elements/android-apps/record-multiple-elements.md
index 992061b0..c856e8bb 100644
--- a/src/pages/docs/elements/android-apps/record-multiple-elements.md
+++ b/src/pages/docs/elements/android-apps/record-multiple-elements.md
@@ -38,15 +38,15 @@ When automating test cases for an android application, you can capture multiple
## **Steps to Record Multiple Elements**
1. From the left navigation bar, go to **Create Tests > Elements**.
-
+
-2. Click on **Record**.
-
+2. Click **Record**.
+
-3. On **Record Elements** overlay, select **Test Lab**, **Test Machine**, **Upload App Source** and click on **Record**.
-
+3. In the **Record Elements** overlay, select **Test Lab**, **Test Machine**, **Upload App Source** and click on **Record**.
+
4. Wait for the app to load fully.
@@ -55,11 +55,11 @@ When automating test cases for an android application, you can capture multiple
5. Once the app is loaded, click on element you want to capture.
-6. On the **Create Element** section, validate the **Name**, **Screen Name**, **Element Type**, and the **Value**.
+6. In the **Create Element** section, validate the **Name**, **Screen Name**, **Element Type**, and the **Value**.
-7. Click on **Create**.
+7. Click **Create**.
@@ -69,10 +69,9 @@ When automating test cases for an android application, you can capture multiple
9. Repeat steps 5 to 7 for every element you want to capture.
-10. Once you have captured the elements, click on **Stop Recording**.
+10. Once you have captured the elements, click **Stop Recording**.
11. You'll be redirected to the **Elements** page, where you can see all recorded elements.
-
---
\ No newline at end of file
diff --git a/src/pages/docs/elements/mobile-web-application/create-manually.md b/src/pages/docs/elements/mobile-web-application/create-manually.md
index 3a12ecc8..0724e352 100644
--- a/src/pages/docs/elements/mobile-web-application/create-manually.md
+++ b/src/pages/docs/elements/mobile-web-application/create-manually.md
@@ -36,27 +36,26 @@ In dynamic websites, elements can have varying attributes/properties across sess
## **Steps to Create an Element**
-1. Navigate to **Create Tests > Elements**.
-
+1. From the left navigation bar, navigate to **Create Tests > Elements**.
+
-2. Click on **Create**.
-
+2. Click **Create Element**.
+
-3. On **Create Element** Overlay, enter all the details:
-
+3. In the **Create Element** Overlay, enter all the details:
+
- **Name:** Enter the name you want to give your element.
- **Screen Name:** Mention the screen that your element resides on.
- **Element Type:** There are 5 types of element types supported in Testsigma. This field is a drop-down list; you can select any of them: **XPATH**, **ID**, **Name**, **Class Name**, or **Accessibility ID**.
- **Enter Value:** Enter the value corresponding to the **Element Type** you selected.
-4. Click on **Create Element**.
-
+4. Click **Create Element**.
+
5. The element will be saved in the elements list.
-
---
\ No newline at end of file
diff --git a/src/pages/docs/elements/mobile-web-application/record-elements.md b/src/pages/docs/elements/mobile-web-application/record-elements.md
index 8d4edf29..dac4f6d6 100644
--- a/src/pages/docs/elements/mobile-web-application/record-elements.md
+++ b/src/pages/docs/elements/mobile-web-application/record-elements.md
@@ -40,7 +40,7 @@ Using the **Testsigma Recorder**, you can swiftly capture elements in mobile web
## **Steps to Record Elements for Mobile Web Apps**
1. From the left navigation bar, go to **Create Tests > Elements**, and click **Record**.
-
+
2. This will open a new window. Enter the URL from which you want to capture the elements. The **Testsigma Recorder** will appear and be ready to start recording. In this case, we are recording elements for the 1mg website.
@@ -65,7 +65,7 @@ Using the **Testsigma Recorder**, you can swiftly capture elements in mobile web
| Some devices might have unique characteristics that will affect element display and interaction, and adding a custom device required for your testing is necessary to identify and resolve these issues.
-6. Once you have selected the dimension, capture elements by clicking on them directly.
+6. Once the dimension is selected, click directly on the elements to capture them, and click **Stop** when you are done capturing the required elements.
---
\ No newline at end of file
diff --git a/src/pages/docs/reports/runs/filter-custom-reports.md b/src/pages/docs/reports/runs/filter-custom-reports.md
index b8e074c4..61a49d64 100644
--- a/src/pages/docs/reports/runs/filter-custom-reports.md
+++ b/src/pages/docs/reports/runs/filter-custom-reports.md
@@ -35,32 +35,26 @@ Quickly view the run results of a test plan by applying filters | Learn how to a
## **Applying Filters on the Run Results Page**
1. From the left navigation bar, go to **Run Results** and click on the test plan for which you want to check the results.
- 
+ 
2. By default, you’ll see the results at test suite level.
- 
+ 
3. To apply filters to the **Test Runs** panel, click the **Filters** icon on the panel.
- 
+ 
4. Add the desired filters and click **Apply**.
- 
+ 
5. To apply filters to the tests, select **Test Cases, Suites, or Machines** from the dropdown menu, then click the **Filters** icon.
- 
+ 
6. Add the desired filters and click **Apply**.
- 
+ 
7. You can click a status in the chart within the **Run Overview** to apply additional filters on top of it.
-
-
-Here's a quick GIF demonstrating how to apply filters on the run results Page.
-
- 
+ 
*For more information on viewing and downloading results of a test plan on test case, test suite or test machine levels, refer to the [documentation on test plan run results](https://testsigma.com/docs/reports/runs/drill-down-reports/).*
-
-
---
\ No newline at end of file
diff --git a/src/pages/docs/test-cases/create-steps-restapi/api-request.md b/src/pages/docs/test-cases/create-steps-restapi/api-request.md
index d72e889e..50071e4d 100644
--- a/src/pages/docs/test-cases/create-steps-restapi/api-request.md
+++ b/src/pages/docs/test-cases/create-steps-restapi/api-request.md
@@ -34,9 +34,9 @@ If you have a request you want to run, you will need to know the **URL**, **meth
Using request URLs in a Restful API allows you to control which URLs are sent to the server when your request is a resource. Testsigma requires an **API endpoint URL** for each request. Each operation you can perform using an API is typically associated with an endpoint.
-1. The URL will typically be the base location plus the path. For example, if you take the base **URL** https://jsonplaceholder.typicode.com/, if you add **/get** to it, it will be the **endpoint path**. 
+1. The URL will typically be the base location plus the path. For example, if you take the base **URL** https://jsonplaceholder.typicode.com/, if you add **/get** to it, it will be the **endpoint path**. 
-2. In a **parameterized URL**, you can **insert test data** by double-clicking on the URL and selecting the **test data type**. For example, https://@reqes.in/api/users?page=@page is the base URL,**?page=page** is a parameter, and **@reqes** and **@page** are **test data types** inserted in the URL. Select the method; by default, it will be **GET**. Click **Send**. 
+2. In a **parameterized URL**, you can **insert test data** by double-clicking on the URL and selecting the **test data type**. For example, https://@reqes.in/api/users?page=@page is the base URL,**?page=page** is a parameter, and **@reqes** and **@page** are **test data types** inserted in the URL. Select the method; by default, it will be **GET**. Click **Send**. 
[[info | NOTE:]]
|For more information on creating test data types, refer to the [documentation on creating test data types](https://website.testsigma.com/docs/test-data/types/overview/) for more information.
@@ -49,7 +49,7 @@ By Default, Testsigma will select the **GET** method for new requests. **GET** m
- **POST** - Add new data.
- **PUT** - Replace existing data.
- **PATCH** - Update some existing data fields.
-- **DELETE** - Delete existing data. 
+- **DELETE** - Delete existing data. 
---
@@ -57,8 +57,7 @@ By Default, Testsigma will select the **GET** method for new requests. **GET** m
In Testsigma, we support Unicode characters in various aspects of testing, such as [documentation on creating parameters](https://testsigma.com/docs/test-cases/create-steps-restapi/adding-parameters/), [documentation on creating request body data](https://testsigma.com/docs/test-cases/create-steps-restapi/add-body-data/), [documentation on adding verifications](https://testsigma.com/docs/test-cases/create-steps-restapi/verifications-request/), [documentation on storing variables](https://testsigma.com/docs/test-cases/create-steps-restapi/store-variables/), and [documentation on storing objects](https://testsigma.com/docs/test-cases/create-steps-restapi/stored-objects/). This enables you to enter and retrieve data in your native language and script, making the testing process more user-friendly and accessible. Moreover, adding Unicode characters to verifications ensures the verification process accurately represents the tested data.
-Here is a quick gif demonstrating how to add Unicode in RESTful API.
-
+
[[info | NOTE:]]
| To enter Unicode characters, copy & paste the characters into the required field.
diff --git a/src/pages/docs/test-cases/create-steps-restapi/authorization-request.md b/src/pages/docs/test-cases/create-steps-restapi/authorization-request.md
index bd9e9d63..d051ecb1 100644
--- a/src/pages/docs/test-cases/create-steps-restapi/authorization-request.md
+++ b/src/pages/docs/test-cases/create-steps-restapi/authorization-request.md
@@ -20,8 +20,6 @@ APIs require authentication information, which you can provide in Testsigma. Aut
- Fill in the required fields based on your authorization.
-- Once your authorization details are set up, click **Create** and save your request.
-
-
+
---
\ No newline at end of file
diff --git a/src/pages/docs/test-cases/create-steps-restapi/verifications-request.md b/src/pages/docs/test-cases/create-steps-restapi/verifications-request.md
index d200a074..7b60e784 100644
--- a/src/pages/docs/test-cases/create-steps-restapi/verifications-request.md
+++ b/src/pages/docs/test-cases/create-steps-restapi/verifications-request.md
@@ -59,7 +59,7 @@ You can verify the response body in three ways.
2. Click **Outline**, then select **Add verification** to upload it directly into **Verification** tab.
- 
+ 
[[info | NOTE:]]
| - Navigate to **Verification** > **Response Body** tab, and click **Add Verification** to add the field manually.
@@ -72,28 +72,32 @@ You can verify the response body in three ways.
2. Hover over the HTML lines in the **Response Body** and select the attribute to add for verification. This action automatically adds the attribute and its value to the **Verifications** tab.
- 
+ 
### **Copy Response from Response body**
-Click **copy response**. It will copy to the **clipboard**, paste the **JSON** or **XPATH** path field, and select the **verification type** from the drop-down list. Enter an **expected value** by using plain text or **test data types**. Click **Create** to add verification.
+Click **copy response**.
+
+ 
- 
+It will copy to the **clipboard**, paste the **JSON** or **XPATH** path field, and select the **verification type** from the drop-down list. Enter an **expected value** by using plain text or **test data types**. Click **Create** to add verification.
+
+ 
### **Verify Response body**
The following are two ways to verify the response body.
1. **Before Invoking API**
- 1. Click the **Verify Response Body**. This will open the Verify Response Body overlay screen.
- 2. Select the **Comparison Type**, **Response Body Type**, and **Verification type** from the drop-down list. Enter the expected value that you wish to compare and verify, then click the **Create** to save your API. 
+ 1. Click the **Verify Response Body**. This will open the Verify Response Body overlay screen.
+ 2. Select the **Comparison Type**, **Response Body Type**, and **Verification type** from the drop-down list. Enter the expected value that you wish to compare and verify, then click the **Create** to save your API. 
-2. **After Invoking API**
- 1. Click **verify response body**. The Verify Response Body overlay screen will appear.
- 2. Open the comparison and **verification types** drop-down lists to select them. Click **Create** to add verification. 
+2. **After Invoking API**
+ 1. Click **verify response body**. The Verify Response Body overlay screen will appear.
+ 2. Select **Comparison Type** and **Verification Type** from the drop-down lists. Click **Create** to add verification. 
---
## **Headers Verification**
@@ -102,13 +106,13 @@ Headers Verification in RESTful API Testing is the process of verifying that the
### **Add Verification in Headers Tab**
-Click **Add Verification** in the **Headers** tab. Enter the **JSON path**, enter the **expected value** in the field, and you can enter **test data types** in the Value field. Choose the **verification type** by opening the drop-down list. Click **Create** to add verification.
-
+Click **Add Verification** in the **Headers** tab. Enter the **JSON path**, enter the **expected value** in the field, and you can enter **test data types** in the Value field. Choose the **verification type** from the drop-down list. Click **Create** to add verification.
+
### **Mousehover to Response Field**
At the bottom of the page, click the **Headers** tab, mouse over to the variable, and click **Add Verification**; it will update in the Verification **headers** tab.
-
+
---
@@ -118,13 +122,13 @@ Status verification in RESTful API testing is the process of verifying that the
### **Add Verification in Status Tab**
-Click **Add Verification** in the **Status tab**. Select the **key name** by opening the drop-down list, enter the **expected value** in the field, and you can enter **test data types** in the Value field. Select the **verification type** by opening the drop-down list.
-
+Click **Add Verification** in the **Status tab**. Select the **key name** from the drop-down list, enter the **expected value** in the field, and you can enter **test data types** in the Value field. Select the **verification type** from the drop-down list.
+
### **Mousehover to Response Field**
At the bottom of the page, click the **Status tab**, mouse over to the variable, and click **Add Verification**; it will update in the Verification Status tab.
-
+
---
diff --git a/src/pages/docs/test-data/data-generators/mailboxaliasfunctions-function-type.md b/src/pages/docs/test-data/data-generators/mailboxaliasfunctions-function-type.md
index 07830687..f23c9228 100644
--- a/src/pages/docs/test-data/data-generators/mailboxaliasfunctions-function-type.md
+++ b/src/pages/docs/test-data/data-generators/mailboxaliasfunctions-function-type.md
@@ -62,10 +62,20 @@ MailBoxAlias Functions enable dynamic interaction with email data in testing and
## **Selecting MailboxAliasFunctions as a Function Type for Data Generator**
-1. Use **NLP** to create a **new step** in the test case and include a placeholder for **test data**.
-2. Click on the **test data** placeholder. From the **Test Data Types** dropdown menu, select the **! Data Generator** option.
-3. On the **! Data Generators** overlay screen, select the **Type** to **Default**. This will enable you to use a collection of built-in test data generators.
-4. Select **MailboxAliasFunctions** from the **Function Type** dropdown list. 
+1. From the left navigation bar, go to **Create Tests > Test Cases** and create a new test case.
+
+
+2. Use **NLP** to create a **new step** in the test case and include a placeholder for **test data**.
+
+
+3. Click on the **test data** placeholder. From the **Test Data Types** dropdown menu, select the **! Data Generator** option.
+
+
+4. On the **! Data Generators** overlay screen, select the **Type** to **Default**. This will enable you to use a collection of built-in test data generators.
+
+
+5. Select **MailboxAliasFunctions** from the **Function Type** dropdown list.
+
[[info | NOTE:]]
| This action will display a list of built-in functions associated with the MailboxAliasFunctions function type, enabling you to select the appropriate function based on your requirements.
diff --git a/src/pages/docs/testsigma-tunnel/setup-installation-kubernetes.md b/src/pages/docs/testsigma-tunnel/setup-installation-kubernetes.md
new file mode 100644
index 00000000..d70ea533
--- /dev/null
+++ b/src/pages/docs/testsigma-tunnel/setup-installation-kubernetes.md
@@ -0,0 +1,627 @@
+---
+title: "Setup and Installation: Kubernetes (Helm)"
+metadesc: "Learn how to deploy Testsigma Tunnel on Kubernetes using Helm to test locally hosted applications, configure it securely, and manage the deployment over time."
+noindex: false
+order: 34.7
+page_id: "Testsigma Tunnel"
+warning: false
+contextual_links:
+- type: section
+ name: "Contents"
+- type: link
+ name: "Prerequisites"
+ url: "#prerequisites"
+- type: link
+ name: "How the Tunnel Works"
+ url: "#how-the-tunnel-works"
+- type: link
+ name: "Create the Helm Chart"
+ url: "#create-the-helm-chart"
+- type: link
+ name: "Configure Your Values File"
+ url: "#configure-your-values-file"
+- type: link
+ name: "Deploy the Chart"
+ url: "#deploy-the-chart"
+- type: link
+ name: "Verify the Deployment"
+ url: "#verify-the-deployment"
+- type: link
+ name: "Configuration Reference"
+ url: "#configuration-reference"
+- type: link
+ name: "Manage Secrets"
+ url: "#manage-secrets"
+- type: link
+ name: "Scale and Manage the Tunnel"
+ url: "#scale-and-manage-the-tunnel"
+- type: link
+ name: "Update the Tunnel"
+ url: "#update-the-tunnel"
+- type: link
+ name: "Advanced Configuration"
+ url: "#advanced-configuration"
+- type: link
+ name: "Troubleshoot"
+ url: "#troubleshoot"
+---
+
+---
+
+The Testsigma Tunnel Client creates a secure connection between your Kubernetes cluster and the Testsigma platform. This connection lets you run automated tests against applications deployed in private networks or behind firewalls, without exposing those applications to the public internet.
+
+This article discusses how to deploy the Testsigma Tunnel Client on Kubernetes using a Helm chart, configure it securely, and manage the deployment over time.
+
+---
+
+> Prerequisites
+>
+> Before you begin, ensure that you have:
+> 1. Referred to the [documentation on key components](https://testsigma.com/docs/testsigma-tunnel/key-components/).
+> 2. A Kubernetes cluster running version 1.19 or later.
+> 3. Helm 3.x installed on your local machine.
+> 4. kubectl configured with access to your cluster.
+> 5. Kubernetes nodes labeled with the appropriate **pool-type** value (for example, **app** or **common**).
+
+---
+
+## **How the Tunnel Works**
+
+When you deploy the Helm chart, it creates the following Kubernetes resources:
+
+| Resource | Description |
+|---|---|
+| **StatefulSet** | Runs the tunnel client pods using an OrderedReady pod management policy. Pods start one at a time in sequence. |
+| **ConfigMap** | Mounts the tunnel configuration file (args.yaml) into each container at startup. |
+| **Service** | (Optional) Provides a headless service for StatefulSet DNS resolution, required when you deploy multiple replicas. |
+
+The chart uses a StatefulSet with an **OrderedReady** pod management policy. This policy ensures that the first pod registers the tunnel with the Testsigma server before any additional pods start. Each subsequent pod then joins the already-registered tunnel session rather than attempting to create a new registration.
+
+[[info | Note:]]
+| If you use a standard Deployment instead of a StatefulSet, all replicas start simultaneously. This creates a race condition in which multiple pods attempt to register the same tunnel at the same time. The StatefulSet prevents this.
+
+---
+
+## **Create the Helm Chart**
+
+Follow these steps to build the Helm chart directory from scratch. If you already have a chart, skip to **Configure Your Values File**.
+
+### **Step 1: Create the Chart Directory Structure**
+
+Run the following commands to create the required directories:
+
+```bash
+mkdir -p testsigma-tunnel/templates
+cd testsigma-tunnel
+```
+
+When you finish creating all the files described in the following steps, your chart directory should have this structure:
+
+```
+testsigma-tunnel/
+├── Chart.yaml
+├── values.yaml
+└── templates/
+ ├── deployment.yaml
+ ├── configmap.yaml
+ └── service.yaml
+```
+
+### **Step 2: Create Chart.yaml**
+
+Create a file named **Chart.yaml** in the **testsigma-tunnel/** directory with the following content:
+
+```yaml
+apiVersion: v2
+name: testsigma-tunnel
+description: Helm chart for Testsigma Tunnel Client
+type: application
+version: 0.1.0
+appVersion: "0.1.0"
+```
+
+### **Step 3: Create the StatefulSet Template**
+
+Create **templates/deployment.yaml**. This template defines the StatefulSet that runs the tunnel client pod and mounts the configuration file.
+
+```yaml
+{{- range $name, $deployment := .Values.Deployments }}
+{{- if $deployment.enabled }}
+---
+kind: StatefulSet
+apiVersion: apps/v1
+metadata:
+ name: {{ (index $.Values.Application $name).name }}-{{ $.Values.Environment.name }}-statefulset
+ labels:
+ app: {{ (index $.Values.Application $name).name }}-{{ $.Values.Environment.name }}
+ namespace: {{ (index $.Values.Namespace $name).name }}
+spec:
+ serviceName: {{ (index $.Values.Application $name).name }}-{{ $.Values.Environment.name }}-headless
+ replicas: {{ $deployment.replicas }}
+ podManagementPolicy: OrderedReady
+ selector:
+ matchLabels:
+ app: {{ (index $.Values.Application $name).name }}-{{ $.Values.Environment.name }}
+ template:
+ metadata:
+ labels:
+ app: {{ (index $.Values.Application $name).name }}-{{ $.Values.Environment.name }}
+ spec:
+ containers:
+ - name: {{ (index $.Values.Application $name).name }}-{{ $.Values.Environment.name }}
+ image: {{ $deployment.containers.image }}:{{ $deployment.containers.version }}
+ imagePullPolicy: {{ $deployment.containers.imagePullPolicy }}
+ volumeMounts:
+ - name: config
+ mountPath: /app/args.yaml
+ subPath: args.yaml
+ readOnly: true
+ volumes:
+ - name: config
+ configMap:
+ name: {{ (index $.Values.Application $name).name }}-{{ $.Values.Environment.name }}-config
+ nodeSelector:
+ pool-type: {{ $deployment.poolType }}
+{{- end }}
+{{- end }}
+```
+
+### **Step 4: Create the ConfigMap Template**
+
+Create **templates/configmap.yaml**. This template generates a ConfigMap that contains your tunnel configuration and mounts it as a file inside the container.
+
+```yaml
+{{- range $name, $deployment := .Values.Deployments }}
+{{- if $deployment.enabled }}
+---
+apiVersion: v1
+kind: ConfigMap
+metadata:
+ name: {{ (index $.Values.Application $name).name }}-{{ $.Values.Environment.name }}-config
+ namespace: {{ (index $.Values.Namespace $name).name }}
+ labels:
+ app: {{ (index $.Values.Application $name).name }}-{{ $.Values.Environment.name }}
+data:
+ args.yaml: |
+ key: {{ $deployment.config.key | quote }}
+ tunnel-name: {{ $deployment.config.tunnelName | quote }}
+ verbose: {{ $deployment.config.verbose }}
+ {{- if $deployment.config.delegateSslValidation }}
+ delegate-ssl-validation: {{ $deployment.config.delegateSslValidation }}
+ {{- end }}
+ {{- if $deployment.config.proxy }}
+ proxy: {{ $deployment.config.proxy | quote }}
+ {{- end }}
+ {{- if $deployment.config.headerRules }}
+ header-rules:
+ {{- toYaml $deployment.config.headerRules | nindent 6 }}
+ {{- end }}
+{{- end }}
+{{- end }}
+```
+
+### **Step 5: (Optional) Create the Headless Service Template**
+
+If you need DNS resolution for StatefulSet pods, create **templates/service.yaml**. This file is required when you set **enabledStatefulSet: true** in your values file.
+
+```yaml
+{{- range $name, $deployment := .Values.Deployments }}
+{{- if $deployment.enabled }}
+{{- if $deployment.enabledStatefulSet }}
+---
+apiVersion: v1
+kind: Service
+metadata:
+ name: {{ (index $.Values.Application $name).name }}-{{ $.Values.Environment.name }}-headless
+ namespace: {{ (index $.Values.Namespace $name).name }}
+ labels:
+ app: {{ (index $.Values.Application $name).name }}-{{ $.Values.Environment.name }}
+spec:
+ clusterIP: None
+ selector:
+ app: {{ (index $.Values.Application $name).name }}-{{ $.Values.Environment.name }}
+ ports:
+ - protocol: TCP
+ port: 80
+ targetPort: 80
+{{- end }}
+{{- end }}
+{{- end }}
+```
+
+---
+
+## **Configure Your Values File**
+
+Create a **values.yaml** file in the **testsigma-tunnel/** directory. Use the following example as a starting point, and replace the placeholder values with your own.
+
+```yaml
+Environment:
+ name: production # Environment name (production, staging, etc.)
+
+Application:
+ myTunnel:
+ name: tunnel-client-mycompany # Unique application name
+
+Namespace:
+ myTunnel:
+ name: my-namespace # Kubernetes namespace for this tunnel
+
+Deployments:
+ myTunnel:
+ enabled: true
+ replicas: 1
+ poolType: app # Must match a node label: pool-type=
+ enabledStatefulSet: true # Set to true to create the headless Service
+ containers:
+ image: testsigmainc/testsigma-tunnel
+ version: amd64-latest
+ imagePullPolicy: Always
+ config:
+ key: "" # JWT key from the Testsigma dashboard
+ tunnelName: "my-tunnel" # Name that appears in the Testsigma UI
+ verbose: true # Enable verbose logging
+ delegateSslValidation: false # Set true to skip SSL certificate validation
+ proxy: "" # HTTP proxy URL (leave empty if not required)
+```
+
+Replace the following placeholder values in your file:
+- **\**: Enter the JWT key from **Settings > Tunnels** in the Testsigma application.
+- **tunnel-client-mycompany**: Enter a name that uniquely identifies this tunnel client in your cluster.
+- **my-namespace**: Enter the Kubernetes namespace where you want to deploy the tunnel.
+- **my-tunnel**: Enter the tunnel name that will appear in the Testsigma UI.
+
+[[info | Note:]]
+| Never store your JWT key in plain text in a values file that you commit to version control. See **Manage Secrets** for recommended alternatives.
+
+---
+
+## **Deploy the Chart**
+
+1. Create the target namespace if it does not already exist:
+ ```bash
+ kubectl create namespace my-namespace --dry-run=client -o yaml | kubectl apply -f -
+ ```
+
+2. Install the Helm chart from inside the **testsigma-tunnel/** directory:
+ ```bash
+ helm install my-tunnel . -n my-namespace
+ ```
+
+---
+
+## **Verify the Deployment**
+
+Run the following commands to confirm that the tunnel deployed successfully.
+
+1. Check the StatefulSet status:
+ ```bash
+ kubectl get statefulset -n my-namespace
+ ```
+
+2. Check pod status:
+ ```bash
+ kubectl get pods -n my-namespace
+ ```
+
+3. View tunnel client logs to confirm the tunnel registered with the Testsigma server:
+ ```bash
+ kubectl logs -n my-namespace -f
+ ```
+
+In the logs, look for a message confirming that the tunnel registered successfully with the Testsigma server. If the tunnel does not appear in the Testsigma UI after a few minutes, see **Troubleshoot**.
+
+---
+
+## **Configuration Reference**
+
+### **Top-level Keys**
+
+| Key | Type | Required | Description |
+|---|---|---|---|
+| **Environment.name** | string | Yes | Environment identifier (for example, **production** or **staging**). Used in naming all Kubernetes resources. |
+
+### **Deployment Keys (Deployments.\)**
+
+| Key | Type | Required | Default | Description |
+|---|---|---|---|---|
+| **enabled** | boolean | Yes | — | Enables or disables this deployment. When **false**, all associated resources are removed. |
+| **replicas** | integer | Yes | — | Number of tunnel client pods to run. |
+| **poolType** | string | Yes | — | Node selector value for **pool-type**. Must match an existing node label. |
+| **enabledStatefulSet** | boolean | No | false | When **true**, creates a headless Service for StatefulSet DNS resolution. |
+| **containers.image** | string | Yes | — | Docker image name for the tunnel client. |
+| **containers.version** | string | Yes | — | Docker image tag. |
+| **containers.imagePullPolicy** | string | Yes | — | Image pull policy. Accepted values: **Always**, **IfNotPresent**, or **Never**. |
+| **config.key** | string | Yes | — | JWT authentication key from the Testsigma dashboard. |
+| **config.tunnelName** | string | Yes | — | Tunnel name visible in the Testsigma UI. |
+| **config.verbose** | boolean | No | true | Enables verbose logging for the tunnel client. |
+| **config.delegateSslValidation** | boolean | No | false | When **true**, the tunnel skips SSL certificate validation for upstream requests. |
+| **config.proxy** | string | No | "" | HTTP proxy URL for outbound traffic. Leave empty if a proxy is not required. |
+| **config.headerRules** | list | No | — | Automatic HTTP header injection rules. See **Inject HTTP Headers** for details. |
+
+### **Application and Namespace Keys**
+
+Each key that you define under **Deployments** must have a matching entry under both **Application** and **Namespace**. The keys must match exactly.
+
+```yaml
+Application:
+ myTunnel: # Must match the Deployments key
+ name: tunnel-client-mycompany
+
+Namespace:
+ myTunnel: # Must match the Deployments key
+ name: my-namespace
+```
+
+---
+
+## **Manage Secrets**
+
+The **config.key** field contains a JWT authentication token. Treat this value as a secret and never commit it in plain text to version control.
+
+### **Option 1: Pass the Key at Deploy Time**
+
+Use the **--set** flag with `helm install` or `helm upgrade` to inject the JWT key without storing it in your values file:
+
+```bash
+helm install my-tunnel . -f my-values.yaml \
+ --set 'Deployments.myTunnel.config.key=eyJhbGciOi...' \
+ -n my-namespace
+```
+
+For deployments with multiple tunnels, pass each key separately:
+
+```bash
+helm install my-tunnel . -f my-values.yaml \
+ --set 'Deployments.siteA.config.key=eyJhbGciOi...' \
+ --set 'Deployments.siteB.config.key=eyJhbGciOi...' \
+ -n my-namespace
+```
+
+### **Option 2: Use a Secrets Manager**
+
+For GitOps workflows, use Sealed Secrets or External Secrets Operator to manage the JWT key:
+
+1. Store the JWT key in your secrets backend (for example, AWS Secrets Manager or HashiCorp Vault).
+2. Create an ExternalSecret resource that syncs the key into a Kubernetes Secret.
+3. Reference the secret in your values file or inject it with **--set** in your CI/CD pipeline.
+
+### **Option 3: Use CI/CD Pipeline Variables**
+
+Store the JWT key as a pipeline secret and inject it during deployment. The following example shows a GitHub Actions workflow step:
+
+```yaml
+- name: Deploy tunnel
+ run: |
+ helm upgrade --install my-tunnel ./testsigma-tunnel \
+ -f my-values.yaml \
+ --set "Deployments.myTunnel.config.key=${{ secrets.TUNNEL_JWT_KEY }}" \
+ -n my-namespace
+```
+
+### **Rotate a JWT Key**
+
+When a JWT key expires or needs to be replaced:
+
+1. Obtain a new key from **Settings > Tunnels** in the Testsigma application.
+2. Update the key using your chosen secret management method.
+3. Run `helm upgrade` to apply the updated ConfigMap.
+4. The pods restart automatically and pick up the new configuration.
+
+---
+
+## **Scale and Manage the Tunnel**
+
+### **Increase Replicas**
+
+To handle more concurrent test traffic, increase the **replicas** value in your values file and apply the change:
+
+```yaml
+# In values.yaml
+Deployments:
+ myTunnel:
+ replicas: 3 # Increase from 1 to 3 pods
+```
+
+```bash
+helm upgrade my-tunnel . -f my-values.yaml -n my-namespace
+```
+
+### **Decrease Replicas**
+
+To reduce the number of active pods, lower the **replicas** value in your values file and run `helm upgrade`. Alternatively, scale down directly with kubectl for a temporary change:
+
+```bash
+kubectl scale statefulset tunnel-client-mycompany-production-statefulset \
+ --replicas=1 -n my-namespace
+```
+
+[[info | Note:]]
+| Scaling with kubectl is temporary. The replica count reverts to the value in your values file the next time you run `helm upgrade`.
+
+### **Stop the Tunnel Without Removing It**
+
+To shut down the tunnel temporarily while keeping the Helm release and configuration intact, scale the StatefulSet to zero:
+
+```bash
+kubectl scale statefulset tunnel-client-mycompany-production-statefulset \
+ --replicas=0 -n my-namespace
+```
+
+To make the change permanent through your values file, set `replicas: 0` and run `helm upgrade`.
+
+### **Disable a Specific Tunnel**
+
+When you manage multiple tunnels from a single values file, you can disable an individual tunnel by setting **enabled: false**. This removes all Kubernetes resources associated with that tunnel:
+
+```yaml
+Deployments:
+ siteA:
+ enabled: true # Keep this tunnel running
+ siteB:
+ enabled: false # Remove this tunnel's resources
+```
+
+```bash
+helm upgrade my-tunnel . -f my-values.yaml -n my-namespace
+```
+
+### **Remove All Tunnel Resources**
+
+To completely uninstall the Helm release and remove all associated Kubernetes resources:
+```bash
+helm uninstall my-tunnel -n my-namespace
+```
+
+---
+
+## **Update the Tunnel**
+
+To upgrade the tunnel client image or update the configuration, you must scale down to zero replicas before running `helm upgrade`. This ensures the tunnel cleanly deregisters from the Testsigma server before the updated version starts.
+
+[[info | Note:]]
+| Do not run `helm upgrade` while pods are active. Doing so can cause tunnel registration conflicts between the existing and updated versions.
+
+1. Scale down to zero pods:
+ ```bash
+ kubectl scale statefulset tunnel-client-mycompany-production-statefulset \
+ --replicas=0 -n my-namespace
+ ```
+
+2. Wait for all pods to terminate:
+ ```bash
+ kubectl get pods -n my-namespace \
+ -l app=tunnel-client-mycompany-production -w
+ ```
+
+3. Update your values file with the new image version or configuration changes:
+ ```yaml
+ Deployments:
+ myTunnel:
+ containers:
+ version: amd64-1.2.0 # Updated version tag
+ ```
+
+4. Apply the upgrade:
+ ```bash
+ helm upgrade my-tunnel . -n my-namespace
+ ```
+
+5. Scale back up to the desired number of replicas:
+ ```bash
+ kubectl scale statefulset tunnel-client-mycompany-production-statefulset \
+ --replicas= -n my-namespace
+ ```
+
+6. Verify the upgrade by checking pod status and logs:
+ ```bash
+ # Confirm pods are running with the new image
+ kubectl get pods -n my-namespace -l app=tunnel-client-mycompany-production
+
+ # Check logs to confirm successful registration
+ kubectl logs -n my-namespace \
+ tunnel-client-mycompany-production-statefulset-0 -f
+ ```
+
+---
+
+## **Advanced Configuration**
+
+### **Deploy Multiple Tunnels**
+
+You can manage multiple tunnel clients from a single values file. Each tunnel requires its own key under **Deployments**, **Application**, and **Namespace**:
+
+```yaml
+Application:
+ siteA:
+ name: tunnel-client-site-a
+ siteB:
+ name: tunnel-client-site-b
+
+Namespace:
+ siteA:
+ name: my-namespace
+ siteB:
+ name: my-namespace
+
+Deployments:
+ siteA:
+ enabled: true
+ replicas: 1
+ poolType: app
+ containers:
+ image: testsigmainc/testsigma-tunnel
+ version: amd64-latest
+ imagePullPolicy: Always
+ config:
+ key: ""
+ tunnelName: "site-a-tunnel"
+ verbose: true
+ siteB:
+ enabled: true
+ replicas: 1
+ poolType: app
+ containers:
+ image: testsigmainc/testsigma-tunnel
+ version: amd64-latest
+ imagePullPolicy: Always
+ config:
+ key: ""
+ tunnelName: "site-b-tunnel"
+ verbose: true
+```
+
+### **Inject HTTP Headers**
+
+Configure the tunnel to automatically inject HTTP headers into requests for specific hostnames. This is useful for adding authentication credentials or custom metadata to outbound requests.
+
+```yaml
+config:
+ headerRules:
+ # Inject a Basic Auth header for a specific host
+ - hostname: "internal-app.example.com"
+ headers:
+ X-TS-BASIC-AUTH-HEADER: "Basic dXNlcm5hbWU6cGFzc3dvcmQ="
+
+ # Inject custom headers for an API host
+ - hostname: "api.example.com"
+ headers:
+ X-Custom-Auth: "my-token"
+ X-Environment: "staging"
+```
+
+[[info | Note:]]
+| Use **X-TS-BASIC-AUTH-HEADER** for URL-based Basic Authentication. This header works with both HTTP and HTTPS endpoints.
+
+### **Route Traffic Through a Proxy**
+
+If your cluster requires an outbound HTTP proxy, add the proxy URL to the **config** section of your values file:
+
+```yaml
+config:
+ proxy: "http://proxy.internal.example.com:8080"
+```
+
+---
+
+## **Troubleshoot**
+
+| Symptom | Possible Cause | Resolution |
+|---|---|---|
+| Pod stuck in **Pending** | No nodes match the **pool-type** selector. | Run `kubectl get nodes --show-labels` and verify that at least one node has the expected **pool-type** label. |
+| Pod in **CrashLoopBackOff** | Invalid JWT key or malformed tunnel configuration. | Run `kubectl logs -n my-namespace` to inspect the error output. Verify that **config.key** and **config.tunnelName** are correct. |
+| Tunnel not visible in Testsigma UI | Incorrect **tunnelName** value or expired JWT key. | Confirm that **config.tunnelName** matches what you expect to see in the UI. Obtain a fresh JWT key from **Settings > Tunnels** if the key has expired. |
+| Connection timeouts during testing | Network policy or proxy misconfiguration. | Verify that **config.proxy** is set correctly and that cluster network policies permit outbound connections to the Testsigma platform. |
+| SSL errors during test execution | The upstream application uses a self-signed certificate. | Set **config.delegateSslValidation: true** in your values file and run `helm upgrade` to apply the change. |
+
+If you cannot resolve the issue using the steps above, collect the full logs from the affected pod and contact Testsigma support.
+
+```bash
+kubectl describe statefulset tunnel-client-mycompany-production-statefulset \
+ -n my-namespace
+
+kubectl logs -n my-namespace \
+ statefulset/tunnel-client-mycompany-production-statefulset -f
+```
+
+---
diff --git a/src/pages/docs/testsigma-tunnel/using-tunnel.md b/src/pages/docs/testsigma-tunnel/using-tunnel.md
index a7d09c56..23140fad 100644
--- a/src/pages/docs/testsigma-tunnel/using-tunnel.md
+++ b/src/pages/docs/testsigma-tunnel/using-tunnel.md
@@ -2,7 +2,7 @@
title: "Using Testsigma Tunnel"
metadesc: "Learn how to use Testsigma Tunnel for Test Automation and Live Testing of REST APIs. This article discusses configuring desired capabilities & API Settings."
noindex: false
-order: 34.7
+order: 34.8
page_id: "Using Testsigma Tunnel"
warning: false
contextual_links:
diff --git a/src/pages/docs/troubleshooting/web-apps/test-execution-queued-for-a-long-time.md b/src/pages/docs/troubleshooting/web-apps/test-execution-queued-for-a-long-time.md
index 5857dff7..31b657e9 100644
--- a/src/pages/docs/troubleshooting/web-apps/test-execution-queued-for-a-long-time.md
+++ b/src/pages/docs/troubleshooting/web-apps/test-execution-queued-for-a-long-time.md
@@ -21,16 +21,16 @@ If the execution status for your tests has been in the state Queued for a long t
## **Steps to Troubleshoot the Issue**
1. On **Dashboard**, click on **Usage details**.
-
+
2. Check the number of **Parallel Tests**.
-
+
-Here, we have a license for 3 parallel executions & 8 allowed queues. We can set up a maximum of 3 test runs to run in parallel, which means executing up to 3 tests simultaneously. In addition to the 3 tests running in parallel, you can have up to 8 tests in the queue. The queued tests will execute once the ongoing parallel executions are complete.
+Here, we have a license for 2 parallel executions & 3 allowed queues. We can set up a maximum of 2 test runs to run in parallel, which means executing up to 2 tests simultaneously. In addition to the 2 tests running in parallel, you can have up to 3 tests in the queue. The queued tests will execute once the ongoing parallel executions are complete.
-In the above example, we have **Parallel Tests 1/3**, which means 1 test is running in parallel, and 3 is the number of parallel runs allowed at a moment.
+In the above example, we have **Parallel Tests 2/2**, which means 2 test is running in parallel, and 2 is the number of parallel runs allowed at a moment.
-Suppose the number of parallel runs is equal to the number of parallel licenses for your Testsigma account. In that case, the tests in the queue will remain in the same status until the parallel test runs are completed.
+If the number of parallel runs reaches the limit of your parallel licenses, the queued tests will remain in their current status until the ongoing parallel test runs are completed.
**You can take the following actions to fix the issue:**
- You can wait for other tests to complete execution.
diff --git a/src/pages/docs/windows-automation/import-tsrx-files.md b/src/pages/docs/windows-automation/import-tsrx-files.md
index f88ab47e..b95b27fe 100644
--- a/src/pages/docs/windows-automation/import-tsrx-files.md
+++ b/src/pages/docs/windows-automation/import-tsrx-files.md
@@ -34,19 +34,26 @@ Once the TSRx file is ready, you can import it with just a few clicks and start
## **Steps to Import TSRx File**
1. From the left navigation bar, go to **Create Tests > Elements**.
+
-2. Click **Import elements** in the top right corner.
+2. Click **Import** at the top right corner of the Elements list page.
+
-3. In the **Import elements** dialog, click **Browse file**, select the **TSRx** file from your local system, and click **Import**.
+3. In the **Import** dialog, click **Browse file** and select a **TSRx** file from your local system.
+
-4. You can see the imported elements under **Create Tests > Elements**.
+4. In the **Import** dialog, under **How should we handle duplicates?**, select one of the following:
+ - **Overwrite** to replace existing elements with the imported ones.
+ - **Ignore** to skip importing duplicate elements.
+ 
+
+5. Click **Import**.
+
+
+6. You can see the imported elements under **Create Tests > Elements**.
[[info | **NOTE**:]]
| - You can replace the updated elements by clicking on **Update Elements** and following the same steps as above.
| - After updating the elements, changes in the app structure might affect some of them, which will be highlighted with a red underline. For information on handling these errors, refer to the [documentation on error handling post TSRx update](https://testsigma.com/docs/windows-automation/error-handling/).
-Here's a quick GIF demonstrating how to import elements for Windows application.
-
-
-
---
\ No newline at end of file