Interviewed by: Mehadi Hasan
Developer: Orhan Eren Kara
Role: QA Engineer and Chrome Extension Developer
Location: Türkiye
Featured Project: QA Bug → Regression Test
Technologies: TypeScript, React, WXT, Chrome Extension Manifest V3, Playwright
Software testing is about more than finding bugs. It is about understanding why something failed, documenting the conditions that caused the failure, and ensuring the same problem does not return.
For Orhan Eren Kara, a QA engineer and independent developer from Türkiye, this principle has shaped his approach to software quality, browser automation, and AI-assisted development. After graduating in Management Information Systems from İzmir Democracy University in 2025, he began exploring ways to make testing workflows more practical and less repetitive.
His work focuses on a familiar challenge for QA engineers: turning a manually reproduced bug into a useful, maintainable automated regression test. Rather than treating automation as a replacement for engineering judgment, Orhan sees it as a way to preserve information, reduce repetitive work, and help developers concentrate on the decisions that matter.
That philosophy is reflected in two of his Chrome extension projects, QA Bug → Regression Test and MindContext. Although they address different workflows, both explore the same broader idea: tools should make existing work easier without hiding the limitations or decisions behind the results.
From Software Testing to Browser Automation
Orhan's professional journey began in software testing. While working with different types of software, including web applications, APIs, chatbots, and AI-powered workflows, he became interested in understanding how applications behave beyond their expected scenarios.
A feature might work perfectly under normal conditions but fail when users provide unexpected input, interrupt a conversation, encounter a timing issue, or move through an unusual sequence of actions.
These experiences shaped his understanding of software quality. Testing is not simply a matter of checking whether a feature works. It also involves identifying edge cases, understanding user behavior, reproducing problems clearly, and giving developers enough information to investigate and fix them.
AI-powered applications made this challenge particularly visible. In conversational and voice-based workflows, small changes in wording, context, timing, or user input can lead to different outcomes. Interruptions, ambiguous responses, and unexpected silence may expose problems that ordinary happy-path tests fail to catch.
Orhan also learned to distinguish between an API returning a successful response and an application delivering the experience users actually expect.
This perspective led him to focus on reproducibility, clear expected and actual results, and appropriate evidence. A bug report should explain what happened and provide the conditions necessary to reproduce it. A fix should then be verified rather than assumed to be correct.
As he explored ways to reduce repetitive testing work, he became interested in tools such as Selenium and Playwright. Eventually, his interest in browser automation led him to Chrome extension development.
Browser extensions offered a practical advantage: they could fit directly into an existing workflow. Instead of asking developers and testers to adopt an entirely separate process, he could build tools that assist them while they were already working.
The Problem Behind QA Bug → Regression Test
One of the most repetitive tasks in software testing happens after a bug has been discovered.
A QA engineer reproduces the problem, documents the steps, records the expected and actual results, and may capture screenshots or other evidence. Later, when the issue needs automated regression coverage, those same interactions must be translated into test code.
The process creates two related but separate tasks: documenting the bug and writing the automated test.
Information can be lost during that transition, and the same work may need to be repeated. Even when the original reproduction is well documented, the person writing the test must reconstruct the sequence of actions and determine which assertions will demonstrate the failure.
Orhan wanted to explore whether a single browser session could serve as the starting point for both tasks.
That idea became QA Bug → Regression Test, a Chrome extension designed to record supported browser interactions and help generate two editable outputs: a Markdown bug report and a Playwright TypeScript test draft.
The objective is not to eliminate the judgment required from a QA engineer. It is to reduce repetitive work and preserve more of the information gathered during the original bug reproduction.
This distinction is central to the project's design. Recording what a user did is useful, but the recording alone does not explain why the behavior was incorrect or prove that a future test will detect the same problem.
The extension aims to make the transition from manual reproduction to automated testing more efficient while keeping the engineer responsible for validating the result.
How the Extension Turns Browser Activity Into Test Drafts
The workflow begins in Chrome's side panel. The user starts a bug session and grants the extension access to the relevant website when recording begins.
The user then reproduces the issue naturally. During the session, the extension records supported interactions, including clicks, form inputs, selections, and navigation.
The user can also add assertions, provide a bug title, document the expected and actual results, and optionally capture screenshot evidence.
After recording, the collected information can be reviewed and used to generate two artifacts.
1. A structured Markdown bug report
The first output organises the captured information into a report containing reproduction steps, expected and actual results, technical notes, and available evidence.
The report can serve as a starting point for issue trackers such as GitHub Issues, Jira, or Linear.
Its value is not simply that it saves time writing documentation. By preserving the sequence of interactions and relevant context, it can help another developer understand what happened and investigate the problem more effectively.
2. An editable Playwright TypeScript test
The second output is a Playwright TypeScript .spec.ts test draft based on the recorded interactions and assertions.
Instead of reconstructing the entire interaction sequence from scratch, the engineer receives an initial structure that can be reviewed, edited, and adapted to an existing Playwright project.
However, the generated code is not automatically a complete regression test. The engineer still needs to check whether the locators identify the correct elements, whether the assertions represent the original failure, and whether the test has the necessary data and environment configuration.
This review stage is essential. A test that replays the recorded clicks may execute successfully without verifying the behavior that originally made the scenario a bug.
For Orhan, the generated artifacts are starting points rather than guarantees. The purpose is to make the work easier without suggesting that recording alone can replace careful test design.
Engineering Decisions: Keeping the Workflow Local and Inspectable
QA Bug → Regression Test is built with TypeScript, React, WXT, and Chrome Extension Manifest V3. Its side-panel interface allows users to work with the extension without leaving the website they are testing.
The architecture must support several connected responsibilities: observing interactions on an active website, maintaining a recording session, collecting relevant information, and generating downloadable artifacts.
Browser permissions are another important consideration. The extension requests site access when a recording begins rather than treating every page as an unrestricted source of data.
Orhan also chose to keep the core recording and generation workflow local. The current version does not require an account, backend, or cloud synchronisation to create reports and test drafts.
This simplifies the architecture and keeps recorded sessions in the browser. It also means users must remain attentive to what they review and share, particularly when reports contain screenshots or captured information from real applications.
For test generation, Orhan favours predictable and inspectable output over claims of complete automation. Playwright provides the target framework for a TypeScript-based browser regression-testing workflow, while the generated test remains editable so engineers can make the necessary adjustments.
These decisions reflect a deliberate trade-off: a focused tool with clear boundaries can be more useful than a broader tool that implies it supports every possible browser interaction.
The Hardest Part: A Recording Is Not the Same as a Test
One of the most important lessons from developing QA Bug → Regression Test is that browser actions alone do not provide everything needed for reliable automated testing.
A recording may accurately capture a sequence of interactions while still producing an unreliable test.
For example, a test might depend on a particular authentication state, user permission, backend record, or initial application configuration. Those conditions may not be recreated by recording clicks and form inputs.
Locators introduce another challenge. If several elements have similar labels or appearances, a generated selector may identify the wrong element. Timing-sensitive behaviour and interactions involving frames, popups, or new tabs can also be more complicated than straightforward actions in the main browser frame.
Orhan approaches these problems by separating the stages of the workflow:
- Capture: What interactions and information did the browser session actually record?
- Representation: How is that information stored and described within the session?
- Generation: How does the extension transform the captured information into a report or test?
- Validation: Does the resulting output accurately represent the original behaviour?
Separating these stages helps identify where information may have been lost or where an assumption has been introduced.
When a scenario cannot be represented reliably, Orhan prefers to expose the limitation or require manual adjustment rather than silently generate code that appears more complete than it is.
Meaningful assertions matter more than replaying clicks
A regression test should preserve the reason a bug matters, not merely reproduce the sequence of actions that preceded it.
Consider a form that accepts an invalid value when it should reject it. A recorded test might successfully fill out the form and click Submit. But unless the test checks the relevant validation behaviour, it has not established that the original problem is covered.
The same principle applies to locators, test data, and starting conditions. A reliable test must identify the intended elements, represent the expected behaviour, and run in the environment where it will be maintained.
Before incorporating a generated test into a suite, Orhan recommends reviewing:
- Starting conditions: The base URL, user state, permissions, fixtures, and required test data.
- Locators: Whether selectors consistently identify the intended elements.
- Assertions: Whether they verify the behaviour that originally made the scenario a bug.
- Test data and privacy: Whether placeholders have been replaced with safe values and real credentials have been excluded.
- Execution and stability: Whether the test runs successfully in the intended project and remains stable when repeated.
Warnings, unsupported steps, skipped interactions, and data placeholders also deserve attention. Some scenarios will require additional setup or manual correction before the generated code becomes useful.
This approach recognises an important boundary in automation: reducing repetitive work is valuable, but hiding uncertainty can undermine the reliability of the entire testing process.
Privacy and Responsible Browser Recording
Recording browser activity introduces privacy considerations, particularly when sessions involve real users, accounts, or sensitive application data.
QA Bug applies rule-based redaction to recognised sensitive values and uses placeholders where appropriate. However, Orhan acknowledges that detection is not exhaustive. Screenshots and other captured information may still contain private data.
That limitation makes review an essential part of the workflow. Users should inspect both the generated report and the test draft before sharing them or incorporating them into a project.
Keeping the core workflow local reduces the need for a backend or cloud synchronisation to generate the artifacts, but it does not eliminate every privacy risk. Information can still be exposed when users export, copy, or share captured material.
The practical lesson is to treat generated reports and tests as material that requires inspection, not as automatically safe outputs.
For tools that operate inside a browser, permissions, data handling, and transparent limitations are part of product quality—not details that can be postponed until later.
Using AI Without Giving Up Engineering Judgment
Beyond test automation, Orhan uses ChatGPT, Claude, and Gemini to explore implementation options, clarify unfamiliar concepts, brainstorm solutions, draft documentation, and accelerate repetitive coding tasks.
He finds these tools particularly useful when developing an initial implementation or comparing different approaches.
However, he does not treat an AI-generated answer as proof that a solution is correct. Generated code still needs inspection, execution, and testing. An API can be used incorrectly, an edge case can be missed, or an implementation that appears reasonable in isolation may not fit the actual project.
For tasks involving precise behaviour, security, browser permissions, or test reliability, he relies on conventional engineering practices: examining the code, running the application, verifying the result, and reproducing failures.
His approach is straightforward: AI can accelerate development, but responsibility for technical decisions and validation remains with the developer.
The level of verification should also match the risk. A draft used for brainstorming does not require the same scrutiny as code intended to run in a production testing pipeline.
This principle connects his work on AI-assisted development with his work on QA automation. In both cases, a generated output is useful only when it can be evaluated against the actual requirements and supporting evidence.
MindContext: Making AI-Assisted Research More Organised
Orhan's interest in practical browser tools extends beyond software testing. Another Chrome extension he built, MindContext, addresses a different problem: managing research context across webpages and AI conversations.
Developers and researchers often collect information across browser tabs, notes, files, and conversations with different AI assistants. Over time, it becomes difficult to remember where a claim originated, why a source was useful, or which details should be reused in a new conversation.
Copying raw URLs into an AI assistant does not guarantee that the assistant will retrieve the correct information. A page may be inaccessible, dynamically rendered, behind authentication, or too large to process as expected. Even when some content is retrieved, important details can be missed and findings can become separated from their original sources.
Orhan's preferred alternative is to provide deliberately selected context: relevant notes, important excerpts, source URLs, the task's goal, and any constraints that matter.
MindContext is intended to help keep research notes and quotations connected to their original webpages and make relevant context easier to reuse across ChatGPT, Claude, and Gemini.
The approach is guided by four principles.
Source traceability keeps notes and quotations connected to the webpages they came from.
Purposeful organisation groups information by research project or task rather than allowing everything to accumulate in one large collection.
Controlled context transfer lets users choose which information is relevant to a particular AI conversation.
User control allows people to review the context before sending it, rather than automatically submitting information they have not checked.
These principles reflect the same concern that shapes his testing tools: information becomes more useful when its origin and limitations remain visible.
For AI-assisted research, organised context can improve the quality of the work, but it does not remove the need to verify sources or evaluate conclusions.
Evaluating Accuracy Through Evidence
Whether generating a regression test or organising research for an AI assistant, Orhan starts by identifying what the output is supposed to establish.
For QA Bug, the questions are practical: Does the report accurately describe the observed behaviour? Does the generated test verify the expected result? Are any interactions missing or unsupported? Have sensitive values been handled appropriately?
For AI-assisted research, the equivalent process involves checking factual claims against relevant sources, revisiting original quotations, and distinguishing evidence from interpretation.
Fluent wording is not a substitute for proof. If a claim cannot be supported by the available information, it should not be treated as established merely because an AI assistant presents it confidently.
This approach also reinforces the importance of traceability. A useful report should help someone return to the original reproduction, while a useful research note should help someone return to the original source.
In both situations, the goal is not to eliminate human review. It is to make that review more focused and effective.
One lesson has had a particularly strong influence on Orhan's approach to software development: a useful tool does not need to automate every possible case.
A tool can deliver value by handling a clearly defined set of scenarios, explaining its limitations, and helping users complete a task more quickly or consistently.
That principle has shaped how he positions QA Bug. Rather than presenting generated code as a guaranteed, ready-to-run solution, he treats it as an editable draft that needs review.
It also influences how he thinks about product development more broadly. The implementation should be clear about what it captures, what it generates, and what the user must still verify.
For developers building similar tools, his experience highlights several practical lessons:
- Start with a specific, repetitive problem rather than attempting to automate an entire workflow at once.
- Preserve the context needed to understand and reproduce the original problem.
- Make generated outputs editable and inspectable.
- Distinguish recorded actions from verified behaviour.
- Surface unsupported cases and uncertainty instead of hiding them.
- Treat privacy and data handling as part of the workflow.
- Match the depth of validation to the consequences of an error.
These are not arguments against automation. They are reasons to design automation around the actual needs of the people using it.
Advice for QA Engineers Moving Toward Automation
For QA engineers who want to move beyond manual bug reproduction, Orhan recommends starting with a small, repeatable scenario rather than trying to automate an entire application immediately.
When a bug is discovered, the first step is to document the conditions required to reproduce it. The expected and actual results should be clear, and the engineer should identify the assertion that would demonstrate the failure.
From there, the next steps are to build a focused regression test, verify its locators and test data, and run it in the environment where it will be maintained.
This sequence keeps the test grounded in an understandable problem.
Automation works best when the underlying test case is clear. It cannot replace knowing what should happen or why a particular behaviour is incorrect.
The same advice applies when AI tools are involved. Generated code can provide a useful starting point, but the engineer must still determine whether the implementation is correct, whether the test proves the intended behaviour, and whether the result is reliable enough for its intended use.
What's Next: Less Repetitive QA and Better Engineering Workflows
Orhan remains interested in making the transition from manual QA to automation less repetitive, improving how browser interactions are captured and represented, and handling scenarios that require more context than a simple sequence of actions.
He also wants to continue exploring tools that combine browser workflows with practical AI-assisted development and research.
His broader goal is to build focused tools that solve real problems in everyday engineering work, learn from people using them, and improve them through concrete feedback.
As an independent developer, he sees each project as an opportunity to learn. Publishing tools and discussing their limitations openly are part of that process.
His work offers a useful perspective on the relationship between automation and engineering judgment. The best tools do not necessarily remove every manual step. They preserve useful information, reduce unnecessary repetition, and help people make better-informed decisions.
For QA engineers, that means turning bug reproduction into a stronger foundation for regression testing. For developers using AI, it means organising context and checking evidence rather than relying on plausible-sounding answers.
Across both areas, Orhan's guiding principle remains consistent: automation should make work more efficient without making the results harder to trust.
About Orhan Eren Kara
Orhan Eren Kara is a QA engineer and independent Chrome extension developer based in Türkiye. He graduated in Management Information Systems from İzmir Democracy University in 2025 and works with software testing, test automation, browser workflows, and AI-assisted tools.
His projects include QA Bug → Regression Test, which helps turn recorded browser interactions into Markdown bug reports and editable Playwright TypeScript test drafts, and MindContext, which helps organise research notes and quotations connected to their original webpages for reuse across AI assistants.
Developer Stories is a CoderLegion interview series highlighting the people, ideas, projects, and engineering decisions behind software development.
