Coder Legion - Recent posts tagged qa

Black-Box Testing with AI Agents: Test the Rules, Not the Code

Mon, 26 Oct 2026 12:01:41 +0000

An AI agent that reads your code writes tests that confirm your bugs. In this video I show how to use AI agents for black-box testing instead: generate test cases from the business rules alone, run them against the real system, and get a findings report that lists every rule the application breaks. It covers why code access weakens AI-generated tests, the four-step pipeline with the prompts and the workspace layout, and when this approach is the wrong tool.

📝 Full article: https://dev.to/soaresdiogo/black-box-testing-with-ai-agents-test-the-rules-not-the-code-17j8
📸 Instagram: https://instagram.com/diogosoares.dev
💼 LinkedIn: https://www.linkedin.com/in/diogoschmidtsoares
🌐 Website: https://diogosoares.dev

STOP reproducing bugs twice. Record once, get both a Markdown Bug Report and a Playwright Regression

Tue, 13 Oct 2026 08:53:10 +0000

📝Every QA engineer and developer knows the drill:
You find a bug. You manually write down steps to reproduce, take screenshots, and format a ticket for Jira or GitHub. Then, you open your IDE and write the exact same steps all over again in code for your automated regression suite.

Why do the same work twice?

I built QA Bug → Regression Test to bridge the gap between manual reporting and automated regression testing. 🎯

💡 How It Works:
Record the Issue: Click Start Bug Session in your browser and reproduce the bug naturally. Clicks, inputs, navigation, and timing are recorded cleanly.
Capture Inline Assertions: Highlight the visible error message, banner, or missing element right on the page to insert an immediate assertion.

Instant Dual Output:
🐞 Markdown Bug Report: Clean, formatted steps to reproduce with environment details and evidence, ready for GitHub Issues, Jira, or Linear.

⚡ Playwright Test (.spec.ts): Production-ready code using resilient locators (getByRole, getByLabel, getByText) that drops straight into your test repository.

🔒 Built for Privacy & Real-World QA:
Zero-Leak Redaction: Passwords, API keys, and session tokens are automatically detected and replaced with REPLACE_WITH_TEST_VALUE in code and [REDACTED] in reports.
100% Local & Offline-First: Manifest V3 compliant. Zero external tracking or servers—everything runs entirely inside your browser.

🔗 Chrome Web Store: https://chromewebstore.google.com/detail/qa-bug-→-regression-test/khoelciicbkdeieibchdndccdncpelbg?authuser=1&hl=tr
🎬 Quick Demo (YouTube): https://www.youtube.com/watch?v=GrtotYTfhbg

I’d love to hear your feedback on how this fits into your daily QA/developer workflow! Try it out and let me know your thoughts below! 👇

What I Wish I Knew When I Started in QA

Wed, 09 Sep 2026 04:51:57 +0000

When I started my first QA job, I had already spent around twenty years working in mechanical engineering and manufacturing.

I had technical experience. I had programmed CNC machines. I had used Linux for years. I had even studied programming as a kid.

And yet, when I entered software development, I quickly discovered how much I didn't understand.

I remember being confused by things that seem completely normal to me today. DEV, QA, STG, PROD. The way a pull request moved through a team. What happened before testing, what happened after it, and who was responsible for what.

I was lucky to have a patient buddy who helped me through those first months. Eventually, I became the person mentoring a new colleague.

Looking back, there are a few things I wish I had understood earlier.

You don't need to understand the whole system on day one

When you're new, it's easy to look around and assume everyone else understands everything.

Developers discuss architecture. DevOps talks about deployments. QA engineers know the product. Someone mentions a database migration or a production incident, and you feel like you've missed an entire chapter.

The truth is that everyone learned those things somewhere.

You don't need to understand the whole system immediately. You need to start building a mental map of it.

Where does the code live? How does it reach a test environment? Where do the logs go? Who owns the service? What happens when a build fails?

One answer usually leads to another question. That's how the map grows.

Ask the question, even when it feels basic

I was fortunate to have Ventsislav as my buddy at SolarWinds. I still remember his patience.

When you're changing careers, there are moments when you don't even know how to formulate what you don't understand. That can be uncomfortable, especially when you've already spent years being competent in another profession.

But pretending to understand something doesn't make you better at your job.

Asking does.

I would rather ask a basic question and understand the system than stay quiet and make decisions based on an assumption.

And if you're the experienced person in the room, remember what those first months felt like. The way you answer a beginner's question can influence whether they ask the next one.

Learn how the product works, not just how to execute a test

At the beginning, it's tempting to focus on the assigned test case.

Open the application. Follow the steps. Compare the actual result with the expected result. Report a defect if something doesn't match.

That's useful work, but it's only part of QA.

The more you understand the product, the more useful your testing becomes.

What is the user trying to achieve? Which parts of the system depend on this feature? What happens when an API fails? What data is involved? What would make this change risky?

A tester who understands the product can ask questions that aren't written in the test case.

And those questions often matter more than another perfectly executed checklist.

Don't treat developers as the other side

Early in a QA career, it can be easy to fall into a pattern where developers build things and testers find what's wrong with them.

But QA and development aren't opposing teams.

You're working on the same product.

A good bug report helps a developer understand the problem. A good conversation with a developer helps QA understand the implementation and the risks. A good developer can teach you a lot about how the system works, and a good tester can reveal assumptions the developer hadn't considered.

Some of the most useful things I've learned came from asking developers to explain why something behaved the way it did.

Not to prove that I was right.

To understand it better.

Automation isn't a different species of engineering

For a long time, I admired colleagues who worked with automation.

I could change parameters and make smaller adjustments, but writing automated tests myself felt like another level.

Then I took a Python course and started building my own projects.

Gradually, automation stopped being something other people did.

It became code I could understand, debug, and write.

If you're a manual QA engineer who wants to learn automation, you don't need to start by building a complete framework.

Start with a small script. Make an API request. Parse a response. Write one test. Run it. Break it. Fix it.

Then learn why it works.

The important part is not how quickly you can copy a framework from a tutorial. It's whether you can understand and maintain what you've written.

Learn the tools around your tests

I wish I had looked beyond the test itself earlier.

APIs, databases, logs, Linux, Git, CI/CD, and environment configuration all became increasingly useful as I moved deeper into automation.

You don't need to become an expert in every one of those areas.

But knowing how to inspect an API response, read a log, understand a pipeline failure, or check whether a service is running can save you hours of guessing.

A failed test doesn't always mean an application defect.

Sometimes the environment is broken. Sometimes the test data is wrong. Sometimes a dependency is unavailable. Sometimes the test itself is wrong.

Understanding the surrounding system helps you find the difference.

Quality is bigger than the number of bugs you find

Finding a serious bug before production is satisfying. It can save a team a lot of trouble.

But the number of bugs you report isn't a complete measure of your value as a QA engineer.

Sometimes your most valuable contribution is asking a question before development starts.

Sometimes it's improving a test that everyone has stopped trusting.

Sometimes it's identifying an environment problem that causes repeated false failures.

Sometimes it's helping the team understand a release risk that no individual test can capture.

Over time, I stopped thinking of QA only as finding defects.

I started thinking of it as helping the team understand quality and risk.

That change in perspective has stayed with me.

Your previous career is not wasted

This is something I would tell anyone entering IT later in life.

I spent roughly twenty years in mechanical engineering, working as a designer and technologist and programming CNC machines.

At first, that experience felt separate from my new QA career.

Today I see a lot of connections.

Precision. Processes. Root-cause analysis. Understanding dependencies. Thinking about what happens before and after your part of the work.

Those habits followed me into software engineering.

You may need to learn a new technology stack, but you don't necessarily need to start your professional identity from zero.

Your previous experience can become an advantage once you learn how to apply it.

You will eventually become the person who explains it

One of my favorite memories from my first QA job is becoming a buddy for a new colleague.

I had gone from struggling to understand the environments and processes to helping someone else navigate them.

That didn't happen overnight.

There was no moment when I suddenly knew everything.

It was a gradual accumulation of questions, mistakes, explanations, and experience.

Growth often works like that. You don't notice it while it's happening.

Then one day someone asks you a question, and you realize you're explaining something that once confused you completely.

Keep looking one layer deeper

If I could give my younger QA self one piece of advice, it would be this:

Don't stop at the first answer.

If a test fails, investigate why.

If a deployment fails, try to understand what happened.

If a developer explains a technical decision, ask about the trade-offs.

If a production issue occurs, look at what the team learned from it.

You don't need to become a developer, DevOps engineer, security specialist, and product manager all at once.

But every layer you understand makes you a more capable QA engineer.

My own curiosity eventually took me from manual testing into Python, Robot Framework, Playwright, CI/CD, Linux infrastructure, observability, and release engineering.

I'm still learning.

And I suspect I always will be.

This is the second article in my My QA Journey series.

If you're starting in QA today, what is one thing you wish someone had told you earlier? And if you've been in the industry for a while, what advice would you give your first-year self?

It Took Me 20 Years to Come Back to Tech

Wed, 02 Sep 2026 11:36:24 +0000

It Took Me 20 Years to Come Back to Tech

Dev Journey | CoderLegion

What happens when someone who discovered programming as a child spends nearly two decades working in a completely different industry—and then finds their way back into technology?

For Jan Duris (@JankoD84), the answer is a journey through programming, Linux, mechanical engineering, CNC, QA, test automation, DevOps, release engineering, and eventually building his own SaaS product.

Jan's relationship with technology began when he was a child experimenting with computers and programming. He later moved into mechanical engineering, where programming continued to appear in a very different form through CNC machines.

Almost twenty years passed before he returned to IT professionally.

His first IT role was in QA, where he had to learn an entirely new world of software development, environments, testing, and processes. From there, he gradually moved into automation, Python, Playwright, CI/CD, DevOps, and release engineering.

Today, Jan works as a QA Automation Engineer and builder, focusing on software quality, release reliability, developer tooling, and AI-assisted delivery. He is also building Dulvarn, a release intelligence platform designed to help teams make better release decisions using evidence, automation, and AI.

This is his story.

It Took Me 20 Years to Come Back to Tech

My career in technology didn't begin when I got my first QA job.

In a strange way, it began when I was about four years old.

Every year during the summer holidays, I used to spend two or three months at my great-grandmother's house in the Czech Republic.

There was a small storage room upstairs.

I spent entire days there with my mother's cousin.

For most people, a storage room probably doesn't sound like the beginning of a journey into technology.

For me, somehow, it was.

That was where computers first became something more than machines.

They became something I wanted to understand.

I had no idea what software engineering was.

I didn't know what QA meant.

There was no DevOps, CI/CD, cloud infrastructure, AI coding assistant, or SaaS product in my world.

There was just curiosity.

And a question that has stayed with me for most of my life:

How does this actually work?

My First Programming Experience Came Before I Really Knew What a Career Was

While I was still in elementary school, I started attending a programming course.

We worked on PMD 85 computers.

For anyone who grew up with modern laptops, cloud IDEs, GitHub, and AI assistants, those machines probably look almost prehistoric now.

But for me, they were fascinating.

I learned things like:

BASIC
Pascal
Turbo Pascal

There was something magical about writing instructions and seeing a machine respond to them.

Later I got my first computer of my own: a Didaktik Compact.

That gave me the freedom to experiment by myself.

There was no carefully structured learning roadmap.

No "become a developer in 12 weeks" course.

I learned because I wanted to make the machine do things.

I broke things.

I tried again.

I read whatever I could find.

And slowly, programming became something familiar.

Then I Discovered Linux

Linux became another important part of that journey.

I started experimenting with some of the distributions that were available at the time.

Again, I wasn't thinking about a career.

I wasn't building a portfolio.

I wasn't trying to optimize my LinkedIn profile.

I was simply interested in what was happening underneath the graphical interface.

Filesystems.

Processes.

Commands.

Configuration.

Bash.

That relationship with Linux never really disappeared.

Even today, Linux and Bash still feel like home to me.

