A launch date is set, the supplier says the system is ready, and management must decide whether to go live. Often nobody can say how much of the system was actually tested, which defects are still open, or what happens to customers and staff if a serious one appears after launch. The decision ends up resting on pressure rather than evidence.
Kemlat gives you an independent view before you decide. We review what the product must do, plan the tests that matter most, run them, and record every defect with its severity and its effect on the business. You receive a clear recommendation: the release is ready, ready with conditions, or not ready, together with what must be fixed first.
How we work
- 01
Review the product and its risks
We study the requirements, the main user flows and the integrations, and ask the business owners what would hurt most if it failed. This decides where testing effort goes.
- 02
Write the test plan and matrix
We write a test plan and a test matrix, a table that links each requirement and user flow to the test cases that check it. You can see at a glance what will be covered and what will not.
- 03
Run the tests
We test the agreed flows on the target browsers and devices, including wrong inputs, permissions and failed connections. Each defect is logged with the steps to reproduce it, screenshots and a severity rating.
- 04
Retest the fixes
When your developers or the supplier fix defects, we retest them and check that the fixes have not broken related features.
- 05
Recommend a release decision
We summarise the open defects and risks in business terms and recommend releasing, releasing with conditions, or delaying. Each condition is specific, such as a fix required before a certain feature is switched on.
What you receive
Test plan
What will be tested, how and on which devices and systems, with the conditions for starting and finishing testing.
Test matrix and test cases
A table linking requirements and user flows to written test cases, with the result of each run.
Defect log
Every defect with reproduction steps, evidence and severity, kept in a tool your team and supplier can both open.
Risk report
Open defects and untested areas explained by their effect on customers, staff and operations.
Release readiness recommendation
A written recommendation, with any conditions attached, for management to approve.
What changes for you
- Management decides on the release with a clear picture of the open risks.
- Serious defects are found before customers find them.
- Your team and the supplier work from one shared list of defects and priorities.
- Later releases can reuse the test plan and test cases.
Where this service sits in the KEMLAT Method
Scope: Testing covers the flows, devices and system copies (for example a test copy and the live system) agreed in the test plan. Fixing defects remains the job of the development team, whether that is your own team or a supplier.
Questions clients ask
Why not let the developers test their own work?
Developers should test their work, and good ones do. An independent tester looks at the product from the user's side and has no stake in a particular release date, which gives management a more neutral view.
What do you need from us to start?
Access to a test environment (a separate copy of the system set up like the live one), the requirements or feature descriptions, test accounts for each role, and a contact on the development side who can answer questions about defects.
Does this include security testing?
We check basic access rules, such as whether one role can see another role's data. A full security test is a separate, specialised assessment.
Can the test cases be reused after the release?
Yes. The test matrix and cases are handed over and can be run again before later releases. The ones repeated most often are good candidates for test automation.
Related services
All servicesStart with a conversation
Tell us where you are today. We will suggest the right first step, with no obligation.