Software quality · Automation · Engineering

Quality first.
Release ready.

I’m Itay Gurwitz. I bring a developer’s mindset, systems thinking, and automation together to help teams release software with confidence.

Explore my work How I work
Experience across automation, QA, and software development
Quality across the development cycle
Test strategyAutomationFast feedbackConfident releases
Articles

Automation keeps
rewriting itself.

A three-part series on how testing tools change as the software we build changes. Starting with a short history, from desktop scripts to AI agents.

QTPTestCompleteSeleniumPlaywrightAI agents

ARTICLE 01 / 03Automation history

From QTP to Playwright agents: the changing story of test automation

Every generation of automation solved one set of problems and exposed another. Here’s the path from fragile desktop scripts to browser automation—and now to agents that can help plan, write, and repair tests.

Read the article

When every click had to be taught

Early UI automation asked scripts to reproduce exact clicks, coordinates, and timing. A small layout change or a slow machine could break a run. Teams spent time nursing brittle scripts, retrying failures, and separating real defects from timing noise.

The desktop era: QTP and TestComplete

Tools such as QuickTest Professional (QTP) and TestComplete brought recording, scripting, and GUI checks closer to everyday QA work. They helped teams move beyond manual repetition, but suites still depended on installed applications, known screens, and carefully managed test environments.

The browser changes the job

As more products moved into the browser, the test surface changed. Teams needed to cover navigation, dynamic pages, and multiple browsers while keeping tests useful across languages and environments.

Selenium opens the web

Selenium began in 2004 as an internal web testing tool called JavaScriptTestRunner, then grew into an open project and a broad browser automation ecosystem. Its flexibility let teams choose languages and run tests across browsers and grids. The tradeoff was that each team often had to assemble more of the surrounding setup: drivers, waits, isolation, and reporting.

A new baseline with Playwright

Playwright brought more of that support into one experience: automatic waiting for elements to be ready, isolated browser contexts, multiple browser engines, and traces that help explain a failure. For teams tired of wiring those pieces together, older Selenium setups could start to feel like too much plumbing. Selenium remains capable and widely used; the bar for convenient defaults and diagnostics simply moved.

Now the agents can help

Playwright’s test agents add a new loop. A planner explores an app and drafts a test plan, a generator turns it into tests, and a healer can run the suite and repair failing tests. That opens room for AI-assisted scenario creation, test data, failure grouping, and result summaries—while keeping proposed changes visible for an engineer to review.

The next chapter

No tool removes the need for judgment. The work shifts toward guiding the agents, checking that a “healed” test still protects the intended behavior, and keeping every test connected to product risk. Automation keeps changing; the goal stays the same: trustworthy feedback that helps a team release with confidence.

Further reading

WinRunner + QTPOpen sourceAI subscriptionsLocal models

ARTICLE 02 / 03Automation economics

From Test Licenses to AI Subscriptions: The Automation Pendulum

Automation’s business model has swung from paid specialist suites to open frameworks—and now toward recurring AI services. The new turn also has a local route.

Read the article

When automation came with a license

For years, automation was sold as specialist software. WinRunner and QuickTest Professional (QTP) brought recording, replay, and result checks to QA teams, usually alongside vendor licensing and support. In a 2008 retirement notice, HP offered a migration path from WinRunner to its Functional Testing suite, which included QTP. Some license conversions required active annual support.

Open source changes the economics

Selenium began at ThoughtWorks in 2004 as an internal tool and moved toward an open project. Its history describes teams using it on commercial projects and contributing improvements back. Developers could build around libraries that fit their languages, applications, and CI pipelines. Selenium and Playwright can run browser tests locally or in CI, without a separate test-authoring license—while teams take on more responsibility for their code and infrastructure.

AI brings subscriptions back into view

AI can draft test code, turn written workflows into test steps, suggest locators, and help update tests as interfaces change. People still need to choose what matters and review generated tests. Testim describes an AI-based testing platform and directs customers to its plans; GitHub’s June 2026 update says Copilot plans use usage-based AI Credits. The examples show how AI features and recurring service costs are converging, though product packaging can change.

The product changed as the pendulum swung

Earlier products bundled test-authoring software and vendor support. Newer subscriptions can package AI assistance, hosted inference, cloud execution, parallel runs, collaboration, and reporting. Teams may be paying for an ongoing service around automation, as well as for the platform itself.

A local route without a paid AI subscription

A subscription is one option, not a requirement. Qwen3.8-27B’s model card lists an Apache 2.0 license. A team can run it locally with Ollama, pair it with the open-source coding agent DeepSeek Harness, and use Playwright as the test runner. Ollama’s guide gives this launch command:

The agent can inspect a project, propose or write a test, and help refine it after a failed run. Playwright then executes the test locally, and a person reviews the result. Local inference can avoid a per-seat AI subscription; the team supplies suitable hardware, manages setup, and maintains the tests. Ollama lists the Qwen3.8 27B model at about 18 GB, so storage and capable hardware matter. DeepSeek Harness is currently a developer preview, so its setup may change.

ollama launch dsh --model qwen3.8

Check what still calls the cloud

A local model does not make every connected feature local. Ollama says DeepSeek Harness web search is enabled automatically and requires access to Ollama’s cloud. Teams aiming for a fully local workflow should review the harness settings and keep web search and other remote services out of the path.