They have followed me through different parts of my career, even during the years when programming itself moved into the background.

Then Life Took Me Somewhere Completely Different

Teenage years arrived.

Programming became less important.

Games became more important.

Technology was still around me, and Linux never completely disappeared, but I stopped imagining programming as the obvious direction of my life.

Then came secondary school.

I ended up studying mechanical engineering.

It wasn't exactly the future I had dreamed about when I was younger.

But sometimes a decision you make early in life defines much more of your future than you expect.

Mechanical engineering became my professional world for roughly the next twenty years.

I worked as a mechanical designer and technologist.

I worked with manufacturing processes.

I worked with technical drawings and 3D components.

And I programmed CNC machines.

So programming never really disappeared.

It just changed form.

Instead of telling a computer how to process data, I was telling machines how to manufacture physical components.

And in hindsight, the two worlds taught me many of the same things.

Precision matters.

Processes matter.

Small assumptions matter.

You need to understand what happens before and after your own part of the work.

And when something goes wrong, the cause is not always where the failure becomes visible.

I didn't know it at the time, but those lessons would later become very useful in QA.

The Dream of Working in IT Never Completely Disappeared

Even after years in mechanical engineering, IT was still somewhere in the back of my mind.

It was one of those things you tell yourself you might return to someday.

The problem with "someday" is that it can easily turn into twenty years.

Then I met the woman who became my wife.

And sometimes another person sees something in you that you have stopped acting on yourself.

She knew that working in IT had been something I had wanted since I was young.

She encouraged me to finally do something about it.

To take an entry-level IT course.

I agreed.

But I had one condition.

She had to do the course with me.

IT wasn't her field at all.

That actually made me respect her even more for agreeing.

We went through it together.

I helped her heavily with the technical parts, and by the end it sometimes felt like I had completed the course for two people.

I didn't mind.

I still don't.

Because what mattered was what happened next.

After about twenty years away from the career I had imagined as a child, I finally had a real path back into technology.

My First IT Job Was in QA

My first job in IT was at SolarWinds in the Czech Republic.

Getting it changed much more than my job title.

We moved to Brno for the opportunity.

I had finally made the transition.

And then I discovered something uncomfortable.

Getting into IT and understanding IT are two very different things.

I was entering an industry with years of technical experience behind me, but software development had its own language.

Its own processes.

Its own mental models.

Things that seem completely normal to me today were confusing at the beginning.

Even environments.

DEV
QA
STG
PROD

Eight Months, One Opportunity, A Lot of Learning — Amita Sharma’s Journey from QA to Development

Wed, 02 Sep 2026 11:24:42 +0000

Eight Months, One Opportunity, A Lot of Learning — Amita Sharma’s Journey from QA to Development

Dev Journey | CoderLegion

Starting your first job can be both exciting and intimidating.

You have spent years studying, learning technologies, completing projects, and preparing for that first opportunity. But when you finally walk into a real workplace, everything can suddenly feel different.

Will I be able to do the work?

Will I understand what everyone is talking about?

What happens when I make a mistake?

For Amita Sharma, her first opportunity came through a college placement drive during her final year.

She went into the process without knowing exactly where it would lead. After an assignment test and two rounds of interviews, she was offered a six-month internship as a QA.

What started as her first corporate experience eventually became much more than that.

Over the next eight months, Amita worked on a real product, learned the fundamentals of quality assurance, discovered the importance of thinking beyond obvious test cases, and eventually got the opportunity to contribute to the development side of the same product.

Today, her experience spans QA, testing, development, and an increasing interest in AI-driven testing.

This is the story of how one opportunity helped her discover that she could do more than she initially thought.

Getting the First Opportunity

Eight months ago, I walked into a college placement drive with honestly no idea where it would take me.

There was an assignment test, followed by two interview rounds. I cleared them and was eventually offered a six-month internship as a QA.

Since it was my final year of college, getting a job before graduating was already a big thing for me.

But getting the offer was one thing, and actually starting was another.

It was my first corporate experience, so I was nervous.

I had so many questions in my head.

Would I be able to do the work?

Would I understand everything?

How would I fit into a completely new environment?

Thankfully, the first few days made things much easier.

Everyone was really welcoming, the team was approachable, and I never felt like I had to figure everything out on my own.

Once the training started and I began working on an actual product, the real learning began.

Discovering What QA Really Involves

When I joined, I had a pretty basic understanding of QA.

Test the feature, find bugs, report them.

But working on QAlity showed me how much more there was to it.

I started working on different features and workflows, reporting and retesting bugs, doing regression testing, and slowly learning to think beyond the obvious scenarios.

I began to understand that testing isn't simply about finding something that doesn't work.

It's about thinking about how people might actually use a product.

What happens if someone takes an unexpected path?

What happens if they enter something you didn't anticipate?

What happens when a new feature interacts with something that was already working?

Those questions gradually became part of the way I approached testing.

The Excitement of Finding My First Bug

I still remember finding my first bug.

It was honestly such a small thing, but I was so happy when I found it.

I don't even know why I was that excited, but I think it was because it made everything feel real.

I was actually testing a product.

I had found something that wasn't working as expected.

And I knew what to do with it.

It was a small moment, but for me it was an important one.

It made me feel like I was no longer just learning about QA.

I was actually doing it.

Learning From a Mentor

My mentor had a big part in helping me get there.

Whenever I got stuck, I had someone to ask, but I was also encouraged to think things through myself.

A simple question like:

"What about this scenario?"

would sometimes send me back to the feature and make me look at it differently.

At first, I needed guidance to figure things out.

Gradually, I became more confident in figuring things out on my own.

That was one of the biggest changes I noticed in myself.

The goal wasn't simply to have someone give me the answer.

It was learning how to find the answer myself.

An Unexpected Turn: From QA to Development

And then my role took a direction I hadn't expected.

Along with QA, I got the opportunity to work on the development side of QAlity too.

I worked on the UI and created pages for the product, which gave me a chance to understand QAlity from a completely different perspective.

That experience was especially valuable because I got to see both sides of the product.

I understood what went into building a feature and also what I needed to think about when testing it.

It gave me a much broader experience than I had imagined when I first joined.

Instead of seeing development and testing as completely separate activities, I started understanding how closely they are connected.

Building something gives you one perspective.

Testing it gives you another.

Having the opportunity to experience both helped me understand the product much more deeply.

Eight Months Later

Now, eight months later, I can see how much has changed.

I came in wondering whether I would be able to do the job.

Today, I have worked on QAlity as a QA, contributed to its development, built UI pages, and taken on things that I wouldn't have imagined myself doing on day one.

Looking back, the biggest change isn't just the number of things I've learned.

It's the confidence I've gained from actually doing them.

The things that seemed intimidating at the beginning gradually became things I knew how to approach.

What I Would Tell Someone Starting Their First Job

If there's one thing I'd tell someone starting their first job, it's to give yourself some time.

You don't have to know everything from the beginning.

Ask questions.

Learn from the people around you.

Take feedback.

And don't hesitate to try something new just because you've never done it before.

Your first job isn't about proving that you already know everything.

It's about learning how to learn in a real environment.

More Than Just a First Job

When I think about these eight months, I don't just think about the work I did.

I think about how much that first opportunity opened up for me.

I joined as a QA intern, but along the way I got to explore development too, learn from some really good people, and discover that I could do more than I initially thought.

And honestly, I think that's what makes these eight months so special to me.

I came here with a lot to learn, and I'm leaving this phase with a lot more experience, confidence, and curiosity about what comes next.

About Amita

Amita Sharma is a Quality Assurance Engineer focused on building reliable, scalable, and efficient testing workflows. Her experience includes manual and automated testing, with a growing interest in AI-driven testing and modern QA practices.

Her CoderLegion profile is:
https://coderlegion.com/user/amitasharmaa

Her technical interests include JavaScript, Python, SQL, Selenium, Playwright, Cypress, Postman, REST APIs, Machine Learning, and Agentic AI.

She is passionate about improving product quality, reducing manual effort, and creating better user experiences through smarter testing solutions.

This story is part of CoderLegion's Dev Journey series, where developers share their real experiences, challenges, lessons, growth, and the opportunities that shaped their careers.

Adding a feature is easy. Hiding the complexity behind it is much harder

Mon, 31 Aug 2026 06:21:43 +0000

One thing I have learned while building QAlity:

Adding a feature is easy. Hiding the complexity behind it is much harder.

Test automation has a lot of moving parts.

Locators. Waits. Assertions. Test data. Browser behavior. Execution history. Reusable flows. Failure analysis.

It’s tempting to expose all of that because technically, every option can be useful.

But then you end up recreating the same complexity that made automation difficult in the first place.

So lately, I have been asking a different question when reviewing QAlity:

“Does the user actually need to understand this?”

If the answer is no, the product should probably handle it.

I think this is especially important for developer tools.

Advanced software does not have to look advanced.

Sometimes the best feature is the configuration screen you never had to build.

Explore QAlity - https://qality.dev

What Happens After QA Says ‘Passed’?

Sat, 29 Aug 2026 14:15:25 +0000

What Happens After QA Says “Passed”?

For a long time, my view of software quality ended at a fairly clear point.

You test the feature.

You verify the requirements.

You report the bugs.

The bugs get fixed.

You retest.

And eventually, you say:

Passed.

At the beginning of my QA career, that felt like the finish line.

Today, I see it very differently.

Because one question kept coming back to me:

What actually happens after QA says “passed”?

That question gradually pulled me outside the boundaries of traditional testing and into CI/CD, Linux, infrastructure, deployment, observability, alerting, and eventually release engineering.

Not because I wanted to stop being a QA engineer.

Quite the opposite.

I wanted to understand the rest of the system that QA was trying to protect.

“Passed” doesn’t mean the software is in production

This sounds obvious to me today.

It wasn’t always obvious.

A feature can pass testing and still have a long journey ahead of it.

Somewhere after QA, things like this start happening:

QA PASSED
    ↓
Build
    ↓
Package
    ↓
CI/CD Pipeline
    ↓
Environment Configuration
    ↓
Deployment
    ↓
Database Changes
    ↓
Infrastructure
    ↓
Health Checks
    ↓
Monitoring
    ↓
Production

And every one of those steps introduces another opportunity for something to go wrong.

The application can work perfectly in QA and fail because production configuration is different.

The code can be correct while an external dependency behaves differently.

A database migration can introduce a problem that wasn't visible during feature testing.

A deployment can technically succeed while the service becomes unhealthy minutes later.

The application can be running while nobody notices that the error rate is slowly increasing.

QA saying “passed” is important.

But it is only one piece of a much larger process.

Even environments were confusing at first

When I entered QA, there were many things I had to learn from the beginning.

One of them was something that feels completely normal to me today:

DEV → QA → STG → PROD

At first, I didn't really understand why software needed so many environments.

Why could something work in one environment and fail in another?

Why couldn't we simply test it and deploy it?

Why did configuration matter so much?

They sound like beginner questions because they were beginner questions.

I was coming into software after spending many years in mechanical engineering and manufacturing.

Software development had its own language, processes, and mental models.

I had to learn them.

But those questions turned out to be useful.

Once I stopped seeing environments as boxes with different labels and started understanding what was actually different between them, I also became better at testing software.

Different data.

Different configuration.

Different infrastructure.

Different integrations.

Different dependencies.

Different failure modes.

Environment differences aren't only a DevOps problem.

They can change application behavior.

And anything that changes application behavior should be interesting to QA.

CI was another world I wanted to understand

For some time, CI pipelines were something I mostly consumed.

A job ran.

Tests passed or failed.

There was a report.

Maybe I needed to investigate a failure.

But the system behind it wasn't really something I understood deeply.

Eventually that stopped being enough for me.

I wanted to know:

What triggers the pipeline?
What happens before my tests start?
How are dependencies installed?
Where does configuration come from?
How are artifacts created?
What happens when one stage fails?
What happens after everything turns green?

