Skip to main content

TestAtlas Project Constitution

TestAtlas — The Open Software Testing Knowledge Base

This constitution defines the standards that protect TestAtlas as it grows. It applies to every chapter, lab, project simulation, template, visual, resource, pull request, and community interaction.

When speed conflicts with quality, this document takes priority.

1. Mission​

TestAtlas exists to help anyone master Software Testing through practical learning, real-world projects, and open-source resources.

We teach testing as experienced QA engineers practise it: by understanding product risk, asking useful questions, designing meaningful coverage, investigating failures, and helping teams make better delivery decisions.

2. Vision​

TestAtlas will become a trusted, free, and practical home for software testing knowledge. It will remain useful because it connects principles to real work instead of treating testing as a collection of definitions.

3. Core values​

Practicality over theory​

Theory matters when it improves decisions. A concept without application is incomplete.

Clarity over complexity​

Explain difficult topics plainly. Do not make a subject sound advanced when a direct explanation, example, or diagram will do.

Accuracy over speed​

Correct, current, well-reviewed material is more valuable than a large collection of shallow or unreliable pages.

Maintainability over shortcuts​

Choose structures, examples, tools, and patterns that contributors can understand and maintain over time.

Learner trust over vanity metrics​

Do not optimize for page count, trends, or impressive-looking content. Optimize for usefulness, accuracy, and a learner's ability to apply what they learned.

Openness with respect​

Strong technical discussion is welcome. Personal attacks, dismissive behavior, and gatekeeping are not. Contributors should be challenged on ideas and supported as people.

4. Documentation principles​

Every learning chapter must answer:

  1. Why does this matter?
  2. What is it?
  3. When should it be used?
  4. How is it used in real projects?

Where appropriate, it must also include a production-inspired scenario, common mistakes, practical recommendations or a checklist, links to related topics, and a diagram or table when it improves understanding.

Content must not exist only to define terminology. Readers should understand how the topic affects testing decisions, product risk, and day-to-day engineering work.

5. Writing standards​

Write as an experienced engineer mentoring another engineer.

  • Use direct, natural English.
  • Prefer concrete examples over abstract statements.
  • Define unfamiliar terms before relying on them.
  • Keep paragraphs focused and avoid repeating the same point.
  • Use realistic names, inputs, constraints, and expected outcomes in examples.
  • Distinguish facts, recommendations, and opinions.
  • State assumptions where they materially affect the advice.
  • Avoid invented sources, unsupported claims, generic introductions, and motivational filler.

The full editorial rules are in STYLE_GUIDE.md.

6. Quality standards​

A contribution is ready only when it is useful, accurate, readable, and maintainable.

  • Technical claims are correct and appropriately scoped.
  • Examples reflect realistic testing work.
  • Links work and related content is connected.
  • Markdown, code, diagrams, and downloadable materials render correctly.
  • Code and labs have clear prerequisites, setup steps, expected outcomes, and verification guidance.
  • Templates are reusable, editable, and explain when to use them.
  • Project simulations maintain traceability from requirements through test coverage and outcomes.
  • Visuals improve understanding; they are not decoration.
  • The change does not duplicate an existing resource without a clear reason.

For fast-changing topics, content must identify its assumptions and be reviewed periodically.

7. Review process​

No substantive contribution is merged without review. Reviewers check whether the change solves a learner need, is technically sound, uses a useful example, follows this constitution, and remains maintainable as the repository grows.

Authors should welcome specific, respectful feedback. Reviewers should explain requested changes clearly and avoid blocking progress over personal preference. The operating process is defined in GOVERNANCE.md and CONTRIBUTING.md.

8. Contribution principles​

Contributors are welcome at every experience level. A useful contribution may be a correction, clearer explanation, practical example, lab improvement, diagram, template, translation, or thoughtful review.

Contributors must work within the project structure, keep changes focused, credit external work, respect licenses, avoid proprietary or sensitive information, and leave the affected area clearer than they found it.

Maintainers must make expectations visible, review work fairly, and explain decisions that affect contributors.

9. Long-term goals​

TestAtlas will grow into an ecosystem of structured learning paths, runnable QA labs, realistic project simulations, workplace-ready templates, practical interview preparation, responsible AI-for-QA guidance, and a healthy contributor community.

Growth must be deliberate. A smaller collection of trusted, well-connected resources is better than a large collection of inconsistent pages. See ROADMAP.md for the planned stages.

10. Decision-making principles​

When choosing between approaches, evaluate them in this order:

  1. Best Practice
  2. Scalability
  3. Maintainability
  4. Contributor Experience
  5. Learner Experience

Trade-offs must be stated openly. Decisions that affect repository architecture, many contributors, or public navigation require documented reasoning and deliberate review. Prefer simple, reversible decisions when uncertainty is high.

When there is conflict, protect learner trust, technical accuracy, and maintainability first.

11. What we will never compromise on​

TestAtlas will not compromise on:

  • Technical accuracy
  • Honest, practical guidance
  • Respectful collaboration
  • Review before substantive changes are merged
  • Clear and maintainable content
  • Proper attribution and license compliance
  • Protection of learner trust
  • Real-world context whenever it improves understanding
  • The principle that every merge must make TestAtlas better than it was yesterday

Amending this constitution​

This constitution is stable, not frozen. A change needs a clear reason, open discussion, and evidence that it improves the project's long-term quality. An amendment must preserve the mission of practical, trustworthy, open software-testing knowledge.