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

В прошлый раз мы рассмотрели, чего бизнес хочет от разработки. А чего бизнес хочет от той части разработки, которую мы называем тестированием?

Иногда говорят, что бизнесу от тестирования нужна уверенность — подтверждение того, что всё в порядке. Это понятно: уверенность — приятное чувство для дизайнеров, разработчиков, менеджеров и всех остальных. Но уверенность и спокойствие — это не цель бизнеса. Цель бизнеса — ценный, беспроблемный продукт.

Автор: Рависурия Ишвара (Ravisuriya Eswara)
Оригинал статьи
Перевод: Ольга Алифанова

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

А вместе с техническим долгом неизбежно появляется и тестовый долг. Определение и понимание объема и значимости тестового долга — часть моей работы.

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

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

Задача любого тестировщика — проверять продукт на соответствие установленным требованиям и своевременно отлавливать любые баги и ошибки. В идеальных условиях или небольших проектах эта схема работает безотказно. Но в ситуациях, когда над продуктом работает несколько команд разработки, в релизы попадает по 30–70 задач, а обновления выкатываются каждую неделю, фокуса тестировщиков может просто не хватить. В таких условиях не обойтись без Quality Gates.

Меня зовут Юлия Садовникова. Я старший специалист по тестированию в команде Core Android компании ОК. В этой статье я расскажу о Quality Gates в ОК и о том, как QA может не просто тестировать, а реально влиять на проект и процессы.

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

Что такое тестирование, управляемое через страх?

Тестирование, управляемое через страх (FDT), — это непреднамеренный подход к тестированию программного обеспечения, возникающий в ситуациях, когда участники процессов обеспечения качества (QA-инженеры, разработчики, бизнес-аналитики и другие) выполняют свои задачи в первую очередь из страха, что дефекты могут ускользнуть и попасть в продуктив.

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

• Разделяется ли ответственность за качество между всеми участниками команды?
• Где находятся контрольные точки качества (quality gates)?

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

Всем привет! На связи Андрей – QA-лид из Совкомбанк Технологий.

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

В этой статье разберем сколько QA-инженеров нужно проекту, от чего это зависит и есть ли корреляция количества тестировщиков с количеством разработчиков. 

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

В статье рассмотрим:

• Оптимальное соотношение QA-инженеров и разработчиков

• Соотношения, которые существуют в реальных проектах и их особенности

• Параметры, которые нужно учитывать, чтобы вывести оптимальное соотношение

• Вывод идеальной формулы

Цель статьи – найти идеальный баланс количества людей в команде, отталкиваясь от сути проекта. 

Евгений Гусинец, Middle+ QA Engineer, автор телеграмм канала о тестировании QA❤️Life https://t.me/QA4Life

На связи Евгений Гусинец — Middle+ QA Engineer из Минска, ментор и автор ТГ‑канала QA❤️4Life. Добро пожаловать в мою небольшую подборку «тестировочной рутины» и советов, как с ней справляться! Наверняка, многие из вас узнают себя в этих ситуациях. А может быть, вы даже сможете поделиться своими «любимыми» повторяющимися задачами в комментариях? В любом случае, надеюсь, этот пост поднимет вам настроение и, возможно, даст пару полезных идей.

Ох, рутина… Это такое знакомое слово каждому, кто хоть раз окунался в мир IT, и тестировщики тут, поверьте, не исключение. Казалось бы, каждый день что‑то новенькое, баги выискиваем, приложения ломаем по‑хорошему... Но если копнуть глубже, у каждого тестировщика найдется свой «день сурка» из повторяющихся задач. Давайте вместе посмеемся (или погрустим?) над этими моментами, разбавив это дело мудростью из книжек, которые не раз помогали мне и моей команде.

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

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

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

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

Автор: Гуськова Мария (работает в стриминговом сервисе, ведет свой телеграмм канал @mashaqasha и на досуге пишет статьи на Хабре), https://t.me/mashaqasha

Привет! Я — Маша, которая заваривает qaшу (и иногда крепкий кофе, когда глаза уже отказываются фокусироваться на экране).

Сегодня хочу поговорить о проблеме, с которой сталкивался, наверное, каждый тестировщик (и не только). В один «прекрасный» день ты садишься проверять фичу или делать регресс, а баги просто перестают быть видны. Ты кликаешь, прогоняешь сценарии, но будто слепнешь — всё кажется рабочим. А потом оказывается, что пропустил очевидный косяк, и по цепочке начинается: чувство вины → стресс → ещё большая усталость → ещё больше ошибок.

Знакомо? Тогда давайте разберёмся, как выбраться из этой ямы, пока она не превратилась в профессиональное выгорание.

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

Ловкость рук и никакого обмана: что такое Гейзенбаг?

Сталкивались ли вы с дефектом, который, казалось бы, отрицает логику и увиливает от всех попыток его воспроизвести?

Если ваш ответ «Да», то уверяю, вы не одиноки.

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

Из-за этого такие проблемы часто называют «невоспроизводимыми дефектами» или, как я недавно узнал, «Гейзенбагами». Одна из основных характеристик Гейзенбагов заключается в том, что любая попытка понаблюдать за ним или подебажить может потенциально изменить поведение кода приложения. Вы просто хотите понаблюдать за проблемой – и непреднамеренно меняете условия ее воспроизведения. Мы об этом еще поговорим.