Once you start looking at CI this way, automated tests stop being isolated scripts.

They become signals inside a much larger delivery system.

That changed the way I looked at test automation.

Automation made the boundaries less clear

My early QA work was mostly manual.

Automation was something I admired in the work of other engineers.

Later I learned Python, started building my own projects, and gradually moved deeper into automation.

Today I work with Robot Framework and Playwright with TypeScript.

And the deeper I went into automation, the more I had to understand everything around the test itself.

Automated tests need environments.

They need data.

They need services.

They need configuration.

They need reliable execution.

They need CI.

And when they fail, the reason isn't always the test.

Sometimes the application is broken.

Sometimes the environment is broken.

Sometimes a dependency is unavailable.

Sometimes the test data is wrong.

Sometimes deployment changed something.

Sometimes infrastructure is the real problem.

The more automation I worked with, the harder it became to say:

That's not QA. That's DevOps.

The boundary simply wasn't that clean anymore.

A failed test doesn't always mean a product defect

This became an important lesson for me.

Imagine an end-to-end test fails.

At first glance, all we know is:

TEST FAILED

But the actual cause might be:

Application bug

or:

Environment instability

or:

API unavailable

or:

Deployment issue

or:

Network problem

or:

Broken test data

or simply:

Test bug

The failing test tells us that something didn't behave as expected.

Understanding why often requires knowledge outside traditional testing.

Logs.

Processes.

Services.

APIs.

Containers.

CI jobs.

Deployment history.

Metrics.

Infrastructure.

The more of that context I understood, the faster I could investigate failures.

And that was the point where DevOps knowledge stopped feeling like something belonging to another team.

It started becoming useful QA knowledge.

Linux helped more than I expected

One thing made this transition easier for me.

Linux had already been part of my life for years.

I had started experimenting with Linux long before I entered QA, and Bash never felt completely foreign to me.

So when my work started moving closer to CI, servers, logs, containers, processes, and infrastructure, there was already something familiar underneath it.

Commands and tools like:

ps
grep
curl
tail
journalctl
ssh
docker

became useful ways to investigate what the system was actually doing.

And that reinforced something I gradually came to believe:

A QA engineer doesn't need to become a full DevOps engineer, but understanding the environment where the software actually runs can make you much better at QA.

Then I started looking at observability

Over time, my curiosity also moved toward alerting and observability.

And that opened another question.

Traditional testing usually asks:

Does the application behave correctly before release?

Observability asks:

Is the application still behaving correctly after release?

Those worlds are closer than they might seem.

A test may tell me:

Checkout completed successfully in staging.

Monitoring may later tell me:

Checkout error rate increased after deployment.

Both are quality signals.

They simply exist at different points in the software lifecycle.

Once I started thinking about quality this way, production stopped feeling like the place where QA responsibility simply ends.

Production became another source of evidence.

QA can learn a lot from DevOps

I don't think every QA engineer needs to become an infrastructure specialist.

That's not the point.

But I do think QA benefits enormously from understanding things like:

CI/CD
Linux
containers
environment configuration
deployment strategies
logs
monitoring
alerting
rollback
infrastructure basics
application dependencies

Because all of these things affect software behavior.

And understanding software behavior is exactly what QA is trying to do.

The deeper I went into these areas, the more I realized that testing a feature in isolation only gives us one perspective.

Users don't interact with test cases.

They interact with the entire running system.

DevOps changed the questions I ask

Earlier in my QA career, many of my questions were focused on functionality.

Does login work?

Can the user complete checkout?

Does the API return the expected response?

Does the validation behave correctly?

Those questions still matter.

But now I also find myself asking:

What happens if this dependency becomes unavailable?

How will we know if this starts failing in production?

What happens if deployment fails halfway through?

Can we roll this back?

What changed between environments?

What evidence do we have that the release is healthy?

Who notices first when something goes wrong?

Those aren't purely testing questions.

They are software delivery questions.

And I think QA belongs in those conversations.

I didn't move toward DevOps because I wanted to leave QA

This is probably the most important part.

I wasn't trying to escape QA.

I wasn't thinking:

Testing isn't technical enough. I need to become DevOps.

It happened much more naturally than that.

QA kept giving me questions that testing alone couldn't answer.

A failed automated test led me to logs.

Logs led me to services.

Services led me to containers.

Containers led me to infrastructure.

CI led me to deployment.

Deployment led me to monitoring and alerting.

And eventually all of those things led me toward release engineering.

It wasn't really a career switch.

It was an expanding field of view.

Quality doesn't stop where testing stops

Today I think about software quality very differently than when I entered QA.

Quality isn't one department.

It isn't a test suite.

It isn't a green automation report.

And it isn't one stage inside a pipeline.

Quality exists across the whole software delivery lifecycle.

CODE
 ↓
BUILD
 ↓
TEST
 ↓
PACKAGE
 ↓
DEPLOY
 ↓
OPERATE
 ↓
OBSERVE
 ↓
LEARN

Problems can appear anywhere.

Understanding more of that lifecycle gives QA more context for the decisions we make.

It helps us test better.

Debug faster.

Ask better questions.

And recognize risks that might never appear inside a normal test case.

Eventually I started asking a different question

Once I started looking beyond testing, something else became difficult to ignore.

Suppose we have:

Build        PASS
Tests        PASS
Security     PASS
Deployment   READY

Does that automatically mean we should release?

What if the change is unusually large?

What if it contains a database migration?

What if rollback hasn't been tested?

What if monitoring is incomplete?

What if QA coverage is weaker than usual?

Nothing is necessarily red.

But that doesn't automatically make the release low-risk.

That was the point where my interest started moving beyond deployment itself.

From:

Can we release this?

to:

Should we release this?

Those are two very different questions.

And that is where release engineering became especially interesting to me.

I didn't move toward DevOps because I wanted to stop being a QA engineer.

I moved toward it because I wanted to understand what happens after QA says “passed”.

And the more I understood, the clearer it became that testing is only one part of software quality.

The rest of the story happens before, around, and after it.

This is the first article in my From QA to DevOps / Release Engineering series.

In the next parts, I want to write about CI/CD from a QA perspective, debugging beyond the test layer, why observability matters to testers, and how understanding deployment and infrastructure changed the way I think about release risk.

How I Got Into QA — And Why I Stayed

Sat, 29 Aug 2026 13:58:59 +0000

My journey into QA didn't start with a testing course.

It didn't even start with software testing.

It probably started when I was around four years old.

Every summer, I used to spend two or three months at my great-grandmother's house in the Czech Republic. I would spend entire days with my mother's cousin in a small storage room upstairs.

For most people, a storage room probably doesn't sound like the beginning of a career in technology.

For me, somehow, it was.

That was where my fascination with computers started.

I didn't know anything about QA, software development, CI/CD, or automation back then.

I just knew that computers were interesting.

And I wanted to understand them.

My first steps into programming

Later, while I was still in elementary school, I started attending a programming course.

We worked with PMD 85 computers, which were among the more accessible computers in our part of the world at the time.

We learned things like:

BASIC
Pascal
Turbo Pascal

Looking back, those machines were incredibly limited compared to what we have today.

But that almost made them more interesting.

There wasn't an endless ecosystem of frameworks, cloud services, package managers, AI assistants, or Stack Overflow answers waiting for you.

If you wanted the computer to do something, you had to understand what you were telling it to do.

Eventually, I got my first computer of my own: a Didaktik Compact.

That changed things again.

I started learning programming by myself.

There was no clear career plan behind it.

I wasn't thinking:

One day I'm going to become a software engineer.

I was simply curious.

I wanted to know how things worked.

Then came Linux

Somewhere along that journey I discovered Linux.

And Linux stayed with me.

I started experimenting with some of the distributions that were available at the time, trying to understand the operating system and what I could do with it.

That relationship never really disappeared.

Even today, Linux and Bash are still part of the way I work and think about technology.

There was a period, especially during my teenage years, when programming became much less important to me.

Like a lot of teenagers, I spent much more time playing games than writing code.

Programming moved into the background.

Linux didn't.

It was always somewhere nearby.

Technology never completely left my life.

But my professional future ended up taking a very different direction.

A 20-year detour through mechanical engineering

When I reached secondary school, I chose a field that wasn't exactly the future I had imagined for myself.

I studied mechanical engineering.

And that decision ended up defining roughly the next twenty years of my professional life.

I worked as a mechanical designer and technologist.

I worked with manufacturing.

I programmed CNC machines.

I worked on the production of 3D components.

So even though I had moved away from traditional software development, programming never disappeared completely.

It simply changed form.

Instead of writing applications, I was telling machines how to manufacture physical components.

There is actually more overlap between these worlds than it might seem.

You still need to think logically.

You still need to understand a process.

You still need to understand what can go wrong.

You still need precision.

And mistakes can have very real consequences.

But somewhere in the back of my mind, the interest in IT was still there.

For years.

I just never really made the move.

Sometimes another person sees the path before you do

Then my life changed.

I met the woman who later became my wife.

She knew that IT had been something I had dreamed about since childhood.

And at some point she pushed me to finally do something about it.

She encouraged me to take an entry-level IT course.

I agreed, but with one condition:

She had to take the course too.

IT wasn't her field at all, which actually made me respect her even more for doing it with me.

We went through the course together.

I spent a lot of time helping her along the way, especially with the technical parts and the final assignment.

By the end, it sometimes felt like I had completed the course twice.

And strangely enough, I didn't mind.

I still don't.

Because that course became the point where something that had been sitting in the background of my life for years finally became real.

It was the beginning of my QA career.

My first QA job

My first job in IT was at SolarWinds in the Czech Republic.

Getting that job meant another major change.

We moved to Brno because of it.

I had finally entered the industry I had wanted to be part of for so long.

And then reality hit me.

I knew far less than I thought I did.

Almost everything was new.

Processes were new.

Terminology was new.

The way software teams worked was new.

Even something that seems completely normal to me today was confusing at the beginning:

DEV.

QA.

STG.

PROD.

Different environments, different responsibilities, different stages of the delivery process.

Today it sounds almost trivial.

At the time, it wasn't.

I had spent years working in technical environments, programming CNC machines and solving engineering problems.

But software development had its own language and its own mental model.

I had to learn all of it.

And I had to learn it quickly.

The person who helped me survive the beginning

One of the people I still remember very clearly from that period is my buddy, Ventsislav.

I owe him a lot.

Mostly because of his patience.

When you're new to an industry, there are questions you don't even know how to formulate yet.

Sometimes you don't understand a process well enough to know what part of it you're actually confused about.

Having someone who is willing to explain those things without making you feel stupid makes an enormous difference.

Ventsislav did that for me.

He helped me understand how the environment worked.

How the processes connected.

What QA was actually responsible for.

And how software moved through the organization.

At the beginning, I needed that help constantly.

But slowly, things started clicking.

And eventually something happened that meant a lot to me.

I became the buddy.

A new colleague joined, and this time I was the one mentoring and helping someone else understand the systems and processes.

That was probably one of the first moments when I realized just how far I had moved from those first confusing weeks.

At first, automation looked like magic

For a large part of my early QA career, my work was primarily manual.

Automation existed around me, but it was mostly something I admired other people for doing.

I could interact with automated tests.

I could change some parameters.

I could make smaller adjustments.

But building automation myself felt like another level.

Something other people knew how to do.

I think many manual testers know this feeling.

You look at automation engineers writing code and think:

I'd like to be able to do that.

But there is a big difference between wanting to understand something and actually sitting down and learning it.

Eventually, I did.

I took a Python course.

Then I started building my own projects.

And gradually, automation stopped looking like something that belonged to other engineers.

It became something I could do too.

That shift changed my career again.

From manual QA to automation

Today I work at Bata as a QA Automation Engineer.

My work looks very different from my first QA job.

I work with Robot Framework.

I work with Playwright and TypeScript.

I work with automated testing.

I deal with APIs, systems, environments, CI/CD processes, and the wider software delivery lifecycle.

And over time, my curiosity has pushed me even further.

