Artem Golubev would like your tests to stop needing repairs

Artem Golubev has a particular objection to busywork: it can arrive disguised as progress. A team automates a software test, celebrates the time saved, then spends the next release repairing the test. The application has changed. The check has taken offence. Soon the people hired to find defects have acquired a second occupation, looking after the machinery that was supposed to help them.

It is a good subject for an engineer with a long memory. Golubev, the co-founder and CEO of testRigor, has made reducing that upkeep a business. The company lets people describe automated tests in plain English, with instructions framed around what a user wants to do. Underneath the approachable language sits an argument about where technical expertise belongs, and how much of a working day a tool is entitled to consume.

The repair bill behind the release

His route into the subject began with building software for logistics companies. Later came Microsoft, AppDirect and Salesforce. Those settings gave him experience of software development at different scales, along with repeated encounters with the difficulty of creating and maintaining automated checks. The frustration accumulated across jobs. A familiar inconvenience became something he thought a company ought to solve.

At Salesforce, he held a senior engineering management role. That detail helps explain why his argument extends beyond the person writing a test. Maintenance occupies people, and people occupy a budget. An engineering manager has to decide what a team can finish with the hours available. Every check requiring another repair competes with a feature, another test or a closer look at an actual failure.

There is an everyday absurdity here. Software changes because someone wants it improved; the checking apparatus then demands attention because the software changed. Golubev’s career supplied ample reason to take that cycle seriously. The founder’s question is whether a test can stay attached to the job the customer wants done, even as developers rearrange the means of doing it.

An engineer makes the case for fewer scripts

Consider a shopper adding an item to a basket. The shopper cares about finding the item and seeing it in the basket. The technical identifiers behind the buttons are somebody else’s concern. Golubev wants automated tests to describe that visible task, so that a change behind the interface does not automatically create another job for the person maintaining the check.

In this approach, a tester writes the intended interaction in ordinary language and the platform carries out the steps. The distinction matters to him because manual testers already possess knowledge of the application. Requiring those people to become programmers before they can contribute automation imposes an additional condition on expertise they already have.

His ambition puts an experienced engineer in the position of arguing for less code in the tester’s hands. There is no contradiction in that. A useful abstraction lets someone work at the level of the problem they understand. Few shoppers wish to inspect a checkout’s internal structure before buying a book. Few testing teams would object to spending less time identifying a button that everyone can see.

Golubev’s product argument is also deliberately about maintenance over time. Creating a check is only the opening transaction. Its usefulness depends on surviving subsequent changes while still detecting the failures that matter. That gives his work a less theatrical measure of progress than a quick demonstration: what happens when the team returns to the same tests after the application has been revised?

Away from the company, his public professional profile lists food-packing volunteer work at the SF-Marin Food Bank, beginning in December 2015. He describes sorting and packing food for distribution. It is a small, concrete detail alongside an otherwise technical career: work with an immediate purpose, where the contribution is measured in something more tangible than a presentation about future productivity.

First, persuade someone you know

Golubev co-founded testRigor in 2015. He and fellow founder Enzo Carlos Biancato had worked together at AppDirect as lead software engineers. Their early idea was discussed with quality assurance directors and engineering vice presidents. That relationship between technical colleagues matters: this venture grew from people familiar with the work, comparing an unsatisfactory practice with what they believed software could do.

The first customer story is agreeably unceremonious. The founders spoke to ten friends, signed them up and grew through word of mouth. It is a modest beginning for an automation business, and a reminder that a new tool still needs an introduction. Trust can get an unfamiliar product into a conversation long before a marketing department has learned how to describe it.

Customers also helped change the description. The company initially emphasized autonomous testing, then adjusted its language when customers explained which value mattered to them. That is an instructive concession from people capable of building the machinery. The feature that interests its maker may differ from the benefit that persuades someone to keep paying for it.

By Summer 2021, testRigor was part of Y Combinator. Golubev continued doing the explanatory work himself: demonstrations, conference appearances and conversations about the practicalities of automation. A founder in this business has to sell an unfamiliar way of working as well as a product. The customer must understand what changes on Monday morning, after the promising presentation is over.

He also participates where testers gather to exchange practical advice. In April 2023, he joined a Ministry of Testing discussion about using AI for automation, pointing readers to a demonstration and identifying himself as a co-founder. The disclosure suits the setting. Among practitioners, a founder arrives with something to sell and an explanation that other people are free to examine.

The Update button has a lesson

One of Golubev’s demonstrations offers a useful antidote to the notion that ordinary language removes every difficult decision. A recorder suggests how to identify an Update button. The nearest text can guide that suggestion, although the person using the page understands the button through the section it belongs to. The recorded instruction may need rephrasing to capture that intention.

Golubev tells users to review those suggestions. The tool’s first account of an action is something to inspect. That small example gives his promise a practical boundary. A person must still express the task clearly enough for it to be useful. A sentence can carry ambiguity just as efficiently as it carries instructions.

His demonstrations of autonomous generation introduce another distinction. A crawler can explore an application, while usage analytics can help generate checks around journeys people actually take. In his explanation, a complex web page presents many possible actions, making it harder for a crawler to select the path the team cares about. Popular user flows provide a different way to choose.

These are questions of attention as much as execution. Which route deserves a check? Which result tells the team something useful? The existence of automation leaves those questions intact. Watching Golubev teach the product reveals a founder occupied with the details that determine whether an attractive principle survives contact with an actual application.

Who checks the checking company?

The argument becomes rather more entertaining when turned towards testRigor itself. A business asking customers to trust its checks must consider how it checks its own work. Golubev has described an engineering operation with 50,000 unit tests and six or seven quality gates before production. AI-generated code still receives human review.

“We can't have bugs.”

Artem Golubev, on the demands of building a testing system

The remark expresses an obligation rather than a literal guarantee. Every defect in a testing product has an awkward second meaning: the customer is relying on that product to help discover defects elsewhere. There is little room for the charming excuse that the shoemaker has been too busy to repair his own shoes.

The company evaluated more than fifteen AI review tools before selecting CodeRabbit as an additional layer. Golubev’s account emphasizes better review quality. Human sign-off remains part of the process. This is a revealing qualification in a career spent advocating automation: help earns its place by improving the work, and people still carry responsibility for the result.

By January 2026, his public conversation still centered on maintenance, coverage and widening access to test creation. Generative AI supplied new ways to pursue that agenda. The continuity matters when considering his career: the vocabulary around a software company can change rapidly, while the work that persuaded its founder to start it remains recognizably the same.

A larger job for the people already there

Across his public teaching, Golubev returns to the existing manual QA workforce. These people know the application, its expected behavior and the journeys worth protecting. He wants them to bring that knowledge into automation without first passing through an engineering apprenticeship. In that ambition, the person using the testing tool matters almost as much as the person using the application.

His conference work extends the conversation to product management. A 2023 engineering leadership roundtable addressed generative AI and productivity; a 2024 paper explored test automation, product management and the development lifecycle. The scope follows naturally from his original complaint. Once testing effort affects delivery, it becomes a question for whoever sets priorities and decides what a team should attempt.

Golubev’s story has the persistence of a problem that refuses to stay solved by ordinary means. He has kept returning to the same expense from different seats: developer, engineering manager, founder and teacher. The aspiration is easy to understand without a technical glossary. Let people specify what should work. Give them useful evidence about whether it does. Leave them more time to do something with the answer.