Give the Method One Home and the Facts Another

The QA methodology was written out in full in two separate files.

Not summarised in one and detailed in the other. Written out, twice, and both versions were correct on the day they were written.

How You End Up With Two of Everything

Nobody duplicates documentation on purpose. It arrives one entirely reasonable copy at a time.

You are writing a process note and the analysis method is relevant, so you include it — properly, because a half-explanation would be worse than none. Six months later somebody needs the method at a different moment in the work, in a different file, and the same reasoning applies. Both authors were right. Both copies were accurate.

Then one gets updated.

That is the whole mechanism. Drift is silent because neither copy knows the other exists. There is no error, no conflict, no build failure. Both files remain individually plausible — internally consistent, well written, confidently phrased — and a reader arriving at either one has no way to tell they are holding the stale version. They pick whichever they opened first.

Consolidating the workspace is what surfaced it, and the methodology was the smaller half. Every customer journey was documented twice as well: hand-written Gherkin feature files on one side, and knowledge notes synthesised from 313 actually-executed test cases on the other. Two full descriptions of how the system behaves, drifted apart, with no marker on either saying which one had been checked against reality more recently.

The Split Everyone Uses Is the Wrong One

Ask where a piece of QA knowledge belongs and the default answer is organised around artefact type. Documentation over here, code over there. Confluence versus the repository. Test cases versus test scripts.

That axis does not predict anything useful, because both sides of it contain the same two very different kinds of sentence.

A method is an instruction. How to analyse a requirement. How to classify a defect. What to check before starting a retest. It answers what do I do, and it is only useful at the moment somebody is doing the work.

A fact is a claim about the system. What the join journey does. Which statuses exist. What happens to the invoice when a discount is applied to an add-on. It answers what is true here, and it is only useful when somebody is reasoning about the system.

Those two things have different lifecycles, different owners, and different failure modes. A stale method makes people work the wrong way. A stale fact makes people test the wrong thing. Filing them together — because they happen to be about the same feature — is what produces documents that must be updated for two unrelated reasons and therefore get updated for neither.

The Rule

Give the method one home and the facts another. Then delete the second copy of each.

Method belongs in the layer that executes: the runbook, the checklist, the standard, the file your tooling loads at the moment the work happens. If an instruction is not read at the point of doing, it is not an instruction — it is an essay about how you would like the work done.

Facts belong in project knowledge, in one place, structured for retrieval rather than for reading front to back. Nobody reads a fact base. They query it, one question at a time, usually under pressure.

And where a second copy feels necessary, put a reference instead. A one-line pointer that goes stale visibly, because a broken link is loud and a drifted paragraph is silent.

Sorting an Existing Pile

You do not need a migration project. You need a rule you can apply to a paragraph in five seconds.

• Read each paragraph and ask: does this tell me what to do, or what is true? Instructions go to the execution layer, claims about the system go to knowledge. Anything you cannot classify is usually two paragraphs that got written as one — split it, and the answer becomes obvious.
• Search for your own headings, not for content. Duplication reproduces structure. If the same section title appears in two files, you have almost certainly written that section twice, and comparing them takes a minute.
• Date the facts, not the methods. A fact about a system is true as of an org state and a release; a method is true until you change your mind. Facts need a "checked on" marker so a reader can weigh them. Methods need an owner.

Prefer What Was Executed Over What Was Intended

The Gherkin half deserves its own conclusion, because it looked like the more rigorous artefact and was the less reliable one.

Hand-written feature files record what somebody intended to test, written before execution, usually before the system was finished. The executed suite records what the system is actually held to — including every correction made during execution, when a step turned out to be conditional, an assertion turned out to belong to a different branch, or a case turned out to be describing behaviour that never existed.

Those corrections are the most valuable knowledge the programme produces, and they only ever land in one of the two artefacts. Intent does not get corrected. It just gets superseded, quietly, by what happened.

So when journey knowledge has to come from somewhere, take it from the cases that ran. They are less elegant, they are written in nobody's favourite syntax, and they are the only version that has been checked against the system.

Why This Is Hard to Notice From Inside

Because the moment of duplication is the moment of maximum usefulness.

You paste the method into the second file precisely because it was needed there. Everyone who reads it that week is better off. The cost lands months later, on a different person, in the form of a decision made from a stale copy — and that person will never know which document they should have opened.

Duplication does not fail. It defers.

Take the two documents you rely on most. Does either contain a paragraph that also lives, in slightly different words, in the other?