IT systems testing *

A normal code review comment usually sounds harmless.

Rename this variable. Move this method. Add a test. Remove the duplicate condition. But sometimes an experienced developer leaves a much shorter comment: No.

Not maybe. Not could we simplify this. Just a clear rejection of the entire approach.

For a junior developer, this can feel strange. The code compiles, tests pass, the implementation is readable, and the ticket requirements seem complete. Why throw it away?

I started saving such cases after one of my pull requests was rejected for the third time in a week. The goal was not to prove that the reviewer was wrong. I simply wanted to understand what experienced engineers noticed before everyone else.

Over several months, I collected review discussions from backend services, internal tools, queue consumers, APIs, and data-processing jobs. I removed comments about formatting and naming. Only full design-level rejections remained.

The result was a small catalogue of professional paranoia.

And honestly, most of it was useful.

Deleting code sounds easy until the code belongs to a running product.

A function may have no direct callers but still be loaded through a plugin registry. A serializer may look duplicated but quietly preserve an old field name used by one customer. A command may not appear in analytics because it runs from cron at 3:10 a.m. on the first Sunday of each month. Python makes this even more fun because imports, decorators, entry points, reflection, monkey patches, and strings can all become hidden edges in the dependency graph.

The project in this story was a multi-tenant reporting backend written in Python. It accepted events, stored normalized records, generated reports, exported CSV and JSON files, and delivered them through HTTP, email, and object storage. Nothing huge. Around 140 API endpoints, 46 background tasks, PostgreSQL, Redis, and a queue.

The repository contained 62,914 lines of Python excluding tests and migrations.

That number was not the actual problem. The problem was that a small change in report filtering could require edits in the API schema, a service class, a repository, a filter translator, a query builder, an export adapter, and several nearly identical tests. The system had layers, but the layers did not reduce complexity. They distributed it.

The first plan was a rewrite. Fortunately, that plan died before production did.

Instead, the question became much simpler: How much code can disappear while externally observable behavior remains unchanged?

That wording changed the whole project.

At some point, ChatGPT stopped feeling like a tool and started feeling like a reflex.

Need a parser? Ask ChatGPT.
Strange exception in a background worker? Ask ChatGPT.
Forgot how a lock behaves under contention? Ask ChatGPT.
Need to rename a method? Apparently, that also required artificial intelligence.

Nothing looked wrong on the surface. Tasks were moving. Pull requests were getting merged. The code usually worked. Sometimes it even looked cleaner than what I would have written from scratch. But there was a small problem. A few days later, I often could not explain why a certain solution was built that way. I remembered the task, the final code, and maybe the prompt. The reasoning in between was missing.

That bothered me more than I expected.

So I set a simple rule: for six months, no ChatGPT, no Copilot Chat, no AI-generated code pasted into production. Documentation, source code, issue trackers, books, debuggers, profilers, and search engines were allowed. AI assistants were not.

The experiment started as a way to test my own dependence. It ended up changing how I design APIs, debug systems, read unfamiliar code, and even write comments.

Despite the annual summer lull, July unexpectedly saw a rise in the percentage of companies with open job listings—even for roles like Manual QA.

Unfortunately, the Tech Hiring Activity Index for June doesn’t bring any particularly good news.

However, there is a compelling trend: just two months ago, roughly three times as many US tech companies were hiring for classic manual QA as for dedicated AI testing roles. That gap has now narrowed to two to one.
But don’t let the growth rates fool you. While dedicated AI roles – those where AI is the deliverable, whether that means building, testing, and evaluating models or developing applications on top of ready-made ones, rather than merely using AI tools to support other work – are emerging, they are doing so from a very low baseline and still represent a tiny fraction of the overall tech job market.

Why I built Requester, a real-time HTTP load testing app for macOS, and what Swift structured concurrency taught me about telling the truth under load.

I wanted to hammer an HTTP endpoint and see what happened. Not read a summary report three minutes later — watch it, live, the way you watch a profiler.

The existing options are great but they all live in the terminal: wrk, hey, k6. I love them, but I kept wishing for a native window with a chart that moved. So I built one for macOS, in Swift and SwiftUI, and called it Requester.

This post is less “here are the features” and more “here are the three things I made building it.” The most interesting one: making the tool honest about backpressure turned out to be a design decision, not an accident.

My name is Vladimir Smirnov, and I am responsible for testing the trading backend at EXANTE. Development moves fast. Regression suites grow. With them come the chaos and inconsistency of test environments, and a steady rise in unstable failures, known as flakes. Real problems hide behind those flakes. How do we keep our automated tests in acceptable shape without spending too much time on it? That is what this article is about.

