Интересное
ISTQB/GTB Advanced Syllabus. Вопросы встречаются сложные (и контр-интуитивные).
«… нанимают людей, которые хорошо отвечают на вопросы, но не умеют решать реальные задачи.»
Анализ первопричин дефектов (Defect Root Cause Analysis, RCA)
Каждому QA-лиду знакомо чувство, когда команда теряет время на мелкие баги. Есть способ, который помогает сфокусироваться на главном — на устранении причин проблем, а не их последствий.
Не прячьте баги за таймаутами и ретраями
Хорошие автотесты должны быть «хрупкими». Если тест падает, это повод радоваться: он сделал свою работу и нашёл проблему. Почему не стоит излишне «укреплять» свои тесты, и как перестать просто чинить баги, а начать наводить порядок в системе.
Инциденты не повторяются, а их паттерны — да
«В одну и ту же реку нельзя войти дважды» — эту фразу Гераклита можно применить и к IT-инцидентам. Автор рассуждает о том, почему каждый инцидент на самом деле уникален, и как стремление предотвратить конкретный сбой мешает увидеть более общие системные проблемы.
Идеальные имена переменных, избыточные комментарии и обилие классов-хелперов — характерные признаки вайбкода. Senior QA Automation Engineer Юлия Баранецкая объясняет, почему такая «идеальность» может скрывать провалы бизнес-логики и критических путей, превращая автотесты в «авто-фейк».
Сначала подумай, потом пиши. Pull Request Driven Development
Слышали про принцип Amazon «Работать от обратного»?
Также
Как в Postman использовать данные из файла
Практические советы по тестированию миграции данных
Представьте себе сложный веб-сервис, интегрированный с несколькими микросервисами и сторонними приложениями. Можно представить, что это служба поддержки клиентов крупной компании.
Система работает по всему миру: в Европе, Африке, Азии, а также в Северной, Центральной и Южной Америке. Каждая из этих версий – это зеркало всей системы для конкретного региона.
Вот в чём подвох: компания хочет сократить расходы. Запуск отдельных систем для разных регионов стоит дорого. Нужно больше серверов, возникают сложности с обновлениями и управлением, да и сторонние приложения недешевы. Поэтому план — объединить всё в одном экземпляре: одна система, управляющая данными всех регионов. Система должна без проблем обслуживать все регионы.
Очевидно, что это большая задача. Нельзя просто свалить все данные вместе. Данные каждого региона должны оставаться в своих пределах. Крайне важно, чтобы система понимала, откуда пришли данные, и сохраняла их упорядоченными согласно правилам и требованиям каждого региона. Хоть всё и работает на одной системе, данные каждого региона продолжают соответствовать своим собственным правилам.
Нефункциональные проверки мобильных приложений
Когда приложение работает и поступает входящий звонок, необходимо проверить, что после его завершения оно возвращается в прежнее состояние без потери данных и продолжает работу с того экрана, на котором пользователь был до звонка.
Для понимания этой проверки нужно знать, что происходит с приложением в момент звонка, а для этого надо разобраться в понятии Activity и его жизненном цикле.
Весь набор тестов состоял примерно из 10 файлов. 9 из них были «более-менее», десятый же был настоящим кошмаром: в нём было примерно 3000 строк кода, которые объединяли в себе ~80 тестовых случаев. Около 95% всего набора тестов приходилось на этот один файл.
Помимо самих тестов, все вспомогательные утилиты, которые использовались в тестах, были разбросаны по этому же файлу.
Самовосстановление в веб-автоматизации
Например, если локатор элемента (ID или CSS-селектор) изменился после обновления страницы, обычный тест сломается и потребует ручной правки. Самовосстанавливающиеся тесты используют такие техники, как машинное обучение и умные эвристики, чтобы находить альтернативные локаторы или динамически адаптироваться. Благодаря этому тест продолжает выполняться без участия человека.
Искуственный интеллект и 4-Shot Testing Flow
Представляем 4-Shot Testing Flow (оно же четырехэтапное тестирование): умный гибридный подход, который сочетает в себе мощь автоматизации на базе ИИ и экспертный взгляд опытных тестировщиков. Вдохновленный методами обучения современных AI — zero-shot, one-shot и few-shot, — этот подход обеспечивает максимальное покрытие, быстрый фидбек и реальную доступность для команд любого масштаба.
Эволюция тестирования — от мейнфреймов до ИИ
До спринтов и DevOps тестирование выполнялось вручную. Вычислительные мощности были дефицитом, а память использовалась только для «важных» задач, к которым тесты не относились.
Инструменты, технологии и регуляторка: как не проиграть на тестировании ставок
Самые важные требования включают:
- GDPR (General Data Protection Regulation, ЕС) регулирует защиту персональных данных пользователей.
- PCI DSS (Payment Card Industry Data Security Standard) – стандарт безопасности для работы с банковскими картами.
- KYC (Know Your Customer) – правило, обязывающее букмекеров проверять личность пользователей перед допуском к ставкам.
Методы API: язык команд и смыслов
REST – это не технология и не волшебный фреймворк, а стиль общения с API, где все держится на простых и понятных правилах. Если провести аналогию, REST – как меню в хорошем ресторане: ты говоришь «принесите суп», а тебе не приносят котлету, потому что правила заказа однозначны.
На Хабре
Гибкий подход к тестированию фильтров с Playwright + TypeScript
Дизайн без интерфейса: как проектировать системы, у которых нет экрана
QA за пределами тестирования: надежность через учебные сбои
Как прийти в IT и не облажаться: мой путь от новичка до руководителя группы тестирования
Образование у меня техническое — я закончил Московский государственный строительный университет по направлению «Информатика и вычислительная техника». В университете мы получили хорошие знания SQL и базовые навыки работы с Linux-системами, которые позже оказались невероятно полезны в моей работе тестировщика. В рамках дипломного проекта я активно использовал Excel для расчётов, применяя сложные формулы и функции, а для автоматизации процессов подключал JavaScript-скрипты.
После окончания бакалавриата я планировал работать специалистом по САПР, но чувствовал, что пока не готов к этой роли. Из-за нехватки опыта и понимания, я год проработал инженером-проектировщиком. Однако со временем понял, что это не моё — сфера не вдохновляла.
Зачем проксировать? Чтобы не перенастраивать приложение, настроили весь трафик в Castlemock + настроили проксирование. Потребители не страдают, мы видим весь трафик. Можем в любой момент включить статичные ответы, добавить задержку, поменять статус-код и т.д.
Раньше мы проводили нагрузочное тестирование вручную: тестовые окружения разворачивались распределенно, но настройка требовала значительных усилий, а метрики собирались с помощью встроенных средств Windows и Linux. По мере роста нагрузки и усложнения инфраструктуры (в том числе за счет поддержки различных ОС, таких как Windows, Astra Linux, Red OS) стало ясно, что такой подход не масштабируется.
Как pytest работает под капотом
Pytest основан на pluggy. Основная единица pytest — pytest плагин. Написан достаточно интересно. Ключевое слово — “капуста” или матрешки. Множество декораторов и адаптеров. Основное взаимодействие в pytest происходит через хуки. Хук это некий этап к которому можно получить доступ к той или иной логики работы. Следуя из названия это некоторые крючки за который можно цепляться вставляя свои заплатки. Начинаются с pytest.
Фикстуры (Fixture) в pytest это некий аналог мока/сетап tear down в unittests. Это некие кусочки кода результаты которых могут быть пере использованы. Сами фикстуры реализованы как плагин.
Обычно все это лежит в разных окружениях (Pipeline, TMS, GIT), все зависит от команды.
Также у каждой команды своя группировка и свой состав отчетов, поэтому стандартные отчеты из CI уже не канают.
Холст для тестировщика: функциональные автотесты с Canvas
Если вы когда-либо писали автотесты для веб-приложений с элементом canvas, то наверняка знаете, как это может быть непросто. Canvas — это «чёрный ящик», где привычные инструменты UI-тестирования бессильны: внутри нет DOM-структуры, за которую можно зацепиться. При этом на экране canvas может отображать что угодно — от графиков с осями X и Y до сложных анимаций.
Что почитать начинающему и продолжающему QA-специалисту
Жизнь хардверного тестировщика отличается от софтверного, но не во многом: все еще надо обладать той же силой духа и внимательностью, которые и в написании юзкейсов помогут, и разработчику передать в деталях, а что собственно не так.
Postman + Newman — как быстро запускать свои тесты
Если надоело открывать Postman и вручную запускать каждую коллекцию или проверять эндпоинты по очереди, то решение есть — Newman, терминальный раннер от команды Postman.
Как меняется тестирование — личный взгляд
Упрощая себе задачу поддержки, команды стали даже выносить отдельные тестовые шаги в библиотеки, используя их в разных (параллельных) проектах. По сути автоматическое тестирование пошло в своем развитии по линии разработки. У нее же и перенимаем основные идеи.
Приятно, что при этом и разработка идет навстречу тестированию. Давным-давно коллеги-разработчики как будто не понимали, зачем мы нужны. А сейчас прониклись и всячески помогают — добавляют отдельные удобные ручки, которые имеют значение только для теста (но не для прода), data-qa тэги для тестирования фронта и т.д.
Как реализовать тестирование сортировки с помощью Playwright + TypeScript
Дело в том, что в реальном приложении, тип данных может отличаться от стандартных, часто используется нетипичные форматы(например цена, или дата), или в кастомные типы данных. Поэтому, при использовании этого подхода, мы столкнемся с тем, что для каждого столбца с данными, придется писать отдельные тест кейсы, передавая в .sort() функцию для сравнения значений.
Искусство ручного тестирования в современном мире
Тестировщик, подобно самураю эпохи Эдо, обладает острым вниманием к деталям (как катана) и несгибаемым терпением (как доспехи). Однако его истинная сила заключается не в поверхностном тестировании, а в способности предвидеть проблемы, понимать намерения пользователя и замечать неочевидные сценарии использования.
Тестируем производительность фронтенда через вкладку Performance в DevTools
Наш продукт — высоконагруженный, как в части бэкенда, так и в части фронтенда. БольшУю нагрузку на web-часть дают графики метрик наблюдаемых баз данных. Нагрузочное тестирование бэкенда в нашей команде — тема отдельной статьи, но об этом постараюсь рассказать в другой раз, а сейчас протестируем производительность фронтенда.
Опыт работы с Protobuf на реальном проекте
Исходные условия: у нас было мобильное приложение, написанное на Objective-C (iOS) и Java (Android). Цель — переписать его на современный стек: Swift и Kotlin. Дополнительно нужно было сделать редизайн приложения и обновить бэкенд: поднять Java с 6 до 21. Приложение общалось с бэкендом по HTTP и использовало Protobuf для сериализации данных.
Jira для управления тестовыми проектами: советы по организации работы и документированию
Позволяет ловить баги и фичи на одном бэклоге: по словам Atlassian, в Jira можно «уловить, отследить, решить и отчитаться о багах и проблемах» на протяжении всего процесса разработки.
При этом инструмент предлагает «единый вид всех элементов бэклога — будь то баг или задача по новому функционалу», что помогает приоритизировать общие цели команды. Это значит, что QA могут иметь в Jira общее пространство тест-кейсов, задач на тестирование и найденных дефектов.
Быстрый старт автотестирования с Playwright
На момент моего прихода в компанию автотесты были написаны с использованием стека технологий PHP, Codeception+Selenium. А большинство наших проектов используют фреймворки для разработки, основным языком программирования которых является PHP.
Codeception — мощный инструмент для написания unit, acceptance и API-тестов на PHP. Он объединяет несколько популярных библиотек (например, PHPUnit, Symfony BrowserKit, Selenium WebDriver) в единый фреймворк с удобным синтаксисом.
С Codeception на тот момент я уже был знаком и писал acceptance-тесты на PHP в одной из компаний, где работал QA-инженером. Но на позицию QA-lead в FixPrice я пришел уже с бэкграундом и знаниями по другим фреймворкам автотестирования, таким как Selenide, Appium, Selenium. Ну и, конечно же, с опытом использования и внедрения Playwright+TS.
Англоязычное
Code Reviews Have Already Changed
Reading was the problem already before generative AI. In my TSQA talk from 2022 ‘Something in the way we test’, I was addressing the ridiculous notion of writing 5000 test cases or spending 11 working days just reading them through. In the upcoming 2 years after that I learned over and over again that there really was no relevant answers to any of the realistic queries we had with business representatives captured in the 5000 test cases I chose to put to the side.
Intellectual conformity: tips for software testers
In the 1950s, psychologist Solomon Asch ran a deceptively simple experiment, one of whose trials you can watch on YouTube. Each session included a group of people who were all part of the experiment, but only one was a genuine subject. The others were actors instructed to give clearly wrong answers. The task was to match one line drawn in ink on a display to another of the same length. When the actors unanimously gave an incorrect answer, over a third of the real participants conformed, choosing the same wrong answer despite the correct one being obvious.
Maaret Pyhäjärvi posted the quote above on LinkedIn a few weeks ago. It speaks strongly to me so I asked Maaret if she’d written more (because she’s written a lot) on this specific point. She hasn’t, and the sentence keeps coming back into my head and I’d like to understand why, so I thought I’d try to write down what I take from it.
I think it’s easy to skim read as some kind of definition of exploratory testing but that would be a mistake in my eyes. Testing by Exploring summarises how I felt last time I went into the definition in any depth and, for me, Maaret’s quote is concerned with the why but says nothing of the what or how.
When hiring software testers doesn’t work
I saw a LinkedIn post recently that got me thinking. A recruiter shared a conversation with a startup CEO who argued that software testers “cause more harm than good” when you factor in cost versus benefit. Long story short: he said that if you hire strong developers with quality mindsets, you don’t need people in dedicated quality roles. And honestly? That’s not entirely wrong…
How to Deal With Dismissive Devs
Unfortunately, I don’t expect this behavior to stop anytime soon. Development teams will always feel under pressure to build new functionality and prioritize these tasks over fixing bugs. Some developers also think a little too highly of themselves and refuse to believe that they introduced a defect in their carefully crafted code. It’s also the unfortunate reality that most organizations don’t fully value QA, dismissing this valuable work and instead focusing on the more tangible work of software engineers.
AI-Assisted Testing – The Rules and Roles
Our job as testers is to collect as much information as we can, and learn about the system we test. And our systems are complex, so we need a lot of time for testing. Time we probably will not get.
We say we’re after coverage. But, that’s not some percentage out of a test plan. Real coverage cannot be calculated, because it includes what we thought about, what we explored, and what we haven’t thought about yet. All these scenarios are in the system. We just didn’t go through all of them yet. Or found them.
Generating API test using Swagger JSON + Github Copilot with Playwright
Also known as the OpenAPI Specification (OAS), Swagger JSON is used to document REST APIs by detailing endpoints, request and response formats, authentication mechanisms, data models, and metadata. This format is widely used by software development teams for version control and is highly accepted across services and integrations. Although it is now part of the OpenAPI Initiative, it was originally developed by a company called Swagger, which is why the name still persists.
What I Learned Using GitHub Copilot for API Automation
As AI tools continue to reshape how we build and test software, I was curious: Can I rely on GitHub Copilot — specifically in Agent Mode — to help automate API tests ? Lets do some research today to find out.
How I taught LLM to migrate legacy tests
Now we have a set of prompts for an AI assistant to analyze existing scenarios, written in an non-supported programming language, and create Gherkin code from it. Although, this approach should work basically for any combination of source and destination PLs.
How I Used AI to Diagnose and Recommend Fixes for Flaky Tests
Просто почитать
Разрешения MAX для Android. Cравниваем с Telegram и WhatsApp*
GPT, Gemini, Qwen и Шедеврум переделывает мужского ГГ в женского
Первое — про поколения. Сейчас в доме базовый минимум выглядит как 802.11ac (Wi-Fi 5), теоретически можно передавать данные на скорости до 3,5 Гбит/с, хотя более реалистичной выглядит скорость более чем в 1 Гбит/с по технологии MU-MIMO.
Чуть выше уровнем идёт Wi-Fi 6. Делался с расчётом на плотные квартиры и офисы. Работает сразу на двух диапазонах (2,4 и 5 ГГц), виснет меньше. Это такой среднячок, работающий с многогиговыми потоками и несколькими клиентами. Технология OFDMA для нарезки канала между пользователями снижает латентность (особенно заметно в многоквартирниках). Переход на Wi-Fi 6E частоту вчетверо увеличивает объём радиоволн, позволяя добавить 14 каналов 80 МГц и 7 дополнительных мегагерцовых каналов. В целом у Wi-Fi 6E тот же максимум потенциальной скорости, что и у Wi-Fi 6 (9.6 Гбит/с), но в реальности у него больше скорость и шире диапазон.
Архитектура сомнений: почему программисты ошибаются даже в очевидном
Есть у меня привычка: если код кажется слишком простым, я начинаю нервничать. Это как будто идёшь по идеально ровной дороге и ждёшь, что за углом кто-то обязательно выставит грабли.
Помню, как однажды мы упали в продакшене из-за того, что в одном месте забыли проверить входной параметр на null. Там было всё — ревью, тесты, monitoring. Но не было самой банальной проверки, потому что «да это же очевидно». В итоге очевидность вылилась в трёхдневный пожар и кучу бессонных ночей.
Jailbreak ChatGPT-5, системный промпт, и скрытый контекст
рассмотрим недавно вышедшую модель ChatGTP-5. Из интересного, в этой версии чатбот автоматически делает и запоминает довольно много выводов о самом пользователе, и о том как с ним лучше общаться. Как минимум любопытно посмотреть, что же конкретного о нас он понял. В конце будет рабочий джейлбрейк с примером использования.
Начну со скрытого контекста. Это первое сообщение, с которого начинается любая беседа. Там находится системный промпт и вся дополнительная информация о пользователе и прошлых беседах.
Волонтёр Википедии обнаружил масштабную саморекламу: годы «работы» и 355 статей
«Я обнаружил, по моему мнению, крупнейшую операцию по саморекламе в истории Википедии, которая длилась более десятилетия и охватила около 200 аккаунтов и ещё больше прокси-IP-адресов»
Тупик chatGPT 5: почему это было неизбежно. И что будет дальше
Итак, я попробовал chatGPT-5. Не программирование, впрочем, из 700 миллионов пользователей chatGPT, я сомневаюсь, что хотя бы 5% кодят, решают сложные математические задачи или двигают науку вперед. Что увидел я, как обычный пользователь — галлюцинации, внезапные переключения между моделями с потерей нити беседы, сбои в режиме размышления, банальные тексты, усиленные фильтры и никакого удивления.
Давайте рассмотрим ситуацию более широко, отложим эмоции и посмотрим на холодные цифры. Любая технология живет или умирает в зависимости от ее экономики. И с экономикой у ИИ все очень непросто.
Со слов Альтмана, даже дорогой тариф Pro за $200 убыточен.
Какие выводы можно сделать? Очевидно, что OpenAi скрывает или запутывает свою статистику.
Статистический предел. Ядро LLM — авторегрессионное предсказание следующего токена. Это компрессор культурных закономерностей, который оптимизирует вероятность, а не истину. Он системно стремится к средним, наиболее ожидаемым формам, Это не недостаток, а имманентное свойство его функции обучения. Чем больше вы будете впихивать в модель знаний, накопленных человечеством, тем увереннее модель будет выдавать средний ответ.
Посмотреть:
Gen-A: как искусственный интеллект переворачивает тестирование ⏱️35 минут
Gen-A — инструмент собственной разработки Альфа-Банка. Он уникален тем, что использует искусственный интеллект для генерации тест-кейсов, экономя время, ресурсы и повышая качество ПО. Спикер рассказал, как работает Gen-A, какие задачи решает и как его можно интегрировать в существующие процессы тестирования.
How to Test LLMs, AI Assistants & Agents ⏱️50 минут
Также Required Skills, Salaries и все такое.
Joe Colantonio Kicks Off Testμ 2025 ⏱️15 минут
Founder of Test Guild, as he kicks off the most anticipated software testing event of the year. Don’t miss this exclusive live session packed with insights and a glimpse into the future of testing.
Разбор способов авторизации в Postman (Basic Auth, Bearer Token, JWT, OAuth2.0, API Key, mTLS) ⏱️2 часа 30 минут
Лекция в текстовом формате — https://coreapp.ai/app/preview/lesson/68a9abe82da9b13049ecab60
Is your company tracking your AI usage? ⏱️1 час
In this 100th episode of This Week in Testing, co-hosts Mariem Safi and Simon Tomes celebrate the milestone with a lively, wide-ranging conversation, from MCP server hype to the surprise reality of companies making AI usage mandatory, and even tracking it.
Christine Pinto kicks things off with her experiences improving performance at Epic Test Quest and ponders how MCP servers could change testing workflows. Eamon Droko shares the big news of landing a new role, plus a teaser for his upcoming conference talk. Maneesh Maddala describes how his company connects MCP servers to tools like Figma and Asana, plus what happens when AI usage is monitored across an organisation.
Ady Stokes spotlights the launch of the Software Testing Essentials Certificate (STEC), a project that was over a year in the making, while Gary Hawkes finally makes a successful live mic appearance. Ujjwal Kumar Singh rounds out the discussion with hands-on stories of switching from Gemini to Claude and evaluating LLMs for automation work.
Cypress v15 Release With The New Experimental Studio: First Look ⏱️10 минут
Cypress v15 release http://on.cypress.io/changelog#15-0-0 has the revamped experimental studio with built-in editor support.
Предыдущий дайджест (12-18 августа)