Into DevOps.

Into alerting and observability.

Into what happens before and after testing.

Into understanding not just whether a feature works, but how the whole system behaves.

That curiosity is probably the one thing that connects every part of my career.

The four-year-old kid fascinated by computers.

The student programming a PMD 85.

The teenager experimenting with Linux.

The mechanical engineer programming CNC machines.

The new QA engineer trying to understand the difference between DEV, QA, STG, and PROD.

And the automation engineer I am today.

Different technologies.

Different industries.

Same question:

How does this actually work?

QA changed the way I look at software

When I started in QA, testing was much more concrete in my mind.

There is a requirement.

There is an application.

You test whether it works.

You find bugs.

You report them.

Over time, my view changed.

Quality isn't just about finding bugs.

A perfectly implemented feature can still become part of a risky release.

A test suite can pass while something important remains untested.

A deployment can succeed while the system becomes harder to operate.

A pipeline can be green while the team still doesn't have enough information to confidently release.

The further I went into automation, CI/CD, infrastructure, and release processes, the more I started looking beyond individual test cases.

Instead of only asking:

Does this work?

I started asking:

What could still go wrong?

That question eventually changed the direction of my work again.

But that's another part of the story.

Looking back

I didn't take the shortest path into IT.

Not even close.

There was childhood programming.

Linux.

A long break.

Twenty years in mechanical engineering.

CNC programming.

An IT course.

A move to another city.

A first QA job where almost everything felt unfamiliar.

Manual testing.

Python.

Automation.

Robot Framework.

Playwright.

DevOps.

And I'm still learning.

Maybe that's actually the part I enjoy most.

I don't think reaching a point where you finally "know enough" is the goal.

Every time I understand one part of software delivery better, I discover another layer underneath it.

QA led me to automation.

Automation led me toward CI/CD.

CI/CD made me interested in DevOps and release engineering.

And release engineering made me start asking much bigger questions about how teams decide whether software is actually ready to ship.

So if I had to explain why I stayed in QA, I wouldn't say it's because I enjoy finding bugs.

I stayed because QA gives me a reason to understand systems.

To question assumptions.

To investigate failures.

And to keep asking one of my favorite questions:

What could still go wrong?

This is the first article in my My QA Journey series.

In the next parts, I want to write about the move from manual testing to automation, the mistakes I made along the way, what I learned from developers and DevOps, and why understanding what happens after QA says "passed" completely changed the way I think about software quality.

CI Is Green. What Could Still Go Wrong?

Mon, 24 Aug 2026 15:30:17 +0000

A green CI pipeline is a nice feeling.

The build passed.
Tests are green.
Linting is clean.
Nothing obvious is on fire.

For a few seconds, it feels like the release question has already been answered.

It hasn't.

A green pipeline tells you something useful: the checks you configured have passed under the conditions in which they were executed.

That is not the same thing as saying the release is safe.

And the gap between those two ideas is where a lot of production problems begin.

I touched on this in my previous article about why a green CI pipeline can create a false sense of security. But there is another question that deserves more attention:

If CI is green, what can still go wrong?

Quite a lot, actually.

CI only knows what you taught it to check

This is probably the most important limitation.

CI is not intelligent by default.

It does not understand your product, your users, your business risk, or the weird operational history of your system.

It runs instructions.

If those instructions cover the right risks, great.

If they don't, the pipeline can be perfectly green while the release is still dangerous.

This is not really a failure of CI.

It is a failure of interpretation.

We often treat CI as if it has answered a bigger question than it actually has.

The pipeline says:

"The checks I know about passed."

Humans often hear:

"This release is safe."

Those are very different statements.

The code can be correct and the release can still fail

Imagine a change that passes every unit test and every integration test.

The code itself is fine.

Then it reaches production and fails because of configuration.

Wrong environment variable.

Missing secret.

Different feature flag state.

A service points to the wrong endpoint.

A timeout is configured differently in production.

A permission exists in staging but not in production.

None of those problems necessarily mean your tests were bad.

They mean the release depended on conditions outside the scope of those tests.

This is one of the reasons I think we should stop treating release readiness as purely a testing problem.

Testing is part of it.

It is not the whole thing.

Database migrations are a good example

Database changes are one of those areas where "green" can be misleading.

The migration itself may be syntactically correct.

Tests may pass against a fresh database.

Everything can look completely normal.

But production has something your test environment often does not have:

history.

Real data.

Old records.

Unexpected null values.

Large tables.

Long-running transactions.

Different indexes.

Different traffic patterns.

A migration that takes two seconds in CI can behave very differently against a production dataset that has existed for six years.

The pipeline can be green because nothing it executed was technically wrong.

The release can still be risky because the environment changed the meaning of that change.

Dependencies can change the picture

Modern software rarely runs in isolation.

A release can depend on:

another internal service
a third-party API
a package update
a cloud service
a message queue
a payment provider
a database
an authentication system

Your own repository may be completely healthy.

The dependency chain around it may not be.

Maybe another service has not deployed the expected API yet.

Maybe a backwards-compatibility assumption is wrong.

Maybe one dependency is already degraded.

Maybe the release introduces a combination of versions that nobody has actually tested together.

Again, CI may remain perfectly green.

It tested what it could see.

The release depends on more than that.

Passing tests do not mean the right tests ran

This one is uncomfortable, because it sounds obvious once you say it.

A test suite can have a 100% pass rate while still telling you very little about the change you are about to release.

The interesting question is not:

How many tests passed?

It is:

Did we test the things that matter for this release?

Those are not equivalent.

If somebody changes a critical authentication flow and your pipeline runs 3,000 tests mostly covering catalog functionality, the number "3,000 passed" looks impressive.

But what does it actually tell you about authentication risk?

Not much.

This is why I find the concept of risk coverage more useful than simply looking at test coverage or test count.

What changed?

What can that change affect?

Which checks give us evidence about those areas?

That context matters more than a big green number.

Feature flags do not magically remove risk

Feature flags are useful.

Very useful.

But sometimes they become another source of false confidence.

The thinking becomes:

"It's behind a flag, so the release is safe."

Maybe.

But the code still shipped.

The flag configuration itself can be wrong.

The disabled path may affect initialization.

The new code may introduce dependencies before the flag is evaluated.

The wrong audience may receive the feature.

The rollback path may not behave the way you expect.

Feature flags reduce certain kinds of risk.

They do not eliminate release risk.

That distinction matters.

Rollback is not a guarantee either

Another sentence I hear in software teams is some version of:

"If something goes wrong, we'll just roll it back."

That can be a perfectly reasonable risk strategy.

But "rollback exists" and "rollback is safe" are not the same thing.

What happens if the release includes a destructive migration?

What happens if new data has already been written in a new format?

What happens if another service starts depending on the new behavior?

What happens if the release changes an external contract?

Rollback sounds simple when we imagine software as a single binary moving backwards.

Real systems are messier.

Sometimes the release creates state that cannot be cleanly reversed.

A green CI pipeline usually does not tell you whether your rollback strategy actually works.

Production traffic is different

There is also a class of failures that only appears under real usage.

Concurrency.

Traffic spikes.

Unusual request sequences.

Large payloads.

Rare account states.

Slow upstream services.

Network instability.

Real users are extremely good at discovering combinations that test environments never produce.

This is not an argument against automation.

It is an argument for understanding what automation can and cannot prove.

A test suite can give you evidence.

It cannot give you certainty.

Observability matters before the release, not only after it

One thing I think teams often underestimate is operational readiness.

Suppose the release does contain a problem.

Will you notice?

How quickly?

Do you have the right metrics?

Do you have logs around the changed area?

Will an alert actually fire?

Can you distinguish expected noise from a real regression?

A release with some uncertainty but excellent observability can sometimes be safer than a release with more passing tests but poor visibility.

Because release safety is not only about preventing every possible failure.

It is also about limiting the damage when a failure happens.

That changes the release decision.

Human context still matters

Not every release risk is technical.

Sometimes the biggest risk is simply that nobody has the full picture.

QA knows about one unresolved issue.

A developer knows the fix was rushed.

Operations knows a dependent system has been unstable all afternoon.

Product knows a feature absolutely must not reach one customer segment yet.

Security raised a concern that is technically "non-blocking."

Each piece of information exists.

But it exists in different places, owned by different people.

Then the pipeline turns green.

And everyone assumes somebody else must have checked the rest.

This is where release processes become dangerous.

Not because there was no information.

Because the information never became part of the decision.

So what does green CI actually mean?

I still want green CI.

Obviously.

A red pipeline is useful information too, but I would much rather start from green.

The problem is not the green status.

The problem is giving that status more authority than it deserves.

For me, a green pipeline should mean something closer to:

The automated checks we currently require did not detect a blocking problem.

That is a strong signal.

It is not yet a release decision.

A real release decision needs more context.

Depending on the system, I would want to know things like:

What changed?
How risky is that area?
Which relevant tests actually ran?
Are there unresolved defects?
Are dependencies healthy and compatible?
Are migrations involved?
Are security checks clean?
Do we have sufficient observability?
Can we roll back safely?
Is there any known operational or business risk?

Only then does the question become interesting:

Do we have enough evidence to release?

Maybe the problem is the way we frame CI

We built CI to automate verification.

Over time, many teams started using it as a proxy for release readiness.

That shortcut works surprisingly often.

Which is exactly why it is dangerous.

Most releases with a green pipeline are probably fine.

Then one isn't.

And when you investigate what happened, the answer is often not:

"CI failed."

It is:

"CI never knew that this was something it needed to evaluate."

That is the gap I keep coming back to.

The future of release engineering, in my opinion, is not just more tests and faster pipelines.

It is better decision-making.

More context.

Better evidence.

A clearer understanding of what we know before we put a change in front of users.

Green CI should absolutely make us more confident.

It just shouldn't make us stop asking questions.

CI is green. Your release may still be risky.

Mon, 24 Aug 2026 15:29:44 +0000

Every team has a moment like this: CI passes, the PR gets merged, the deploy goes out — and two hours later someone's asking why checkout is throwing 500s in production.

Nobody skipped a step. The pipeline was green the whole time.

The false comfort of green CI
Green CI feels like permission. It's a checkmark, it's fast, and it's automated — so it's easy to treat it as the final word on whether a release is safe. For a lot of teams, "tests passed" and "safe to ship" have quietly become the same sentence.

They're not.

What CI actually checks
Most CI pipelines are built to catch a specific, narrow slice of problems:

Does the code compile / build?
Do unit tests pass?
Does lint pass?
Maybe: does a small integration suite pass?

That's genuinely useful. It catches typos, broken imports, obvious logic errors, regressions in covered code paths. It's necessary.

It's just not the same thing as "this release is safe to put in front of users."

What CI doesn't tell you
CI has no opinion on:

Downstream dependencies — does the third-party API you call still behave the way your integration test mocked it to?
Manual steps — did someone actually run the DB migration on staging before merging, or is that still "to do"?
Deploy-time risk — blue-green cutover, cache invalidation, feature flag state — none of that is exercised by a test suite that runs against a branch.
Human process gaps — did the person who approved this PR actually understand the blast radius, or did they approve because the CI badge was green?

None of this shows up as a failing check. It shows up as an incident.

Release risk is a different question than test pass/fail
"Did the tests pass" is a yes/no question about code. "Is this release safe to ship" is a probabilistic question about a system: what changed, how big is the diff, does it touch a critical path, is there a rollback plan, has this kind of change caused problems before.

Most teams answer that second question with vibes — a Slack message, a shrug, "looks fine to me." That works fine until it doesn't, and by the time it doesn't, you're writing a postmortem instead of a checklist.

What a release risk gate actually looks like
The teams that don't get burned by this usually have some version of the same thing, whether they call it that or not:

A policy layer that blocks release on concrete conditions (required approvals, coverage thresholds, freeze windows) — not vibes, actual enforced rules.
A signal aggregator that pulls test results, error rates, and coverage into one release health view instead of five open tabs.
An audit trail — an immutable record of what was actually in a release, so when something breaks you're debugging from evidence, not memory.

