On every SSB software product
Flat 30% discount on any software
School, hospital, hotel, restaurant, HR, lab, pharma and the rest of our software. Ask for a quote and we apply 30% on the price. Write to info@ssbconsultancy.com.
Most painful defects are not exotic. They are the second click, the back button, the same bill saved twice, and the user who has no permission. A test pass that only walks the demo misses all of them.
The demo uses one clean customer and one happy payment. Go-live uses a partial payment, a duplicate tap, and a staff login that should not see prices. Those fail, and the team spends the next week in the customer’s office.
QA here is a list drawn from how the operation actually goes wrong. We run it. We write what failed in enough detail to reproduce. We run the failed items again after the fix.
We do not certify that software is bug-free. We say which cases passed, which failed, and which were not tested because nobody could describe them.
Including cancel, duplicate, permission and empty
What broke, on which step, with the data used
A fix is not done until the same case passes
The pass happens prior to go-live, not after the first complaint
Testing is the demo script, so only the happy path is proven.
Defects are reported as “it doesn’t work”, with no steps.
A fix is declared done without repeating the case that failed.
Permission bugs are found by a customer, not by a second login.
There is no time left because testing was scheduled after the launch date was promised.
The list includes the unhappy cases you already know: cancel, edit, duplicate, no permission, no network.
Each failure names the steps and the data.
The same case is run again after the fix.
A second role is part of the pass whenever two roles exist.
The launch date includes the pass. If the pass has not happened, the date moves.
What staff do, and the last three things that went wrong in real use.
On the build you intend to ship, not on a private branch.
Steps, data, and whether it blocks go-live.
Only the failures, plus anything the fix could have broken beside them.
No. We report what we ran and what happened. Untested areas stay labelled untested. A guarantee of zero defects is not something we sell.
No. The pass is against the build you point us at, with access and an environment that matches production closely enough to matter.
Not for a first pass. A written manual list of the real cases finds more, faster, when the product is still changing. Automation is worth it for cases you will rerun every release.
Before the date you told the customer. A test pass booked for the night before launch can only tell you the news. It cannot buy you time to fix it.
The project starts from a paragraph and grows in chat. A custom software engagement writes the first release, the price and the milestone you can click.
A brochure site looks finished and still leaves orders, applications or bookings in email. Web development here means the page that does the job.
A chatbot that sounds clever and answers from the wrong document. AI work here starts from the workflow and the source of truth, not from a demo script.
Tell us the operation that is breaking. We will walk that screen and send a written quote.
We reply instantly
