Coder Legion - Recent posts tagged testautomation

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! 👇

A Failed Test Is a Clue, Not a Diagnosis

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

An end-to-end test fails.

The report is red.

Someone asks, “Is it a bug?”

Maybe.

But at that moment, all we really know is that the test didn't observe the expected behavior.

That distinction sounds small, but it changed the way I investigate failures.

When I started working more deeply with automation, I gradually learned that a failed test is not a diagnosis. It's the beginning of an investigation.

The same failure can have very different causes

Imagine an automated checkout test that expects an order to be created.

The test fails because the order confirmation never appears.

The cause could be an application defect. But it could also be a failed API request, unavailable service, incorrect test data, expired credentials, a deployment issue, an environment configuration problem, or a timing issue in the test.

All of those can produce a similar result in the report.

If we immediately label the failure as a product bug, we may send developers looking in the wrong place.

If we immediately label it as a flaky test, we may hide a real defect.

The first job is to find out which one it is.

Start with the failure, not the assumption

My first step is to understand exactly what failed.

Was it an assertion? A timeout? A missing element? An HTTP error? Did the test fail before the application was even reached?

The details matter.

A test that receives a 500 response is different from a test that cannot connect to the server. A timeout waiting for a button is different from a timeout waiting for an API response.

I also want to know whether the failure is reproducible.

Does it happen every time? Only in CI? Only in one environment? Only when tests run in parallel? Did it start after a particular deployment?

Those questions help narrow the problem before anyone starts changing code.

Check whether the application is actually healthy

One of the most useful habits I developed was to stop looking only at the test report.

If an API test fails, I want to know whether the API is responding outside the test.

If an end-to-end test fails, I want to know whether the underlying service is healthy.

A simple request, a health endpoint, or a look at the service logs can reveal that the test is only reporting a symptom of a larger problem.

For example, a login test might fail because the authentication service is unavailable.

Changing the Playwright locator won't fix that.

Neither will adding another ten seconds to the timeout.

Environment differences matter

I remember how confusing DEV, QA, STG, and PROD were when I first entered QA.

Today, environment differences are one of the first things I consider during an investigation.

The same code can behave differently because of configuration, data, dependencies, feature flags, external integrations, or infrastructure.

If a test passes locally but fails in CI, I want to compare the conditions.

Are the same versions running? Is the test using the same configuration? Are required services available? Is the data equivalent? Are there resource constraints? Is there a difference in browser or runtime versions?

“Works on my machine” isn't a diagnosis either.

It's another clue.

Logs connect the test to the system

This is where my long-standing interest in Linux and Bash became especially useful.

I don't need to understand every internal detail of a service to start investigating it.

But I do need to know how to find relevant information.

Application logs, container logs, system services, network responses, and CI output can help connect the failure in the test to what actually happened in the system.

The important skill isn't memorizing a hundred commands.

It's knowing what question you're trying to answer.

Did the request reach the service? Did the service reject it? Did a dependency fail? Was the process restarted? Was there an error at the same time as the test failure?

When the timestamps and evidence line up, the investigation becomes much more useful.

Don't fix flakiness by hiding it

Flaky tests are frustrating, especially when they slow down a team.

But adding retries or longer waits without understanding the cause can make the situation worse.

Sometimes a retry is a reasonable mitigation. But it should not become a substitute for investigating why the test is unreliable.

Is the application genuinely slow? Is the test waiting for the wrong condition? Is shared test data causing interference? Are tests running in parallel without proper isolation? Is the environment overloaded?

A test that passes on the third attempt may still be telling you something important.

The question is whether you understand what that something is.

Test data deserves more attention than it gets

Test data is another common source of misleading failures.

An account might already exist. A record may have been modified by another test. An external system may have changed state. A cleanup step may not have run.

A test can be technically correct and still fail because its assumptions about data are no longer true.

This is why I increasingly value predictable setup, isolation, cleanup, and clear ownership of test data.

Reliable automation isn't only about good assertions.

It's also about controlling the conditions under which those assertions run.

Look at the change that happened before the failure

When a previously stable test starts failing, I want to know what changed.

A new commit? A dependency update? A deployment? A configuration change? A database migration? A new feature flag?

The recent change isn't automatically the cause, but it provides useful context.

This is also where understanding CI/CD becomes valuable for QA.

A pipeline isn't just a place where tests run. It contains information about the build, dependencies, environment, and changes that produced the result.

The more of that context you can read, the less you have to guess.

A useful investigation produces more than “fixed”

Eventually, the failure is resolved.

Maybe it was an application bug. Maybe the test needed a better wait condition. Maybe a service was unavailable. Maybe the data setup was unreliable.