None of this requires an enterprise platform. Small teams can build a lightweight version of this with GitHub Actions, a policy file, and some discipline. The point isn't the tooling — it's separating "code compiles" from "release is safe" as two distinct questions with two distinct answers.

Where to start if you don't have this yet
You don't need to build a whole release control system this week. Start smaller:

Write down the 3–5 things that, if skipped, have caused an incident before. Turn them into a checklist that's actually enforced, not just documented.
Add one non-negotiable gate to your PR template — coverage on touched files, or a manual QA sign-off for anything touching payments/auth.
Capture a snapshot of what shipped in each release (commit list, who approved, what tests ran) so your next postmortem starts with facts instead of "let me check Slack."

If you want a starting point instead of building it from scratch, I put together a Release Checklist Pack and a GitHub QA Gates Pack — practical templates for exactly this, no platform lock-in required.

I'm building Dulvarn, a release control system for GitHub-first teams, plus a set of standalone QA/release tools and templates. This post reflects my own experience shipping software, not any employer's views or confidential information.

Best Selenium Alternatives in 2026: Top Testing Tools to Replace Selenium

Tue, 21 Jul 2026 07:55:56 +0000

Selenium has been a major part of test automation for more than two decades. It helped shape how teams approached browser testing and became the default framework for UI automation.

But in 2026, software development moves much faster than it did when Selenium became popular.

Teams ship weekly. Interfaces change often. QA is no longer limited to automation engineers.

That is where Selenium starts to show its age.

It is not that Selenium is outdated. It is that modern teams need faster, simpler, and easier ways to build and maintain test automation.

If you are looking for a better alternative, this guide covers the best Selenium alternatives in 2026, what they do best, and which teams they fit.

Why Teams Are Replacing Selenium

Selenium still powers thousands of automation frameworks, but it comes with challenges that are harder to justify today.

High maintenance
Selenium relies heavily on locators like XPath and CSS selectors. Small UI updates often break tests.

That means:

Frequent debugging
Constant test maintenance
Slower releases

Flaky test execution
Timing issues are one of Selenium’s biggest pain points. Tests often fail because elements are not ready or page states change unexpectedly.

This creates unstable pipelines and unreliable regression runs.

Developer dependency
Selenium is code-first. That means QA teams need technical expertise to build and maintain tests.

In many teams, only a few engineers can actually work on automation.

That creates bottlenecks.

Infrastructure management
Scaling Selenium usually requires browser grids, CI setup, and execution infrastructure.

This adds operational overhead that many teams want to avoid.

Best Selenium Alternatives in 2026

1. QAlity
Best for: No-code web automation for SaaS teams

QAlity is a no-code test automation platform built for modern web application teams.

Instead of writing scripts, teams can record workflows directly in Chrome and turn them into reusable automated tests.

The biggest advantage of QAlity is Auto-Heal. When UI elements change, it intelligently updates test steps instead of failing.

This dramatically reduces maintenance effort.

Key features:

No-code workflow recording
Cloud-based execution
AI-powered step generation
Auto-Heal for UI changes
Screenshots at every test step
Scheduled and on-demand runs
Easy collaboration across QA and product teams

Limitations:
Focused on web application testing.

Best for:
Startups, SaaS companies, and QA teams that want automation without writing code.

2. Playwright
Best for: Fast and reliable open-source automation

Playwright has become the strongest technical replacement for Selenium.

Built by Microsoft, it uses native browser communication instead of WebDriver, making it faster and more stable.

Its built-in waiting system reduces flaky tests significantly.

Key features:

Fast execution
Multi-browser support
Parallel testing
Powerful debugging tools
Strong CI integration

Limitations:
Still requires coding knowledge.

Best for:
Engineering teams with JavaScript, TypeScript, or Python expertise.

3. Cypress
Best for: Front-end developer testing

Cypress is one of the most popular tools for front-end teams.

It runs directly inside the browser, giving developers better visibility into application behavior during test execution.

Its developer experience is one of the best in the market.

Key features:

Live test runner
Easy debugging
Strong developer workflow
Fast feedback loop

Limitations:
Mostly JavaScript-focused and less flexible for non-technical QA teams.

Best for:
Frontend development teams.

4. Katalon
Best for: Enterprise and low-code automation

Katalon offers a low-code approach and supports web, API, mobile, and desktop testing.

It is popular among larger organizations that need centralized reporting and broader test coverage.

Key features:

Multi-platform support
Reporting and analytics
Team collaboration
Enterprise governance

Limitations:
Can feel complex for smaller teams.

Best for:
Enterprise QA teams with larger automation needs.

5. testRigor
Best for: AI-powered test automation

testRigor focuses on natural language-based test creation.

Instead of coding or complex selectors, users can write test cases in plain English.

This makes automation easier for non-technical teams.

Key features:

Natural language testing
AI-powered maintenance
Self-healing capabilities
Faster test creation

Limitations:
Less flexible for highly customized workflows.

Best for:
Teams looking for AI-first automation.

6. BugBug
Best for: Lightweight browser automation

BugBug is designed for simplicity.

It allows users to record browser actions and create automated tests without complex setup.

Its lightweight nature makes it a practical option for teams moving away from Selenium.

Key features:

Browser-based recording
Cloud execution
Simple UI
Quick setup
Minimal learning curve

Limitations:
Focused mainly on web applications.

Best for:
Startups and growing teams looking for fast onboarding.

How to Choose the Right Selenium Alternative?

The right tool depends on your team.

Ask yourself:

Who will create and maintain the tests?

If your developers own automation, tools like Playwright and Cypress are excellent.

If your QA team includes manual testers, product managers, or non-technical contributors, no-code tools like QAlity, testRigor, or BugBug may be a better fit.

Also consider:

Release frequency
Team size
Maintenance bandwidth
Technical skill level
Infrastructure requirements
The best automation tool is not always the most powerful. It is the one your team can use consistently.

Should You Move Away from Selenium?

For many teams, yes.

The hidden cost of Selenium is not licensing. It is maintenance, flaky failures, and engineering time spent fixing automation instead of shipping features.

Modern alternatives reduce that burden.

Some improve reliability. Some simplify authoring. Some remove code completely.

The right choice depends on how your team works.

If your goal is speed and flexibility, Playwright is a strong option.

If your goal is making automation accessible to everyone, QAlity offers a much simpler path.

Stop asking AI to generate test cases: how to integrate AI into your engineering workflow

Sun, 19 Jul 2026 19:28:37 +0000

Every time a new feature or fix comes up, some people do the same thing. They open their favorite AI chat, copy the requirement or the PR description, paste it in, and ask "generate test cases for this feature". Then they copy the output back into their test management tool or their notes.

There is nothing wrong with using AI this way, it works. I do think there is something wrong with having a manual flow around it. You have to remember to do it, you have to copy and paste the context every single time, and the AI only knows what you decided to paste. If you forget a detail, or if the feature touches something you did not think to mention, the AI will not know either.

Instead of manually going to an AI chat every time, you can integrate that same LLM into your workflow, so it runs automatically and already has the context it needs.

One example I built recently at work is a GitHub workflow that runs on the PR level.

Every time a developer opens a PR implementing a feature or a fix, we have a label called "ai:generate-test-cases". When someone adds this label, it triggers a GitHub workflow that runs a script calling an LLM. This script reads the full PR diff, the comments, and even external links using MCPs, to gather as much context as possible. Then it drops a comment on the PR with a list of possible test scenarios, the risk level of that change, and whether the developer already added automated tests for it. This way we can focus on the areas that matter the most.

Traditional workflow
Requirement
    ↓
Copy
    ↓
Paste into AI chat
    ↓
Generate Test Cases

Integrated workflow
Pull Request
    ↓
Label added
    ↓
GitHub Action
    ↓
LLM reads diff + context
    ↓
PR Comment with:
- Test scenarios
- Risk level
- Test coverage insights

Test case suggestions are just one output of this. The same context, the diff, the comments, the linked docs, could just as easily be used to flag risk, or check if something important was missed. Generating test cases is just the first thing I built with it.

This is opt-in by design. It will not generate anything on infra related PRs, or any PR where the label is not added. You choose which PRs need test case suggestions. This is useful not only for QAs, but also for developers who want to make sure they covered the main scenarios, and it can surface an outcome or edge case you had not thought about.

Of course this does not replace human judgment. It is a tool to help organize and prioritize scenarios, not a guarantee that every hidden path has been covered. We should always use our own experience to decide what is worth testing and what is not, since it is impossible to test everything.

AI is much more valuable when it becomes part of your engineering workflow instead of another browser tab. Test case generation is just one example of that.

If this is something you want to try or adapt to your own workflow, the repo is public and I am happy to talk through how it works.

