About

Hi, I'm Riza

I am Lutfiyan Riza Amada, known to most as Riza. Based in Surabaya, Indonesia, I serve as a QA Engineer at a global management consulting firm that partners with leading multinationals on strategy, growth, and cross-border expansion. I work at the point where business process meets software, making sure the systems a firm runs on behave exactly the way its people expect.

What I safeguard: HUB

I am the sole quality owner for HUB, the firm's internal ERP platform that underpins its day-to-day operations across three core domains:

HUB is used across offices and countries, so its quality directly shapes how smoothly the firm operates every day.

What I built: HUB-Automate

I designed and continue to grow HUB-Automate, the end-to-end test automation framework that guards HUB's regression path, built with Playwright and TypeScript. It is engineered to be trusted and easy to act on: page objects and shared fixtures keep flows reusable, test data is created and cleaned up on every run, role-based smoke tests follow what each user can actually access, and every failure ships with a trace, screenshot, and video. Results are published as Allure reports, and the suite runs locally, in Docker, or in CI through GitHub Actions.

Now: next-generation HUB

How I work

My week is split. Manual testing during the sprint, against acceptance criteria and against the parts of the product nobody wrote criteria for. Automation in between, so regression stops eating release days. I verify APIs with Postman, track defects and test runs in Jira, and write bug reports a developer can act on without a follow-up call. Every release passes through end-to-end testing before it reaches the teams who rely on it, so what we ship is not only functional, but dependable.

Before this: performance at scale

Before joining the firm, I worked on performance testing at Bank Rakyat Indonesia, designing load, stress, and spike profiles in JMeter and reading how the system responded in Kibana and Dynatrace. That job taught me that a number is only a finding once you can explain which part of the system produced it.

Beyond the test suite

I write here when something is worth explaining twice: a testing decision, a flaky test I finally understood, a habit that made review faster. So far that has meant arguing that flaky tests are a design problem, taking apart what makes a bug report worth fixing, and documenting a weekend spent taming stubborn Playwright tooling.