FAQ
See how DahTahDoc keeps specs, diffs, and QA test cases aligned
DahTahDoc is a traceable Spec-to-QA handoff workspace for small software teams. It connects specs, version diffs, references, and QA test cases so PMs, system analysts, engineers, and QA teams can work from the same delivery context.
Not yet. DahTahDoc is currently an alpha preview built to validate the core Spec-to-QA workflow, version diffs, bidirectional anchors, and QA handoff tracking. Features, UI details, and workflows may still change, so it should not be treated as a mature commercial product or a full test management platform yet.
Notion and Confluence are strong general-purpose knowledge bases for notes, wikis, and broad team documentation. DahTahDoc is more focused on software delivery handoff. It connects spec publishing, version diffs, bidirectional anchors, QA test cases, and update reminders, so a requirement does not just sit in a wiki after it is written; it stays traceable through testing and delivery.
Jira is better for issue tracking, sprint planning, and engineering task management. TestRail-style tools are better for large-scale test management and execution. DahTahDoc is not trying to replace them. It covers the upstream handoff that small software teams often lose: after a spec is written or changed, QA needs to know which test cases should be created, reviewed, or updated. Teams can still use Jira or TestRail while using DahTahDoc as the traceable spec-to-QA context layer.
If your team only needs a knowledge base, a general document tool may be enough. DahTahDoc is a better fit when spec changes often get missed by QA, test cases live separately in documents or spreadsheets, and delivery context depends on people remembering to notify each other. It is built for small PM, system analysis, engineering, and QA teams that need specs, diffs, and test cases to stay aligned without adopting a heavy enterprise process.
Spec-to-QA is DahTahDoc's core workflow. When a project spec is published, DahTahDoc can create a linked QA test case document. Later spec versions do not create duplicate QA files; they add update reminders to the existing QA document so testers know what may need review.
Bidirectional anchors connect document sections to related specs, design notes, technical decisions, external resources, or QA content. Readers can jump from source to target, and also see what references a section, creating a traceable delivery trail.
No. Stable QA preface sections come from templates, such as test scope, status definitions, test environment, and stop/resume criteria. The LLM only helps draft test cases. Test results and statistics should still come from real QA execution.
Yes. DahTahDoc separates default AI prompts for general documents, Specs, and QA documents. General documents focus on organizing, rewriting, and expanding content; Specs focus on requirements, flows, rules, and technical detail; QA documents focus on test case generation. Individual documents can still override the default prompt from the toolbar.
No. Role Review only appears for Spec documents. It helps SAs and PMs quickly see questions or attention points that PMs, SAs, frontend engineers, backend engineers, QA, or designers might raise. It reads only the current document, not the whole project, external resources, or other files. It does not score, approve, reject, or create QA. The result may be incomplete or incorrect and still requires human judgment.
No. Spec Change Plan only appears for editable Project Specs. The user first describes the proposed change, or explicitly sends one comment into the change description, then AI uses only the current Spec to suggest likely places to revisit, content to add, QA testing areas, and questions to clarify first. It does not read the whole project, QA files, all comments, anchors, links, external resources, or version history. It does not modify the Spec, create comments, create QA, or save results.
No. Reader Brief only appears on published Spec versions. Someone with edit access must actively generate or regenerate it with their own AI API key. Viewers can only read the saved brief; they do not trigger AI calls or spend tokens. The brief reads only that published version, not comments, external resources, linked documents, or the whole project. The original Spec remains the source of truth.
No. Folder Q&A answers only from visible, non-deleted documents inside the selected folder and shows source documents. It does not read other folders, the whole project, external resources, comments, or trash. Opening the Q&A page does not spend tokens; AI is called only after you submit a question. Each user keeps their own Q&A history for that folder, can ask a prior question again, and can clear only their own saved history. Saved answers keep source-document snapshots so older answers can be flagged after documents are updated or deleted.
Yes, DahTahDoc stores your API key, but saved raw keys are not returned to the browser: • Storage: Your key is transmitted via HTTPS and stored in the Supabase cloud database behind Row Level Security (RLS) and account-level access rules. • Never returned to the browser: Once saved, the key is never sent back to your browser. Only a boolean "configured" status is returned. • Server-side use only: When you use AI features, DahTahDoc's authenticated server API reads your key and calls the AI provider you selected. The key does not appear in your browser network requests. Security tip: We strongly recommend setting a daily or monthly usage/spending limit on your API key in your provider's console.
Yes. DahTahDoc uses Yjs CRDT technology for real-time collaboration. PMs, system analysts, engineers, and QA teams can edit and review the same document without passing around duplicate files.
Yes. DahTahDoc supports named spec versions and diff preview. You can review what changed in a read-only comparison view, and QA users can open the relevant diff from update reminders without losing their test case context.
Yes. You can invite members and manage view or edit permissions. Project documents follow project-level roles, which makes it easier to keep specs, QA files, and external references in one workspace for the same delivery goal.
Yes. DahTahDoc currently supports Microsoft Word (.docx), PDF, and Markdown (.md), so you can hand off documents to clients, teammates, or archival workflows.
No installation is required. DahTahDoc is a web platform. Desktop is best for full editing and collaboration, while mobile and tablet views are useful for reading, checking status, and following document updates.
Yes. DahTahDoc includes SA specification templates and QA preface templates. SAs can start from a structured spec outline, and QA documents can keep consistent sections for scope, criteria, environment, and summary data. Users can also save frequently used document skeletons as personal custom templates and reuse them from My Templates in the Template Picker.