DEV Community: Mochammad Alie

Things Junior QA Engineers Don’t Expect in Their First QA Role

Mochammad Alie — Sun, 21 Dec 2025 15:59:07 +0000

Hi there 👋🏻! I'm Alie, working as a Software QA Engineer (freshhh...) at SaaS company.

In this post, I want to share my experience after successfully transitioning from Customer Support to a QA Engineer role.
Hopefully, this can give you some context—and maybe a bit of clarity—if you’re considering a similar path.

Background

After graduating from university, I started my professional career as a Customer Support Associate at a SaaS company.

After about a year, I began to feel conflicted. I enjoyed working with the product and users, but I also felt the urge to grow into a different role. At that time, I considered several options, such as:

SEO Specialist
QA Engineer

After a lot of thinking (and persistence), I finally decided to pursue a QA Engineer role.

And… here I am.

1. QA Is Not Just About Finding Bugs

During my first month as a QA Engineer, I realized something important:

QA is not just about finding bugs or executing test cases.

As a QA, you’re expected to be proactive in the software development process.

This was very different from my role in Customer Support. As a QA Engineer, I needed to:

Get involved in product development discussions
Review mockups and designs
Understand the business goals behind each feature

So before jumping into a QA role, I highly recommend sharpening soft skills such as:

Business understanding
Logical thinking
User experience awareness

These matter more than I initially thought.

2. Understanding the Product Matters More Than Tools

One thing I’m very grateful for is my background in Customer Support.

By dealing directly with users and solving their problems, I gained deep product knowledge even before becoming a QA Engineer. Because of that:

I could work more independently
My onboarding process was much faster

Tip:
If you’re applying for a QA Engineer role, try to understand:

What the product does
Who the target users are
What problems the product is solving

This will help you understand the system far beyond what tools alone can teach you. DO NOT just apply by feel the role is matches with your dream.

3. Automation Is Not the First Priority

In today’s job market, many Junior QA roles require some automation skills—and sometimes even hands-on experience.

While automation is important, I learned that it should not be the first priority.

Automation is a tool to save time on repetitive work—not the goal itself.

Before automating any test, there are important questions to ask:

Do we really need to automate this test?
Why should this test be automated?
What happens if we don’t automate it?
Is this scenario critical to the user?
Is the feature stable enough to automate?

Without business and product understanding, automation can easily become wasted effort.

4. Reading Logs and Errors Is a Core Skill

Let me be very honest here:

Do not become a QA Engineer if you’re lazy.

QA Engineers read a lot (read = understand).

In daily work, you’ll:

Read the Product Documents
Review and understand the UI Mockup
Read logs from development and testing
Analyze bug reports and error messages
Debug failed automated tests
Inspect API responses and system behavior

All of this requires patience and curiosity.

If you dislike reading logs, errors, or technical details, QA can feel very exhausting.

5. Communication Skills from Customer Support Are a Big Advantage

Another thing I truly appreciate from my Customer Support background is communication skill.

In Customer Support, I interacted with users from:

Different countries
Different cultures
Different communication styles

That experience helped me:

Explain issues more clearly
Communicate better with developers and product teams
Think from a real user’s perspective

When I test new or existing features, I often ask myself:

“How would an actual user experience this?”

That mindset is incredibly valuable in QA.

Final Thoughts

I hope this post gives you a small preview of what it’s like before jumping into a Software QA Engineer role.

Transitioning roles is not easy—but it’s possible.

Remember:
Chase your dreams regardless of the situation, because only you truly understand your own capabilities.

Good luck on your journey 🚀

Playwright: Test Structure (Tiny part that bring a huge impact)

Mochammad Alie — Sun, 21 Dec 2025 04:47:51 +0000

Hi there 👋! This is my first post since I joined dev.to
I’m a Junior QA Engineer who recently transitioned from Customer Support into QA.

While I don’t have tons of experience yet—especially when it comes to discussing automated testing at a deep level. However, during my day-to-day work as a QA Engineer, I’ve noticed one important thing:

Many QA Engineers write automated tests, but not all of them truly understand their test structure.

And... that often becomes a problem.

Without a clear and well-thought-out test structure, automated tests can quickly become:

Hard to maintain
Difficult to debug when tests fail
Risky to scale as the product grows

One simple but often overlooked improvement is how we structure our automated tests.

Even though test structure sounds very basic, many QA Engineers—especially those who are new to automation or have limited hands-on experience with real projects—may not be fully aware of its importance.

In this post, I want to share a few simple tips about managing test structure, based on what I’ve learned so far.
It might be a small topic, but I believe it has a big impact.

Hopefully, through this tiny post, we can become better QA Engineers—not only in terms of technical skills, but also in:

Business mindset
Risk awareness
Long-term maintainability thinking

Let’s get started 🚀

I'll use my automated-test project as a reference, and why this approach works better than sticking to the default structure.

📂 Default Playwright Test Structure (The Starting Point)

tests/
 ├── example.spec.ts
 ├── another-test.spec.ts
playwright.config.ts

This is totally fine for:

demos
tutorials
very small projects

But as tests grow, this structure quickly starts to hurt you.

Common problems with the default structure:

Selectors are duplicated across test files
Tests become long and hard to read
UI changes require updating many test files
Debugging failed tests takes longer

That’s why, in my project, I decided to move away from the default structure early.

🧱 Custom Test Structure Used in the Repository

Instead of placing everything directly inside *.spec.ts files, I separated concerns clearly.

High-level structure (simplified):

tests/
 ├── pages/
 ├── fixtures/
 ├── utils/
 ├── ai/
 │   └── ai-movie.spec.ts

📄 1. Page Object Model (POM)

The pages/ folder contains page classes that handle:

selectors
page actions (click, fill, submit, etc.)

Instead of writing selectors directly in test files, tests interact with the page through methods like:

search movie
submit prompt
read AI response

Why this matters:

UI changes only affect page files
Test files stay clean and readable
Less selector duplication

👉 Compared to the default Playwright approach, this dramatically reduces maintenance cost.

🔁 2. Fixtures for Shared Setup

The fixtures/ folder contains reusable setup logic, such as:

navigating to the app
preparing test state
shared test configuration

This prevents every test from repeating the same setup steps.

Advantages over default structure:

tests focus on behavior, not setup
easier to standardize test flow
fewer copy-paste mistakes

🧰 3. Utilities for Complex Logic

In AI-related testing, some validations are not trivial.
For example:

Checking response format
Validating content rules
Handling async behavior consistently

Those logic pieces live in utils/.

Why this beats default structure:

assertions stay reusable
test files don’t become bloated
logic can be improved without touching tests

📁 4. Feature-Based Test Grouping

Instead of random spec files, tests are grouped by feature.
For example:

AI-related tests live in their own folder
future features can follow the same pattern

Compared to default structure:

Easier navigation
Clearer ownership
Better scalability as features grow

🧠 Final Thoughts

Even as a junior QA Engineer, I’ve learned that good structure is a skill, not a luxury.

You don’t need:

A huge project
Years of experience
Perfect architecture

What you do need is the mindset that:

Automated tests are long-term assets, not one-time scripts.

By moving beyond Playwright’s default structure and organizing tests intentionally, you:

Reduce future pain
Improve collaboration
Build better testing habits early

Hopefully, this post helps other junior QAs avoid the mistakes I’m still learning from 🚀

Feel free to take a look onto my project here and make it as reference

Let's connect!