But I think a good investigation should leave behind something more useful than a green rerun.

What was the actual cause? How did we confirm it? Could the same failure happen again? Can we improve the test, environment, monitoring, or process so it's easier to diagnose next time?

A failure is an opportunity to improve the system's ability to explain itself.

That matters to QA, DevOps, and everyone responsible for reliable delivery.

The broader lesson

The deeper I moved into automation, the more I realized that debugging requires an expanding field of view.

Sometimes the answer is in the test.

Sometimes it's in the application.

Sometimes it's in the environment, CI, infrastructure, or deployment history.

You don't need to be an expert in every layer to investigate effectively.

But you do need to be willing to look beyond the layer where the failure first appeared.

A red test is useful evidence.

It tells us something didn't go as expected.

The real engineering work is finding out why.

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

When an automated test fails in your team, what's the first thing you check outside the test report?

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

Everyone’s online. But not everyone’s in focus.

Wed, 19 Aug 2026 05:47:14 +0000

Everyone’s online. But not everyone’s in focus.

Software teams are constantly shipping new features, fixing bugs, and preparing for the next release.

But with every release comes the same repetitive testing:

The product changes, but many of these tests stay the same.

And when your team spends hours repeating the same tests, there’s less time for what really matters — finding new issues, improving the product, and building better experiences.

That’s where QAlity comes in.

QAlity helps teams automate repetitive tests so they can spend less time on busywork and more time focused on quality.

Less repetition.
Fewer distractions.
More impact.

Focus on what matters. Automate the rest.

👉 Get started at qality.dev

#QAlity #TestAutomation #SoftwareTesting #QA #QualityEngineering

Simulating natural selection to solve computer science problems!

Mon, 01 Dec 2025 12:23:44 +0000

Simulating natural selection to solve computer science problems!
While researching some of the newer developments in computer science, I explored using a Genetic Algorithm to automatically "evolve" a high quality test suite for a tricky e-commerce pricing function. The algorithm learns the validation rules and generates a concise set of intelligent tests on its own.

I've written a full, step-by-step guide explaining how the Python code works from the fitness function to crossover and mutation. You can also checkout a written paper explaining the motivation and logic behind the exploration.

Check out the paper here:
https://github.com/ShivangVora1206/Genetic-Algorithm/blob/main/paper.pdf

Check out the developer's guide here on dev.to:
https://dev.to/shivangvora1206/a-developers-guide-to-test-case-generation-with-genetic-algorithms-4mef

How to Achieve Automated Testing Within Sprint?

Thu, 06 Feb 2025 20:21:38 +0000

How to Achieve Automated Testing Within Sprint?

In the debate over whether automated testing should wait until development is completed, one compelling argument for early testing is the use of dummy test cases. Dummy test cases are simple, placeholder tests that can be implemented early in the development process to ensure that the testing framework is in place and functioning correctly. This article explores how to implement dummy test cases and how they can encourage a culture of early automated testing.

What are Dummy Test Cases?

Dummy test cases are basic, often minimalistic tests that serve as placeholders in the early stages of development. They are not meant to thoroughly test the application but to ensure that the testing infrastructure is set up correctly and to provide a foundation for more comprehensive tests later on.

Let's Understand the concept of Dummy Tests by real world example

Let's create some dummy tests for a login feature using Playwright (you can write for Selenium, Cypress, webdriver.io in similar way). These tests will serve as placeholders and ensure that the testing framework is set up correctly.
Setting Up Playwright -

npm install - save-dev playwright

Creating Dummy Tests

To keep the dummy test data in a separate file and segregate the test and data, you can follow these steps:

Create a Separate File for Dummy Test Data
Move Dummy Test Data to the New File
Import and Use Dummy Test Data in Your Test File

Step 1: Create and Move Dummy Test Data to the New File

Create a new file named dummyTestData.ts in the tests folder. Move the dummy test data to the new file dummyTestData.ts:

// tests/dummyTestData.ts

export const loginTestData = {
    validUser: {
        username: 'validUser',
        password: 'validPass',
    },
    invalidUser: {
        username: 'invalidUser',
        password: 'invalidPass',
    },
    // TBA = To Be Added
    selectors: {
        loginForm: 'TBA',
        loginButton: 'TBA',
        usernameInput: 'TBA',
        passwordInput: 'TBA',
        errorMessage: 'TBA',
        welcomeMessage: 'TBA',
    },
};

Step 2: Import and Use Dummy Test Data in Your Test File

Import the dummy test data into your test file and use it in your tests. For example, in login.test.ts:

// tests/login.test.ts

import { test, expect } from '@playwright/test';
import { loginTestData } from './dummyTestData';

