> ## Documentation Index > Fetch the complete documentation index at: https://onetest.ai/llms.txt > Use this file to discover all available pages before exploring further. # Organizing Tests > Best practices for structuring your test suite This page is under construction. More content coming soon! ## Why Organization Matters A well-organized test suite is: * **Easy to navigate**: Find tests quickly * **Maintainable**: Clear structure makes updates simple * **Scalable**: Grows cleanly as product expands * **Collaborative**: Team can work efficiently Poor organization leads to duplicate tests, missed coverage, and wasted time. ## Organization Methods OneTest provides multiple ways to organize tests: Hierarchical structure for logical grouping Flexible labels for categorization Product-specific metadata ## Folder Structure Strategies ### Organize by Product Features Recommended for most teams. ``` 📁 Authentication 📁 Login ✅ Valid credentials ✅ Invalid password ✅ Locked account 📁 Registration ✅ New user signup ✅ Email verification 📁 Password Reset ✅ Request reset link ✅ Reset with valid token 📁 User Profile 📁 View Profile 📁 Edit Profile 📁 Upload Avatar 📁 Products 📁 Browse Products 📁 Search Products 📁 Product Details 📁 Reviews 📁 Shopping Cart 📁 Add to Cart 📁 Update Quantity 📁 Remove Items 📁 Checkout 📁 Shipping Information 📁 Payment 📁 Order Confirmation ``` **Pros:** * Mirrors product structure * Easy for new team members * Scales well **Cons:** * May need reorganization after refactoring ### Organize by User Flows Good for customer-centric products. ``` 📁 New User Journey ✅ Discover product ✅ Sign up ✅ Complete onboarding ✅ First action 📁 Purchase Journey ✅ Browse catalog ✅ Add to cart ✅ Checkout ✅ Payment ✅ Confirmation 📁 Return User Journey ✅ Login ✅ View history ✅ Repeat action ✅ Logout 📁 Admin Journey ✅ Login as admin ✅ Access dashboard ✅ Manage users ✅ Generate reports ``` **Pros:** * Reflects real user behavior * Easy to identify gaps * Clear end-to-end scenarios **Cons:** * Tests may span multiple features * Can have overlapping tests ### Organize by Testing Type Common in mature testing organizations. ``` 📁 Functional Tests 📁 Smoke Tests 📁 Regression Tests 📁 Integration Tests 📁 Non-Functional Tests 📁 Performance Tests 📁 Security Tests 📁 Usability Tests 📁 Accessibility Tests 📁 Platform Tests 📁 Web Tests 📁 Mobile - iOS 📁 Mobile - Android 📁 API Tests 📁 Environment Tests 📁 Dev Tests 📁 Staging Tests 📁 Production Smoke Tests ``` **Pros:** * Clear separation of concerns * Easy to run specific test types **Cons:** * May duplicate structure * Less intuitive for new team members ### Combine Multiple Strategies Most flexible approach. ``` 📁 Smoke Tests (by type) ✅ Login ✅ Homepage loads ✅ Add to cart ✅ Checkout 📁 Features (by feature) 📁 Authentication 📁 Products 📁 Orders 📁 User Journeys (by flow) 📁 First-time Buyer 📁 Returning Customer 📁 Platforms (by platform) 📁 Web 📁 iOS App 📁 Android App ``` **Pros:** * Maximum flexibility * Accommodates different needs **Cons:** * Can become confusing * Requires discipline to maintain ## Effective Tagging Strategy Tags provide cross-cutting categorization: **Purpose:** Indicate criticality * `p0` or `critical`: Must pass before release * `p1` or `high`: Important, impacts core functionality * `p2` or `medium`: Standard functionality * `p3` or `low`: Nice to have * `p4` or `trivial`: Optional ```oql theme={null} priority = p0 # Built-in field # OR tags CONTAINS "critical" ``` **Purpose:** Categorize by testing approach * `smoke`: Critical path verification * `regression`: Full suite before release * `sanity`: Quick verification * `exploratory`: Ad-hoc testing * `security`: Security-focused tests * `performance`: Load/stress tests * `accessibility`: A11y tests ```oql theme={null} tags CONTAINS "smoke" OR tags CONTAINS "regression" ``` **Purpose:** Identify target platform * `web`: Web application tests * `mobile`: Mobile-specific * `ios`: iOS app * `android`: Android app * `api`: API/backend tests * `desktop`: Desktop application ```oql theme={null} tags CONTAINS ANY (ios, android) ``` **Purpose:** Link to features/components * `auth`, `login`, `signup` * `cart`, `checkout`, `payment` * `search`, `filter`, `sort` * `profile`, `settings` * `notifications`, `email` ```oql theme={null} tags CONTAINS "checkout" AND tags CONTAINS "payment" ``` **Purpose:** Track when tests were added * `sprint-24`: Tests for sprint 24 * `v2.1.0`: Tests for version 2.1.0 * `q1-2024`: Tests added in Q1 ```oql theme={null} tags CONTAINS "sprint-24" ``` **Purpose:** Track test lifecycle * `draft`: Work in progress * `ready-for-review`: Needs review * `approved`: Ready to use * `automated`: Has automation * `flaky`: Inconsistent results * `deprecated`: Being phased out ```oql theme={null} tags CONTAINS "flaky" AND last_run >= -7d ``` Many of these have built-in status fields. Use tags only if you need custom statuses. ## Naming Conventions ### Clear, Descriptive Titles **Format:** `Verify [action] [condition] [expected result]` * `Verify user can login with valid credentials` * `Verify error message displays for invalid email format` * `Verify shopping cart updates when quantity is changed` * `Verify checkout completes successfully with credit card` * `Login test` ← Too vague * `Test #47` ← No context * `Check if it works` ← What is "it"? * `User does something and sees a thing` ← Too generic **Tips:** * Start with action verb: "Verify", "Validate", "Confirm" * Include condition being tested * Be specific about expected outcome * Keep under 80 characters if possible ### Folder Naming **Rules:** * Use Title Case: `User Profile`, not `user profile` * Be concise but descriptive * Avoid abbreviations unless universal (e.g., "API" is okay) * Use plurals for collections: `Products`, not `Product` **Examples:** ``` ✅ Good: 📁 Authentication 📁 User Management 📁 Product Catalog 📁 Payment Processing ❌ Bad: 📁 auth (unclear abbreviation) 📁 User_Management (underscores) 📁 product catalog (not title case) 📁 paymentprocessing (no spaces) ``` ### Tag Naming **Rules:** * Use lowercase * Use hyphens for multi-word tags: `smoke-test`, not `smokeTest` * Be consistent across team * Avoid redundant tags **Examples:** ``` ✅ Good: smoke, regression, critical, login, checkout, ios, android ❌ Bad: Smoke (capitalized) smoke_test (underscore) smokeTest (camelCase) smoke-tests (plural when others are singular) ``` ## Maintenance Best Practices Review test suite quarterly: * Remove obsolete tests * Update outdated tests * Consolidate duplicates * Fix organizational issues ```oql theme={null} # Find old draft tests status = draft AND created_at < -90d # Find tests without folders folder_id IS NULL # Find untagged tests tags IS NULL OR tags = [] ``` Assign test ownership: * Feature teams own their feature tests * QA owns smoke/regression suites * Individuals own exploratory tests Use custom fields to track ownership: `owned_by: "payments-team"` Document your structure: * Create folder descriptions * Define tag meanings * Maintain test suite README * Train new team members Automate organization tasks: * Auto-tag based on folder location * Bulk move tests between folders * Generate coverage reports * Alert on orphaned tests ## Common Anti-Patterns Avoid these common mistakes: **Problem:** Deeply nested folders (>5 levels) ``` ❌ Bad: 📁 Web 📁 Desktop 📁 Chrome 📁 Windows 📁 Authentication 📁 Login 📁 Valid Credentials ✅ Test ``` **Solution:** Flatten structure, use tags for additional categorization **Problem:** Some tests organized one way, others differently **Solution:** Choose a strategy and stick to it. Migrate existing tests. **Problem:** Too many tags (>10 per test) **Solution:** Use only meaningful tags. Remove redundant ones. **Problem:** All tests in root folder **Solution:** Start organizing today! Create basic folders. ## What's Next? Work together effectively Find tests with queries General testing best practices Back to test management