為何我開發並測試：我的前端工程與 QA 歷程

My professional journey didn't begin with writing code. It began in customer service, where my career started before I moved into frontend development and, later, software quality assurance.

Today, I approach software from both perspectives. Frontend engineering has taught me to think about how an application is built and how people interact with it. QA has taught me to question assumptions, investigate behavior, and look for evidence that something works as intended.

Those two perspectives shape how I approach engineering and the philosophy behind Naj Builds:

BUILD • VALIDATE • SHIP

From customer service to building software

I worked in customer service from May 2021 to April 2023. In April 2023, I transitioned into a Junior Frontend Developer role, contributing to frontend development in a Laravel-based application environment.

That was an important change in my professional responsibilities. I was no longer looking at software only from the perspective of someone interacting with it. I was contributing to the application itself, working within an existing system where implementation decisions needed to fit the surrounding code and requirements.

In September 2023, I transitioned into software quality assurance as a QA Tester. In November 2024, I progressed to QA Analyst II.

Each role brought a different responsibility into focus: understanding how people experience software, contributing to how it is built, and investigating whether its behavior meets expectations.

My learning has also included BlueCrest, the ALX Software Engineering programme, the AltSchool Africa Frontend Engineering programme, HNG internship participation, and further testing and AI-related training.

Today, my technical interests include React, TypeScript, modern frontend engineering, manual and API testing, and AI-assisted development.

I don't see frontend engineering and QA as competing directions. They give me different ways to approach the same problem: building software that behaves as intended and being able to explain how I know.

QA changed the questions I ask

Working in QA has changed how I examine software.

When investigating an issue, I reproduce the behavior, compare what happens with what the requirement describes, examine relevant UI states and API responses, and document expected and actual results.

When a developer implements a fix, I retest the affected behavior. Functional testing helps determine whether requirements are met, while regression testing helps identify whether a change has affected existing functionality.

One distinction matters especially to me: observing a problem is not the same as knowing its cause.

A screen may display the wrong value, but that observation alone does not establish whether the issue originates in frontend state, an API response, or somewhere else.

This is one reason I value clear reproduction steps and evidence. They make an investigation easier to communicate, repeat, and evaluate.

And yes, sometimes QA feels a little like detective work. The difference is that the clues need to be reproducible.

One interaction, two engineering perspectives

Consider a simple shopping-bag interaction.

This is an illustrative example, not a recorded incident or executed test from my work.

Suppose a customer changes an item's quantity from one to two. The requirement is that a successful update changes the displayed quantity and line total. If the update fails, the interface should communicate the problem and remain consistent with the saved state.

From a frontend perspective, I would consider the quantity control, pending state, successful update, error feedback, and the relationship between the interface and saved data.

From a QA perspective, I would examine the same interaction through expected behavior.

Does the quantity change correctly? Does the line total reflect the updated quantity? What happens when the update fails? Can the customer understand what happened?

Both perspectives begin with the same requirement, but they explore different responsibilities.

Building the interaction is one part of the work. Checking whether the interaction behaves correctly is another.

For me, that is where frontend engineering and QA become especially valuable together.

Bringing those perspectives into Lumé House

Lumé House Web is an ecommerce application where I am the project developer and owner. My responsibilities include frontend engineering, product decisions, QA, and AI-assisted implementation and review.

The application uses React, TypeScript, Vite, Tailwind CSS, and Supabase.

My work has included implementation and validation across the product catalogue, authentication, shopping-bag and cart behavior, checkout, and order-related workflows.

Working on an ecommerce application brings connected interactions into the same project. A customer might browse a product, add it to a bag, sign in, and proceed towards an order. Each interaction has implementation requirements and behavior worth checking.

As the project owner, I am responsible for defining what the application should do, reviewing the implementation, and evaluating the evidence supporting its behavior.

The project is available through its GitHub repository and web deployment.

However, implemented functionality, validation of a particular scope, and full release readiness are not interchangeable. Outstanding staging, infrastructure, and release work remains. This article does not claim that every feature is production-complete or that the current deployment has been independently validated.

I intend to explore specific implementation decisions and testing evidence in future Lumé House case studies.

BUILD • VALIDATE • SHIP

Build means understanding a requirement and making implementation decisions that fit the application.

Validate means examining whether the behavior meets expectations, investigating differences, and documenting what the available evidence supports.

Ship means making a readiness decision with a clear understanding of what has been checked and what remains unresolved.

These three words are more than a slogan for Naj Builds. They describe the responsibilities I want to make visible in my engineering work and technical writing.

I want to explain not only what I built, but also why I approached it that way, what I checked, and what I still need to improve.

Working with AI and owning the result

AI-assisted engineering is part of how I work on Lumé House.

I use AI tools to support implementation, investigation, code review, and testing. But using AI does not transfer responsibility for the result.

I still need to understand the requirement, evaluate suggestions, review the implementation, and check whether the resulting behavior is appropriate.

An AI-generated explanation can be useful without being correct. A proposed fix can appear reasonable without addressing the underlying issue.

That is why I want evidence and review to remain part of the workflow.

In future articles, I plan to share how AI contributes to particular tasks, which decisions remain mine, and how I evaluate the results.

Why Naj Builds, and what comes next

Naj Builds is where I bring these parts of my journey together: frontend engineering, QA, continuous learning, and the projects through which I apply what I learn.

I want this space to contain more than finished screenshots or lists of technologies.

I want to write about the decisions behind implementations, the problems I investigate, the tests I perform, and the lessons that come from work that is still progressing.

That includes frontend architecture, React, mobile development, Supabase authentication, QA practices, AI-assisted workflows, HNG learning, and ecommerce engineering.

I am still learning, building, and refining how I work. Technical writing gives me a way to document that process and share something useful with others who are navigating similar paths.

If you build software, test it, or do a little of both, I hope you find something useful here.

What is one question testing has taught you to ask before calling a feature done?