---
title: "Common Mistakes to Avoid in Xray:  Manual Tests with too many Steps"
canonical: "https://docs.getxray.app/space/ProductKB/46269295/Common%20Mistakes%20to%20Avoid%20in%20Xray%3A%20%20Manual%20Tests%20with%20too%20many%20Steps"
format: markdown
---
This article aims to explain some Xray Anti-patterns  that can lead to future constrains or even data integrity issues. Please use this information carefully and taking in consideration your own setup and team processes. Anti-Pattern Description When a Manual Test contains too many  Steps , it might be  consider as an anti-pattern.  Having Manual Tests with too many Steps leads to increased complexity, longer execution times, difficulty in debugging and high maintenance effort.  Solution Audit and Review We suggest a recurrent audit; you can define its cadence, especially in daily meetings or any team gathering to assist and provide feedback. Xray Data Center Should you be using Xray Data Center, feel free to use the JQL below to build a filter and add it to Dasbhboard or even follow up in a e-mail subscription: "Steps Count" >=  10 Xray Cloud In Xray Cloud there isn't a straighforward way to search for Test with to many Steps. You can select Tests created in the last month and make a verification by sample. Do's & Don'ts   Manual Tests should not have too many Steps to follow and, upon a Manual Test creation, we should always look to decompose Test Steps into simpler tasks. Here are examples on how to decompose: Group related steps → Identify Steps that test the same functionality and group them into smaller, focused Test cases. Prioritize Core Functionality → Focus on testing the core functionality in each Test case, avoiding excessive detail that doesn’t directly contribute to the main objective. Use  Preconditions  → Instead of repeating setup Steps in each Test case, create a set of Preconditions that can be referenced, making individual Test cases more concise. One goal per Test → Ensure that each Test case focuses on a single objective or outcome. Avoid testing too many different aspects in one Test case. Test Scenario: Testing the Purchase Cycle in a Marketplace App The goal of this scenario is to evaluate the various stages of the purchase cycle, including authentication, item selection, and payment processing. Initial Approach In an effort to cover all parts of the purchase cycle, you might be tempted to create one Test case that includes multiple Steps: Navigate to the site. Log in to the site. Select an item and add it to the shopping cart. Pay for the Item in the shopping cart. Attempt to use the Refund/Cancel button for the recent purchase. While this approach seems to capture the whole flow, it can lead to Tests that are difficult to maintain, debug, and reuse. If one Step fails (e.g., login), the entire Test will fail, making it harder to diagnose the actual problem. Additionally, it bundles different features together in a way that prevents proper focus on each function (authentication, cart functionality, payment, etc.). Recommended Approach To avoid these pitfalls, the Test should be broken down into smaller, more focused Test cases. This improves clarity, maintainability, and the ability to isolate issues. Test 1: Authentication This Test focuses exclusively on verifying the site's login/logout functionality. Precondition:  Navigate to the Site. Steps: Outcome:  Ensure that both login and logout are successful, without involving other features like item selection or payments. Test 2: Adding and Removing Items from the Cart This Test isolates the cart functionality by checking how items are added and removed from the shopping cart. Steps: Outcome:  Verify that items can be successfully added and removed from the shopping cart, without needing to log in or make payments. Test 3: Payment and After Sales Automation This test focuses solely on the payment process and the associated post-payment options (refund or cancel). Steps: Outcome:  Confirm that the payment is processed correctly and that refund or cancellation options work as expected. Decomposing like this will assist you in navigating your  Test Runs  and Evidence documentation by creating a more linear approach to Test Coverage. Additionally, having these tests decomposed will make way for the use of Xray Features such as "Modular Tests"  in which you can call a previous Test and respective Test Steps. Finally, you should make use of preconditions to facilitate your testing writing. Learn More The following articles guide you through creating a Test Cases, respective steps, and much more. Xray DC:  Best practices on writing great Test cases Xray Cloud:  Best practices on writing great Test cases Also, it might be useful to learn more about:  Modular Tests (Xray DC) Modular Tests (Xray Cloud) Xray Academy Join for free our  Xray Academy  and take the   Xray Essentials for Cloud & Data Center   Course to help you get familiarized with how to fill in Test Steps and how to use the Modular Test Functionality. We encourage your team to go through all the courses →  Xray Academy If you have questions or technical issues, please  contact the Support team via the Customer Portal (Jira service management)  or  send us a message using the in-app chat .