@testdriverai/agent 7.8.0-test.38

package/docs/v6/overview/faq.mdx

@@ -0,0 +1,162 @@
+---
+title: "FAQ"
+sidebarTitle: "FAQ"
+description: "Frequently Asked Questions about TestDriver"
+icon: "block-question"
+---
+
+## What's TestDriver?
+
+TestDriver is an AI-powered testing platform that simulates user interactions to automate end-to-end testing for web, desktop, and mobile applications.
+
+## How does TestDriver work?
+
+It interprets high-level prompts, interacts with interfaces like a user would, and verifies expected outcomes using visual assertions.
+
+## What platforms does TestDriver support?
+
+TestDriver supports Windows, Mac, Linux, desktop apps, chrome extensions, web browsers, and mobile interfaces (via emulator or device farm).
+
+## Can it be used for exploratory testing?
+
+Yes. TestDriver can autonomously navigate the application to generate new test cases.
+
+## Can it test desktop applications?
+
+Yes. It supports testing native desktop applications by simulating mouse and keyboard input and identifying UI elements.
+
+## Can it test mobile apps?
+
+Yes, via mobile emulators or integration with device farms.
+
+## Can TestDriver generate tests automatically?
+
+Yes, it explores the app and creates test cases based on UI flows and user interactions.
+
+## Can I create tests from natural language prompts?
+
+Yes. You can write high-level instructions in plain language, and TestDriver will interpret and build tests from them.
+
+## Can it generate tests from user stories or documentation?
+
+Yes. It can use minimal descriptions to produce complete test cases.
+
+## Can it turn recorded user sessions into tests?
+
+No, an important part of AI-native testing is the intent behind the actions. TestDriver focuses on understanding user goals rather than just recording actions.
+
+## What happens when the UI changes?
+
+TestDriver adapts using AI—if a button or label changes, it can often infer the correct action without breaking.
+
+## Do I need to rewrite tests often?
+
+No. TestDriver reduces maintenance by handling common UI changes automatically.
+
+## How does it handle flaky tests?
+
+TestDriver Enterprise Dashboards provide insights into test stability, helping you identify flaky tests and their causes.
+
+## How are tests updated over time?
+
+TestDriver will open pull requests in your repository with updated tests when it detects changes in the UI or application behavior. You can also regenerate tests using the original prompts manually.
+
+## How does TestDriver report test failures?
+
+It provides detailed logs, screenshots, console output, and visual diffs.
+
+## What happens when a test fails?
+
+It stops execution, flags the failing step, and provides context for debugging.
+
+## Can I view why a test failed?
+
+Yes. You can view step-by-step logs, network traffic, DOM state, and video playback of the test run.
+
+## Can it automatically retry failed actions?
+
+Yes. You can configure retry behavior for individual steps or full tests.
+
+## Can I run tests in parallel?
+
+Yes. TestDriver supports parallel execution using multiple VMs or containers.
+
+## Can I track performance metrics during testing?
+
+Yes. It can log CPU, memory, load times, and frame rates to help catch performance regressions.
+
+## Can it validate non-deterministic output?
+
+Yes. It uses AI assertions to verify outcomes even when outputs vary (for example, generated text or dynamic UIs).
+
+## Can it test workflows with variable inputs?
+
+Yes. It supports data-driven tests using parameterized inputs.
+
+## Can it test file uploads and downloads?
+
+Yes. TestDriver can interact with file pickers and validate uploaded/downloaded content.
+
+## Can it generate tests for PDFs or document output?
+
+Yes. It can open and verify generated files for expected text or formatting.
+
+## Can I trigger tests based on pull requests or merges?
+
+Yes. You can integrate TestDriver with your CI to trigger runs via GitHub Actions or other CI/CD tools.
+
+## Does it integrate with CI/CD tools?
+
+Yes. TestDriver integrates with pipelines like GitHub Actions, GitLab CI, and CircleCI.
+
+## Can I integrate TestDriver with Jira, Slack, etc.?
+
+Yes. You can receive alerts and sync test results with third-party tools via API/webhooks.
+
+## Does it support cloud and local environments?
+
+Yes. You can run tests locally or in the cloud using ephemeral VMs for clean state testing.
+
+## Does it work with existing test frameworks?
+
+It can complement or convert some existing test cases into its format, though full conversion depends on compatibility.
+
+## How does TestDriver measure test coverage?
+
+It tracks UI paths, element interaction frequency, and application state changes to infer coverage.
+
+## Can it suggest missing test scenarios?
+
+Yes. Based on interaction patterns and user behavior, it can propose additional test cases.
+
+## Can it analyze test stability over time?
+
+Yes. You can view trends in pass/fail rates and test execution consistency.
+
+## Is it safe to test sensitive data?
+
+Yes. TestDriver supports variable obfuscation, secure containers, and test data isolation.
+
+## Can I avoid using production data in tests?
+
+Yes. You can configure mock data, sanitize logs, and use test-specific environments.
+
+## How does the AI understand what to test?
+
+It uses language models to interpret your goals, element names, and interface cues to perform tasks.
+
+## Can I adjust how the AI interprets my prompt?
+
+Yes. You can rewrite prompts, add constraints, or review and tweak auto-generated steps.
+
+## Can I see what the AI is doing behind the scenes?
+
+Yes. You can inspect the resolved steps, see element matches, and adjust test flows before execution.
+
+## Can I use TestDriver to test new features?
+
+Yes. It's great for validating changes, ensuring no regressions, and verifying rollout configurations.
+
+## Can it test seasonal or time-based behaviors?
+
+Yes. You can schedule tests or run them under specific date/time settings to verify time-sensitive logic.

