A practical test pass before you launch

Testing gets vague when it is described as “make sure it works”. A launch pass is more useful when it is a list someone can finish in a day or two and sign. Start from the journeys, not from the screens. For a shop, that is finding a product, paying, and seeing the order. For a portal, it is signing in, completing the main task, and signing out on a second device. For an internal tool, it is the path a new member of staff would take on a Monday morning. If a journey is not on the list, it is not in this release. Each journey needs one happy path and two ways it can fail. A card payment that is declined. A form submitted with a missing field. A session that expires in the middle of the task. These are the failures customers actually meet. They are cheaper to rehearse than to explain later. Devices are part of the pass. At least one current phone, one laptop, and the browser your own staff use. If the product is a point-of-sale app, the pass happens on that hardware, not on a developer’s handset. A layout that is fine on a wide monitor and broken on the device in the shop is not launched. Security checks at this stage are plain. Accounts cannot see each other’s data. A password reset works. Admin pages are not public. Files and exports contain only what that person should have. This is not a full audit. It is the minimum that should be true on day one. Decide in advance what blocks the launch. A broken payment blocks it. A typo in a footer does not. Write that down so the last evening is not spent negotiating. After launch, keep a short list of what was skipped on purpose, and schedule it. “We will watch it” is not a plan unless someone is actually watching. Sayra Tech’s testing work covers manual passes and automated checks, aimed at software that is fit for the people who use it. The useful starting point is the journey list, not a tool name.