A mixed future

The likely future is neither a return to proprietary test suites nor a requirement that every team pay for AI. Commercial platforms can sell convenience and managed services; open frameworks and local models can give teams more control over cost, data, and customization. The useful question is which parts of the stack a team wants to operate—and which it would rather subscribe to.

Further reading

IdeaDraftRunRefine

ARTICLE 03 / 03AI-assisted automation

Don’t Let a Token Limit Interrupt the Test

How local AI can help test automation ideas keep moving

Read the article

Good automation grows through iteration

The best ideas rarely arrive on schedule. They surface while exploring a product, watching someone struggle through a workflow, or seeing the same regression slip through again. Turning that spark into a reliable test takes focus: inspect the code, choose a scenario, write and run the test, learn from failure, and refine.

When the token limit stopped the work

I was in the middle of a promising idea when my five-hour token allowance ran out. I could pay for a more expensive subscription and continue, or wait for the limit to reset and work on something else. The interruption did more than delay me: it broke the thread of the work.

Convenience has a continuity cost

Hosted subscriptions provide powerful models without asking a developer to manage hardware. But when a usage limit arrives mid-task, it puts a price on uninterrupted exploration. In test automation, useful results often come after several rounds of trying, checking, and improving. An interruption can cost momentum as well as time.

A local model can keep the iteration going

A practical stack can pair Qwen3.8-27B, running locally through Ollama, with DeepSeek Harness, an open-source coding agent, and Playwright as the test framework. Ollama documents launching the harness with a Qwen model; its registry lists a 27B variant.

The harness can help explore a codebase, draft a Playwright test for a user journey, and revise it after a local run reveals a problem. Playwright runs on a developer’s machine as well as in CI, so a cloud testing service does not have to be part of the basic loop. The feedback cycle still needs a tester: describe the behavior, run the proposed test, and check that its assertions would catch a real failure.

ollama launch dsh --model qwen3.8:27b

Local also means local trade-offs

With local inference, a hosted-model token allowance cannot run out mid-session. You can keep exploring at your own pace. The setup is not cost-free: the model needs suitable hardware, uses electricity, and may respond more slowly than a hosted service. Ollama lists Qwen3.8-27B at about 18 GB, a reminder that local AI has real storage and hardware requirements.

Know where the cloud still appears

DeepSeek Harness is described as a developer preview, and Ollama’s guide says web search is enabled automatically and requires its cloud. Teams that want prompts and code to stay on the machine should configure the workflow with those boundaries in mind and keep remote features out of the path.

Choose continuity as well as capability

Hosted subscriptions offer convenience, high-end models, and managed infrastructure; local models offer more control over where and when inference runs, in exchange for setup and maintenance. The choice is not only about quality or price, but also about how a team wants to work. AI should help move an idea toward a useful, reviewed test—not become another reason to stop halfway through. With a local model, DeepSeek Harness, and Playwright, teams can keep experimenting while the idea is still fresh.

Further reading

The approach

Quality isn’t a
final checkpoint.

Quality comes from small decisions throughout development: what to test, where to test it, and how to help the team understand what happened.

The goal is useful, maintainable coverage that gives clear answers, adapts to change, and helps teams move forward with confidence.

More about my experience
01

Understand the system

Learn the risks, dependencies, and user journey before deciding what to automate.

02

Build a safety net

Place tests where they give the team fast, useful feedback.

03

Improve as you go

Keep automation readable, stable, and relevant as the product changes.

Expertise

From strategy
to CI.

Quality looks different in every product. The right approach depends on the risks, the pace, and the people building it.

AI testing & integration

Tests that
heal themselves.

Self-healing tests can adapt selectors as interfaces evolve. AI can also draft scenarios, generate test data, group related failures, and summarize results—integrated into CI with reviewable changes and human approval.

Self-healingAI scenariosTest dataFailure triageCI integration
TOOLS & TECHNOLOGIES
PlaywrightTypeScriptPythonJavaC# / .NETSeleniumJSystem
Experience

Experience across
the whole system.

My work spans QA, automation, and software development, with a close-up view of the challenges on each side.

Current · Revuze

Automation in a product environment

At Revuze, I work on automation for an AI platform that analyzes customer reviews at scale. I help make the systems that distinguish genuine customer experiences from engineered or incentivized reviews reliable, so brands can make decisions from a signal they trust.

Across my career · QA & automation

From test infrastructure to regression

Across QA and automation roles, I have built regression coverage and frameworks for complex products—from QTP-based object-oriented testing and JSystem to Selenium and Playwright. I take work from understanding workflows and risks through writing tests, investigating failures, and maintaining the suite. I also share practical guidance on moving Selenium teams to Playwright, including TypeScript and AI tools.

Software development · Complex systems

Systems thinking, close to the code

My software engineering background includes Java, C# / .NET, and web development. It helps me read and contribute to application code, work with developers to diagnose root causes, and shape automation around a system’s architecture and delivery workflow—not just its visible interface.

✳Graduate of the Open University of IsraelOPEN UNIVERSITY OF ISRAEL
Start a conversation

Building something
worth trusting?

I’d like to hear what you’re building and what challenge comes next.

Connect on LinkedIn