Автор:

В бытность младшим QA-специалистом я быстро поняла, что не каждому разработчику нравятся те типы багов, которые я находила. Некоторые баги существовали годами до того, как я их обнаруживала, а другие было невероятно сложно воспроизвести. Я шутила, что мне нужно держать на столе целую горку леденцов на случай, если разработчики подойдут попросить продемонстрировать баг, который я описала. Непросто бывает услышать, что что-то не работает, и иногда сладости очень помогают.

Спустя годы работы в тестировании я поняла, что QA — это не просто проверка того, есть ли тут баг. Качество — это умение отстраниться и оценить все типы циклов обратной связи. Это может быть процесс, встречи, в которых мы участвуем, отчёты или формы регистрации багов. Оценка наших циклов обратной связи может помочь нам понять, получаем ли мы эффективную обратную связь, необходимую для принятия чётких решений.

Конечно, я говорю не о настоящих конфетах - мы будем использовать эвристику CANDY, которая поможет командам предоставлять друг другу и самим себе прекрасную обратную связь.

Твой тимлид открывает Jira и смотрит на статистику: за две недели ты завел три дефекта. Три. Он спрашивает, чем ты занимался все это время. Ты начинаешь объяснять про двадцать багов, исправленных через личку с разработчиками. Он кивает и говорит: «Понятно. Но в системе этого нет».

Через неделю тебя включают в список на сокращение. Это не страшилка. Это реальность для тестировщиков, которые считают, что быстрая личка эффективнее формального баг-трекера. В этой статье я расскажу, с какими рисками сталкиваются тестировщики ЛАНИТ и других ИТ-компаний, когда заменяют баг-трекер личными переписками, и как это защитит твою карьеру.

Автор:

В пространстве Rapid Software Testing критическое мышление — это мышление о мышлении с целью не быть обманутыми. У нас есть простая мнемоника, которая запускает критическое мышление: WHeReAS. Задавайте вопросы: Кто? А? Правда? И что? И что с того?

Долгое время в нашем списке вопросов были только последние четыре пункта. Оценка наблюдения или утверждения зависит от того, убедились ли мы, что поняли утверждение или идею, которую рассматриваем. Это «А?». «Правда?» — о достоверности утверждений. «И что?» побуждает подумать о том, что могло быть упущено. А «И что с того?» — о последствиях и о том, стоит ли предпринимать какие-то действия.

Некоторое время назад один из наших коллег указал на то, чего не хватало в этой небольшой модели: социального измерения. Избежание ошибок в мышлении зависит от мотивов, экспертизы и надёжности людей, которые эти утверждения озвучивают. Поэтому мы добавили «Кто?». Кто говорит?

В выпуске собраны ссылки на новые статьи, слайдкасты, отобраны самые интересные публикации в ленте блогов.

Содержание рассылки доступно по ссылке.

Подписаться на рассылку

Работая в Сбере, я столкнулся с тем, что общепринятым инструментом для функционального тестирования в моем трайбе был JMeter. Нравится ли мне это? Вопрос второстепенный. Приходилось работать с тем, что есть. По мере того как разрастались наши компоненты и их функциональность - разрастались и JMeter-тесты. Если кто не сталкивался - вся логика JMeter-тестов описана в файле с расширением .jmx. По сути это XML-файл, содержащий в себе всю логику тестов: вызовы endpoints, проверки JSON и прочая логика. И если подойти к этому вопросу без знания, то можно столкнуться с такой же проблемой, как у нас: файл разросся до 50 000+ строк и вносить/ревьюить/поддерживать его стало крайне сложно. Я нашёл способ уменьшить размер файла в 10 раз. Давайте же вместе распилим этот монолит)

• правильно сформулировать задачу для автоматизации;
• проверить, что именно ИИ написал (а он может сделать неправильно, но, чтобы это понять, нужна база, которую дает курс)

Автор:

Мы с Джеймсом Бахом разработали предварительный набор эвристик-ориентиров для «синдромов» нежелательного поведения больших языковых моделей — устойчивых паттернов проблем, которые мы наблюдали и за которыми теперь можно системно следить.

Это не взаимоисключающие категории; они могут пересекаться или взаимодействовать друг с другом.

Примечание: наши названия для этих категорий могут показаться антропоморфными. Мы на самом деле не считаем корректным приписывать человеческие свойства машинам, которые генерируют вывод стохастически. Но если поклонники ИИ утверждают, что их большие языковые модели ведут себя «прямо как люди!», наш ответ в том, что это поведение часто похоже на поведение крайне дисфункциональных, некомпетентных и ненадёжных людей.

