Автор: Хосе Каррера (Jose Carrera)
Оригинал статьи
Перевод: Ольга Алифанова

Есть ли тут проблема? Почему определенные тесты падают, кажется, всегда

Как тестировщики, мы хотим, чтобы тесты говорили нам, если код продукта ведет себя не так, как мы ожидаем. Во многих окружениях непрерывной интеграции и деплоя (CI/CD) мы привыкли ожидать, что упавшие тесты будут «красными» на дашборде результатов. Красный цвет сообщает, что где-то есть проблема.

Тесты, которые падают время от времени, особенно в областях продукта, подверженных регрессионным дефектам, очень полезны, ЕСЛИ становятся красными по веской причине: когда внедрен дефект, или в тест-окружении произошло что-то неожиданное.

Автор: Анна Север (Литвинова), Ведущий инженер по качеству, Рексофт

Любите ли вы чек-листы так, как люблю их я?

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

В этом процессе осознали, что каждый обращает внимание на что‑то своё, и пора бы это стандартизировать и расшарить на команду (обмен опытом, наш любимый). Так был создан чек‑лист проверок для ревьюера тест‑кейсов.

Хорошая практика, когда сначала по нему проходишь сам, а потом уже отдаёшь коллеге в более чистом виде. С ним, кстати, удалось и подтянуть менее опытных коллег — например, они использовали его как шпаргалку, где ожидаемый результат должен быть 400, а где — 404, какие проверки валидны, какие — уже и нет, а какие — следует добавить. Поехали!

Автор: Венкат Рамакришнан (Venkat Ramakrishnan)
Оригинал статьи
Перевод: Ольга Алифанова

Тестирование персональных предложений критически важно для приложений, применяющих ИИ и предлагающих такую возможность. Эти предложения важны как для Apple Intelligence в iPhone 16.0, так и для других областей, так как применяются для:

• Предложения часто используемых приложений
• Уведомлений на основании времени, локации или деятельности
• Рекомендаций при поиске (приложений и виджетов)
• Интеллектуального ввода текста.

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

Автор: компания Simbirsoft

Вот уже пару лет чат-боты, основанные на больших языковых моделях, «гремят» на весь интернет. Поражают своими возможностями и делают то, о чем около 15 лет назад можно было услышать только в фантастических сюжетах. При этом важно что, сейчас Large Language Model (LLM) дошли до широкого круга потребителей и все могут их увидеть и протестировать. В связи с этим возникают дискуссии, размышления, статьи-прогнозы на тему того, как искусственный интеллект (ИИ) изменит рынок труда, кого заменят, сократят, а кто останется и т.д. Профессия QA и процессы тестирования тоже не остались без подобных рассуждений. 

Меня зовут Андрей, я QA-специалист в компании SimbirSoft. В этой статье хочу поделиться опытом и впечатлениями моих коллег в использовании ИИ для рабочих задач.

Автор: Саймон Томс (Simon Tomes)
Оригинал статьи
Перевод: Ольга Алифанова

Сообщество тестировщиков – собрание умных людей с богатым опытом и множеством идей. Мы собрали ряд идей для тестирования ПО – возможно, они помогут вам при регрессионном тестировании, тестировании API, исследовательском тестировании, мобильном тестировании, тестировании миграции данных, релизном тестировании, следующем bug bash и многом другом!

Как этим пользоваться:

1. Проматывайте список вверх-вниз, остановитесь на случайном месте страницы.
2. Выберите любого тестировщика и станьте им (некоторые тестировщики предложили более одной идеи).
3. Посмотрите на эвристику тест-идеи.
4. Примените ее при следующей сессии тестирования.

БОНУС: скомбинируйте несколько идей.

ДВОЙНОЙ БОНУС: свяжитесь с автором и поблагодарите его. Дайте ему знать, что он вам помог.

ТРОЙНОЙ БОНУС: поделитесь своим успехом в клубе.

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

Я Михаил Бибик, работаю в СберТехе QA‑automation‑инженером, пишу автотесты для СУБД Pangolin — это целевая СУБД в Сбере и не только. В прошлом году наша команда искала и нанимала QA‑инженеров с различным опытом, в том числе совсем начинающих. Когда я провёл штук 15–20 собеседований, то понял, что могу обобщить некоторые наблюдения и составить простые советы по поводу составления сценариев тестирования для начинающих (скорее, очень начинающих) тестировщиков. В этой статье я покажу, как применить теорию тестирования на техническом собеседовании. Для этого разберу реальную задачу с нашего собеседования.

Автор: Томаш Балог (Tamás Balog)
Оригинал статьи
Перевод: Ольга Алифанова

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

В ходе моей карьеры значительная часть моей тест-автоматизации включала применение какого-либо BDD-фреймворка – например, инструменты вроде Cucumber или JBehave. Как человек, который программирует, я всегда интересовался рефакторингом, сокращающим количество стандартного или дублирующего кода – кода становится меньше, и он становится понятнее. Это включает и сокращение стандартного кода в методах определения шагов и прочем связующем коде. Как их упростить? Или вообще от них избавиться?

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

Только как быть, если в вашей команде уже не 5 человек, а 15, и вручную отслеживать данные стало непросто?

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

Под катом рассказываем, как мы начали (и продолжаем) централизованно мониторить эффективность нашего QA-направления. Поэтапно и с практическими советами. 

Привет, меня зовут Василий, я Deputy CTO в Сравни. Уже пару лет мы централизованно мониторим производительность в командах, чтобы видеть реальную рабочую нагрузку, выявлять сложности в процессах и влиять на персональное развитие сотрудников. Речь, по сути, о визуализации данных из корпоративного таск-трекера — по настраиваемым полям получаем на дашбордах данные в нужном нам разрезе, на их основе делаем выводы.