#Organization & Structure Best Practices Guide
A well-structured workspace makes test management scalable, discoverable, and easy to maintain. This guide explains how to organize Hawzu workspaces and projects in a way that supports growth, collaboration, and long-term maintainability.
#Workspace Organization
#Project Boundaries
Use projects to represent clear functional or ownership boundaries.
Recommended approaches:
- One project per application or product
- Separate projects for web, mobile, or API layers when needed
- Independent projects for long-running platforms vs short-lived initiatives
Avoid:
- Mixing unrelated applications in a single project
- Using projects as folders (projects should be meaningful boundaries)
#Naming Conventions
Consistency matters more than perfection.
Best practices:
- Use clear, human-readable project names
- Avoid environment-specific names (e.g.,
App-QA, App-Prod)
- Prefer product or domain-based naming
Example:
- ✅
Billing Platform
- ❌
Billing_App_Final_v2
#User & Access Structure
#Role Assignment
- Assign workspace roles for administrative responsibilities
- Use project roles for execution and contribution
- Avoid overusing high-privilege roles
#Group-Based Access
- Create groups for teams (QA, Automation, Release Managers)
- Assign project roles via groups instead of individuals
- Review group memberships periodically
This keeps access predictable and easier to audit.
#Folder Organization
#Folder Hierarchy Design
Folders are your primary organizational tool inside projects.
Recommended structures:
- Feature-based (
Authentication, Payments, Reports)
- Journey-based (
Onboarding, Checkout, User Management)
- Module-based (
API, UI, Backend)
Guidelines:
- Keep folder depth shallow (3–4 levels max)
- Avoid creating folders for every minor variation
- Document your chosen structure and reuse it across projects
#Folder Naming
- Use singular, descriptive names
- Avoid abbreviations unless widely understood
- Keep naming consistent across all projects
Example:
- ✅
User Authentication
- ❌
Auth_Stuff
#Test Suite Organization
#Purpose of Test Suites
Test suites are execution-focused, not storage-focused.
Use test suites to:
- Group tests for execution
- Define scopes like Smoke, Regression, or Release validation
- Track progress during test runs
Avoid using suites as a replacement for folders.
#Suite Design Best Practices
- Create suites per release, sprint, or testing goal
- Reuse the same test case across multiple suites
- Keep suite sizes manageable (50–200 tests)
Common suite patterns:
- Smoke Suite
- Regression Suite
- Release Validation Suite
- Hotfix Verification Suite
#Shared Assets & Reuse
#Shared Steps
- Use shared steps for common workflows (login, setup, teardown)
- Prefer workspace shared steps for organization-wide standards
- Use project shared steps for project-specific logic
Avoid duplicating the same steps across multiple test cases.
#Parameters & Custom Fields
- Use workspace parameters for values reused across projects
- Keep project parameters focused and intentional
- Avoid overloading custom fields—introduce them only when they add clarity
#Scaling & Maintenance
#Regular Structure Reviews
- Periodically review folder and suite structure
- Archive obsolete folders and suites
- Merge or refactor duplicate structures
#Avoid Over-Structuring
More structure is not always better.
Red flags:
- Too many empty folders
- Deep nesting with few test cases
- Multiple ways to represent the same concept
#Summary
A strong organization strategy in Hawzu:
- Makes test cases easy to find
- Improves execution efficiency
- Reduces duplication
- Scales with team and product growth
Structure should serve clarity—not complexity. Start simple, document your conventions, and evolve deliberately.