Quality Assurance (QA)

Core tool for daily work: Network to see the request a screen actually sent and the status it got back, Console to catch front-end errors, Elements to confirm what is on the page versus what should be

Full format: ID, title, preconditions, steps, test data, expected result, actual, status — written so a person who has never seen the screen can execute them without asking questions.

Taking one product screen by screen and producing a coverage record: what was tested, what was not, and what is deliberately out of scope — trained until the intern can do this on a product nobody walked them through.

The five standing questions (what were you doing, what did you see, which record when, has it worked before) that turn "the booking page is broken" into something testable.

Knowing which question to ask a developer, the most useful being which distinct values a status column actually holds — which exposes values nobody intended, including typos the front end has been saving for months.

The checks that run before every release for one product: each critical flow with its exact test data, plus every defect found during the program added as a permanent check so it cannot return

Building test case sheets and coverage records: COUNTIF to tally pass/fail/blocked, filters to isolate one product or one screen, formatting to make gaps visible at a glance.

Grouping inputs that should behave identically and testing one value per group, then testing the value on each side of every limit (mileage 0 and -1 , the day a month ends, the status that is no longer editable).

Run on every form: submit empty, one character over and under each limit, wrong data type, value outside the allowed list, double-submit quickly, leave mid-way and return, and submit on a slow then dropped connection.

Reproducing on staging with the same role and data before anything reaches a developer, and sorting the result into one of four outcomes: reproduced, production-only, cannot reproduce, or working as designed.

Our servers store UTC while Indonesia spans three zones: testing a record created at 23:30 Jakarta time across every screen and report, to catch both wrong times and wrong dates.

What is verified before and after a deploy, including the checks that only matter in production: a real login works, an integration actually fired, no error spike started.

All eight and who uses each: two websites and the embedded form on the customer side, then CRM, DMS, CMS, Master Data and User Management for staff — including which gateway serves each, and that CMS is still in development.

Working every field deliberately wrong: blank, too long, wrong type, wrong case, a value outside the allowed list — and recording which of those are refused cleanly and which break something.

Logging in as each role and checking both what is visible and what is actually permitted, including whether a hidden button is genuinely blocked or merely hidden — producing a permissions matrix per dashboard.

Three sentences in plain language — what was found, what happens next, when they will hear again — with no internal jargon, and the loop always closed, including when the answer is that the system is behaving correctly

Mapping which statuses exist, which transitions are allowed and which are final, then testing the forbidden ones: cancelling an already-cancelled booking, editing a closed record, sending a status that does not exist.

Investigating whether we should automate at all: comparing Playwright, Cypress and Selenium against what our frontends are built with, identifying which checks are worth automating and which never are, estimating setup and maintenance cost, and naming who would own it after month 6. Delivered as a written recommendation plus one proof-of-concept script, not a framework.

What 400 , 401 , 403 , 404 , 422 and 500 mean, and the distinction triage depends on: 422 means the server understood and refused, 500 means the server broke.

Title, environment, numbered steps from login, expected, actual with the exact message, evidence, severity — the standard being that a developer can reproduce it from the report alone. They will still discuss the fix with you — a good report is what makes that discussion short and about the fix rather than about what you meant.

Using the request a screen sent to answer one question: did the page fail to send something sensible, or did the server reject it — noting that our encrypted request bodies look unreadable by design, and that a 500 is always worth filing

One row per issue: date, reporter, symptom, outcome, resolution, days open — maintained so the mentor and whoever handles support next can see the shape of what comes in.

What a callback is, why one can arrive twice, and why "we sent it" and "they received it" are different claims — including that a vendor replying 200 proves delivery, not understanding

One owned project presented to the dev team: a CMS test suite, a staff issue playbook, an FMS integration test pack, or a documented test data generator.

Staging only, never production; no commands that write data; redacting customer names, phone numbers and plate numbers before anything leaves our systems.

Critical, high, medium, low, each with a one-line justification, so two people reading the same defect agree on how urgent it is.

Dashboards on a laptop, website and embedded form on a phone, because that is where customers are — a form that works on desktop and fails on mobile is a customer-facing defect

Keeping a tally of repeated expectations, on the principle that three staff making the same "mistake" is a product problem rather than three support problems.

Verifying that something which should have happened actually happened, since a skipped action and a successful one look identical unless somebody checks — the habit that catches the bugs no screen shows.

All test cases, logs and suites in a place the team will find, plus a walkthrough with whoever inherits the work.

Writing down what they know that is not yet written down, which is usually the most valuable thing produced in the whole six months.