What Does 'QA' Really Mean? (Hint: It's Not a Person)

Sun, 19 Jul 2026 16:07:09 +0000

I'm tired of seeing people refer to QA as simply "the person who tests." And honestly, it's exhausting. As a tester (or QA engineer, if you prefer) I feel the need to clear a few things up.

QA is not a person. It's an entire discipline.

Quality Assurance is about quality as a whole. There are many types of QA across different industries: software, hardware, manufacturing, and beyond. So when someone says a task is "just waiting on QA," it tells me something: that person doesn't take their own code seriously enough.

QA engineers are not the sole guardians of quality.

Saying that "QA is responsible for the quality of the system" implies that developers can simply ignore quality while building it. That's a dangerous assumption. Quality is a shared responsibility and it belongs to the entire team.

And when a company says "we don't need QA," what are they actually saying? That their software doesn't need quality? More likely, what they mean is they don't need testers, and those are very different things. Conflating them is part of the problem.

Replacing testers with developers doesn't work.

Some companies are delegating the "QA role" to developers themselves. I could expand on this on another post, but the short version: developers have confirmation bias. They build things to work, so they test to confirm they work. That's not the same as testing to find where things break. Saying "let's get rid of the QA people on the team" isn't a quality strategy, it's a blind spot.

The "QA responsibilities" debate is muddier than it needs to be.

Everyone seems to have a different opinion on what QA is supposed to do. You've probably heard things like "being in QA isn't just about testing" or "QA needs to wear multiple hats." And sure, testers do much more than find bugs. Documentation, reporting, risk analysis, process improvement, it's all part of the work.

But here's what bothers me: the false promises. Saying that QA is responsible for "ensuring quality and preventing all bugs" is unrealistic and, frankly, unachievable. It sounds good in a job description, but reality is far less dramatic. What we are primarily responsible for is finding problems, and those problems reveal the actual state of the product's quality. That's not a lesser role. That's an honest one.

So where does that leave us?

The solution starts with language. If we're more precise about what we mean: tester vs. QA, shared responsibility vs. sole ownership, risk reduction vs. zero-defect guarantees then conversations about quality become more honest and more productive. Teams make better decisions when they understand what they're actually asking for.

I won't pretend the industry is close to getting this right. But what keeps me going is knowing that good professionals exist, people who genuinely understand these distinctions, who treat testers as strategic partners rather than a final checkpoint. And despite all the noise, I keep showing up and doing my best work. Because the craft matters, even when the title is misunderstood.

I Published a Complete Guide to Software Quality Assurance

Mon, 01 Jun 2026 11:59:45 +0000

Quality isn't a phase you add before shipping — it's a discipline that needs to run through every stage of development. And the data backs this up: fixing a bug in production costs 10x more than fixing it during requirements. Yet 56% of all defects originate in the requirements phase.
I just published a structured overview of Software Quality Assurance that breaks down:

How verification and validation work (and why they're different)
Testing strategies: when to use white-box vs. black-box
Why quality processes fail in most organizations
The complete testing lifecycle: unit → integration → system → acceptance
Practical frameworks for building quality into your process from day one

Whether you're writing code, managing QA, or leading an engineering team, this gives you the framework to understand how quality actually fits into real software development.

Read the full article

Based on: Bartié, Alexandre. Garantia da qualidade de software: adquirindo maturidade organizacional.

I Built a Free JSON Karate DSL Schema Generator for QA Engineers

Sun, 10 May 2026 18:34:28 +0000

If you work with Karate DSL for API testing, you already know how important and useful schema validation can be.

You also know how repetitive it becomes.

Writing Karate match schemas manually for every API response is one of those tasks that feels small at first until you start working with:

deeply nested JSON responses
arrays of objects
large payloads
optional fields
multiple endpoints

After doing this repeatedly in real automation projects, I decided to build a small utility focused on solving exactly that problem.

So I created a free browser-based tool:

JSON → Karate DSL Schema Converter

https://jsonkaratedslgenerator.codeqazone.com/

The tool instantly converts a JSON payload into a ready-to-use Karate DSL schema.

The Problem

Karate DSL does not use traditional JSON Schema syntax.

Instead, it uses type matchers like:

"#string"
"#number"
"#boolean"
"#[]"
"##string"

That approach is powerful and very readable once you understand it.

But manually transforming a real API response into a Karate validation schema can become repetitive and time-consuming.

For example, a response like this:

{
  "id": 101,
  "name": "Alice",
  "active": true,
  "roles": ["admin", "user"]
}

Usually becomes something like:

{
  "id": "#number",
  "name": "#string",
  "active": "#boolean",
  "roles": "#[] #string"
}

And that is a very small example.

In real-world APIs, payloads can be much larger and more nested.

What the Tool Does

The converter takes a JSON payload and automatically generates a Karate-compatible schema while preserving the original structure.

It supports:

primitive types
nested objects
arrays
arrays of objects
nested arrays
optional fields
copy to clipboard
schema download

Everything runs directly in the browser.

No installation.
No backend.
No data storage.

Just paste your JSON and generate the schema instantly.

Example Conversion

Input JSON

{
  "id": 101,
  "name": "Alice",
  "active": true,
  "user": {
    "email": "*Emails are not allowed*",
    "profile": {
      "age": 30,
      "verified": true
    }
  },
  "orders": [
    {
      "orderId": 1,
      "amount": 99.99
    }
  ]
}

Generated Karate Schema

{
  "id": "#number",
  "name": "#string",
  "active": "#boolean",
  "user": {
    "email": "#string",
    "profile": {
      "age": "#number",
      "verified": "#boolean"
    }
  },
  "orders": "#[] {\"orderId\":\"#number\",\"amount\":\"#number\"}"
}

Required vs Optional Fields

One thing I intentionally wanted in the tool was explicit control over required and optional fields in the schema.

Instead of automatically guessing business rules, the tool lets the tester define which fields are required.

Example:

id, name, user.email

Fields included in that input remain required while all other fields are automatically converted into optional Karate matchers using the ## syntax.

That decision came directly from real QA workflows.

As testers, we usually already know:

which fields are mandatory
which fields are conditional
which fields depend on business logic

The tool is not trying to replace that understanding, it is simply removing the repetitive manual work.

Why I Built It

This project came from real automation work. The goal was not to create a massive platform, it was to create something:

fast
practical
useful immediately
frictionless to use

A tool you can open, use in seconds, and continue with your work.

Features

Current features include:

JSON → Karate DSL conversion
Required fields input
Optional field generation (##type)
Nested object support
Array schema generation
Demo examples
Copy-to-clipboard support
Schema download
Browser-only execution

Who Is This For?

This tool is especially useful for:

QA Automation Engineers
API Testers
Developers using Karate DSL
Teams building API validation suites
People learning Karate schema validation

Try It

https://jsonkaratedslgenerator.codeqazone.com/

The app also includes:

Base Demo
Advanced Demo

so you can immediately understand how the conversion works.

If you work with Karate DSL, I hope this tool saves you some time. Feedback and suggestions are always welcome.

Happy Testing!

The Test Manager’s Guide: From Chaos to Predictable Quality — Part 2: MVP Test Strategy — First 30 Days Wins

Thu, 09 Apr 2026 11:31:11 +0000

In Part 1, we diagnosed the problem.

Not incompetence.
Not lack of effort.

Structure.

Invisible gaps. Unclear boundaries. Quality that depended on individuals rather than systems.

Diagnosis creates clarity.

But clarity alone does not stabilize a project.

The next question is inevitable:

Where do you start — without making things worse?

The Trap After Diagnosis

After diagnosing chaos, most test managers fall into one of two traps.

Trap A:
Write the perfect strategy document.
Forty pages. Maturity models. Target states. Roadmaps.

Six weeks later, nothing has changed.

Trap B:
Fix the first broken thing you see.
Create a template. Introduce a tool. Patch a symptom.

The system absorbs it. Chaos remains.

Neither approach alters the structure.

Diagnosis without movement erodes credibility.
Movement without structure reinforces disorder.

There is a third path.

What “MVP Test Strategy” Actually Means

MVP does not mean minimum testing.

It means:

Minimum viable structure.

The smallest set of enabling constraints that:

Make quality visible
Reduce unseen risk
Survive without heroics

Before taking any action, apply three filters:

Does this reduce hidden risk — not just organize work?
Can this be implemented using what already exists?
Will it survive if I leave next month?

If the answer is no to any of these, it is not MVP.
It is activity.

MVP = the intersection of visibility, constraint, and sustainability. (Gemini generated image)

The 30-Day Structural Arc

The first 30 days are not about fixing everything.

They are about shifting the system.

Week 1 — Visibility

Chaos survives in silence.

Establish one shared defect log.
Not a tool migration. A spreadsheet is enough.

Hold one weekly 30-minute quality review.
Three questions only:

What broke?
Why didn’t we catch it?
What changes tomorrow?

No blame. Only patterns.

Quality becomes visible.

Week 2 — Boundaries

Without boundaries, testing becomes negotiation.

Define one clear entry criterion for testing.
Only one.

Not “code complete”.
Not “should work”.

Make it concrete. Visible. Agreed upon.

Write it down. Share it. Protect it.

Quality now has edges.

Week 3 — Causality

Take one recent production defect.

Trace it backward.

Where could it have been detected?
At what cost?
Under which condition?

This is not forensic blame.
It is system mapping.

Quality becomes causal.

Week 4 — Shared Commitment

Ensure testing is present when scope is committed.

One slice. One iteration. One discussion.

The tester is no longer downstream verification.
They are upstream risk awareness.

Quality becomes shared.

Structure enters gradually. Not loudly. (Gemini generated image)

The Uncomfortable Truth

You will not fix regression coverage in 30 days.

You will not automate legacy workflows.

You will not eliminate manual testing.

You will not redesign the lifecycle.

So what did you achieve?

You changed the conversation.

From:

“When will testing be done?”

To:

“What does done mean — and how do we know?”

That shift is structural.

Everything else builds on it.

Why This Works

Because chaos in software projects is rarely caused by laziness.

It is caused by local optimization.

Everyone is busy.
Everyone is fixing something.
Everyone is moving.

But nothing stabilizes.

MVP Test Strategy does not increase effort.
It reduces entropy.

It introduces constraints that make quality predictable.

And predictability is the beginning of trust.

Next: Bridge to Post 3

Thirty days in:

Quality is visible.
Boundaries exist.
Causes are discussed.
Testing is present at commitment.

The system feels slightly different.

But one question remains:

Is it working?

Transition KPIs — Measuring Structural Health, Not Just Output

Series Navigator: From Chaos to Structure — Series Overview

1️⃣ Diagnosing Chaos & Defining the Target Model
Understand the invisible disorder. See what’s broken before you fix it.

2️⃣ MVP Test Strategy: First 30 Days
Small, immediate actions to start taming chaos — without waiting for perfect conditions.

3️⃣ Transition KPIs: Measuring Structural Health
How to know if the new test structure is actually working — before a major defect appears.

4️⃣ Stakeholder Alignment & Feasibility
Building buy-in and negotiating constraints with the team and leadership.

5️⃣ Economic Impact: Cost of Non-Structure
Translate structured testing into predictable outcomes and business value.

✨ If you see these patterns in your projects, share your experience below — or connect with me to discuss ways to bring structure and predictability to software quality.

© 2026 Abdul Osman. All rights reserved. You are welcome to share the link to this article on social media or other platforms. However, reproducing the full text or republishing it elsewhere without permission is prohibited.

The Test Manager’s Guide: From Chaos to Predictable Quality — Part 1: Diagnosing Chaos & Defining the Target Model

Tue, 07 Apr 2026 14:03:40 +0000

You can't see bad structure. You only see its symptoms: missed deadlines, production escapes, exhausted teams.

You join a project. No test plans. No ownership. Defects appear unpredictably. People are busy — yet quality drifts.

Most assume testing is the problem. It isn’t. The real issue is structural: misalignment, missing feedback loops, invisible risk.

The Hidden Disorder

Testing chaos is rarely about testers.
It’s about the system: unclear responsibilities, ad-hoc processes, and invisible bottlenecks.

Without diagnosing the underlying structure, any strategy is a guess.

Diagnose Before You Prescribe

Step one: listen and observe.
Talk to line managers, architects, developers, testers. Don’t ask “How do you test?”

You're not asking "How do you test?" You're asking:

• "Where does information get lost?"
• "What decision, if made earlier, would have saved the most rework?"
• "When do you first realize something is going wrong?"
Diagnosis begins with listening. (Gemini generated image)

Define the Target Operating Model

Once the current state is clear, define the target. Not perfect. Practical.

Key elements:

Clear ownership & responsibilities
Risk-aware testing aligned with project goals
Transparent defect tracking
Entry/exit criteria for test levels
Feedback loops for continuous adjustment

The goal isn’t process. It’s predictable outcomes and structural visibility.

Structural visibility means: when a developer commits code, three people immediately know what risks it carries — without asking.

A target operating model brings clarity to chaos. (Gemini generated image)

A Calm Warning

Chaos grows silently. Missed deadlines, defects, and rework are symptoms — not causes.

With structure, you regain visibility, predictability, and control — but only if you first understand the hidden disorder.

A target operating model brings clarity to chaos. (Gemini generated image)

Next: A Bridge to Action

"You've diagnosed the chaos. Now, how do you move—without waiting for permission or perfect conditions?"

Part 2: The MVP Test Strategy — first 30 days to start taming chaos.

Series Navigator: From Chaos to Structure — Series Overview

1️⃣ Diagnosing Chaos & Defining the Target Model
Understand the invisible disorder. See what’s broken before you fix it.

2️⃣ MVP Test Strategy: First 30 Days
Small, immediate actions to start taming chaos — without waiting for perfect conditions.

3️⃣ Transition KPIs: Measuring Structural Health
How to know if the new test structure is actually working — before a major defect appears.

4️⃣ Stakeholder Alignment & Feasibility
Building buy-in and negotiating constraints with the team and leadership.

5️⃣ Economic Impact: Cost of Non-Structure
Translate structured testing into predictable outcomes and business value.

✨ If you see these patterns in your projects, share your experience below — or connect with me to discuss ways to bring structure and predictability to software quality.

Can AI Replace QA Engineers? The Truth Behind the Hype

Fri, 16 Jan 2026 11:26:07 +0000

The software testing world is going through a massive shift right now. If you've been around the industry lately, you've probably felt the tension. Everyone is asking the same nervous question: is AI actually going to take my job?

You’ve seen the headlines. There’s a constant wave of new tools promising to automate everything from basic unit tests to the most complex visual regressions. It's enough to make anyone wonder if manual expertise is becoming a relic of the past.

But here’s the reality. The role of the tester isn't disappearing—it’s just finally evolving into something more strategic. We’ve looked at the current tech and the emerging industry standards to figure out where we're actually heading. This list breaks down the facts behind the hype.

Top 8 Truths About AI in Quality Engineering

1. Automated Test Maintenance via Self-Healing

Modern testing tools now use machine learning to spot changes in application code and update scripts on the fly. This means if a developer tweaks a button's ID or shifts an element, the test doesn't just break. You don't have to drop everything for a manual fix.

Platforms like Mabl have built these features so your test suites keep running without constant human babysitting. By handling the work of updating selectors, these tools give you your time back. You can focus on high-level strategy instead of hunting down broken scripts.

2. Generative Test Case Synthesis for Boilerplate Code

Generative AI is getting surprisingly good at writing the initial drafts of test cases based on simple requirements. Instead of staring at a blank screen, you can just describe a feature. The AI then spits out the boilerplate code and basic assertions for you.

This is a lifesaver in agile shops where speed is everything. While you’ll still need to do a quick review, it removes the heavy lifting of initial setup. It’s like having a junior dev who writes all the foundation work so you can focus on the logic.

3. Visual Regression with Intelligent Perception

Traditional automated tests often miss "soft" bugs that don't technically break the code but definitely ruin the user experience. Think of overlapping text or buttons that hide behind banners. Standard code-based assertions usually ignore these layout fails.

Applitools uses visual AI to mimic how the human eye actually sees a screen. This tech is vital for cross-browser testing because it ensures things look right on every device. It automates the "look and feel" checks that used to take hours of manual squinting.

4. The Shift from Executor to Quality Architect

As AI takes over repetitive tasks, the "QA Engineer" title is slowly turning into "Quality Architect." This isn't just a fancy name change. It reflects a move away from clicking buttons and toward building big-picture quality frameworks.

Engineers today are focusing more on how these tools fit into the CI/CD pipeline. They're learning how to interpret the massive piles of data these platforms generate. The goal is no longer just finding a bug, but building a system that stops them from existing.

5. The Persistent Need for Business Logic Validation

AI is great at following patterns, but it’s pretty bad at understanding complex business logic. A human tester knows why a specific bank transfer has to follow a certain path. An AI might only see the technical steps without the context of why they matter.

We still need humans to find those "logical" edge cases where different business rules crash into each other. You bring a level of domain expertise that an algorithm just can't copy. You’re the person making sure the software actually solves the user's real-world problem.

6. Ethical Bias and Accessibility Auditing

AI models can accidentally pick up biases from their training data, which makes them unreliable for testing fairness. Recent ISTQB standards point out that a "human-in-the-loop" is mandatory for checking ethics and user experience.

A human tester can feel if an interface is truly accessible to someone with different needs. An automated tool might give a "pass" based on technical tags, but a human sees the struggle. This ensures your software is inclusive and meets legal standards that go beyond code.

7. Complex Exploratory Testing in Unscripted Environments

Exploratory testing relies on curiosity and the gut feeling that something isn't right. AI is generally stuck on the paths it was trained on or the parameters you gave it. It doesn't get "curious."

Human testers are the masters of the "what if" scenario. You try things a programmer never intended or even dreamed of. This creative way of breaking software is usually where the most critical vulnerabilities are hiding. It’s a uniquely human skill.

8. Legal Governance and Final Production Sign-off

At the end of the day, an AI can't be held legally responsible if a software crash causes a disaster. Official governance rules require a human lead to give the final okay for production deployments.

There has to be clear accountability when things go live. The AI acts as a powerful advisor that gives you data and confidence, but the "Go" button is yours. The decision to release software remains a human responsibility, and it likely always will.

Which One is Right for You?

How do you choose the right path? It really depends on what your team is building and how fast you need to move. For big enterprise teams dealing with massive environments like SAP or Salesforce, a model-based approach like Tricentis Tosca is usually the best bet.

If you’re at a fast-paced startup, you might prefer low-code tools like Mabl. These let non-technical team members help with testing using natural language prompts. It opens up the process so everyone can contribute to quality.

For teams that need a pixel-perfect UI across many different phones and browsers, Applitools is the standard. Most modern teams end up using a hybrid model. They combine AI-driven regression with human-led exploratory testing to get the best results.

Final Thoughts

The real story isn't that AI is coming for your desk. It’s coming for the parts of your job that you probably hate doing anyway. By handling script maintenance and boring boilerplate, AI frees you up for the creative and strategic work.

The future belongs to the "AI-Assisted Tester." This is the person who knows how to use these tools to build better software faster than ever. If you want to stay ahead, now is the time to start playing with prompt engineering and model validation.

Don’t wait for the industry to change around you. Why not be the person who leads the evolution of quality in your shop? The tools are ready when you are.

The "Spinner of Death": Why Localhost Latency is Lying to You

Fri, 19 Dec 2025 15:19:20 +0000

The "Localhost" Bias
We've all been there.

On your machine, the API responds in 5ms. The UI updates instantly. You click "Submit," the modal closes, and you move on to the next ticket. Status: Done. ✅

But on a user's 4G connection in a subway tunnel, that same API call takes 2 seconds.

Because you tested on localhost (Gigabit Fiber), you missed critical race conditions:

️ The Double-Click Bug: The user clicks "Submit" twice because "nothing happened," charging their credit card twice.
The Infinite Spinner: The loader gets stuck forever because a packet was dropped.
️ Race Conditions: Data arrives out of order, overwriting the user's input.

Your app feels fast because you are cheating. 0ms latency is a lie.

The Wrong Solution: time.sleep()
I often see tests that look like this:

# ❌ Don't do this
page.click("#submit")
time.sleep(2) # Simulating "network lag"
expect(page.locator(".success")).to_be_visible()

Why this fails: `sleep()` just pauses the test execution script. The browser engine itself is still blazing fast. It doesn't simulate network queues, slow handshakes, or constrained bandwidth. You aren't testing the network; you're just making your test suite slower.

The Right Solution: Network Throttling (CDP)

To test this properly in automation, you need to talk directly to the browser engine. You need to tell Chrome: "Pretend you are on a terrible 50kb/s connection."

We can do this using the Chrome DevTools Protocol (CDP) within Playwright. This forces the browser to handle packet delays and loading states exactly as a real user would experience.

The Code (Python + Playwright)
Here is how to inject a "Bad 3G" connection into your test:

from playwright.sync_api import Page, expect

def test_slow_network_handling(page: Page):
    # 1. Connect to Chrome DevTools Protocol (CDP)
    # This gives us low-level access to the browser
    client = page.context.new_cdp_session(page)
    
    # 2.  CHAOS: Emulate "Bad 3G"
    # Latency: 2000ms (2 seconds)
    # Throughput: 50kb/s (Very slow)
    client.send("Network.emulateNetworkConditions", {
        "offline": False,
        "latency": 2000, 
        "downloadThroughput": 50 * 1024,
        "uploadThroughput": 50 * 1024
    })

    page.goto("https://myapp.com/search")
    
    # 3. Trigger the slow action
    page.fill("#search-box", "Playwright")
    page.click("#search-btn")

    # 4. Resilience Assertion
    
    # Check 1: Does the UI prevent double submission?
    expect(page.locator("#search-btn")).to_be_disabled()
    
    # Check 2: Does the user get immediate feedback?
    expect(page.locator(".loading-spinner")).to_be_visible()

Why this matters: This test proves your UI provides feedback. If a user clicks a button and waits 2 seconds with no visual feedback, they will assume the app is broken.

But wait, what about Mobile Apps?
The script above is perfect for automated CI pipelines running Chrome. But CDP has a major limitation: It doesn't work on a physical iPhone or Android device.

If you are a Mobile Developer or manual QA, you can't "attach Playwright" to the phone in your hand to simulate a subway tunnel.

The Manual Alternative (System-Level Proxy)

To test latency on a real device without writing code, you need a System-Level Proxy that sits between your phone and the internet.

You can use desktop tools like Charles Proxy (if you enjoy configuring Java apps and firewalls), or you can use a cloud-based tool like Chaos Proxy (which I'm building).

It allows you to simulate "Subway Mode" (2s latency) on any device—iPhone, Android, or Laptop—just by connecting to a Wi-Fi proxy.

The Workflow:

Create a "Chaos Rule" (e.g., Latency = 2000ms).
Connect your phone to the proxy via QR code.
Watch your app struggle (and then fix it).

Summary
Stop trusting Localhost. It hides your worst bugs.
Automated: Use Playwright + CDP to inject latency in your E2E tests.
Manual/Mobile: Use a Chaos Proxy to test resilience on physical devices.

Happy testing!

If you found this useful, check out my previous post: Stop Testing Success. Kill the Database.

gRPC for Testers: Quick Start After REST

Thu, 11 Dec 2025 12:03:55 +0000

REST API has long been the standard, but it has its limitations. When load increases, streaming scenarios appear, or business requires faster communication between services, REST stops being the ultimate solution. gRPC solves what REST cannot: it provides high data transfer speeds, supports streaming, and enforces a strict interaction structure. It is convenient to use in microservices, mobile, and IoT applications.

For a tester, this means one thing: knowing how to work with gRPC is shifting from a "nice-to-have" to an essential skill. If you haven't worked with this protocol yet, this article will help you understand its basics, how it differs from REST, the structure of .proto files, and most importantly - how to test gRPC services using Postman.

What is gRPC and Why is it Needed?

gRPC is a high-performance framework from Google. As a QA specialist, you don't necessarily need to dive into implementation details, but understanding how this protocol works and how to test it will definitely be useful.

To simplify, REST can be compared to paper letters sent in envelopes, while gRPC is like a phone call. Both are formats for communication between an application and a server, but with REST API, data is transferred in JSON or XML formats, which in our analogy can be equated to envelopes. This is okay and works, but not always fast or convenient.

gRPC proposes wrapping data in a binary protocol, which transmits data faster, has a smaller size, and is strictly structured. It uses Protocol Buffers (protobuf). Thanks to this, both sides participating in the information exchange know in advance what questions will be asked and what answers to expect. For a tester, this means less ambiguity and more predictability in verifications.

When we first implemented gRPC in a project, it unexpectedly turned out that Postman, by default, couldn't work with this protocol. We had to find workarounds - we tried BloomRPC, then grpcurl. In the end, we found a solution: uploading .proto files into a new beta version of Postman. It was a useful lesson - tools aren't always ready "out of the box," and it's important for a tester to have several alternatives on hand.

Key Advantages of gRPC

Why is gRPC usage increasingly common in product development? Here are the main reasons:

High performance thanks to the binary protobuf format.
Support for streaming: data can be transmitted not only in a
"request-response" format but also as streams.
Cross-platform: gRPC can be used for projects in different
programming languages.
Code autogeneration: client and server code is automatically
generated from .proto files.

All of this leads to fewer misunderstandings with developers, clear rules for validation, and new testing scenarios - for example, for streaming.

Key Differences Between gRPC and REST

Moving from testing REST to gRPC implies conceptual changes in the process. Instead of endpoints and HTTP methods - methods and messages described in a contract. For convenience, let's compare them in a table.

Next, let's look in more detail at one of gRPC's advantages over REST - the presence of streaming.

Types of gRPC Calls

Unlike REST, which has the familiar GET/POST/PUT/DELETE, gRPC works with methods defined in a .proto file.

Four types of calls are supported:

Unary - one request, one response.
Server streaming - one request, stream of responses.
Client streaming - stream of requests, one response.
Bidirectional streaming - stream of requests, stream of responses.

When designing tests, it's important to consider that "one test - one request" isn't always suitable. For streaming, you need scenarios with multiple sequential messages.

But to understand which methods are available and what data can be transmitted in these calls, you need to understand how a .proto file is structured.

How a .proto File is Structured

This is a simple text file with a .proto extension. In it, we essentially agree on what data can be sent and received, and what methods the service has.

You can think of it as an instruction or contract between the service developer and those who use it (for example, QA specialists).

Usually, the .proto file is created by the backend service developer, because they know which methods the service must support, as well as what data is accepted and returned.

A tester can also open a .proto file to understand how to correctly form a request, suggest improvements (for example, add a field or change a data type), and, if desired, write their own .proto for learning or experiments.

Before moving on to the structure of a .proto file, let's make an important clarification.

gRPC indeed transmits data in the binary Protocol Buffers format, not JSON - this is why it is more efficient than REST in terms of speed and traffic volume. However, when testing via tools like Postman, BloomRPC, or grpcurl, you will see requests and responses in a human-readable format resembling JSON. This is a visualization of the binary data for humans. The tools automatically convert the binary stream into such "pseudo-JSON" to make it easier for you to work with the fields.

In our examples, we will also use this readable format - not because gRPC uses JSON, but so you can quickly understand the message structure.

Let's look at a simple example of a .proto file:

syntax = "proto3";

service HelloService {

  rpc SayHello (HelloRequest) returns (HelloResponse);

}

message HelloRequest {

  string name = 1;

}

message HelloResponse {

  string message = 1;

}

What's Inside:

Syntax Specification

syntax = "proto3";

Syntax indicates which version of the Protocol Buffers language we are using. At the time of writing, the current version is the third - proto3.

Service Definition

service HelloService {

  rpc SayHello (HelloRequest) returns (HelloResponse);

}

Service HelloService - declaration of a service named HelloService.You can think of a service as a class containing methods.
rpc SayHello (...) returns (...) - this describes a remote procedure call, where:

SayHello - the method name.
(HelloRequest) - what the method accepts (request type).
returns (HelloResponse) - what the method returns (response type).

In our example, the service has only one method, SayHello, which accepts a HelloRequest message and returns a HelloResponse.

Request Message Description

message HelloRequest {
string name = 1;
}

Message HelloRequest defines the data type for the request. Inside it:

string name = 1;

string - data type (string).
name - field name.
= 1 - sequence number (needed for serialization).

This means: the client must pass a string field name.

Example:

Response Message Description

message HelloResponse {

  string message = 1;

}

Message HelloResponse defines the data type for the response. Inside:

string message = 1;

a string that will contain the result.

In our case, the server will return a greeting string.

Example:

All of this works as follows: the client calls the SayHello method, in the HelloRequest it sends the name field, the server receives this field, forms a response, and in the HelloResponse it returns a string with a greeting.

If you know how to read and understand .proto files, you can easily grasp the data structure and suggest improvements to the API even at the design stage.

And now, it's logical to move on to the next question: what else does the service return besides useful data? Here we'll talk about gRPC status codes.

gRPC Status Codes: What a Tester Needs to Know

In gRPC, every response (even a successful one) is accompanied by a status code. These are not HTTP 200/404/500, but their own set of codes defined in the gRPC library. In total, gRPC has 17 predefined status codes, from 0 to 16, but we will consider only the most basic and commonly used ones.

Main gRPC Status Codes

It's important not only to verify the correctness of the data in the response but also to ensure the service correctly returns status codes in various scenarios.

gRPC in Postman: Practical Testing

Previously, Postman could only work with REST, but now - also with gRPC.

How it works:

Upload the .proto file into Postman.
Select the service and method.
Form the request (data is taken from the request structure in the
.proto).
Look at the response and status code.

For example, for a simple service:

A request in Postman will contain the name field, and in response a greeting message will arrive.

Let's look at an example.

Create a new request → select the request type gRPC Request (not HTTP!).

Specify the URL, open the Service Definition tab, import the .proto file.

After importing the .proto file, all available methods the service can work with will become available for selection.

Select the method we need, and a JSON-like form with fields that need to be filled in will appear in the request body (all required fields are defined in our .proto file).

Click Invoke and you will see the response and status code.

Summary

gRPC is faster than REST, supports streaming, and enforces strict
contracts.
For a tester, the key skills are: being able to read .proto files,
check different call types, and work with tools (Postman, grpcurl,
BloomRPC).
Don't forget about status codes: they help understand how a service
behaves in error scenarios.
In practice, you may encounter pitfalls: not every tool supports gRPC
as conveniently as REST.

By mastering gRPC, you will expand your arsenal: you'll be able to test not only REST services but also more modern microservice systems. And that means—you'll become a more in-demand specialist.

Author: Vasil Khamidullin

Bloodhound Security by Agunech

Fri, 05 Dec 2025 23:48:15 +0000

Instead of guessing at race conditions, memory leaks, attack paths, I architected a local engine that runs 7 parallel detection threads to recursively map entire Call Graphs.

It traces Tainted Control Flow across file boundaries to prove Deterministic Reachability, to give the exact execution path from input to crash without the theoretical noise of standard linters.

Here is the architectural breakdown:

Recursive Taint Analysis: Instead of regex-matching for "bad patterns" (like eval()), Blood Hound builds a complete Call Graph of the application. It maps data from Sources (Inputs) to Sinks (execution) across file boundaries. It does not flag a vulnerability unless it can prove a connected path exists in runtime. Therefore filtering out theoretical noise plaguing syntax testers.
Local Parallelization: To handle the computational load of tracking state across 2M+ LOC without timing out, the system runs 7 detection engines in parallel locally. This allows for exhaustive recursion to validate dependency chains too deep for manual review, all done locally.
White Box Execution: This is not a DAST that pokes from the outside. It operates as a White Box analyst, linking runtime crashes directly to the exact source lines causing them.

The Goal: I didn't build this to replace engineers. I built it to handle the computational drudgery of dependency tracing. It clears the false positives so I can focus on complex exploit chains.

It runs via CLI (blood hound). Just install needed.

If you are an Engineer with a repo in prod, I’d love for you to stress-test the reachability logic against your messiest repo and compare it to your other testing tools

Here's some images from how it looks inside the IDE:

My AI Bot Argues With My Swagger Schema (And Why That's Good)

Mon, 24 Nov 2025 08:30:02 +0000

In my last posts, I talked a lot about UI tests. But the real meat (and the real pain) of automation often lies with the API.

API tests need to be fast, stable, and cover 100% of your endpoints. "Simple," you say. "Just take the Swagger schema and run requests against it."

Oh, if only it were that simple.

When I started adding API test automation to Debuggo, I realized the whole process is a series of traps. Here is how I'm solving them.

Step 1: Parsing the Schema (The Deceptively Easy Start)

It all starts simply. I implemented a feature:

You upload a Swagger schema (only Swagger for now).
Debuggo parses it and automatically creates dozens of test cases:
- [Positive] For every endpoint.
- [Negative] For every required field.
- [Negative] For every data type (field validation).

This already saves hours of manual work "dreaming up" negative scenarios. After this, you can pick any generated test case (e.g., [Negative] Create User with invalid email) and ask Debuggo: "Generate the steps for this."

Step 2: Creating Steps (The First Challenge: "Smart Placeholders")

...the first real problem begins. How does an AI know what a "bad email" is?

The Bad Solution: Hardcoding the knowledge that *Emails are not allowed* is a bad email into the AI. This is brittle and stupid.

The Debuggo Solution: Smart Placeholders.

When Debuggo generates steps for a negative test, it doesn't insert a value. It inserts a placeholder.

For example, for a POST /users with an invalid email, it will generate a step with this body:

{"name": "test-user", "email": "%invalid_email_format%"}

Then, at the moment of execution, Debuggo itself (not the AI) expands this placeholder into real, generated data that is 100% invalid. The same goes for dropdowns, selects, etc. — the AI doesn't guess the selector, it inserts a placeholder, and Debuggo handles it.

Step 3: The First Run (The Second Challenge: "The Schema Lies")
So, we have our steps with placeholders. We run the test. And it fails.

The Scenario: The schema says POST /users returns 200 OK. The application actually returned 201 Created.

A traditional auto-test: Will just fail, giving you a "flaky"
test.

The Debuggo Solution: A Dialogue with the User.

Debuggo sees the conflict: "Expected 200 from the schema, but got 201 from the app."

It doesn't just fail. It pauses the test and asks you:

"Hey, the schema and the real response don't match. Do you want to accept 201 as the correct response for this test?"

You, the user, confirm. Debuggo fixes the test case. You just fixed a brittle test without writing a single line of code.

Step 4: Adaptation (The Third Challenge: "Secret" Business Rules)
This is the coolest feature I've implemented.

The Scenario: The app returns a 400 Bad Request with the response body: {"error": "name cannot contain spaces"}.

A traditional auto-test: Will fail, and you have to manually analyze the logs to find the hidden rule.

The Debuggo Solution: Adaptation on the Fly.

Debuggo doesn't just see the 400 error. It reads the response body and sees the rule: "name cannot contain spaces."

It automatically changes the placeholder for this field. It creates a new one — %string_without_spaces% — and re-runs the test by itself with the new, correct value.

The AI is learning the real business rules of your app, even if they aren't documented in Swagger.

What's the takeaway?
I'm not just building a "Swagger parser." I'm building an assistant that:

Generates hundreds of positive/negative test cases.
Uses "Smart Placeholders" instead of hardcoded values.
Identifies conflicts between the schema and reality and helps you fix them.
Learns from the application's errors to make tests smarter.

This is a hellishly complex thing to implement, and I'm sure it's still raw.

That's why I need your help. If you have a "dirty," "old," or "incomplete" Swagger schema—you are my perfect beta tester.

Why Automation Testing Fails Without the Right QA Mindset

Sat, 04 Oct 2025 16:41:45 +0000

Introduction

Why automation testing fails is one of the most common challenges in DevOps today. While automation promises speed, many teams still struggle with fragile pipelines, missed defects, and wasted effort. The missing piece is often the QA mindset in automation testing—a way of thinking that ensures automation is purposeful, adaptable, and aligned with business goals.

Why Automation Testing Fails

Automation fails most often when speed is prioritized over strategy. According to DevOps.com, many organizations rush into automation without proper planning, leading to flakiness and wasted investments.

Key reasons why automation testing fails include:

Late QA involvement: Tests are created after functionality is built, missing early risks.
Coverage obsession: Teams measure test count, not risk coverage.
Fragile scripts: UI and API changes constantly break automated cases.
Poor data practices: Static or unreliable test data undermines results.
No risk focus: Teams test what’s easy, not what matters most.

The Role of QA Mindset in Automation Testing

A QA mindset in automation testing means looking beyond scripts. It focuses on user needs, risk-based scenarios, and real-world workflows.

For example, BrowserStack highlights that brittle test cases often fail because teams ignore business priorities. A QA mindset ensures automation adapts to change and focuses on outcomes, not just execution.

This mindset asks questions like:

How could this feature fail under real use?
Does this workflow support business logic?
Will users trust the experience?

Why Human QA Thinking Still Matters

Automation validates what it is programmed to check. But real-world systems evolve, and business rules shift. Human testers bring adaptability, creativity, and judgment.

For example, a payroll system upgrade used automation for regression, but human QA validated integration with finance rules and user experience. Without that, automation alone would have missed critical compliance risks.

A LambdaTest study confirms that combining automation with human-driven testing reduces defect leakage and improves release confidence.

How to Prevent Automation Testing Failures

To ensure automation delivers value instead of false confidence, teams should:

Involve QA From the Start
Engage QA during requirement and design phases, not just at the end.
Prioritize by Risk
Focus automation on features with high business or customer impact.
Build Maintainable Scripts
Use modular design, version control, and avoid brittle selectors.
Balance Automation With Manual Testing
Automation handles regression; humans explore edge cases, UX, and new features.
Continuously Improve
Track metrics like coverage, stability, and ROI. Refine strategies after every release.

Why Automation Testing Fails Without QA Mindset

Even the most advanced frameworks fail if guided by the wrong mindset. Scripts can pass while defects slip into production.

Consider a mortgage calculation tool: automation validated formulas, but only human QA confirmed compliance with real lending laws. Without the QA mindset, the system would have shipped “working” but non-compliant code.

This is why automation testing fails when treated as a toolset rather than a discipline.

Final Word from UpTech Solution

At UpTech Solution, we’ve seen firsthand that automation succeeds only when guided by human insight. A strong QA mindset in automation testing ensures automation delivers more than speed—it delivers trust, compliance, and user satisfaction.

Automation accelerates, but QA ensures resilience. The question is: are you just automating scripts, or are you automating with purpose?