How QATestLog works

1 · A team, then a project

Everything belongs to a team. You create one and become its admin; you add colleagues by e-mail, and each gets a role in that team — admin, editor or viewer. The roles are per team, so the contractor who edits on one project can be a viewer on another without a second account. If the person has not registered yet, the invitation waits and they join the moment they sign up with that address.

A project is the application under test. Give it a short prefix and its bugs are numbered ACME-1, ACME-2, and so on — permanently, because a reference written down in a chat log has to keep meaning one thing. Write the description properly: it is what the plan generator reads.

2 · Versions

An application has versions, and a bug that does not say which version it was found in is a rumour. Add them as they appear — planned, in development, in test, released. Bugs record the version they were found in and the version they were fixed in, which is what makes a regression visible.

3 · Log the bug

Summary, steps, expected, actual, environment, severity, priority, how often it happens, and any screenshots. Severity is the consequence to the user; priority is when somebody looks at it. They are different questions and the form keeps them apart.

If you would rather type what you saw and sort it out afterwards, paste the note into the drafting page. What comes back is a filled-in form — not a saved bug — with a list of everything it could not tell from your note. You correct it and save it yourself.

4 · Test plans and cases

A plan states the objective, what is in scope, what is deliberately out, the approach, the risks, and the entry and exit criteria. Its cases each end in one observable result. You can write them by hand, or draft them from the project description and edit what you keep — every generated case is marked as AI-drafted, so a reviewer can always see where it came from.

5 · Run them

A run is one pass through a set of cases against one version. The whole case list is written in as untested when the run starts, so coverage is a fact rather than a guess. Record pass, fail, blocked or skipped as you go. When a case fails you can open the bug from there, and it carries the case's steps and expected result across.

6 · Talk about it somewhere else

Each team has a message board: threads and replies, pinned where it matters, closed when a question is settled. A thread is either a general message to the team or about one particular project, so the board can be read a project at a time, and a project's own page shows what has been said about it. It exists so that a bug's history stays the record of that defect — readable years later by someone who was not there — instead of collecting "has anyone got the staging password". The author of a post can edit it and a team admin can edit anything; nobody else rewrites a colleague's words.

7 · Decide

The version page shows what was found, what is still outstanding — including anything a developer marked Fixed that no tester has verified — and what every run against it covered. Ask for a readiness summary and you get a verdict with the blockers named, the gaps listed, and the date it was written, so nobody quotes a summary that three later failures have overtaken.

Working to ISO/IEC/IEEE 29119

Any project can be switched from the everyday flow to ISO/IEC/IEEE 29119. It does not change how the tool works — it changes what it insists you write down. The test plan gains the sections §7.2 calls for, test cases gain their identifier, objective, coverage items and traceability, bugs gain the context and risk that §8.11 asks for, plans carry environment and data requirements with their readiness, and a run keeps an execution log. Status and completion reports are assembled from a run and frozen: the figures are those of the day they were issued, because that is the whole reason somebody asks for one later.

A conformance page lists every document type, says which sections are still empty and names the document types this tool does not produce. It is a documentation aid, not a certification. It cannot judge whether what you wrote is adequate, and conformance is assessed by people against all of the standard, of which Part 3 is one part.

The choice is made per project, so one audited client engagement does not put its paperwork on every internal tool in the same team.