Home

Автор: Саманта Коннелли (Samantha Connelly)
Оригинал статьи
Перевод: Ольга Алифанова

Я рекомендую всем соло-тестировщикам регулярно проводить bug bash/групповое тестирование. Этим можно заняться в конце спринта или цикла разработки функции. Вы приглашаете команду, запасаетесь закусками и напитками и вместе тестируете около часа.

Подготовка

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

Я использую эту доску для проведения bug bash в Insight Timer; слева регресс, в середине – то, что недавно менялось, а прочее, что нужно не забыть – справа.

Необременительная отчетность

Поощряйте необременительную отчетность о багах.

• Баги можно писать на бумаге для заметок
• Добавлять их в общую таблицу
• Или ставить баги напрямую из Slack, используя ярлык /jirio

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

Что тестировать в ходе Bug Bash

У меня есть трехступенчатая эвристика для определения, что тестировать (руководство и правило буравчика):

1. Что недавно менялось? Изменения порождают новые риски. Какие функции были добавлены? Какой код подвергся рефакторингу? Какие библиотеки обновлялись? Сконцентрируйте команду на том, чтобы начать с этих областей.
2. Регресс-тестирование. Подготовьте чеклист из максимум дюжины сценариев основной функциональности (возможно, связанных с регистрацией, оплатой и основными задачами людей в вашем приложении). Попросите коллег учитывать эти кейсы, работая над пунктом 1; возможно, стоит попросить их указывать свое имя у кейса, если они над ним работают, чтобы получить представление о покрытии.
3. Что еще мы должны/можем сделать? Иногда имеет смысл провести сессию тестирования безопасности, производительности или кросс-браузерности, но это необязательно должно происходить каждый раз.

Тестируйте на проде

Тестируйте на проде, если можете. Ни одно окружение с ним не сравнится.

Если это невозможно, убедитесь, что ваше тест-окружение стабильно, данные настроены, и команда предупреждена – "Не трогаем ничего, кроме необходимого для Bug Bash".

Завершение

Поблагодарите людей за потраченное время, подсчитайте баги и поздравьте самого успешного охотника. Тестирование и качество – ответственность всей команды, в конце концов. Разошлите благодарственные письма с результатами, вручите награды.

Обсудить в форуме