В телеграме QA Live | тестирование ПО
Дайджесты + Вакансии QA
Почитать:
Стратегии упрощения определений шагов BDD
Как тестировщик, вы, возможно, слышали о разработке через поведение (BDD) и окружающих ее спорах о том, что это, как это использовать и для чего. Вне зависимости от личного мнения о предмете, нельзя отрицать, что инструменты автоматизации тестирования, поддерживающие BDD, уже с нами. Они широко распространены в отрасли, и пока не собираются никуда уходить. В ходе моей карьеры значительная часть моей тест-автоматизации включала применение какого-либо BDD-фреймворка – например, инструменты вроде Cucumber или JBehave. Как человек, который программирует, я всегда интересовался рефакторингом, сокращающим количество стандартного или дублирующего кода – кода становится меньше, и он становится понятнее. Это включает и сокращение стандартного кода в методах определения шагов и прочем связующем коде. Как их упростить? Или вообще от них избавиться?
Внедряем простой мониторинг производительности в командах (на примере QA)
Анализ показателей по ключевым метрикам — то, что помогает командам принимать верные решения. Оперативно выявлять узкие места в процессах, оценивать их эффективность на разных этапах релизного цикла, равномерно распределять нагрузку между сотрудниками. Только как быть, если в вашей команде уже не 5 человек, а 15, и вручную отслеживать данные стало непросто? Вариант: заручиться поддержкой аналитиков и начать собирать данные по командам из таск-трекера, с последующей визуализацией на дашбордах. Как показала практика, это не быстрый, итеративный процесс — особенно когда нужно мониторить сразу несколько команд. Но в результате такой мониторинг может стать мощным подспорьем для роста показателей по метрикам и в целом выступать индикатором качества процессов. Под катом рассказываем, как мы начали (и продолжаем) централизованно мониторить эффективность нашего QA-направления. Поэтапно и с практическими советами.
Почему я перевел наш фреймворк автоматизации с JavaScript на TypeScript
TypeScript пользуется всеми преимуществами JavaScript и NodeJS и усиливает их – он поможет писать код, который легче читать и проще поддерживать. У него статическая типизация, классы, интерфейсы, типы, декораторы и поддержка IDE в режиме реального времени вроде Visual Studio Code. Типы позволяют JavaScript-разработчикам пользоваться высокопроизводительными инструментами и практиками разработки при создании JavaScript-приложений – например, статической проверкой и рефакторингом кода. Типы опциональны, вывод типов позволяет нескольким аннотациям типов сильно изменить статическую верификацию вашего кода. Типы позволяют определять интерфейсы между компонентами ПО и понять, как ведут себя существующие JavaScript-библиотеки.
Фича была простая: сделать возможность создавать ручные тест-кейсы не только через тест-план, а напрямую из библиотеки или секций, чтобы уменьшить количество кликов для создания тест-плана. Запрос пришел от пользователей.
Кнопка «Оплата» становится невидимой: как ошибки юзабилити сливают продажи
Как-то был проект, где наша команда тестировала интернет-магазин. Красивый, удобный – на первый взгляд. Всем очень нравилось, как всё аккуратно сверстано. Но когда дошли до мобилки, радость поутихла. Открываю мобильную версию и пробую пройти путь обычного пользователя. Образно говоря, почувствуй себя Шерлоком. Кнопка «Оплатить» была, да. Но чтобы её найти, надо было проскроллить через блоки с акциями, отзывами и чем-то ещё – и не пропустить. И эта гадость {«извините», – гнусаво сказал Слоненок} на странице, где уже оформлена (!!!) корзина. То есть человек решился купить, готов заплатить, и вдруг не может найти, как это сделать.
Лидерство в тестировании: инструменты
Эта серия предназначена для того, чтобы помочь тестировщикам с многолетним опытом работы, особенно в Agile командах, преуспеть в своей роли руководителя тестирования и менеджера.
В предыдущей статье мы рассмотрели инфраструктуру приложения и способы ее тестирования. В этой статье мы обсудим набор инструментов для тестировщика, о том, как выбрать между проприетарным и открытым исходным кодом, а также разберем краткое упражнение по выбору инструмента.
Команды по разработке ПО, работающие самостоятельно, используют более широкий набор инструментов, чем когда-либо прежде. В обычной команде по разработке ПО может быть двадцать или даже тридцать инструментов.
Отказаться от Postman, перейти на Bruno
Bruno предлагает новый подход к работе с API-коллекциями, выгодно отличаясь от конкурентов, таких как Postman, в первую очередь за счет локального хранения данных. Все коллекции и запросы хранятся как файлы на вашем диске, обеспечивая полный контроль над конфиденциальной информацией и позволяя использовать привычные операции с файлами, включая текстовый поиск и резервное копирование. Это также кардинально упрощает совместную работу: коллекции легко интегрируются с системами контроля версий, такими как Git, что позволяет командам бесплатно и эффективно отслеживать изменения, обмениваться запросами через pull-запросы, а также безопасно хранить учетные данные в файлах .env. Возможность автоматизации тестов с настройкой пререквизитов и добавлением ассертов делает Bruno мощным инструментом для проверки API, решая проблемы с контролем версий и безопасностью, характерные для облачных решений.
Как мы организовали генерацию SQL-запросов, проверку сложных данных
В статье опишем проблемы, с которыми сталкивались при ручном написании SQL-запросов и проверке данных: дублирование кода, сложность поддержки, отсутствие единого стиля и низкая информативность тестов. Для решения этих проблем мы разработали инструмент QueryBuilder, который позволяет динамически генерировать SQL-запросы с помощью Java-кода.
Мы создали иерархию классов CriteriaBasic и Table для удобного описания критериев поиска данных в базе, используя паттерн fluent interface. Также мы разработали кастомные классы проверок на базе AssertJ с поддержкой Allure-шагов, которые позволяют проверять сложные многоуровневые объекты с возможностью погружения во вложенные структуры. Для облегчения рутинной работы создали плагин, автоматически генерирующий классы DTO и Table на основе структуры базы данных. Библиотека интегрирована с Hibernate через DaoCommon, что обеспечивает удобное выполнение SQL-запросов и управление сессиями. Результатом стало существенное улучшение читаемости тестов, повышение переиспользуемости кода, стандартизация подхода к тестированию и создание информативных Allure-отчетов.
Мы тестируем систему ЦФТ-банка, где тестирование данных — это отдельная наука. Тестовые данные разбросаны по разным таблицам, и найти их — это целое приключение. В процессе работы сталкиваемся с некоторыми особенностями. Постоянная валидация данных в базе — сотни строк SQL-кода, которые постоянно дополняется новыми критериями — приводит к дублированию кода, из-за чего тесты становятся тяжело поддерживаемыми.
Также стоит учитывать, что наши заказчики — регрессионные тестировщики. Для них важно, чтобы Allure-отчёт был максимально похож на шаги в тест-кейсе, чтобы не пришлось гадать, что же именно произошло в тесте. Также этот инструмент должен решать задачи не только на уровне базовых проверок, но и на уровне кастомных бизнес-логик.
19 лет в айти, чтобы прикинуться джуном: как искать баги в приложениях с помощью ИИ
В статье расскажу про:
- ИИ для запуска тест-кейсов: автоматизация без глубоких знаний
программирования.- Обучение ИИ-генерации тест-кейсов: как ИИ помогает придумывать
сценарии.
- Обучение ИИ-генерации тест-кейсов: как ИИ помогает придумывать
- Написание баг-репортов с ИИ: создание чётких и технически точных
отчётов. - Эксплоративное тестирование с ИИ: поиск уязвимостей с подсказками ИИ.
- ИИ как учитель: фидбэк и обучение тестированию.
- Подводные камни ИИ для джунов: чего избегать, чтобы не плодить
ошибки.
Что не убивает, делает сильней: как мы тестируем СХД, «ломая» его по частям
Моя задача — не просто проверить, что СХД работает, а воспроизвести реальные риски отказа системы и проверить ее на устойчивость: высокая нагрузка, внезапные отказы компонентов системы, нестабильные внешние условия, например перебои в сети. В этом тексте расскажу, как мы тестируем отказоустойчивость СХД TATLIN.UNIFIED: какие сбои моделируем, как устроены автотесты и почему короткие прогоны не справляются с поиском критичных багов.
ПОТРАЧЕНО. Как тестировать локализацию переводов
Доступ к ресурсам — штука местами сложная. В большинстве компаний разработчики по тем или иным причинам боятся предоставлять доступ к ресурсам, если вдруг нужно внести какие-то правки. Они считают, что «нет такого переводчика, который не мог бы что-то сломать в ресурсных файлах». На самом-то деле эта проблема решается, если просто, сделать отдельный репозиторий или ветку в нём, где переводчики и будут ковырять всё то, что им нужно, и забирать потом оттуда готовые файлики.
Важность тест-кейсов вы и без меня понимаете — без них вам будет очень сложно, особенно, если вы используете билд-тестирование.
То же самое касается и качественного фидбека, потому что коммуникация с командой локализации — это и вправду важно. Бывает, что команды разработки и команды локализации существуют довольно обособленно друг от друга, и в таком случае коммуникация между ними может превратиться в испорченный телефон. Наладили прямую коммуникацию между командами — получил профит.
И последний пункт списка — мониторинг изменений. Выкатили вы какой-либо хотфикс —, проверьте, нужно ли в нем что-то локализовать, попали ли в него все нужные данные.
Я разделяю веселье | Джонатан Коул расскажем об одной из полезных мнемоник для тестирования мобильных приложений. FUN first: три ключевых направления тестирования
🔹 F — Functional: проверка функциональности приложения. Всё ли работает так, как задумано? Реализованы ли все заявленные возможности?
🔹 U — User Scenarios: тестирование пользовательских сценариев. Насколько удобно и логично использовать приложение в реальной жизни?
🔹 N — Network: взаимодействие с сетью. Как приложение ведёт себя при нестабильном интернете, смене сети или полном отключении?
http://www.kohl.ca/articles/ISLICEDUPFUN.pdf
От слепых котят к ИИ-гуру: история автоматизации qa в Сбере
Почему именно API-тесты
Мы выбрали API-требования, потому что UI-требования нередко включают в себя диаграммы, макеты и т. д. Нам было проще создать инструмент и изучить работоспособность ИИ с помощью GigaChat. Тогда наша команда была далека от этой темы: мы, как слепые котята, двигались на ощупь, методом проб и ошибок.
Слишком много текста и токенов Требования бывают разной длины и разного формата, могут включать в себя таблицы. Поэтому мы сразу же столкнулись с проблемой: работа с контекстом заканчивалась слишком быстро и была некачественной. Сначала мы разделили текст и стали работать только с теми фрагментами, которые нужны в момент выполнения задачи. Но это не слишком помогло: количество используемых токенов по-прежнему зашкаливало, а результат не улучшился. И тут на помощь пришли эмбеддинги.
Эмбеддинги Представьте себе два вектора в пространстве. Когда они равны? Когда их длина и направление одинаковы. Так вот, эмбеддинги — это способ представить слова в виде числовых векторов. Чтобы не только снизить количество токенов при поиске по тексту, но и помочь модели лучше улавливать смысл слов и фраз при работе с контекстом.
Начать внедрять интеграционные тесты
Александра Смирнова, старший фронтенд-разработчик в команде Календаря, VK WorkSpace в компании VK Tech
Как быть, если вы перешли в новый проект, над которым работают несколько команд, а под ваше окружение нет тестов? Как писать новые фичи и быть уверенными, что они не сломали что-то в чужом окружении? Именно этими вопросами задавалась наша команда в начале работы над B2B-Календарем.
Параллельно с нами в одном репозитории работала команда, пишущая фичи для B2C-календаря. И мы хотели быть уверенными, что при разработке не ломаем ничего не только у себя, но и у них. Инфраструктура у параллельной команды отличалась от нашей: разные процессы раскатки кода на стенды, совершенно разные способы настройки фичей, да и сами фичи заточены под разные задачи, а также у B2B больше тестовых стендов, каждый из которых может быть настроен по-своему.
У ребят уже был набор интеграционных тестов, заточенных под B2C-окружение. Тесты хранились в отдельном репозитории вместе с тестами других проектов. Нам в B2B предстояло решить, как подружить наши новые тесты Календаря с уже существующими, избежать сильного разделения между окружениями и вписать автоматизированное тестирование в процесс команд, работающих над проектом.
Сначала мы думали хранить свои тесты отдельно, но постепенно склонялись к идее хранить их там же, где уже были тесты проекта, пусть и для другого окружения. Тогда не пришлось бы создавать инфраструктуру с нуля — ведь там уже есть тесты многих проектов и много общих утилит. С помощью ранера удобно запускать тесты для любых проектов, настроен CI, подключены боты и другое. В итоге решили сделать именно так.
Как настроены процессы в обеспечении качества
Памятка для тестировщика: Если в команде нет цели найти причину бага, а есть лишь цель найти виноватого, то необходимо взять ответственность за освещение данной проблемы. Иногда это поможет запустить процесс по исправлению ситуации. Разговор — это самое эффективное средство, в сравнении с молчанием и уходом из команды. Также считаю нет ничего страшного подсветить проблемы работы лида, раз уж на вас всё сваливают) Молчание — знак согласия.
В большом мире QA:
From Junior to Senior Test Engineer
Mindset Shift #2: From Bug Detection to Problem Prevention
Junior Thinking: “My goal is to find as many bugs as possible.”
Senior Thinking: “My goal is to understand why bugs exist and prevent similar issues systematically.”
For years, I measured my success by bug counts. High severity findings felt like victories. My bug reports were trophies proving my testing prowess.
This scoreboard mentality is seductive but ultimately counterproductive.
Senior test engineers think like quality detectives. When they encounter a bug, the defect itself is less interesting than the conditions that allowed it to exist.
They investigate patterns:
- Are similar bugs appearing across different features?
- What gaps in our development process enabled this?
- How can we catch this category of issue earlier in the pipeline?
- What automation or process change prevents this from recurring?
I remember discovering a critical data validation bug just before a major release. My junior self would have celebrated finding it so late in the cycle. My senior self was horrified that our entire quality process had failed to catch it earlier.
Mindset Shift #8: From Feature Focus to User Impact Focus
Junior Thinking: “This feature works according to the acceptance criteria.”
Senior Thinking: “This feature creates the intended user value without negative side effects.”
Acceptance criteria are starting points, not finish lines. They define minimum functionality but rarely capture the full user experience.
Introducing quality in a company that didn’t have the culture
A tool, on its own, is important. But it’s not the most important thing. You can buy the fastest car in the world — if you don’t master its power, it’ll just be an expensive and dangerous machine with high maintenance costs. Same goes for testing tools.
The Primacy of Primary Testing
In primary testing, we’re actively looking for trouble. We’re obtaining experience with the product, exploring its nooks and crannies, and performing experiments on it. We’re developing and deepening our awareness and working mental models of the product of interest, as it has actually been built.
Primary testing tends to be focused on interactive, experiential, analytical work. It can be supported by lots of tools. It is productive in terms of discovering risks and test ideas that we didn’t anticipate during prospective testing. It’s an opportunity to develop new ideas for automated regression checks — and to learn whether shallow checking is sufficient, or whether deeper testing is necessary.
Most importantly, in primary testing, we find lots of bugs. Those bugs are real, in that they are actually in the built product, and have therefore have a chance of affecting the users and the business.
Prospective testing is important, but it doesn’t account very well for emergence — aspects of behaviour that aren’t intrinsic to the units and components initially, but that result from changes to them over time, and from the interactions between them. Prospective testing doesn’t account for the fact that some bugs will slip past us through the precursors and into the built product, even in a highly disciplined development process. Automated checks are often derived from what we believe the built product will be like, and not from what it’s actually like. That is: automated regression checks without primary testing will be based on theories about the imagined product, not on experience with the built product.
The same incident never happens twice, but the patterns recur over and over
Saturation is an example of a higher-level pattern that I never hear people talk about when focusing on eliminating incident recurrence. I will assert that saturation is an extremely common pattern in incidents: I’ve brought it up when writing about public incident writeups at Canva, Slack, OpenAI, Cloudflare, Uber, and Rogers. The reason you won’t hear people discuss saturation is because they are generally too focused on the specific saturation details of the last incident. But because there are so many resources you can run out of, there are many different possible saturation failure modes. You can exhaust CPU, memory, disk, threadpools, bandwidth, you can hit rate limits, you can even breach limits that you didn’t know existed and that aren’t exposed as metrics. It’s amazing how much different stuff there is that you can run out of.
My personal favorite pattern is unexpected behavior of a subsystem whose primary purpose was to improve reliability, and it’s one of the reasons I’m so bear-ish about the emphasis on corrective actions in incident reviews, but there are many other patterns you can identify. If you hit an expired certificate, you may think of “expired certificate” as the problem, but time-based behavior change is a more general pattern for that failure mode. And, of course, there’s the ever-present production pressure.
On No/LowCode and AI for Automation, Testing, and Quality Engineering
This post has gone through a few versions, as I figured out exactly what it was I wanted to get across. Please bear with me, but also feel free to skip.
I think my TL;DR is:
- I’d rather write automation code than use a no / low code tool, even though I don’t consider myself a programmer
- I still use AI to my advantage, even though I don’t fully trust it
- I’m a little bit stubborn when it comes to what I want to use and how, and I’m not sure what that says about me, as a tester
Pick E2E Tests To Run Using AI Summaries
Summarize the existing E2E tests and pick the tests to run based on the code pull request changes.
Imagine you have a web application. If you are reading this blog, you probably have an extensive set of end-to-end Cypress tests for this web application. Someones modifies the source code for the web app (could be changes to HTML, JavaScript, or CSS styles), and asks you “which tests should I run to confirm my changes are purely a refactoring?” Ideally, you would run all E2E tests, but that might be wasteful. We need to run a small subset of all tests to give the fastest feedback for the current pull request. How do you pick these tests?
Where does a tester fit into a software development team?
I think that there are basically three options:
- Your testers do not add something essential.
- It’s not clear if your testers add something essential.
- Your testers do add something essential.
Why the testing industry is the way it is
I was inspired to put virtual pen to virtual paper again by a LinkedIn post from my good mate, Paul Seaman, lamenting his experience of spending nine months looking for a new testing role in Melbourne (Australia):
During 9 months of job searching it was hard not to notice that the job market for software testers is broken. Not just a little broken, a lot broken…
…we have the job ads that ask for a million different things and tools. I was told by a recruiter that, in a market like the current one, it’s a form of filtering. We both agreed it’s a particularly poor filter. I suspect it’s more fundamental. Many companies seeking a tester do not know what they need so they resort to a “wish list”.
Paul asks how the testing industry got to be this way and that got me thinking. When you look at a system and it seems completely broken or makes no sense, it’s worth thinking about how it could make perfect sense just the way it is. The US “healthcare” system is a perfect example, it’s not broken for those who’ve architected it to be the way it is – far from it!
We know how systems become the way they are thanks to these sage words from Jerry Weinberg:
Things are the way they are because they got that way
So, what lens can we use to look at the current testing market and see it making sense? Who benefits from the way it is? Who decided it got this way?
Don’t Use Page Object Model (POM) in Small Mobile Automation Projects и
As a QA engineer working in mobile automation, I’ve spent time with both heavyweight frameworks like Appium and Espresso and lighter tools designed for quick, readable test scripts. One thing I’ve consistently found: the Page Object Model (POM) doesn’t always make sense — especially for smaller projects.
Playwright Tests with Chrome DevTools Protocol
In this post, we’ll explore how we can take advantage of Chrome DevTools Protocol (CDP) with Playwright to unlock advanced testing features. From blocking resources to capturing browser logs, CDP gives us deep access to the browser’s internals — and yes, it’s all automatable!
Automation Learning Roadmap | Wangyingya
I began my career as an Embedded System Test Engineer. Back then I was involved in testing hardware-software integration and verifying system functionality.
Посмотреть:
Суету охота навести: тесты клиент-серверных взаимодействий на примере WebSocket | Heisenbug ⏱️45 минут
Тестирование WebSocket-взаимодействий всегда было большой задачей под звездочкой. Мы решили создать механизм, который максимально упростит написание огромного числа автотестов в проектах с клиент-серверными взаимодействиями по real-time протоколам. В докладе обсудили: — как автоматизировать процесс клиент-серверного взаимодействия без боли для всех участников команды — даже тех, кто не хочет или не может разбираться в технической стороне реализации «общения»; — как победить сотни различных сценариев взаимодействия по протоколу WebSocket в тест-кейсах проекта и не сойти при этом с ума; — пример запутанного тест-кейса из нашей практики и как наше решение его существенно упростило; — использование библиотеки asyncio в тестовом фреймворке на pytest; — как применить механизм, если у вас не веб-сокеты, а, например, только REST API (даже так можно); — как легко дебажить созданный асинхронный механизм. Также спикер дал ссылку на GitHub (в презентации) с демореализацией механизма, чтобы вы смогли легко попробовать внедрить его у себя в проектах.
GitLab CI/CD Masterclass for Beginners (2025 Edition) | LambdaTest
⏱️2 часа 30 минут
In this 2-hour masterclass, you will learn GitLab fundamentals, gain a clear understanding of how it works, and build a GitLab CI/CD pipeline using Maven, covering both basic and advanced concepts.
Как устроены метрики показателей эффективности работы ПО | SQA Days #35 ⏱️20 минут
— Как устроены метрики показателей эффективности работы ПО и как их тестируют
В условиях рыночной экономики для большинства компаний, занимающихся разработкой ПО, ключевое значение имеют повышение качества выпускаемого продукта и минимизация затрат на его разработку. Метрики показателей эффективности работы системы – это мощный инструмент, являющийся заключительным шагом в вопросе оценки и обеспечения качества работы ПО. Метрики помогают отслеживать и контролировать определенные проблемы и расставлять приоритеты по их решению, позволяя системно подойти к решению ряда задач. В докладе рассматривается основная функциональность метрик, принципы работы, примеры использования, а также практические подходы к тестированию данного функционала, наиболее часто возникающие проблемы и пути их решения.
Quality Assurance Jobs in USA June 2025 Update
⏱️15 минут
In this video, we are going to look how QA job market in USA changes in the last 6 months.
Основы нетворкинга | ⏱️Moscow QA 1 час 30 минут
Основы нетворкинга: от теории к практике, Лидия Рогова
Мнемотехника: запомнить всё | развитие памяти, насмотренность, саморазвитие | Podlodka ⏱️2 часа
Почему мозг так упрямо забывает важное, но помнит строчки из рекламы 2007 года? Что вообще такое память и можно ли натренировать её так, чтобы не забывать ни имён, ни паролей, ни зачем пришёл на кухню? Разбираемся, как устроено запоминание, почему эмоции и внимание — это топливо для памяти, и как мнемотехника превращает мозг в суперхранилище. Вспоминаем истории чемпионатов по запоминанию, смотрим, что говорит нейронаука, и обсуждаем, как связаны насмотренность, креатив и способность держать в голове абстрактные концепции. Байки, наука, техники — всё как мы любим!
Вайбкодим всей командой ⏱️2 часа 30 минут
С каждой неделей AI становится все умнее, и это влияет не только на то, как пишется код, но и на то, как работают целые команды. Андрей Володин – фаундер стартапа Gracia, рассказал про то, как AI агенты изменили его собственный подход к разработке, как поменялись роли в их команде, инженерные стандарты, технический стек, и как в итоге они ускорились во много раз, не жертвуя при этом качеством.
Собеседование на QA Auto Middle уровня в 2025 году ⏱️ 2 часа
Alex Pshe