Our test framework broke as services grew. We redesigned it with clear layers to scale tests, reduce coupling, and support SDKs and AI.

Every prompt is a gamble. Your AI writes code that compiles, looks right, and silently breaks things you already built. Tests catch it before your users do. The best part? Your AI can write the tests for you.

~206 символов. Добавил "compiles, looks right" из A для конкретики, убрал "And here's the thing" на более кликбейтное "The best part?".

Добавить в начало статьи?

Regular expressions (also called regexp, or regex) are a mechanism for finding and replacing text. In a string, a file, multiple files... They are used by developers in application code, testers in autotests, and even just when working on the command line!

Why is this better than a simple search? Because it allows you to specify a pattern.

For example, you receive a date of birth in the DD.MM.YYYYY format. You need to pass it on, but in the YYYY-MM-DD format. How can you do this with a simple search? You don't know in advance what the exact date will be.

My name is Anatoly Bobunov, and I work as a Software Development Engineer in Test - or SDET for short - at EXANTE. When I joined one of our projects, I discovered that several of our test suites took more than an hour to run - painfully slow, to the point where running them for every merge request was simply unrealistic. We wanted fast feedback on each commit, but at that speed, it just wasn’t going to happen.

Eventually, through a series of small but precise improvements, I managed to speed things up to 8.5× faster, without rewriting the tests from scratch. In this article, I’ll walk through the bottlenecks we found and how we fixed them.

From outsourcing to product: a QA engineer’s honest journey to better releases, healthier work culture & real impact on the product.

During load testing of Tantor Postgres databases or other PostgreSQL-based databases using the standard tool pgbench, specialists often encounter non-representative results and the need for repeated tests due to the fact that details of the environment (such as DBMS configuration, server characteristics, PostgreSQL versions) are not recorded. In this article we are going to review author's pg_perfbench, which is designed to address this issue. It ensures that scenarios are repeatable, prevents the loss of important data, and streamlines result comparison by registering all parameters in a single template. It also automatically launches pgbench with TPC-B load generation, collects all metadata on the testing environment, and generates a structured report.

We all strive to build better software, and to do it faster. I believe Test-driven Development offers us a path towards this goal. Still struggling to efficiently utilize this approach? Then I invite you to discuss my tips and tricks to unlock the benefits of TDD!

This article explores the concept of equivalence classes from the perspective of mathematical analysis and their application in QA testing. The author explains how properly defining equivalence classes helps optimize test design, reducing the number of test cases while maintaining thorough verification.

Using the example of currency conversion from rubles to euros, the article demonstrates how to construct equivalence classes, verify their compliance with mathematical properties (reflexivity, symmetry, transitivity), and identify errors in data partitioning.

This article is useful for QA engineers, developers, and analysts who want to gain a deeper understanding of logical testing principles and improve the efficiency of their test strategies.

We are a brokerage platform operating in a dynamic and complex domain. This specificity comes with a set of challenges. On the one hand, it entails a high variability of scenarios and potentially significant risks associated with errors. On the other hand, it has short development iterations with frequent delivery cycles. 

In this article, we will share how we maintain the quality of our numerous backend services, which provide essential information to our trading terminals.

A story about evolving our CI process for a monolithic Python repo with tests, challenges faced, and solutions. Discussing Docker, linters, Allure TestOps, and more.

Hi, I’m Nastya, the Product Owner of EXANTE’s desktop and web trading terminals. I began working at the company nearly five years ago as a Junior QA Engineer. Since then, I’ve advanced to QA Lead and ultimately to Product Owner. In this article, I’d like to share my growth journey within the company and the steps that helped me progress. I hope that my story will be helpful to those seeking to advance their careers but are unsure where to start.

In today's fast-paced world of software development, integrating third-party APIs and services is a common practice. These integrations can enhance functionality, improve user experience, and provide additional features that would be time-consuming and costly to develop in-house. However, ensuring these integrations work seamlessly with your software is crucial, and this is where the importance of a test environment, or sandbox, comes into play.

A sandbox environment allows developers to test the integration between their software and third-party services without risking the stability and security of the production environment. This controlled setting enables thorough testing, helping to uncover issues before they affect end-users. By covering as many test cases as possible, developers can ensure robust and reliable integrations.

But what if your third-party provider, such as a bank or government e-system, does not offer a sandbox environment? This scenario can pose significant challenges, but there are several strategies you can employ to mitigate these issues.

Hello everyone, my name is Denis, I am Software Developer Engineer in Test (SDET) at Bimeister. I am in charge of test software development - frameworks, automated tests, CI Pipelines configuration, and much more.

In this article, I will tell you how we defeated the Stale Element Reference Exception while developing our framework using Selenium WebDriver and C#.