Меня зовут Александр, я из Сбера, лидер по автоматизации в Департаменте Сервисы и Безопасности. В тестировании я около 13 лет, и последние лет 10 занимаюсь автоматизацией и её развитием в своём подразделении.

В этой статье расскажу, как с помощью IDE, LLM и RAG‑подхода можно автоматизировать одну из самых рутинных задач автоматизаторов — разработку новых автотестов по ручным сценариям, и при этом сохранять стиль и архитектуру проекта.

Где мы сейчас: ИИ уже в разработке, но почти не в автотестах

По данным недавнего опроса StackOverflow, 84% разработчиков постоянно используют ИИ‑ассистенты в своей работе. Для них это такой же привычный инструмент, как IDE или Git.

Как обычно работает подобный ИИ‑помощник в IDE:

• анализирует открытые файлы;

• дополнительно смотрит на соседние файлы в проекте;

• учитывает локальный контекст: какие вопросы вы задавали и какой код меняли.

А вот автотестировщики часто оказываются как будто «на обочине» этой ИИ‑революции.

Автор:

Как можно использовать GPT в тестировании? Некоторые предлагают использовать его для генерации тестовых данных. Случайные тестовые данные могут помочь предвзятости меньше влиять на тестирование.

Можно предположить, что заставить бота генерировать случайные данные по простому промпту — это легко. Поэтому я провёл небольшой разовый эксперимент «первого барьера» 24 июля 2025 года, используя Google Gemini 2.5. Здесь отмечу случаи, соответствующие пунктам из нашего списка синдромов больших языковых моделей — шаблонов неправильного поведения, которые мы с Джеймсом Бахом наблюдали у LLM.

Сторонники ИИ часто делают чрезмерно громкие заявления о том, что GPT может делать что-то «как человек» — и нередко намекают, что GPT лучше людей, потому что быстрее и имеет мгновенный доступ к информации в интернете. Чтобы это было правдой, нужно на разумных основаниях ожидать, что GPT выполнит задачу так, как было запрошено, и учтёт возможные недопонимания по ходу дела. Это ожидание не оправдывается.

Специфика продуктов InfoWatch состоит в анализе самых разнообразных данных. Поэтому практически каждый автотест требует подхода с широким набором параметров. Для нашей команды хорошим решением стало вынести генерацию параметров pytest.mark.parametrize в отдельный компонент, который собирает данные из файловой коллекции проекта.

Существует множество способов параметризировать тестовые функции. Эта статья — пример изящной параметризации Pytest для сценариев, основанных на файловой коллекции проекта с большим количеством данных. Расскажем про наш опыт решения такой задачи.

Параметризация Pytest позволяет сделать из теста каркас, шаблон, который принимает данные для конфигураций, для assert и т.д.

Автор:

В противовес моей идее о том, что тестирование программного обеспечения должно быть ролью, а не просто задачей, мне иногда говорят, что «настоящий Agile» этого не допускает. Почему? Потому что в Agile «качество — ответственность каждого». Это утверждение иногда подаётся так, будто это моральная истина, не подлежащая обсуждению, или же как моральное достижение, уникальное для аджайлистов, будто предыдущим поколениям разработчиков программного обеспечения никогда не приходило в голову помогать друг другу создавать хорошие вещи.

В любом случае, для меня это не имеет смысла.

Первая мысль, которая приходит в голову: «Я говорю о тестировании, а не о качестве. Почему сюда притягивается качество?» Тестировщики не обеспечивают качество. Тестировщики НЕ МОГУТ обеспечить качество. Тестировщики сейчас и никогда не «владели качеством» ни в каком смысле.

Но даже если отложить это в сторону, качество не должно считаться «ответственностью каждого». Вот почему меня беспокоит эта формулировка:

Недавно знакомый PM попросил рассказать «Что значит отвечать за качество?» в контексте продуктовых команд. Вопрос оказался не из простых, ведь каждый проект имеет свои особенности. Да и понятие качества может отличаться. Ниже — мой взгляд на тему через призму измеримых показателей. Если у вас есть дополнения, другие метрики или иной управленческий опыт — велкам в комментарии. Будет интересно обсудить и расширить картину.

Начну немного издалека. Последние лет пять тема продуктовых команд очень популярна. Тестировщиков из «колодцев» и подчинения QA лидам и хэдам забирают в команды. Если сначала было матричное управление с функциональным руководством, то последние годы растет тренд на отказ от QA лидов с передачей функции лидам продуктовых команд.

Автор:

Никто не любит переключаться между контекстами, и я не исключение. Когда я глубоко погружён в работу, то обычно записываю заметки где-нибудь сбоку и продолжаю работать.

