The QA Engineer path
From testing the requirement rather than the build, through designing coverage and running cycles, to closing the loop on defects and traceability.
The order below is a suggestion, not a sequence you have to follow. Start wherever is useful to you.
- What a QA Engineer actually does
QA is not the last step before release. It is the discipline of deciding what evidence would prove a requirement was met, and gathering it.
The version of the role that starts before the build exists.
Foundation4 min read - Writing acceptance criteria that hold up
Acceptance criteria fail for predictable reasons. Here is how to write them so a QA Engineer can build coverage without asking you a single clarifying question.
Read this even though a Business Analyst usually writes them. Coverage is only as good as the criteria it targets.
Practitioner4 min read - Generating test cases from requirements
How to turn an elaborated requirement into test coverage you can defend, using TestCraft, and the design principles that make generated coverage trustworthy.
Practitioner4 min read - Running a test cycle: a TestExecute guide
Why blocked is a first-class result rather than a kind of failure, what a run record needs to stay meaningful, and how execution feeds readiness.
Practitioner4 min read - Tracking defects across the pipeline
Defects do not only come from testing. How ReqLens tracks where a defect was found, separates severity from priority, and makes rejection reasons useful.
Practitioner4 min read - A traceability matrix people actually use
Most traceability matrices are compliance artefacts nobody reads. Here is what to link, what to leave out, and how to keep it alive after week three.
The link most teams skip is criterion to test. This is why it matters.
Practitioner4 min read