Home

Автор: Майкл Болтон (Michael Bolton)
Оригинал статьи
Перевод: Ольга Алифанова

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

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

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

Меня зовут Владислав Тимашенков, я занимаюсь автоматизацией тестирования в ГК InfoWatch. Мы разрабатываем DLP-систему для защиты контента и предотвращения утечек информации.

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

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

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

Автор: Джеймс Бах (James Bach)
Оригинал статьи
Перевод: Ольга Алифанова

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

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

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

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

Автор: Пономарева Анастасия

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

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

Автор: Филип Рик (Filip Hric)
Оригинал статьи
Перевод: Ольга Алифанова

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

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

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

На связи Анастасия Шильникова, менеджер по тестированию компании «Гарда».

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

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

Автор: Джеймс Бах (James Bach)
Оригинал статьи
Перевод: Ольга Алифанова

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

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

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

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

Оригинальная публикация

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

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

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

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

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

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

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