Но после завершения сессии концентрации обычно приходится сталкиваться со скучной и длительной задачей — переносить эти заметки в систему тикетов, чтобы команда могла обработать обратную связь по продукту и баг-репорты.

И поскольку мне нравится автоматизировать свои проблемы, я решил упростить это с помощью инструментов, которые пробовал в последнее время. Покажу, как использовал Goose, Playwright MCP и их новое расширение Playwright MCP Bridge для Chrome, чтобы автоматизировать скучную задачу создания множества тикетов во внутренней системе отслеживания задач.

Мы регулярно сталкиваемся с ситуациями, когда в Jira к задаче вроде есть какое-то описание, стоит статус «готово», но, чтобы понять, в чем была проблема, что было исправлено, как было проверено, приходится «нырять» в мессенджер или звонить коллегам. Все это съедает время, размывает ответственность между командами и мешает выпускать продукт быстро, качественно, в срок.

Вот несколько реальных примеров, когда описание к задаче похоже на квест:   

Автор:

Существует множество способов «ускорить что-то в 10 раз».

• Ехать со скоростью 300 миль в час по оживлённой городской улице.
• Съесть 15 000 калорий за один приём пищи.
• Завести десять собак.
• Родить десять детей.
• Завести сотни друзей.

У всех этих вещей есть вполне очевидные последствия и побочные эффекты. Даже простое наличие гораздо большего количества друзей заставит понимать дружбу гораздо поверхностнее, чем можно было бы себе позволить. Так почему же, когда фанаты ИИ говорят о «десятикратном» росте своей продуктивности, они никогда не упоминают о побочных эффектах?

Потому что они говорят и действуют безответственно.

Это третья статья из серии. В первой я разобрал 5 техник тест-дизайна, во второй - API и Security Testing на собеседованиях. Сегодня тема другая - не техническая. Хочу поговорить про роли в команде.

Недавно я попал на концерт симфонического оркестра. Сижу в зале, 80 музыкантов на сцене, всё серьёзно - скрипки, виолончели, духовые. И тут дирижёр поднимает палочку, зал затихает, и у меня в голове:

«Подожди... а зачем он вообще нужен? Они же все профессионалы. Ноты перед глазами. Каждый знает свою партию. Ну начните играть, чего ждать-то?»

И тут меня накрыло. Я же слышу такое каждый месяц на работе:

«Зачем нам QA? Разработчики сами протестируют.»

«Зачем менеджер? Мы сами разберёмся, мы же взрослые.»

Одна и та же логика. И там, и тут. Давайте разберу, почему она не работает.

Автор:

Когда вы пишете end-to-end тесты, аутентификация часто становится первым барьером. Невозможно протестировать реальную функциональность приложения, не пройдя сначала экран логина. Но современные методы аутентификации могут усложнять автоматизацию, используя несколько факторов, которые трудно автоматизировать (в этом и заключается смысл 2FA).

Обычно с этим справляются, либо отключая такие методы в тестовых окружениях, либо используя различные обходные решения. Кто-то может сказать, что это уже не настоящее e2e-тестирование. Честно говоря, это, скорее, тема для отдельной дискуссии, но критика подхода с обходом логина определённо имеет основания.

Так как же правильно работать с аутентификацией?

Предисловие

Эта статья — не критика Agile или Kanban как подходов и не попытка доказать, что в IT «всё делают неправильно». Я делюсь наблюдениями из собственного опыта работы с качеством в промышленности, энергетике, а затем — в IT‑продуктах.

Речь пойдёт не о терминах и инструментах, а о том, как часто теряется системное мышление, когда сложные управленческие модели упрощаются до ритуалов.

Если у вас уже выстроена работа и всё стабильно — это отлично. Если нет — возможно, некоторые наблюдения покажутся полезными

Автор:

ИИ-ассистенты для написания кода - Claude Code, Cursor и GitHub Copilot, - становятся частью повседневного рабочего процесса. Они читают файлы, понимают кодовую базу и помогают писать код быстрее. Но есть проблема — они также могут читать .env-файлы. В последнее время в соцсетях ходит история об этом, и я сам столкнулся с этим на практике:

Всем привет! Меня зовут Юлия, и уже 6 лет я занимаюсь тестированием. За свою карьеру я успела принять участие в разных проектах компаний от стартапов до гигантов индустрии, тестировала бэк, фронт, мобилки, веб и даже устройства интернета вещей, успела дорасти до тимлида и начать осваивать автоматизацию.