test.describe('Login Feature', () => {
    test('Dummy Test Case 1: Page should have a login form', async ({ page }) => {
        await page.goto('https://example.com/login');
        const loginForm = await page.$(loginTestData.selectors.loginForm);
        expect(loginForm).not.toBeNull();
    });

    test('Dummy Test Case 2: Login button should be disabled initially', async ({ page }) => {
        await page.goto('https://example.com/login');
        const loginButton = await page.$(loginTestData.selectors.loginButton);
        const isDisabled = await loginButton?.isDisabled();
        expect(isDisabled).toBe(true);
    });

    test('Dummy Test Case 3: Should display error message for invalid credentials', async ({ page }) => {
        await page.goto('https://example.com/login');
        await page.fill(loginTestData.selectors.usernameInput, loginTestData.invalidUser.username);
        await page.fill(loginTestData.selectors.passwordInput, loginTestData.invalidUser.password);
        await page.click(loginTestData.selectors.loginButton);
        const errorMessage = await page.$(loginTestData.selectors.errorMessage);
        expect(errorMessage).not.toBeNull();
    });

    // Add real tests here as development progresses
    test('Real Test Case: Successful login', async ({ page }) => {
        await page.goto('https://example.com/login');
        await page.fill(loginTestData.selectors.usernameInput, loginTestData.validUser.username);
        await page.fill(loginTestData.selectors.passwordInput, loginTestData.validUser.password);
        await page.click(loginTestData.selectors.loginButton);
        await page.waitForNavigation();
        const welcomeMessage = await page.$(loginTestData.selectors.welcomeMessage);
        expect(welcomeMessage).not.toBeNull();
    });
});

Explanation

dummyTestData.ts: This file contains the dummy test data. The loginTestData object holds the test data for the login feature, including valid and invalid user credentials and selectors.

login.test.ts: This file imports the loginTestData object and uses it in the dummy test cases. This keeps the test data separate from the test logic, making the code more organized and maintainable.

Running the Tests

Run the tests using the Playwright Test runner:

npx playwright test

Benefits of Dummy Test Cases

Early Detection of Issues: By implementing dummy test cases early, teams can identify and resolve issues with the testing framework, dependencies, and configurations before they become critical problems.

Continuous Feedback: Dummy test cases provide continuous feedback to developers, ensuring that the basic functionality of the application is being tested from the outset.

Encourages a Testing Culture: Implementing dummy test cases early in the development process encourages a culture of testing within the team. It sets the expectation that testing is an integral part of development, not an afterthought.

Reduces Technical Debt: Early testing helps to identify and fix issues before they accumulate, reducing technical debt and making the codebase more maintainable.
Facilitates Test-Driven Development (TDD): Encourage TDD approach where tests are written before the actual code.

Cost-Effective: Implementing dummy tests requires minimal effort and resources, making it a cost-effective way to improve the testing process.
Improves Test Coverage: Dummy tests provide a baseline level of test coverage, ensuring that at least the basic functionality is being tested.

Conclusion

This approach encourages early automated testing, providing continuous feedback and fostering a culture of quality within the development team. By keeping the dummy test data in a separate file, you can maintain a clean and organized codebase. This approach allows you to easily manage and update test data while keeping your test files focused on the test logic. This practice encourages early automated testing and helps in maintaining a high level of code quality throughout the development lifecycle.

If you enjoyed this story, please like and share to help others find it! Feel free to leave a comment below.

Coder Legion - Recent posts tagged testautomation

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

A Failed Test Is a Clue, Not a Diagnosis

The same failure can have very different causes

Start with the failure, not the assumption

Check whether the application is actually healthy

Environment differences matter

Logs connect the test to the system

Don't fix flakiness by hiding it

Test data deserves more attention than it gets

Look at the change that happened before the failure

A useful investigation produces more than “fixed”

The broader lesson

It Took Me 20 Years to Come Back to Tech

It Took Me 20 Years to Come Back to Tech

It Took Me 20 Years to Come Back to Tech

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

Then I Discovered Linux

Then Life Took Me Somewhere Completely Different

The Dream of Working in IT Never Completely Disappeared

My First IT Job Was in QA

Everyone’s online. But not everyone’s in focus.

Simulating natural selection to solve computer science problems!

How to Achieve Automated Testing Within Sprint?

How to Achieve Automated Testing Within Sprint?

What are Dummy Test Cases?

Dummy Tests for a Login Feature

Creating Dummy Tests

Step 1: Create and Move Dummy Test Data to the New File

Step 2: Import and Use Dummy Test Data in Your Test File

Explanation

Running the Tests

Benefits of Dummy Test Cases

Conclusion