Saifullah MuhamadBusiness analyst, QA

Open to work, Johor, Malaysia

System and business analystI take systems from requirements
to sign-off.

Four years of council and enterprise systems: the requirements, the Figma screens, then UAT sign-off with Playwright and Appium.

Download résumé See my work

Saifullah MuhamadSystem and business analyst, QA

Years on council and enterprise systems

Public-sector clients in production

Automated E2E tests in the repo

~100

Regression suite, Playwright and Appium

Delivered for

MBPGMajlis Bandaraya Pasir Gudang FELDA DBKLDewan Bandaraya KL

Real projects, real screens.

Four systems. What I built, what my role was, and what changed after.

01MBPG

IPS, Integrated Patrolling System

A web portal for the council’s enforcement unit to schedule patrols by zone and track officers live on a map.

My roleRequirements, process flows, portal design, testing

4 zones5-min GPS refresh2026

02MBPG

IPS Mobile, Patrol App

The Android app officers carry in the field: today's schedule, a live patrol timer and GPS on the route.

My roleUI design and end-to-end testing

AndroidLive GPS2026

03Figma

IPS Portal, Clickable Prototype

The whole portal designed in Figma before any code, so the client could click through it and changes cost minutes, not sprints.

My roleUX design, ERD, swimlane diagrams

FigmaERD + swimlaneWeb

04FELDA

IMS PPP, Settler Development System

A dynamic form builder with multi-level approvals, complaints, PDF reports and a CMS portal.

My roleWrote URS and SRS, led data migration

SpecsETL migrationLaravel

05Automation

~100

automated E2E test cases

~80%

shorter regression cycle

platforms, web and Android

CI/CD

runs on every merge

E2E Regression Suite

Replaced days of manual re-testing with Playwright (web) and Appium (mobile) suites that run on every merge.

My roleDesigned and built the suite, Page Object Model

PlaywrightAppiumPOM

06Side project

ShopeePilot

My own automation tool: reads product frames from video, writes Malay captions from 12 copy frameworks, and queues them in a review dashboard.

My roleBuilt it solo, end to end

476+ videos12 frameworks2026

Me, as an analogy.

This is how I picture who I am. Imagine a restaurant: I'm the waiter, the client is the customer, and the developer is the chef.

A client asking for a “user-friendly system” is like a customer asking for a “delicious tom yum”. My job is to turn that wish into an order the kitchen can actually cook. Flip through the story.

Waiter = me (BA & QA)Customer = clientChef = developer Order ticket = URS / SRSTaste test = UAT & automation

Client asks the waiter for a delicious tom yum; the waiter looks puzzled — 01
**"Delicious" can't be tested.** Neither can "fast" or "user-friendly". So I don't nod. I ask.

Waiter asks questions and writes down the order — 02
**"Prawns, no peanuts, level 3."** Now it's measurable. That's requirement gathering.

Waiter hands a written order ticket to the smiling chef — 03
**The chef gets a clear ticket, not a guess.** That ticket is my URS / SRS for the developer.

Waiter serves the tom yum and the client gives a thumbs up — 04
**"Exactly what I wanted!"** Because I test it first (UAT and automated checks), the client never gets a surprise.

One person, the whole cycle.

Most projects hand work between an analyst, a designer and a tester. I cover all three, so nothing gets lost between them.

Gather

Sit with the users, map how the work really happens, and pin down the rules.

Output: process flows, requirement list

Design

Clickable Figma screens the client can try, so changes happen before code, not after.

Output: Figma prototype, ERD, swimlane

Specify

One written source of truth that developers build from and the client signs.

Output: Requirements and design specs, acceptance criteria

Verify

Run UAT and FAT to sign-off, then automate regression so it stays green.

Output: signed UAT, automated test suite

Bugs? This is how I report every one before it goes to production.

Here is a sample ticket that follows my usual flow: found in UAT, fixed by the developer, retested by me, then cleared for release.

Clear title that says where, what and when.
Exact steps with the user, role and test data, so anyone can repeat it.
Expected vs actual, linked to the requirement it breaks.
Proof and a hint: screenshot, video, network log, and where I think it breaks.

Sample bug ticket BUG-214: steps to reproduce, expected vs actual result, note for developer, attachments, and the fix and retest activity

View full size ↗

Sample ticket with made-up data, written the way I write real ones.

What I use every day.

Grouped by the job they do on a project.

Business Analysis

Requirements and specsUser storiesAcceptance criteria Requirements gatheringClient sign-offChange requests

Test Automation

PlaywrightAppiumSelenium Page Object ModelGitHub Actions CI/CD

Testing

UAT, FAT and PAT sign-offFunctional testingAPI testing in Postman Defect triageTest scripts & data

Design & Documentation

FigmaERDUse-case diagrams SwimlaneUser manuals

Technical

MySQLLaravel, PHPJavaScript / TypeScript PythonMarkup and stylingGit

Ways of Working

SDLCAgile / ScrumWaterfall Bahasa MalaysiaEnglish

Highlighted = strongest, used on every project

Where I've worked.

4+ years across government and enterprise projects.

Sep 2025 to presentContract, remote

Current role

Business Analyst & Lead Automation Tester

NK System (M) Sdn Bhd

Own the Enforcement (Penguatkuasaan) module of the ePBT system for local councils. Main contact between council users, developers and QA.

Turn requirements into Requirements and specs, user stories and acceptance criteria, and walk them through with SMEs to get sign-off before build.

Built the module's E2E regression suite in Playwright and Appium, cutting the regression cycle by ~80%; lead manual and API testing before each release.

Jun 2024 to Aug 2025Contract, Petaling Jaya