В этой статье я поделюсь своим опытом QA-инженера и расскажу о самых распространенных ошибках, которые могут убить ИТ-продукт на корню. Я собрала примеры из реальной жизни, чтобы показать, как даже самые мелкие недочеты могут обернуться огромными проблемами.

Все хотят успешный ИТ-продукт. Но создание успешного ИТ-продукта – это настоящее искусство, требующее от команды не только технических навыков и софт скилов, но и глубокого понимания потребностей пользователей. Правда убить продукт намного легче, чем сделать качественный. Далее расскажу, какие методы убийства я встречала чаще всего. В конце составила чек-лист, как спасти ИТ-продукту жизнь…

Автор:

В недавней статье я писал о том, как использовал Claude Code для анализа кода RestAssured.Net и выполнения рефакторинга, используя написанные вручную тесты в качестве страховочной сетки. В той статье я упомянул, что не хочу, чтобы Claude трогал сами тесты, и объяснил, почему. Тем не менее, мне было любопытно самому выяснить, на что способен Claude с точки зрения написания тестов и насколько оправдано доверие, которое всё больше людей возлагают на тесты, созданные LLM.

В этой статье я поделюсь первыми шагами в этом направлении, а также своими мыслями и ходом рассуждений на этом пути. Вы увидите, как я создаю начальный набор тестов для небольшого API на Spring Boot, который я написал для использования в своих воркшопах, и как я оценивал результат. В следующей статье я покажу, как улучшил набор тестов на основе своих наблюдений, снова используя Claude Code.

Всем привет, меня зовут Олег. В прошлой статье я рассказывал, как генерить автотесты из Swagger и тест-кейсов при помощи OpenAPI Generator + Cursor AI / Claude Code и как с этого всего автоматически снимать покрытие через Swagger Coverage.

В этой статье я хочу рассказать, как мы разбираем упавшие автотесты при помощи интеграции ТестОпс с Яндекс Трекером, MCP TestOps, MCP Яндекс Трекера и Cursor AI / Claude Code.

Но начнем не с AI. Сначала расскажу про сам процесс: зачем нам дефекты в TestOps, как мы руками разбираем запуск автотестов, почему без matcher-правил это быстро превращается в рутину и что именно мы потом автоматизировали.

Автор:

Если вы следите за сферой AI-ассистентов для программирования, то, скорее всего, заметили, насколько быстро всё развивается. Новые модели выходят каждый месяц, и все пытаются выявить «правильный способ» работы с этими инструментами. Я провёл последние пару месяцев, создавая тесты на Playwright с помощью Cursor, и, честно говоря, прошел через множество проб и ошибок. Некоторые вещи работали отлично, другие… не очень.

Я решил собрать всё, чему научился, в этом посте. Давайте разберёмся.

Я хочу рассказать, как я сделала отчет о дифференциальном тестировании (сравнение двух функций на одних данных) через ИИ. Знаю, что многие уже применяют ИИ и в хвост и в гриву, но также много тех, кто пока не умеет этого делать.

Поэтому я хочу показать на конкретном примере из жизни, где еще несколько лет назад пришлось бы делать красивый отчет в ручную, а теперь его делает робот за пару минут. Возможно, это вдохновит вас тоже попробовать сделать нечто похожее =))

Автор:

Как некоторые из вас, вероятно, знают, воркшопы и обучающие курсы, которые я провожу, выступления, которые делаю, и статьи, которые пишу, как правило, сосредоточены на фундаментальных навыках тестирования ПО, разработки и автоматизации тестирования, а не на последних технологиях и трендах. Я просто не очень-то «работаю» с трендами. Тем не менее, я много читаю о том, что думают и пишут по поводу этих технологий другие, поскольку я независимый консультант и просто не могу позволить себе не следить за тем, что происходит в индустрии.

До недавнего времени я в основном избегал активного использования инструментов ИИ, за исключением ChatGPT, который помог мне составить персональный план тренировок на выносливость для велоспорта. Так было до тех пор, пока я не начал всё чаще слышать, как люди обсуждают Claude Code и насколько он хорош, особенно с новой моделью Opus 4.6. Это подтолкнуло меня проверить самому, действительно ли он полезен, и эта статья, вероятно, первая из цикла, где я буду делиться своими наблюдениями и выводами.

Конечно, можно было бы начать с создания чего-то с нуля (или «vibe coding», как сейчас модно говорить), но мне не кажется, что это хороший способ понять, что именно ИИ может дать для моей работы. В конце концов, я не занимаюсь созданием принципиально новых вещей, а помогаю людям выполнять уже существующие и важные задачи — в моём случае это тестирование и автоматизация — лучше и эффективнее.