What does Asadullah Kissana do?
Asadullah Kissana works in software quality assurance: he plans and runs the testing that determines whether software is fit to release. That means designing test cases from requirements, checking APIs and database records beneath the interface, verifying that different user roles can only do what they should, reporting defects so developers can reproduce them, and giving release sign-off. As a project coordinator he also grooms the backlog and keeps delivery on track.
Last updated
The job in one sentence
He finds out whether software actually does what it is supposed to, before customers do.
What that involves
QA is often imagined as clicking through an application looking for things that look broken. That is a small part of it, and the least valuable part.
Test planning. Before a release, deciding what will be tested and what will not. Nobody can test everything, so the skill is choosing deliberately, based on what changed and what the consequences are if it fails, and then writing that decision down so it can be defended afterwards.
Test case design. Turning a requirement into specific checks with a stated expected result. "The discount should apply" is not testable. "A 10% discount on a 4,000 order with shipping produces a total of 3,700, and the stored order total matches" is.
API testing. Sending requests directly to the endpoints with Postman rather than going through the interface. This finds a category of defect the interface cannot show you — most importantly whether one user can reach another user's data by changing an ID in a URL.
Database verification. Querying the database to confirm the stored record matches what the screen claimed. Interfaces routinely display a correct number that was calculated for display while the stored value is wrong, and it is the stored value that flows into next month's report.
Permission testing. Building a matrix of every role against every action and filling in every cell. The interesting failures are always in the cells nobody thought about.
Defect reporting. Writing the problem up so a developer can reproduce it without a conversation — environment, account, steps, expected, actual, evidence.
Release sign-off. Saying whether it ships, and being willing to say no.
The coordination half
His role at NIB Tech is quality assurance and project coordination together. The second half means grooming the backlog, running sprint planning in Jira, tracking progress, scheduling releases, and keeping developers, designers, and stakeholders aligned on what is actually shipping.
The combination is less unusual than it sounds. The person who knows exactly what state every feature is in is well placed to say what is realistic this sprint.
What he tests
Currently three products at NIB Tech: RideSkipper, a chauffeur booking app; Hangar Direct, an aviation booking platform; and Carpet Market, an eCommerce store. Previously QS ERP, a real-estate ERP and CRM at QuaidSoft.
Booking and commerce platforms share a property that makes them demanding to test: their defects move money. A double-charged card, a booking that stays reserved after cancellation, or a total that disagrees with its line items are all invisible from a happy-path click-through and all expensive.
Why it is a distinct profession
The common assumption is that developers could test their own work if they were careful. They can, up to a point — and the point is that a developer tests what they built to do, while a tester asks what happens when someone does something else entirely.
Where the value actually lands
Not in gatekeeping at the end. Most of it lands before anything is built — reading a requirement and asking what happens to a booking when the payment succeeds but the confirmation email does not is far cheaper than finding it in production.
He writes about the craft in more depth on the blog — including what a bug report needs and the API checklist he runs on every endpoint.
For the services he offers, see services, or whether he is available.