package/docs/v6/overview/performance.mdx

@@ -0,0 +1,52 @@
+---
+title: "Performance"
+sidebarTitle: "Performance"
+description: "Expected Command Performance"
+icon: "rabbit-running"
+---
+
+This guide outlines the typical performance characteristics of each TestDriver command based on observed average execution times. These measurements can help guide optimization, identify bottlenecks, and set realistic expectations when designing automated tests.
+
+## Fastest Commands
+
+These commands execute quickly and can be relied upon for high-frequency usage in complex test sequences.
+
+| Command                                      | Avg Duration | Notes                                                                                          |
+| -------------------------------------------- | ------------ | ---------------------------------------------------------------------------------------------- |
+| [`exec`](/commands/exec)                     | **0.28s**    | Fastest command — used for running system-level operations or internal scripting logic.        |
+| [`wait-for-image`](/commands/wait-for-image) | 2.21s        | Relatively fast if the image is readily present; can be slower if the UI takes time to render. |
+| [`remember`](/commands/remember)             | 2.80s        | Internal memory operation — used for tracking previous outputs or locations.                   |
+| [`hover-text`](/commands/hover-text)         | 3.11s        | Efficient for UI elements with immediate accessibility.                                        |
+| [`scroll`](/commands/scroll)                 | 3.34s        | Smooth and fast in most scrollable containers.                                                 |
+| [`assert`](/commands/assert)                 | 3.47s        | Used for validation — usually lightweight unless image or text detection is delayed.           |
+
+## Medium Performance Commands
+
+These are reliable but may involve minor delays due to image processing, UI rendering, or input simulation.
+
+| Command                                            | Avg Duration | Notes                                                                         |
+| -------------------------------------------------- | ------------ | ----------------------------------------------------------------------------- |
+| [`focus-application`](/commands/focus-application) | 4.83s        | Includes system-level context switching — may vary by OS and app state.       |
+| [`scroll-until-text`](/commands/scroll-until-text) | 5.94s        | Slightly slower due to iterative scroll and search logic.                     |
+| `click`                                            | 6.15s        | Includes visual target matching and precise cursor control.                   |
+| [`press-keys`](/commands/press-keys)               | 6.18s        | Slightly slower if key sequences involve modifier keys or application delays. |
+| [`type`](/commands/type)                           | 7.32s        | Simulates real typing — intentionally throttled for realism and stability.    |
+| [`wait`](/commands/wait)                           | 7.50s        | Direct sleep used for explicit pauses. Use sparingly for faster tests.        |
+
+## Slower Commands
+
+These commands tend to be slower due to intensive image comparison, polling loops, or delays in dynamic content rendering.
+
+| Command                                    | Avg Duration | Notes                                                                                                                                  |
+| ------------------------------------------ | ------------ | -------------------------------------------------------------------------------------------------------------------------------------- |
+| [`hover-image`](/commands/hover-image)     | 11.95s       | Requires locating a target image — performance depends on image quality and rendering time.                                            |
+| [`wait-for-text`](/commands/wait-for-text) | 12.08s       | Polls repeatedly for expected text — delay depends on application speed and visibility.                                                |
+| [`match-image`](/commands/match-image)     | **16.55s**   | Most time-consuming operation — relies on pixel-level image detection which may be affected by resolution, anti-aliasing, and scaling. |
+
+---
+
+- **Avoid overusing [`match-image`](/commands/match-image)** unless strictly necessary. Prefer [`wait-for-text`](/commands/wait-for-text) or [`hover-text`](/commands/hover-text) when working with text-based UIs.
+- **Use [`remember`](/commands/remember) and [`assert`](/commands/assert) early** in the test to catch failures before expensive commands.
+- **Favor [`exec`](/commands/exec) for background operations** like launching processes or setting up test conditions.
+- **Use [`wait`](/commands/wait) intentionally** and sparingly — prefer dynamic waits ([`wait-for-image`](/commands/wait-for-image), [`wait-for-text`](/commands/wait-for-text)) when possible.
+- **Monitor cumulative test time**. Replacing slower commands can dramatically improve test suite duration.

