Jerry Finol QA

The Day I Stopped Competing With Other QA Engineers

Thu, 30 Jul 2026 00:00:00 +0000

When I first started learning Quality Assurance through a bootcamp, I thought I knew exactly how to become a great QA engineer.

Write more test cases. Find more bugs. Cover more edge cases.

I still remember one assignment where I wrote nearly 150 test cases for a single feature. At the time, I thought:

“This is it. This is what professional QA looks like.”

I was proud. And honestly… That exercise taught me discipline. But it didn’t teach me how to stand out.

Then I hit my first wall.

I graduated.

Started looking for opportunities.

And suddenly I realized something. There were hundreds of other junior QA engineers. Many had completed the same bootcamp. Many had learned the same techniques. Many knew exactly what I knew.

So I thought…

“Maybe automation will make the difference.”

So I built frameworks.

One after another. Each one more ambitious than the last.

Python. Playwright. Selenium. TypeScript. CI/CD. Reports. Coverage. Architecture.

And I genuinely loved building them. I still do. In fact, some of my favorite projects on this portfolio are automation frameworks. But eventually… I hit another wall.

Mid-level engineers also build frameworks. Senior engineers build even better ones. Once again…

I wasn’t really different.

I stopped trying to become the QA engineer who found the most bugs. I started trying to become the QA engineer founders wanted on their team.

Then I tried something completely different.

Instead of applying for jobs… I started helping startups. I sent a simple message.

“I’m a QA engineer. I’d like to review your product for free and share my thoughts.”

That small decision changed everything.

I wasn’t trying to impress them anymore.

I was trying to understand them.

I wanted to know: Why did they build this? Who were they building it for? What problem were they trying to solve?

Once I understood that…

The report almost wrote itself.

Yes. I still documented bugs. I still reproduced issues. I still reported broken functionality.

But something else started appearing in every report.

Ideas. Observations. Questions. Suggestions. Praise.

Empathy.

Something unexpected happened.

Founders didn’t remember how many bugs I found. They remembered something completely different. They remembered feeling understood. Instead of receiving a document saying,

“Here’s everything that’s wrong.”

they received something that felt more like:

“I understand what you’re trying to build. Here’s how I think we can make it even better.”

That changed every conversation.

I finally understood what my job was.

I’m not trying to beat other QA engineers. I’m not trying to write the biggest bug report. I’m not trying to build the most complex automation framework.

Those things matter.

But they aren’t the reason founders come back. They come back because they feel like someone cared enough to understand their product before judging it.

That’s What Makes My Reports Different

Every report still contains technical findings. Bug reports. Reproduction steps. Expected behavior. Severity. Recommendations.

That’s part of the job.

But every report also answers questions like:

Would I keep using this product? Where did I hesitate? What made me smile? What made me trust the platform? What would make me recommend it to someone else?

Because users don’t stay because your API returns 200.

They stay because your product makes sense.

Final Reflection

For a long time, I thought I needed to compete with other QA engineers.

Today…

I don’t think that’s the goal anymore.

My goal is much simpler. To understand your product deeply enough that I can help you improve it. That’s why I still enjoy building automation. That’s why I still enjoy finding bugs. But above everything else… That’s why I enjoy listening.

Because every startup begins with someone believing they can build something people will love. And if my work can help them get a little closer to that goal…

Then I’ve done mine.

Understand first. Test second. Explain always.

The first thing I test isn't the software.

Thu, 30 Jul 2026 00:00:00 +0000

When I first started in QA, I believed testing started the moment you opened a website.

Click every button. Open every menu. Verify every link. Try to break everything. That was my process. Or at least…

I thought it was.

One day I opened a website and found myself completely lost.

Not because it was confusing. Because I didn’t understand what it was.

I remember thinking:

“I can test every button on this page… but I still don’t understand what this product is.”

So I stopped. Made myself a cup of coffee. And started asking questions instead.

What is this? Who built it? Why does it exist? What problem is it trying to solve?

A few minutes later… Everything clicked. It wasn’t a SaaS platform. It wasn’t an application.

It was the official website for a product.

That changed everything.

Suddenly, I Was Asking Different Questions

Instead of asking:

“Does every button work?”

I started asking:

Does this website explain the product clearly? Does it build trust? Does it make me curious? Does it make me want the product? Would I keep reading?

Because that’s the real purpose of a product website. Not existing. Converting visitors into customers.

Only after understanding that…

I started the technical review.

UI. UX. Accessibility. Responsiveness. Broken links. Forms. Edge cases. Performance. Everything.

But now… Every technical finding had context.

That’s When My Reports Changed

Before… My reports answered technical questions.

Now… They answer business questions too.

Questions like:

Where did I feel confused? What made me trust the product? Where did I hesitate? What convinced me to continue? Would I recommend it?

Those aren’t bug reports. They’re user insights. And founders have told me those observations are often just as valuable as the technical findings.

Final Reflection

Today, before writing my first bug…

I try to understand the idea.

Because if I don’t understand what a founder is trying to build…

I can’t honestly tell them whether they’re succeeding.

The first thing I test isn’t the software.

It’s the idea.

Why I Review Software Like I Review Restaurants

Wed, 29 Jul 2026 00:00:00 +0000

I genuinely enjoy leaving restaurant reviews.

Not after every meal. Only when something was exceptionally good… or exceptionally bad.

A few days ago, while writing one of my QA reports, I realized something. A good software review and a good restaurant review are almost the same thing.

Think about Starbucks.

Why did Starbucks become famous?

Because they didn’t just sell coffee. They sold an experience. Walking into the store. Hearing your name called. The familiar atmosphere. Trying a seasonal drink. Knowing your favorite coffee will taste exactly the same every single visit.

