testeiya 0.2.1 → 0.3.9

package/skills/testeiya/testomatio-docs/docs/project/tests/classical-test-case-editor.md

@@ -1,354 +0,0 @@
----
-title: Classical Test Case Editor
-description: Learn how to create effective test designs with Testomat.io. This guide covers building test scenarios, using various test design techniques, and integrating them into your project workflow for improved test case management and automated test runs.
-type: article
-url: https://docs.testomat.io/project/classical_editor
-head:
-  - tag: meta
-    attrs:
-      name: keywords
-      content: test design, test cases, test management, test automation, testing techniques, Testomat.io, BDD, Gherkin, Cucumber, test scenarios, project workflow, software testing
----
-
-## Test Case Editor
-
-Test Case Editor is a dynamic interface, designed to accommodate the diverse requirements of test case formulation. Through this platform, testers wield the power to architect meticulously structured test scenarios, encompassing a range of variables, actions, expected results, and potential outcomes.
-
-Regarding test case creation, Testomat.io offers two distinct editor types: the **Classical** Editor and the **BDD** (Behavior-Driven Development) Editor. Each caters to different testing methodologies and user preferences, enabling testers to choose the approach that best aligns with their needs.
-
-Let's have a look at **Classical** Editor.
-
-## Classical Editor Review
-
-Introducing the Classical Editor, a tool that places the art of test editing firmly in your hands. Crafting tests becomes a seamless endeavor as you immerse yourself in the Classical Editor's capabilities.
-
-![Classical Editor](./images/edit_test_classical_editor.png)
-
-# Test Editor Overview
-
-1. **Test Title Field** – Enter the title of your test and add relevant tags.  
-2. **Formatting Toolbar** – Use formatting options to enhance your text.  
-3. **Editing Area** – Add test requirements, preconditions, steps, and expected results.  
-4. **Preview Button** – View a live preview of how the test will appear.  
-5. **Edit Steps** – Open the steps editor to modify test steps and expected outcomes.  
-6. **Attachments Button** – Open the attachments dialog to upload supporting files.  
-7. **Draw Button** – Launch the drawing editor to add visual elements.  
-8. **Editor Mode Switch** – Toggle between block-based and Markdown editor modes.  
-9. **Autocomplete Steps** – Enable or disable automatic step suggestions.  
-10. **Autocomplete Snippets** – Enable or disable snippet suggestions.  
-11. **Autocomplete Tags** – Enable or disable tag suggestions.  
-12. **Full Screen Button** – Switch to a distraction-free, full-screen editing mode.  
-13. **Set Labels Button** – Open a window to assign existing labels or create custom fields.  
-14. **Use Template Button** – Apply a predefined test template.  
-15. **Change State** – Change the test state (e.g., from manual to automated).  
-16. **Save Button** – Save your progress.  
-17. **Go Back Button** – Return to the previous screen.  
-18. **Close Button** – Exit the test editor.
-
-
-However, the Classical Editor's influence transcends singular tests. With Pre-Requirements, you can now wield the power to define the contextual prerequisites that set the stage for entire test **suites**. Seamlessly integrate high-level descriptions of dependencies, system states, or configurations required to execute a suite effectively.
-
-![Edit a suite](./images/edit_suite.png)
-
-# Suite Editor Overview
-
-1. **Suite Title Field** – Enter the suite title and any relevant tags.  
-2. **Formatting Toolbar** – Use text formatting tools as needed.  
-3. **Editing Area** – Provide a description for the suite.  
-4. **Preview Button** – See a live preview of the suite’s appearance.  
-5. **Attachments Button** – Open the dialog to upload attachments.  
-6. **Extra Menu Button** – Access additional suite editor options.  
-7. **Autocomplete Steps** – Enable or disable step autocompletion.  
-8. **Autocomplete Snippets** – Enable or disable snippet suggestions.  
-9. **Autocomplete Tags** – Enable or disable tag suggestions.  
-10. **Full Screen Button** – Enter distraction-free editing mode.  
-11. **Set Labels** – Assign existing labels or create new custom fields.  
-12. **Use Template Button** – Apply a predefined suite template.  
-13. **Save Button** – Save your changes.  
-14. **Go Back Button** – Return to the previous view.  
-15. **Close Button** – Exit the suite editor.
-
-
-### Why Do We Use Markdown in Classical Editor?
-
-Markdown is a lightweight and versatile markup language that revolutionizes the way content is formatted and presented. It combines the simplicity of plain text with the ability to produce well-structured documents, making it a favored choice for various applications, including software documentation and test case creation. Here are its benefits:
-
-**Simplified Syntax:** Markdown's straightforward syntax empowers testers to articulate intricate test scenarios with clarity. Utilize headings to structure test steps, employ bullet points for concise lists, and employ emphasis (bold, italic) to highlight crucial details.
-
-**Swift Formatting:** Testers can bid adieu to convoluted formatting menus and endless mouse clicks. Markdown's minimalist syntax allows testers to swiftly format text, enabling them to focus more on the content itself and less on the mechanics of formatting. This efficiency translates to accelerated test case creation.
-
-**Collaboration Amplified:** Collaborative testing endeavors thrive on clear communication. Markdown's plain text format is version control-friendly, facilitating seamless collaboration using tools like Git. Team members can easily track changes, suggest modifications, and merge contributions, ensuring that test cases evolve cohesively.
-
-**Readable and Accessible Content:** Markdown's clean and uncluttered appearance translates into test cases that are effortlessly readable, even by non-technical stakeholders. This enhances cross-functional communication by bridging the gap between testers, developers, and business analysts.
-
-**Media Integration:** Beyond text, Markdown accommodates image and file embedding. Testers can attach screenshots, diagrams, or supplementary documentation directly within test cases. This integration injects valuable context, aiding in comprehension and enabling more accurate bug reproduction.
-
-**Consistency and Templates:** Markdown's consistent structure allows for the creation of reusable test case templates. This ensures that test cases adhere to a standardized format, streamlining comprehension and navigation across a myriad of test scenarios.
-
-### Rich Editor for Classical Test Projects
-
-The editor follows a block-based layout, making it easier to structure and maintain detailed test cases.
-
-It supports adding expected results for each step and attaching images directly within steps, improving clarity and documentation quality. The editor is fully compatible with the markdown format, enabling more effective use of AI features when creating and updating tests. \
-
-:::note
-
-The Classical editor page is already part of the tree.
-
-:::
-
-The new editor improves test readability and structure, simplifies creation of detailed step-by-step scenarios, and enhances AI-assisted workflows through markdown compatibility.
-
-### Examples of Markdown Written Test Cases
-
-In the realm of Markdown-based test case creation, the handling of test unveils an array of versatile techniques. Below, we delve into several illustrative examples that showcase various methods for incorporating steps and expected results into your test cases.
-
-In this pattern, the steps are listed one after the other, along with their respective expected results. This is a simple and straightforward way to document the steps for a test case. You can see expected results as plain text just after step. Need to mention that expected results in this way will no go to steps database and you won't have autocompletion for it.
-
-```
-## Steps
-
-* Step 1
-    Expected result: Step 1
-* Step 2
-    Expected result: Step 2
-* Step 3
-    Expected result: Step 2
-```
-
-Some example:
-
-```
-## Steps
-
-* Go to the payment page
-    Expected result: Payment page loads
-* Enter credit card details and submit
-    Expected result: Payment is processed and confirmation page loads
-```
-
----
-
-### Expected Results as Steps One After Another
-
-This pattern is similar to the previous one, but instead of listing the expected results right after each step as plain text, they are listed after all the steps have been documented. This approach will give you ability to use autocompletion and expected results will be stored in steps database.
-
-```
-## Steps
-* Step 1
-* Expected result: Step 1
-* Step 2
-* Expected result: Step 2
-* Step 3
-* Expected result: Step 2
-```
-
-Some example:
-
-```
-## Steps
-* Go to the payment page
-* Verify that Payment page loads
-* Enter credit card details and submit
-* Verify that Payment is processed and confirmation page loads
-```
-
----
-
-### Steps with Expected Results as Nested List
-
-This format is useful for breaking down each step into multiple sub-steps, each with its own expected result. This can be helpful when a step is complex and has several different parts or when there are multiple expected behaviors that need to be documented for each step. By nesting the expected results under each step, it's easy to see which expected results are related to which sub-steps, making it easier to track and verify expected behaviors.
-
-```
-## Steps
-* Step 1
-    1. Expected result: Step 1.1
-    2. Expected result: Step 1.2
-* Step 2
-    1. Expected result: Step 2.1
-    2. Expected result: Step 2.2
-* Step 3
-    1. Expected result: Step 3.1
-    2. Expected result: Step 3.2
-```
-
-Some example:
-
-```
-## Steps
-
-* Go to the payment page
-    1. Verify that Payment page loads
-* Enter credit card details and submit
-    1. Verify that Credit card number is accepted
-    2. Verify that Expiration date is accepted
-    3. Verify that CVV code is accepted
-* Submit payment and confirmation page loads
-    1. Verify that Payment is processed
-```
-
-:::note
-
-In case you use numbered list for your steps and unordered list for expected result or sub-steps, to see the correct formatting, **add 4 spaces or 1 tab** before unordered list. Check the relevant case below.
-
-:::
-
-```
-## Steps
-
-1. Step 1
-    - Expected result: Step 1.1
-    - Expected result: Step 1.2
-2. Step 2
-    - Expected result: Step 2.1
-    - Expected result: Step 2.2
-3. Step 3
-    - Expected result: Step 3.1
-    - Expected result: Step 3.1
-```
-
-Some example:
-
-```
-## Steps
-
-1.  Go to the payment page
-    - Verify that Payment page loads
-    - Verify that payment page matches the design
-2. Enter credit card details and submit
-    - Verify that Credit card number is accepted
-    - Verify that Expiration date is accepted
-    - Verify that CVV code is accepted
-3. Submit payment and confirmation page loads
-    - Verify that Payment is processed
-```
-
-![Edit Test Case](./images/Edit_test_case_numbered_list.gif)
-
----
-
-### Steps with Separated Expected Results
-
-Instead of listing the verification actions after each step, they are listed under a separate section for expected results. This can be a good way to provide a summary of the expected behavior and can be helpful in identifying any gaps in the test coverage.
-
-```
-## Steps
-* Step 1
-* Step 2
-* Step 3
-
-## Expected results:
-* Verify that ...
-* Verify that ...
-* Verify that ...
-```
-
-Some example:
-
-```
-## Steps
-
-1. Go to the payment page
-2. Enter credit card details and submit
-
-## Expected Results:
-
-1. Payment page loads
-2. Payment is processed and confirmation page loads
-
-```
-
----
-
-### Steps with Table of Expected Results
-
-In this pattern, the steps are presented in a table format, with the expected results listed in a separate column. This can be a good way to provide a clear and concise summary of the test case and can be helpful in identifying any variations in the expected behavior.
-
-```
-## Steps
-
-| Step          | Expected results |
-|---------------|------------------|
-| Success login | Check form       |
-| Failed login  | Check form       |
-```
-
-Some example:
-
-```
-## Steps
-
-| Step                           | Expected results                                           |
-|--------------------------------|------------------------------------------------------------|
-| Go to the payment page         | Payment page loads                                         |
-| Enter credit card details      | Credit card number is accepted, Expiration date is accepted, CVV code is accepted |
-| Submit payment                 | Payment is processed and confirmation page loads           |
-```
-
-## ![Testomat.io - Table inside test case description](./images/New_10TBA7jV_2024-08-03.png)
-
-### Steps with Expected Results as Subheadings
-
-In this format, the expected results are included as subheadings under each step. This can be useful when you want to provide a more detailed description of the expected behavior for each step. So each section will provide more complex details and many verification point per each step
-
-```
-## Steps
-
-### Step 1
-
-* Expected result 1.1
-* Expected result 1.2
-* Expected result 1.3
-
-### Step 2
-
-* Expected result 2.1
-* Expected result 2.2
-* Expected result 2.3
-
-### Step 3
-
-* Expected result 2.1
-* Expected result 2.2
-* Expected result 2.3
-```
-
-Some example:
-
-```
-## Steps
-
-### Go to the payment page
-
-* Verify that Payment page loads
-
-### Enter credit card details
-
-* Enter credit card number
-    1. Verify that Credit card number is accepted
-* Enter expiration date
-    1. Verify that Expiration date is accepted
-* Enter CVV code
-    1. Verify that CVV code is accepted
-
-### Submit payment
-
-* Verify that Payment is processed
-* Verify that Confirmation page loads
-
-```
-
-Use Markdown shortcuts to edit test case description quickly and easily. Visit the [Keyboard Shortcuts](https://docs.testomat.io/usage/keyboard-shortcuts/) page to learn more.
-
-## Cross-Linking Tests, Suites and Folders
-
-Another useful feature that allows you to cross-link test cases, suites, and folders by embedding their unique IDs directly into the description of another test or suite. This functionality provides you with clickable links to other related items within your project, and clicking on it displays a dynamic preview of the linked test, suite or folder in an additional window. 
-
-This feature is available for Classical and BDD projects but have a difference in formating.
-
-### For Classical Project
-
-All you need to do is copy test cases/suites IDs and paste them into a test/suite description:
-
-![Testomat.io - Use ID In Tests](./images/New_0ldrsL29_2024-10-05.gif)
-

package/skills/testeiya/testomatio-docs/docs/project/tests/classical-vs-bdd.md

@@ -1,169 +0,0 @@
----
-title: Classical vs BDD
-description: Learn the fundamental differences between Classical and BDD projects in Testomat.io and why they must remain separate. This guide covers Markdown vs. Gherkin syntax, storage architecture, and automation mapping. It also provides insights into refactoring manual tests into Gherkin scenarios and explains why the strictness of BDD is essential for scalable, machine-readable test suites.
-type: article
-url: https://docs.testomat.io/project/classical_vs_bdd
-head:
-  - tag: meta
-    attrs:
-      name: keywords
-      content: test design, test cases, test management, test automation, testing techniques, Testomat.io, BDD, Gherkin, Cucumber, test scenarios, project workflow, software testing, Classical Project, BDD Project, Markdown, CodeceptJS, manual test, automation test, refactoring tests
----
-
-In the world of quality assurance, choosing the right framework is like choosing the right foundation for a building. Maintaining clear boundaries between project types is essential for ensuring test suite integrity and automation stability.
-
-While both, **Classical** and **BDD** projects, allow you to manage manual and automated tests, their underlying logic, syntax, and storage methods are fundamentally different. Below is a guide to help you understand these differences and why keeping them in separate projects is a technical necessity.
-
-## Classical vs BDD Projects
-
-In Testomat.io, projects are categorized into two distinct types: **Classical** and **BDD**. Choosing the right project type at the beginning of your testing journey is crucial, as the underlying architecture and syntax requirements differ significantly between the two. This choice determines your editor, your automation workflow, and how your team collaborates.
-
-### Classical Projects
-
-Classical projects are designed for maximum flexibility, primarily using **Markdown** formatting for test cases. This format is ideal for manual testing and traditional automation workflows where you describe how a test should be performed through detailed steps and expected results.
-
-- **Formatting:** Uses standard Markdown.
-- **Structure:** Test-centric. Each test is an independent entity with its own description.
-- **Automation:** Flexible mapping to various automation frameworks.
-- **Best For:** Teams moving from spreadsheets or traditional TMS, and those using non-BDD automation frameworks (like Playwright, Cypress, or TestCafe).
-
-### BDD (Behavior-Driven Development) Projects
-
-BDD projects are built for collaboration and strict structure. They use **Gherkin syntax** (`Given`, `When`, `Then`). This project type is built with an automation-first mindset, ensuring that the business requirements and the test code stay in perfect synchronization. The goal here is to describe the behavior of the system in a way that business stakeholders, developers, and QAs all understand.
-
-- **Formatting:** Strictly follows Gherkin syntax rules.
-- **Structure:** Feature-file centric. Tests (Scenarios) are organized within Feature Files. In Testomat.io, a suite in a BDD project represents a `.feature` file.
-- **Automation:** Each step in the description must correspond to a specific function in the underlying test code.
-- **Best For:** Teams practicing 'Three Amigos' (business, developers, QAs) collaboration and using Cucumber-based frameworks. Those who want their documentation to serve as the direct source of truth for automation. 
-
-### Key Differences at a Glance
-
-| Feature | Classical Project | BDD Project |
-| --- | --- | --- |
-| **Editor** | Visual/Markdown Editor | Gherkin Editor (Scenario-based) |
-| **Syntax** | Flexible (Bullet points, text) | Strict (Given, When, Then, And) |
-| **Data Storage** | Inside the individual test case | Inside the Feature file (Suite level) |
-| **Automation** | Syncs code to test descriptions | Syncs Feature files to step definitions |
-| **Stakeholders** | Primarily QA and Developers | BA, Product Owners, Devs, and QA |
-| **Main Focus** | Test execution steps | System behavior |
-
-## Why You Cannot Combine Both in One Project
-
-A common question is: **'Can I just add a few Gherkin tests to my Classical project?'** The short answer is **NO**. Testomat.io enforces a strict separation to protect your data integrity and workflow efficiency. Here is why:
-
-1. **Syntax Strictness vs. Flexibility**
-
-Gherkin is a much stricter format than Markdown. In a BDD project, the editor validates your syntax in real-time. If you try to move a flexible Markdown test into a Gherkin suite, the **syntax will break**. BDD requires specific keywords to function; without them, the 'Feature file' becomes unreadable to both the system and the automation parser.
-
-2. **Different Storage Architecture**
-
-In a Classical project, metadata (tags, descriptions) is stored at the **individual test level**. In BDD, the 'truth' lives in the **Feature File**. A suite in BDD is not just a folder; it is a physical `.feature file`. Mixing these would create a 'logical mess' where the system wouldn't know whether to treat a file as a collection of independent tests or a single synchronized document.
-
-3. **Automation Mapping**
-
-BDD automation relies on a 1:1 mapping between a Gherkin step and a function in your code.
-**In BDD Projects:** Every step must have a corresponding function (Step Definition) in your code.
-**In Classical Projects:** You have the freedom to write descriptive steps that don't necessarily map to code, providing more flexibility for manual testers.
-
-Attempting to support both in one project would lead to inconsistency. You would end up having some tests that require strict code-mapping and others that don't, leading to broken automation reports and confusing 'out-of-sync' notifications.
-
-## Moving Between Project Types
-
-Because of the strictness of Gherkin, there has traditionally been no "one-click" way to turn a flexible Markdown test into a rigid BDD scenario. However, with the integration of **AI-feature** within Testomat.io, you now have three distinct paths depending on your timeline and automation goals:
-
-**Option 1: AI-Powered Migration (Usign the 'Transform Project to BDD' AI-Agent)**
-
-If you want to move your entire workspace to a BDD framework without the manual overhead, you can use the **'Transform Project to BDD'** feature. This AI-powered agent automatically analyzes your existing Classical tests and generates a new, structured BDD environment.
-
-- **How it works:** The AI rewrites your test steps into a valid `Given/When/Then` Gherkin syntax and generates a **completely new BDD project** containing the converted suite.
-
-- **Why use it:** It eliminates manual rewriting, standardizes test styles across the team, and makes your tests "automation-ready" in seconds.
-
-- **Key Benefit:** It bridges the gap between descriptive manual steps and strict BDD requirements automatically.
-
-:::note
-
-Read more about Testomat.io **'Transform Project to BDD'** and other AI-agents on a separate [AI-Agents](https://docs.testomat.io/advanced/ai-powered-features/ai-agents/) page.
-
-:::
-
-**Option 2: Manual Refactoring**
-
-For teams that want granular control or have highly complex logic that requires human nuance, manual refactoring remains the standard.
-
-- **Classical → BDD:** You must create a new BDD project and manually rewrite tests to ensure each step follows Gherkin rules and is built for reusability.
-
-- **BDD → Classical:** Currently, this direction is not supported as a direct migration due to the risk of losing the structured Feature file history and metadata.
-
-**Option 3: The Hybrid Alternative (CodeceptJS)**
-
-If you aren't ready to commit to the strict overhead of Gherkin but want BDD-style readability, we recommend **CodeceptJS**. Instead of a full project migration, you stay in your Classical project and write code that looks like BDD. This allows you to write 'Human-Readable' code (e.g., `I.click('Login')`) that fits perfectly into Classical projects while remaining easy for non-technical stakeholders to follow.
-
-This gives you the descriptiveness of BDD without the strict overhead and formatting limitations of Gherkin.
-
-:::note
-
-Regardless of the method chosen, remember that BDD is a **'Behavioral Contract'**. Whether you use the AI or rewrite manually, ensure your team is prepared to map these new steps to corresponding functions in your automation code.
-
-:::
-
-### Example of Refactoring from a Classical format to Gherkin
-
-Refactoring from a Classical format to Gherkin is less about changing the words and more about changing the philosophy. In a Classical project, you’re writing a 'How-to' guide for a human; in BDD, you’re writing a 'Behavioral Contract' that a machine can also read.
-
-Here is a common scenario—User Authentication—refactored to show the shift from flexibility to strictness.
-
-**Classical Project Manual Test:**
-
-**Format:** Markdown
-In this format, you can be as descriptive or as brief as you like. You can combine multiple actions into one step.
-
-```
-Test Case: Successful Login
-
-1. Open the login page at https://app.testomat.io/login.
-2. Enter a registered email and the correct password into the fields.
-3. Hit the blue 'Sign In' button at the bottom of the form.
-
-Expected Result: The user is redirected to the Project Dashboard and sees a "Welcome" toast message.
-```
-
-**The Refactored Gherkin Scenario (BDD Project):**
-
-**Format:** Gherkin Syntax
-Notice the use of specific keywords. Each line below would ideally map to a reusable 'Step Definition' in the automation code.
-
-```
-Feature: User Authentication
-Scenario: Successful login with valid credentials
-
-Given the user is on the Testomat.io login page
-When the user enters valid credentials
-And the user clicks the 'Sign In' button
-Then the user should be redirected to the Project Dashboard
-And a "Welcome" message should be displayed
-```
-**Why the BDD Version is 'Stricter'**
-Switching to BDD isn't just a formatting change; it’s a shift toward a more disciplined testing architecture. Here is why the Gherkin format is considered 'stricter' than Classical Markdown:
-
-1. **Atomicity:**
-
-In a **Classical** project, a single step like `Login with valid credentials` is a black box — it’s easy to write but hard to automate efficiently.
-**BDD** forces **Atomicity**. By breaking actions into individual lines (`Given I am on the login page`, `When I enter my email`), you create Reusable Building Blocks. If you have 50 tests that require a login, you only write the code for that 'step' once. In BDD, if a step isn't atomic, it isn't truly reusable.
-
-2. **Resilience to UI Fluctuation (Abstraction):**
-
-**Classical** tests often get bogged down in 'Implementation Noise' — mentioning a `red cancel button` or `the top-right dropdown`. If the UI changes, your documentation is instantly broken, 'outdated'.
-**BDD** encourages **Abstract Logic**. You focus on the intent (e.g.,` When I cancel the transaction`) rather than the mechanics (`Click the red button`). This makes your test suite significantly more resilient to minor frontend updates.
-
-3. **State Management (Explicit Preconditions):**
-
-One of the biggest causes of flaky tests is a missing starting point. **Classical** tests often assume the user is already 'there'.
-The `Given` keyword in **BDD** is a mandatory contract. It forces the author to define the exact state of the system before the action happens. This 'State Management' eliminates the "it works on my machine" excuse by ensuring every runner starts from the same functional baseline.
-
-4. **Syntax Enforcement (The Parser Factor):**
-
-In a **Classical** project, the editor is passive — it’s essentially a digital notepad. You can write whatever you want, and the system won't complain.
-In **BDD**, the Gherkin Parser acts as a compiler. If you misspell a keyword or fail to follow the `Scenario:` structure, the test is syntactically invalid. This strictness ensures that your test suite is always machine-readable and ready for automation, preventing "junk" documentation from piling up.
-
-While the **Classical** project offers the 'freedom to write', the **BDD** project offers the 'structure to scale'. The strictness of BDD is an upfront investment that pays off in lower maintenance and more reliable automation.

package/skills/testeiya/testomatio-docs/docs/project/tests/copy-and-move-your-tests.md

@@ -1,156 +0,0 @@
----
-title: Copy and Move your Tests
-description: Learn how to create effective test designs with Testomat.io. This guide covers building test scenarios, using various test design techniques, and integrating them into your project workflow for improved test case management and automated test runs.
-type: article
-url: https://docs.testomat.io/project/copy_move_tests
-head:
-  - tag: meta
-    attrs:
-      name: keywords
-      content: test design, test cases, test management, test automation, testing techniques, Testomat.io, BDD, Gherkin, Cucumber, test scenarios, project workflow, software testing, duplicate, meta data, link attachments, link issues, link labels
----
-
-## How to Copy your Tests, Test Suites, and Folders
-
-You can copy a single test from a test suite, an entire test suite, or even a folder containing a set of test suites. You can copy these items either within your current project or to a different project.
-
-### Copying Tests or Test Suites Within Your Project
-
-1. Go to the **Tests** page.
-2. Select the item you want to copy (e.g., a test suite).
-3. Open the drop-down menu by clicking the **three dots** next to the **Edit** button.
-4. Click **Copy**.
-5. Select the destination folder where you want to move your test suite.
-
-![Testomat.io - 'Copy' button](./images/Copy_option_Tests.png)
-![Testomat.io - 'Copy tests' pop-up](./images/copy_test_inside_project.png)
-
-### Copying Tests or Test Suites to Another Project
-
-1. Go to the **Tests** page.
-2. Select the item you want to copy (e.g., a test suite).
-3. Open the drop-down menu by clicking the **three dots** next to the **Edit** button.
-4. Click **Copy**.
-5. In the pop-up menu, click **'Change project'**.
-6. Select the specific project from the drop-down list.
-7. Select the destination folder where you want to move your test suite.
-
-![Testomat.io - 'Change project' button](./images/change_project_button.png)
-
-### Advanced Copy Options
-
-When copying tests, suites, or folders, you can include additional metadata. To do this, open the **Copy** modal and expand the **More options** section.
-
-- **Assign labels** — copies all labels associated with tests, suites, or folders, including **custom labels**
-- **Assign attachments** — copies all attached files to tests, suites, or folders
-- **Assign issues** — copies linked issues
-
-![More options](./images/att1_1033.png)
-
-:::note
-
-Linked issues are copied only if the destination project has an active integration with the **same Issue Management System and the same project/configuration**.
-
-Otherwise, linked issues will be **skipped** and **not copied**.
-
-:::
-
-You can select **one**, **multiple**, or **all** options at the same time, depending on your needs. If no options are selected, the system creates a copy **without labels, issues, or attachments** by default.
-
-These advanced options are available for **all copy modes**:
-
-- **Same project**
-- **Other project**
-- **Bulk selection project** (for suites and folders)
-
-:::note
-
-**Bulk selection project** is not available when copying individual tests. Tests must belong to a suite, while bulk copying places items into the **project root**, which is not supported for tests.
-
-:::
-
-This flexibility allows you to either fully duplicate test assets with all related context or create a clean copy without additional metadata.
-
-## Duplicate Tests
-
-The **Duplicate** feature allows you to quickly create a copy of an existing test inside Testomat.io. It helps QA engineers reuse test structure, steps, and configuration without creating tests from scratch.
-
-When a test is duplicated:
-
-- A new independent test is created in the same suite
-- Test content, steps, and parameters are copied
-- The new test name automatically includes a **Copy** badge
-
-During duplication, you can also choose whether to copy additional metadata using **Advanced Duplicate Options**. This allows you to either create a clean test or a full clone of the original test depending on your workflow.
-
-You can optionally duplicate:
-
-- Labels
-- Linked issues
-- Attachments
-
-These options help preserve test organization, traceability, and supporting materials when creating similar tests.
-
-### How to Duplicate Test
-
-1. Navigate to the **Tests** section
-2. Open a test you want to duplicate
-3. Click the (`⋯`) actions menu
-4. Click the **Duplicate**
-
-![Duplicate](./images/att1_7987.png)
-
-When the **Choose duplicate settings** modal opens:
-
-5. Select advanced duplication options if needed:
-
-- Assign labels
-- Assign issues
-- Assign attachments
-
-6. Click **Duplicate** button to confirm
-
-![Duplicate tests](./images/att2_7987.png)
-
-A new test is created immediately with the selected metadata.
-
-:::note
-
-Your selected duplication settings are **remembered automatically**. The next time you open the **Choose duplicate settings** modal, previously selected metadata will already be preselected, so you don’t need to configure them every time.
-
-:::
-
-## Move Your Tests
-
-You may need to move your tests within a project, for example to another suite. For this purpose, you can use **Move** or **Drag and Drop** functionality.
-
-### Move menu action
-
-1. Go to the **Tests** page.
-2. Select the item you want to move (e.g. a test suite).
-3. Open the drop-down menu by clicking the three dots next to the Edit button.
-4. Click **Move**.
-
-![Alt Move tests button ](./images/move_tests_1.png)
-
-5. Select the destination folder where you want to move your tests.
-
-![Alt Move tests button ](./images/move_tests_2.png)
-
-### Drag and Drop option
-
-1. Go to the **Tests** page.
-2. Expand the folder or suite where you want to move your test(s).
-3. Hover over the test, suite, or folder you want to move until the drag handle (⠿) appears.
-4. Click and hold the drag handle, then drag the item to your desired location.
-5. Position the item slightly below the item you want it to appear under. When space opens up, release to drop.
-
-![Alt Move tests button ](./images/drag_and_drop.gif)
-
-## How to restore deleted tests?
-
-The **Trash Bin** feature is designed to enhance data recovery and user experience by allowing users to easily restore accidentally deleted suites or test cases. Revisions are stored for up to 90 days, ensuring that valuable testing data is not permanently lost and can be quickly recovered without the need for complex restoration processes.
-
-![Testomat.io - Trash Bin](./images/New_vzUGVzmP_2024-08-13.gif)
-
-You can also track changes to Suits and Test Cases, including deletions, on the [Pulse](https://docs.testomat.io/usage/pulse/) page.