Acceptance turns into an argument when what was agreed was a set of wishes rather than checkable criteria. The question "is it done" then becomes a matter of taste, and the answer depends on who happens to be speaking.
For us, testing starts in the same place analysis does: from the requirements. Every test case is linked back to a requirement and an acceptance criterion, so the result is not an opinion but a written basis for a decision.
The test cases are written so that your team, your development partner or an automation engineer can run them. The form is Gherkin-style or tabular, depending on what your tools already work with.
A requirement, an acceptance criterion and a test case are three links in one and the same chain. When they are written by the same person who made sense of the requirements, nothing is lost in translation: what gets tested is what was agreed, not what the developer thought had been agreed.
The same pattern repeats across all our services. In analysis it is requirement, control and evidence. In migration it is field, transformation rule and reconciliation check. In testing it is requirement, criterion and test case.
That is why testing is analyst's work for us. The user stories and acceptance criteria that are part of the requirements set anyway are already half of the test basis.
Scope, levels, environments, test data and exit criteria.
Steps, preconditions, expected results, and the link to the requirement.
Requirement through to test case and back, with the uncovered areas marked.
What was tested, with what result, which findings are open, and what their impact is.
Reproducible steps, severity, impact, and the result of retesting.
All deliverables are handed over in editable formats. The test cases stay with you and can be used before every release that follows.
A security requirement is a requirement like any other, and that makes it testable. Checking access rights role by role, the visibility of sensitive data in the wrong views, session behaviour, information leaking through error messages, and logging of the events that later have to be proven. These go into the test set exactly as functional cases do.
Test data is a decision of its own. If real data is needed for testing, we agree beforehand in what form it is used and how long it is kept in the environment. For attack testing and penetration testing we bring partners in, and we agree that before the work starts.
The founding analyst has 13+ years of practice with requirements, acceptance criteria and system-to-system checks in banking, telecom, IT consulting and logistics. In those fields acceptance is a written act: somebody has to state, on the basis of a document, whether the solution matches what was agreed.
Qualification: BCS Foundation Certificate in Business Analysis. Working languages Estonian and English.
We write in Estonian first. The pieces below have not been translated yet and open in Estonian.
Each of these is a starting point; we settle its scope in conversation and fix it in a written offer. The steps can be taken separately, or one after another in a logical sequence.
A fixed-scope written document that settles what is tested, at what level, and on what basis. Suits the start of a project, or the run-up to a larger release.
What it includes:
Turning requirements and acceptance criteria into runnable test cases, with a coverage matrix. The deliverable is usable even when somebody else runs the tests.
What it includes:
Running the tests before acceptance, producing a record on the basis of which "accepted" can be stated in writing. Works for internal development and for acceptance under a tender contract alike.
What it includes:
A look at how testing is done in your organisation today. Suits you when defects are found late and you want to know where that comes from.
What it includes:
Write down what is nearing completion and on what basis you would accept it today. We talk the scope through and send a written offer. We reply within one working day, and the first discussion is free.