package/docs/v6/overview/quickstart.mdx

@@ -0,0 +1,137 @@
+---
+title: "Quickstart"
+sidebarTitle: "Quickstart"
+description: "Get started with TestDriver in minutes."
+icon: "gauge-high"
+mode: "wide"
+---
+
+<Steps>
+  <Step title="Create a TestDriver Account">
+      
+  You will need a [TestDriver Pro](https://app.testdriver.ai/team) account ($20/month) to get an API key. 
+    
+    <Card
+      title="Sign Up for TestDriver"
+      icon="user-plus"
+      href="https://app.testdriver.ai/team"
+      arrow
+      horizontal
+    ></Card>
+
+  </Step>
+  <Step title="Set up your environment">
+      
+    Copy your API key from [the TestDriver dashboard](https://app.testdriver.ai/team), and set it as an environment variable.
+    
+    <Tabs>
+      <Tab title="macOS / Linux">
+        ```bash Export an environment variable on macOS or Linux systems
+        export TD_API_KEY="your_api_key_here"
+        ```
+      </Tab>
+      <Tab title="Windows">
+      ```powershell Export an environment variable in PowerShell
+      setx TD_API_KEY "your_api_key_here"
+      ```
+      </Tab>
+    </Tabs>
+
+    <Tip>Using VS Code, Cursor, or Windsurf? [Try our VS Code Extension (beta)](/getting-started/vscode).</Tip>
+
+  </Step>
+  <Step title="Check out an example test">
+      
+    Download the TestDriver GitHub repository and run the example test.
+
+    ```bash
+    git clone --depth 1 https://github.com/testdriverai/cli testdriverai
+    cd testdriverai/testdriver/acceptance
+    ```
+
+    TestDriver tests are written in YAML, a human-readable data format. The `prompt.yaml` file contains an example series of steps for the agent to execute.
+
+    ```yaml testdriver/acceptance/prompt.yaml
+    steps:
+      - prompt: log in
+      - prompt: add an item to the cart
+      - prompt: click on the cart icon
+      - prompt: complete checkout
+    ```
+
+    Each step has a `prompt` that describes what the agent should do. The agent will use the prompt to generate [commands](/commands/assert) that make the tests faster and more reliable the next time you run the test.
+
+  </Step>
+  <Step title="Generate regression test from prompts">
+    
+    Run the following command to run the test file. TestDriver will spawn a virtual machine, launch the sandbox test page, and execute the steps defined in the `prompt.yaml` file.
+
+    ```bash
+    npx testdriverai@latest run prompt.yaml --write --heal
+    ```
+
+    The `--write` flag tells TestDriver to save any generated commands to the test file, and the `--heal` flag allows TestDriver to recover from unexpected issues during the test run.
+
+    <Tip>You can use an interactive CLI to generate test steps with the [explore command](/interactive/explore)</Tip>
+
+  </Step>
+  <Step title="Run the generated regression test">
+
+    After TestDriver has run the exploratory test, you'll see that the `prompt.yaml` file has been updated with commands generated by the agent to make the test faster and more reliable.
+
+    ```yaml
+      version: 6.0.0
+      steps:
+        - prompt: focus chrome
+          commands:
+            - command: focus-application
+              name: Google Chrome
+        - prompt: enter a username
+          commands:
+            - command: hover-text
+              text: Username
+              description: username input field
+              action: click
+            - command: type
+              text: standard_user
+        - prompt: enter a password
+          commands:
+            - command: hover-text
+              text: Password
+              description: password input field
+              action: click
+            - command: type
+              text: secret_password
+      ```
+
+      The `--write` command tells the agent to save the generated commands to the test file, and the `--heal` command gives the agent permission to recover if something goes wrong.
+
+  </Step>
+
+  <Step title="Managing your test suite">
+
+    There's so much more you can do with TestDriver! Here are some popular features to explore:
+
+    <Columns cols={2}>
+      <Card title="Importing Tests" icon="table" href="/importing/csv">
+        Generate tests from other formats like CSV, Gherkin, etc.
+      </Card>
+      <Card title="Self Healing" icon="bandage" href="/features/auto-healing">
+        Automatically update tests when the application changes.
+      </Card>
+      <Card title="Variable Test Data" icon="square-root-variable" href="/guide/variables">
+        Use variables run the same test with different data sets.
+      </Card>
+      <Card title="Reusable Snippets" icon="repeat" href="/features/reusable-snippets">
+        Embed reusable snippets to simplify your test scripts.
+      </Card>
+      <Card title="Running Custom Code" icon="code" href="/guide/code">
+        Use custom powershell or NodeJS code to extend the capabilities of your tests.
+      </Card>
+      <Card title="Setup & Teardown" icon="wrench" href="/guide/lifecycle">
+        Systemically prepare the sandbox before running tests and clean up afterward.
+      </Card>
+    </Columns>
+
+  </Step>
+  </Steps>

package/docs/v6/overview/what-is-testdriver.mdx

@@ -0,0 +1,85 @@
+---
+title: "What Is TestDriver?"
+sidebarTitle: "What Is TestDriver?"
+description: "TestDriver is a computer-use agent for QA testing of user interfaces."
+icon: "circle-info"
+---
+
+TestDriver uses AI vision and keyboard and mouse control to automate end-to-end testing. TestDriver is `selectorless`, meaning it doesn't rely on CSS selectors or static analysis to find elements.
+
+<CardGroup cols={3}>
+  <Card title="Cross-Platform" icon="bolt">
+    Test web, mobile, desktop and more with a single tool.
+  </Card>
+  <Card title="Easy Setup" icon="wrench">
+    No need to craft or maintain complex selectors.
+  </Card>
+  <Card title="Less Maintenance" icon="bandage">
+    Tests won't break when code changes.
+  </Card>
+</CardGroup>
+
+TestDriver is different from other computer-use agents as it produces `YAML` based test script which increases the speed and repeatability of testing.
+
+### Selectorless testing
+
+Unlike traditional frameworks (for example, Selenium, Playwright), TestDriver doesn't rely on CSS selectors or static analysis. Instead, tests are described in plain English, such as:
+
+```
+> Open Google Chrome and search for "testdriver"
+```
+
+This means that you can write tests without worrying about the underlying code structure:
+
+- Test any user flow on any website in any browser
+- Clone, build, and test any desktop app
+- Render multiple browser windows and popups like 3rd party auth
+- Test `<canvas>`, `<iframe>`, and `<video>` tags with ease
+- Use file selectors to upload files to the browser
+- Resize the browser
+- Test chrome extensions
+- Test integrations between applications
+
+### The problem with current approach to end-to-end testing
+
+End-to-end is commonly described as the most expensive and time-consuming test method. Right now we write end-to-end tests using complex selectors that are tightly coupled with the code.
+
+```js
+const e = await page.$(
+  'div[class="product-card"] >> text="Add to Cart" >> nth=2',
+);
+```
+
+This tight coupling means developers need to spend time to understand the codebase and maintain the tests every time the code changes. And code is always changing!
+
+### End-to-end is about users, not code
+
+In end-to-end testing the business priority is usability. All that really matters is that the user can accomplish the goal.
+
+TestDriver uses human language to define test requirements. Then our simulated software tester figures out how to accomplish those goals.
+
+| Old and Busted (Selectors)                                 | New Hotness (TestDriver) |
+| :--------------------------------------------------------- | :----------------------- |
+| `div[class="product-card"] >> text="Add to Cart" >> nth=2` | buy the 2nd product      |
+
+These high level instructions are easier to create and maintain because they're loosely coupled from the codebase. We're describing a high level goal, not a low level interaction.
+
+The tests will still continue to work even when the junior developer changes .product-card to .product.card or the designers change Add to Cart to Buy Now . The concepts remain the same so the AI will adapt.
+
+## How exactly does this work?
+
+TestDriver uses a combination of reinforcement learning and computer vision. The context from successful text executions inform future executions. Here's an example of the context our model considers when locating a text match:
+
+| Context            | What's it?                                                                          | Touchpoint     |
+| :----------------- | :---------------------------------------------------------------------------------- | :------------- |
+| Prompt             | Desired outcome                                                                     | User Input     |
+| Screenshot         | Image of computer desktop                                                           | Runtime        |
+| OCR                | All possible text found on screen Runtime                                           |
+| Text Similarity    | Closely matching text                                                               | Runtime        |
+| Redraw             | Visual difference between previous and current desktop screenshots                  | Runtime        |
+| Network            | The current network activity compared to a baseline                                 | Runtime        |
+| Execution History  | Previous test steps                                                                 | Runtime        |
+| System Information | Platform, Display Size, etc                                                         | Runtime        |
+| Mouse Position     | X, Y coordinates of mouse                                                           | Runtime        |
+| Description        | An elaborate description of the target element including it's position and function | Past Execution |
+| Text               | The exact text value clicked                                                        | Past Execution |

package/docs/v6/scenarios/ai-chatbot.mdx

@@ -0,0 +1,28 @@
+---
+title: "AI Chatbots"
+sidebarTitle: "AI Chatbots"
+description: "Integrate AI chatbots into your testing workflow."
+icon: "message-bot"
+---
+
+import TestPrereqs from "/snippets/test-prereqs.mdx";
+
+# Testing AI Chatbots with TestDriver
+
+TestDriver can be used to test AI chatbots, or any two way assertions like:
+
+- Approval workflows
+- Chatbots
+- Email or SMS notifications
+- And more!
+
+This scenario is an example of how to set up and run tests for an AI chatbot using TestDriver.
+
+<TestPrereqs />
+
+## Scenario overview
+
+1. Load a website with an AI chatbot.
+2. Type a chat message or ask a question.
+3. Wait for the chatbot to respond.
+4. Verify that the chatbot's response is correct and meets the expected criteria.

package/docs/v6/scenarios/cookie-banner.mdx

@@ -0,0 +1,32 @@
+---
+title: "Cookie Banner"
+sidebarTitle: "Cookie Banner"
+description: "Test cookie banners with TestDriver"
+icon: "cookie"
+---
+
+import TestPrereqs from "/snippets/test-prereqs.mdx";
+
+<iframe
+  width="600"
+  height="400"
+  src="https://www.youtube.com/embed/VUmjDQ4rM9M"
+  title="Testing Cookie Banners with TestDriver"
+  frameborder="0"
+  allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture"
+  allowfullscreen
+></iframe>
+
+---
+
+# Testing Cookie Banners with TestDriver
+
+With TestDriver, you can automate the testing of cookie banners on your web application. This scenario demonstrates how to check if a cookie banner appears when a user visits the site and how to interact with it.
+
+<TestPrereqs />
+
+## Scenario overview
+
+1. **Visit the Site**: The test will navigate to the target URL.
+2. **Check for Cookie Banner**: It will verify if the cookie banner is displayed.
+3. **Decline Cookies**: The test will simulate a user clicking the "Decline All" button on the cookie banner.

package/docs/v6/scenarios/file-upload.mdx

@@ -0,0 +1,33 @@
+---
+title: "File Upload"
+sidebarTitle: "File Upload"
+description: "Test file upload functionality with TestDriver"
+icon: "upload"
+---
+
+import TestPrereqs from "/snippets/test-prereqs.mdx";
+
+<iframe
+  width="600"
+  height="400"
+  src="https://www.youtube.com/embed/9fMAJ0AC6Qw"
+  title="File Upload Testing with TestDriver"
+  frameborder="0"
+  allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture"
+  allowfullscreen
+></iframe>
+
+---
+
+## Testing file upload functionality with TestDriver
+
+This scenario demonstrates how to automate testing the file upload functionality of a web application using TestDriver's capabilities. The test will check if the file upload process works correctly and if the uploaded file is processed as expected.
+
+<TestPrereqs />
+
+## Scenario overview
+
+1. Load a website with a file upload feature.
+2. Generate a file that will be used for the upload.
+3. Use TestDriver to perform the file upload process.
+4. Check if the uploaded file is processed correctly by the application.

package/docs/v6/scenarios/form-filling.mdx

@@ -0,0 +1,32 @@
+---
+title: "Form Filling"
+sidebarTitle: "Form Filling"
+description: "Test form filling functionality with TestDriver"
+icon: "list"
+---
+
+import TestPrereqs from "/snippets/test-prereqs.mdx";
+
+<iframe
+  width="600"
+  height="400"
+  src="https://www.youtube.com/embed/R0xHyuaBy3A"
+  title="Form Filling With TestDriver"
+  frameborder="0"
+  allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture"
+  allowfullscreen
+></iframe>
+
+---
+
+# Testing Form Filling with TestDriver
+
+TestDriver provides a powerful solution for testing form filling functionality on web applications. This scenario demonstrates how to automate the process of filling out forms, such as login or registration forms, using TestDriver's capabilities.
+
+<TestPrereqs />
+
+## Scenario overview
+
+1. Open a webpage containing a form (Log in, Registration, etc.).
+2. Use TestDriver to fill in the form fields with test data.
+3. Submit the form and verify the expected outcome (for example, successful login, registration confirmation, redirect etc.).

package/docs/v6/scenarios/log-in.mdx

@@ -0,0 +1,75 @@
+---
+title: "Login"
+sidebarTitle: "Login"
+description: "Test login functionality with TestDriver"
+icon: "lock"
+---
+
+import TestPrereqs from "/snippets/test-prereqs.mdx";
+
+# Testing Login Functionality with TestDriver
+
+Test login functionality with TestDriver. This scenario demonstrates how to automate testing the login process for a web application using TestDriver.
+
+<TestPrereqs />
+
+## Scenario overview
+
+1. Visit the login page of the web application.
+2. Enter the username and password into the respective fields (see [Reusable Snippets](/features/reusable-snippets#How-to Create-and-Use-Reusable-Snippets)).
+3. Click the "Login" button.
+4. Verify that the user is redirected to the dashboard or home page after a successful login.
+5. Optionally, check if the user is logged in by verifying the presence of a logout button or user profile information.
+
+### Setup your test environment with predefined credentials.
+
+This example uses GitHub secret management to store credentials.
+
+<Tip>
+  You can also use the [`exec`](commands/exec) command to fetch a test user
+  dynamically from a database or API.
+</Tip>
+
+To use GitHub secrets, create or modify an existing `.env` file in the root of your project and add the following lines:
+
+```bash
+TD_TEST_USERNAME=your_test_username
+TD_TEST_PASSWORD=your_test_password
+```
+
+2. Create a test file and use the credentials like this:
+
+```yaml login.yaml
+version: 6.0.0
+steps:
+  - prompt: Log in to the application
+    commands:
+      - command: hover-text
+        text: Email address
+        description: email input field label
+        action: click
+      - command: type
+        text: ${TD_USERNAME} # Use environment variable for username
+      - command: hover-text
+        text: Password
+        description: password input field label
+        action: click
+      - command: type
+        text: ${TD_PASSWORD} # Use environment variable for password
+      - command: hover-text
+        text: Log In
+        description: log in button
+        action: click
+```
+
+3. Run the test using the command line:
+
+```bash
+npx testdriverai@latest run login.yaml
+```
+
+4. Watch replays in [Your account](https://app.testdriver.ai)
+
+### Conclusion
+
+In this scenario, we demonstrated how to automate the login process for a web application using TestDriver. By leveraging reusable snippets and environment variables, you can create efficient and maintainable tests for your applications. This approach not only saves time but also ensures that your tests are easily adaptable to changes in the application or test data.

package/docs/v6/scenarios/pdf-generation.mdx

@@ -0,0 +1,25 @@
+---
+title: "PDF Generation"
+sidebarTitle: "PDF Generation"
+description: "Test PDF generation functionality with TestDriver"
+icon: "file-pdf"
+---
+
+import TestPrereqs from "/snippets/test-prereqs.mdx";
+
+# Testing PDF Generation with TestDriver
+
+Test PDF generation functionality with TestDriver. This scenario demonstrates how to automate testing the PDF generation process for a web application using TestDriver's capabilities.
+
+<TestPrereqs />
+
+## Scenario overview
+
+1. Open a webpage or desktop app that will allow you to generate a PDF.
+2. Trigger the PDF generation process (for example, by clicking a button).
+3. Verify that the PDF is generated successfully and contains the expected content.
+4. Optionally, check the file size and format of the generated PDF.
+
+## What's next
+
+From here you can automate and add coverage to your PDF generation process, removing manual testing from the equation.