В телеграме QA Live | тестирование ПО
Дайджесты + Вакансии QA
Почитать:
Точнее, Android-аппку Dropbox. У приложения более миллиарда загрузок, из-за разнообразия клиентских девайсов вынуждены плотно инвестировать в инфраструктуру. Используют Espresso, Robolectric, Paparazzi, и собственную библиотеку Dropshots для скриншотов.
ИИ не оставит без работы тестировщиков, а наоборот сделает нужнее
Смелое утверждение, по нынешним временам — но аргументированное. Techcrunch пишет, что даже лучшие модели ИИ не умеют в дебаг (подразумевается, что и не научатся). Поэтому ИИ – да, еще больше ускорит разработку — но и повысит востребованность грамотных тестировщиков.
Также:
Ошибки в нагрузочном тестировании
Сейчас во многих системах для обеспечения надежности используют сложные системы авторизации, которые не позволяют одним и тем же пользователям заходить под разными сессиями. Для функциональных тестов, как правило, не требуется большого количества тестовых пользователей, и их создают ограниченное количество, которого недостаточно для нагрузочного тестирования.
Например, можно сделать 5—10 пользователей, и они покроют весь необходимый набор для ручных тестов. Другая ситуация складывается, когда команда делает НТ и они хотят получить сотни, а то и тысячи уникальных пользователей во время НТ.
Когда дело доходит до разработки скрипта, приходит осознание, что у нас всего несколько пользователей. В результате бегаем по командам и ищем решение. А можно подумать об этом заранее, изучить опыт других команд и заложить в код системы на этапе тестирования необходимое поведение. Одним из возможных вариантов может быть допуск использования разных сессий для одного и того же пользователя. Но все это должно быть актуально только для тестовой системы и не присутствовать в прод-среде.
Как справляться с невоспроизводимыми дефектами
Представьте, что вам нужно протестировать приложение с многопоточностью – методом запуска, который позволяет создавать несколько цепочек внутри процесса. Каждая цепочка выполняетс самостоятельно, но делит ресурсы с другими цепочками. Создание такого приложения требует тщательного программирования, дабы избежать потенциальных проблем вроде состояния гонки и взаимоблокировки.
В коде приложения разработчики создают функцию, которая модифицирует общую переменную счетчика. В идеале разработчики пользуются синхронизацией, чтобы убедиться, что каждая цепочка достигает определенной точки в операциях по отношению к другим цепочкам, прежде чем продолжиться. Однако при отсутствии синхронизации обе цепочки смогут одновременно изменять общий счетчик.
10 ошибок QA и как их избежать
Доказательства тестирования в баг-репортах предоставляют разработчикам конкретные данные для воспроизведения и устранения проблем. Особенно в сложных сценариях важно мыслить нестандартно и находить креативные способы представить эти доказательства. Это может значительно упростить понимание причины проблемы и обеспечить её эффективное устранение.
Пять ошибок общения, из-за которых команда теряет миллионы и время
Ключевые принципы конструктивных коммуникаций:
- Своевременность
- Адресность
- Оперирование фактами и данными
- Намерение решить проблему (фокус на проблеме)
Ещё несколько лет назад тестирование в страховании сводилось к проверке «отправляется ли форма» и «открывается ли PDF-полис». Сегодня же digital-продукты страховщиков — это целые экосистемы, где переплелись микросервисы, мобильные приложения, решения на базе ИИ и интеграции с внешними сервисами.
Подходы QA на разных стадиях продукта
Первая крайность — тестировщик-Гендальф. Он стоит на мосту, отбивается от демонов, и главная его миссия — не пропустить ни одного бага в прод любой ценой, даже если весь бизнес сгорит за его спиной: «Ты не пройдёшь!». Есть даже практика, когда разработке ставят KPI дотащить максимум задач до релиза, а тестировщикам — не пропустить косяки. Итог — вечная война на истощение.
Вторая крайность — тестировщик-Голлум. Он как информатор — не блокирует релиз, не встает насмерть, а просто говорит: «Вот баги, вот риски. Дальше решение за вами». И ответственность за то, катить релиз или нет, переходит к бизнесу. Этот подход тоже рабочий, потому что если бизнес решил выкатываться, остановить его невозможно.
Хабр:
От релиз-менеджера до разработчика: почему я ушел из QA и не жалею
2007-й год не вернуть: профессия QA-инженера, которая ещё недавно была престижной и высоко ценилась, сегодня стремительно теряет влияние, превращая опытного эксперта в «универсального бойца», которому можно спихнуть любую работу. Эта статья — моя личная история, в которой я разбираю, почему профессия больше не ценится и что сделать, чтобы она не попала в красную книгу как исчезнувший вид.
Что происходит с собеседованиями QA в 2025 году? Взгляд с обеих сторон баррикад
Иногда компании используют не совсем привычные методы оценки, вроде анализа натальных карт, раскладов таро, соответствие знаков гороскопа или чего-то подобного. Казалось бы, чем бы дитя не тешилось, но не все так просто.
У такого подхода есть огромный минус и ни одного плюса. Компания полагается на мистику (а по факту, тыкает пальцем в небо) вместо рационального подхода к оценке навыков. Чем это плохо для компании: риск найма некомпетентных сотрудников и отказы действительно клевым кандидатам, у которых месяц рождения в доме Нептуна.
Для самих кандидатов такой подход — это тоже весьма серьезный повод задуматься. Если вы прошли испытание гороскопом — поздравляю. Дальше, возможно, будут корпоративные жертвоприношения.
История о свершениях одного QA: о Quality Gates и оптимизации релизных процессов
Примечание: Quality Gates — заранее определенные этапы, во время которых проект проверяется на соответствие необходимым критериям для перехода к следующему этапу. Цель Quality Gates — обеспечить следование набору определенных правил и практик, чтобы предотвратить риски и повысить качество проекта.
Мошеннические курсы по тестированию — развод, маркетинг и пустышки
Чтобы быть честным — нет, не все курсы плохие. Есть отличные. Есть такие, после которых действительно появляется понимание, навык и даже шанс на работу. Более того — есть бесплатные ресурсы, которые уделывают половину «платных гуру».
Автоматизация UI тестов на Cypress
SAFe представляет собой набор шаблонов и практик для проектирования процессов, включая встречи, роли и распределение ответственности с чёткой структурой проведения. Его ключевое преимущество — гибкое масштабирование для команд и проектов большого масштаба. Фреймворк структурирует процессы на три уровня:
- командный (внутри одной команды),
- программный (координация сквозных потоков),
- портфельный (управление проектами компании).
Основная цель — повышение скорости команд и качества продукта через выравнивание стратегических целей с тактическими задачами.
Да, запросы на изменение (ЗНИ) приходят от пользователей не как бизнес-требования, а кратенькое описание в почте, но у нас есть аналитики, которые проводят глубинные интервью и собирают всю нужную для разработки задачи информацию. Ну и что, что наши ребята-разработчики могут переключиться с одной задачи на другую, более приоритетную, они ведь делают «хорошо» бизнес-пользователям. Да и тестируем мы от души, на скорую руку накидав чек-лист.. Комментариев в тасках ни разработчики нам, ни мы пользователям не оставляли, а при необходимости — просто созваниваемся, демонстрируем экран и отвечаем на вопросы.
Методы убийства ИТ-продукта: мнение QA-инженера
У каждого из вас наверняка найдется по парочке примеров, когда проверить бы стоило, но увы, не стали. Я начну с истории на реальных событиях. В одном банке жил-был проект для сотрудников. Суть простая – сотрудник авторизуется, попадает на лендинг с выгодными предложениями и акциями для клиентов и в течение дня предлагает оформить эту выгоду всем, кто попадется под руку.
Естественно, на это завязано куча метрик и рекламных компаний, и, естественно, уже прорисованы и выведены на большие мониторы красивые графики. Но в один из понедельников почему-то графики не показали никакого прогресса, а почта саппорта была переполнена письмами от сотрудников…
Почему? А потому что вечером в пятницу, часам к 11, один бэкенд разработчик, назовем его Михаил, решил, что нет смысла писать тестерам и терять время. Он сделал MR и трое других разработчиков на удивление быстро дали апрув. Закрыв глаза на то, что релизить в пятницу вечером – плохая примета, Михаил ушел заниматься своими делами, а в понедельник обнаружил что его изменения повлияли на политику антифрода и 90% сотрудников было заблокировано. Система не была готова к такому повороту событий, и следующие три дня QA, менеджеры и саппорт разблокировали каждого в ручную. Было потрачено три дня на то, чтобы разобрать последствия, и еще почти две недели, чтобы окончательно исправить эту проблему.
Автоматизированное E2E-тестирование App.Farm: от хаоса к системе
Практический гайд по Left Shift Testing
Этот этап можно кратко охарактеризовать как подготовку инфраструктуры под автотесты. Даже если сами тесты ещё не пишутся, заранее подготовленная среда позволяет в дальнейшем значительно сократить время на реализацию и избежать накопления технического долга.
Важно понимать: не всегда и не везде это возможно. Где-то фича слишком нестабильна, где-то слишком динамичный процесс, а где-то просто нет смысла заранее тратить время. Однако если это возможно — лучше начать подготовку заранее. Это убережёт от ситуаций, когда в продакшн улетает «огромный» pull request с тестами на 1500 строк, написанными в спешке.
pytest.raises: ловим исключения правильно
Тест — это не просто проверка результата. Это формулировка ожидания. Мы говорим системе: вот этот участок кода, и вот что мы считаем его корректным поведением. И если функция должна выбросить исключение — мы обязаны это зафиксировать в тесте как норму, а не как сбой.
pytest.raises является той конструкцией, которой мы говорим: вот сейчас должно случиться исключение — и это хорошо.
Когда‑то, ещё в школьные годы, я читала журнал «Хакер» и мечтала, как было бы здорово «ломать серверы» и находить их слабые места. Теперь я занимаюсь этим вполне законно — через нагрузочное тестирование.
XCUITest для начинающих: как сделать тестирование iOS красивым с Allure
В большом мире QA:
Slack: Optimizing Our E2E Pipeline
The Results: A 60% Drop in Build Frequency and 50% Drop in Build Time
How to enhance test workflows in Cypress and Playwright with tags and test filters
To provide some context: some time ago, Gleb created a grep plugin named cypress-grep. This plugin was submitted to Cypress.io, which renamed it to @cypress/grep, making it the official version. However, to introduce improvements, Gleb forked the newly named @cypress/grep plugin into a separate project called @bahmutov/cy-grep. He has since maintained his new plugin in the new repository.
AI Unit Test Generation: Key Strategies and Tools
This is a generic framework design for AI unit test generation. You can also add other modules to make it more productive and efficient, depending on their requirements. However, the stated modules have to be present as a foundation.
Building a Custom Jest File Structure Matcher
Jest has many built-in matchers for various types of comparisons, but surprisingly, none specifically for comparing file structures. In this post, we’ll build a custom Jest matcher called toMatchFileStructure() that lets you elegantly validate directory contents in your tests.
In Software, Delivery Is Just the Beginning
There’s a principle in thermodynamics called entropy, the idea that all systems tend toward disorder over time. Coffee cools. Sandcastles crumble. Weeds overtake gardens. Our bodies are constantly declining unless we actively care for them.
It’s not the most uplifting message, I know. But here’s the hopeful twist: once we accept that entropy is inevitable, we can plan for it. We eat well, exercise, and go for check-ups, not to stop aging, but to manage it. The same mindset applies to software.
Product Quality for Non-Technical Founders
I’m a big fan of philosophy. One of my favourite books of all time is Zen & the Art of Motorcycle Maintenance, in which the author Robert M. Pirsig attempts to define what quality actually is:
Something you know when you see it, even if you can’t fully explain it.
Bug Advocacy 101: Make Sure Your Bugs Get the Attention They Deserve
The concept of Bug Advocacy was popularized by Cem Kaner, one of the fathers of modern software testing, in the early 2000s.
Quality Engineering as philosophy, a framework and a tool
I keep coming back to this one because it really helped me shape how I think about quality engineering. It’s not just a set of practices, but something that can shape culture. It’s about how philosophy, frameworks and tools all work together to build quality into people, processes and products.
If There’s No Time for Testing at the End of the Sprint, There’s No Time Management at All
In this article, we’ll explore planning models that don’t push QA into the corner at the end. We’ll talk about how testing can shift to earlier phases, how the Shift Left mindset can be realistically implemented, and how collaboration between developers and QA can be strengthened.
Building a Rock-Solid Testing Framework at Bynry
In Part 1 of this series, I shared how and why we embraced Test-Driven Development (TDD) at Bynry Inc. to improve the quality and reliability of our Smart360 utility management platform. Now, let’s dive into the technical details of our implementation — how we designed our testing framework, the architectural choices we made, and the real-world results we’ve achieved.
How Testing Became My Code’s Lifeline
Code Coverage: What the Experts Really Think
Many experienced developers and authors — like Kent Beck, Martin Fowler, Michael Feathers, Vladimir Khorikov, Raymond Hettinger, and Roy Osherove — agree on one thing: code coverage is useful, but only if you use it wisely.
The Async Nature of Cypress: Don’t Mess with the Timelines in Your Cypress Tests ‘Dual-Verse’
A lot has been said about the asynchronous nature of the Cypress test framework. This asynchrony is often blamed as the primary cause of flakiness in Cypress tests. And, I would say… yeah, I agree. Asynchrony is the main reason of flakiness, but that’s because it’s not used correctly, which stems from it not being properly understood.
Посмотреть:
Поднимаем Android-ферму за 10 минут ⏱️45 минут
Автоматизированное тестирование Android-приложений часто осложняется сложной инфраструктурой: развертывание занимает много времени, конфигурация нестабильна, а существующие решения либо дорогие, либо требуют глубокого погружения в DevOps. А что, если можно запустить собственную Android-ферму на эмуляторах всего за 10 минут?
Паттерн Saga ⏱️15 минут
Краткое описание.
MCPs, Agents and the Future of Software Testing ⏱️35 минут
In this LIVE episode of Test Case Scenario, host Jason Baum, along with co-hosts Marcus Merrell and Evelyn Coleman, engages in a compelling conversation with Angie Jones, Global Vice President of Developer Relations, Block, Inc. They delve into the transformative impact of agentic AI and Model Context Protocols (MCPs) on software development and testing.
Angie shares insights from her recent presentation at the Selenium and Appium Conference, discussing how AI agents are evolving from mere code assistants to autonomous entities capable of writing and executing tests. The discussion covers the practical applications of MCPs, the ethical considerations of AI in testing, and the future role of QA professionals in an AI-driven landscape.
Automation, Playwright, and the Future ⏱️20 минут
Automation was once seen as the ultimate solution in testing—but with the rise of AI and low-code tools, that narrative is evolving fast. In this fireside chat, we explore how AI is changing the landscape of test automation, the shifting role of programming, and what tools like Playwright (backed by Microsoft) might look like with deeper AI integration.
We’ll also dive into current challenges with Playwright and end with sharp, role-specific advice for Test Directors, Architects, Managers, Manual Testers, and Automation Engineers navigating this AI-led shift.
A grounded, insightful conversation designed to spark reflection—and action.
This video is of one of the sessions presented at #QonfX ‘Future of Testing’ Week 2-Day Virtual Conference, 2025.
QA? Нет, Q&A ⏱️35 минут
В этом видео я открыто и честно отвечаю на анонимные вопросы подписчиков: и про менторство, и про деньги, и про выгорание, и про обратную сторону работы с учениками. Мы поговорим не только о тестировании, но и о том, что остаётся за кадром — эмоциях, страхах, перегрузах, мотивации и росте.
Предыдущий QA-дайджест — c 21 по 27 апреля