I have a home office. I can make my own coffee. I can work from my desk without leaving the house. Yet every once in a while… I still grab my laptop and spend the afternoon working at Starbucks. Not because I need coffee.

Because the experience feels different.

Or maybe your favorite local restaurant.

Everyone has one.

The place where the waiter already knows your order. Where the chef knows exactly how you like your food. Where you don’t just feel like another customer. You feel welcome. When people review places like that… They rarely write:

“★★★★★ Food was good.”

Instead they write something like:

“The food was incredible. The atmosphere felt like home. The staff made us feel welcome. We’ll definitely come back.”

Notice something?

They aren’t reviewing only the food.

They’re reviewing how the place made them feel.

Software Works Exactly the Same Way

People often assume QA is about asking questions like:

Does this button work? Does this form submit? Does this API return 200? Those questions matter.

But they’re only part of the story.

When I review software, I pay attention to something different first.

How did it feel? Was every click intuitive? Did I naturally know what to do next? Did the interface guide me without making me think? Did I enjoy using it? Or was I simply trying to finish as quickly as possible?

That’s Why My Reports Feel Different

Yes.

I include bug reports. Reproduction steps. Expected results. Severity. Recommendations.

That’s part of the job.

But before I become an engineer… I become a customer. I document what confused me. What delighted me. What made me trust the product. What made me hesitate.

Because fixing software isn’t only about fixing bugs. Sometimes it’s about improving moments.

The Sticky Notes

One of my favorite things about some restaurants is seeing hundreds of little notes left by customers.

Tiny messages.

“Best burger I’ve ever had.”

“We’ll come back.”

“Thank you.”

Those notes aren’t there because everything was technically perfect. They’re there because people remembered how the place made them feel. Software is no different. The products we recommend aren’t always the ones with the most features. They’re the ones we enjoyed using.

That’s Why I Start With Feelings

Most QA reports begin with functionality.

Mine usually begin with experience. Only after I understand the experience… do I move into the technical details.

Because if users love using your product… they’re surprisingly forgiving of the occasional typo. They might overlook a button that required a second click. They may never notice that one icon is two pixels misaligned.

But they’ll never forget how your product made them feel. That feeling is what determines whether they come back… or quietly uninstall it.

Final Reflection

Every founder hopes people fall in love with the product they’ve built.

QA exists to help make that happen.

That’s why I don’t review software the same way I inspect code. I review it the same way I review restaurants.

Not just asking:

“Did it work?”

But asking something much more important.

“Would I come back?”

Understand first. Test second. Explain always.

What Quality Assurance Means to Me

Wed, 29 Jul 2026 00:00:00 +0000

What I Thought QA Was

When I first started learning Quality Assurance, I thought I understood the job. Or at least… I thought I did.

I believed QA meant clicking every button. Typing strange inputs into forms. Reading long requirement documents. Writing endless bug reports. Creating hundreds of test cases for the same placeholder simply to prove it behaved correctly.

I imagined long meetings where the QA engineer existed only to ask, “What happens if the customer breaks this?” In my mind, Quality Assurance was mostly about finding problems. And if I’m honest…

It sounded a little boring.

Then Something Changed

As I started working with startups, something unexpected happened.

I stopped seeing products. I started seeing people. Behind every application was a founder excited to explain an idea. Someone who had invested months—sometimes years—trying to solve a real problem. I also watched a talk that completely changed the way I thought about software quality. Instead of asking,

“How do we find more bugs?”

it asked something much simpler.

“What does Quality Assurance actually mean?”

Quality Assurance

Two words. Simple words. But surprisingly difficult to define.

Is QA…

a person?

a team?

software testing?

building the product correctly?

making a promise to customers?

My answer today is… Yes. But it’s also much more than that.

The Founder Changed Everything

One of my favorite parts of this job isn’t discovering bugs.

It’s listening. I genuinely enjoy hearing founders explain why they built something. Watching their eyes light up when they describe an idea. Understanding the problem they’re trying to solve. Because once I understand that… My work changes completely.

Instead of saying,

“This button is broken.”

I find myself saying,

“I think this small change could make the experience much clearer for your users.”

That conversation feels completely different. It’s no longer QA versus Development. It’s people improving a product together.

The Small Things Matter

A few days ago I reviewed a startup whose landing page taught me something. There were several feature cards. Normally those sections are just marketing. Static text. Nothing more.

But each card was actually clickable. Instead of repeating marketing copy, every one of them opened the exact documentation explaining how that feature worked. Such a small interaction. Yet it completely changed how I experienced the product.

Moments like that are why I love QA. Because users don’t remember software only because it works. They remember how it made them feel.

Why People Stay

Think about the applications we use every day.

Take X, for example. Millions of people understand almost immediately how to like a post. Reply. Share. Bookmark. Those interactions feel obvious today.

But someone had to design them. Someone had to ask, “Will users understand this without thinking?”

That’s user experience. And that’s where Quality Assurance becomes much larger than testing.

My Definition of QA

Today, if someone asked me what Quality Assurance means… I wouldn’t start by talking about test cases. Or automation. Or bug reports.

I’d say this. Quality Assurance is helping founders deliver the best product they can build. And helping users receive the best product they can experience.

That’s why I love this profession. Because my job serves both sides. The people creating software. And the people who trust it.

My Philosophy

That’s why my personal philosophy has become incredibly simple.

Understand first. Test second. Explain always.

Understanding comes before testing. Testing comes before reporting. And reporting should always leave the product better than it was before.

That’s what Quality Assurance means to me.