К моим заметкам на полях, выписки из нижеуказанной книги.
Организация тестирования может достаточно сильно отличаться в различных компаниях. Всё зависит от количества тестировщиков, уровня автоматизации тестирования, типа системы (просто сервер + интернет приложение или, возможно, вы выпускаете «коробочные» версии программ?), частоты релизов, критичности ПО (блог-сервер или система управления полётами) и т.д.
Максимально увеличить эффективность ручного тестирования, т.е. найти лучших тестировщиков, обеспечить их лучшими инструментарием и убедиться, что они сообщают о тех задачах, которые отнимают много времени и могут быть автоматизированы.
Для начала, тестировщику следует заняться подготовкой к тестированию. А именно: написанием спецификаций тестов, подготовкой тестового окружения и так далее. Таким образом, когда у разработчика появится что-нибудь готовое к тестированию, тестировщик должен быть готов начать тестирование.
Если команда практикует TDD, люди с первого дня заняты написанием тестирующего кода. В этом случае, тестировщик может заняться парным программированием с разработчиками, пишущими тестирующий код. Если же тестировщик вообще не умеет программировать, ему следует работать в паре с разработчиком в роли "штурмана", дав напарнику возможность печатать. У хорошего тестировщика обычно получается выдумать больше разных тестов, чем у хорошего разработчика, поэтому они друг друга дополняют. Если же команда не занимается TDD или же количества подлежащих написанию тестов недостаточно, чтобы полностью загрузить тестировщика, он просто может делать всё что угодно, чтобы помочь команде достичь цели спринта. Как и любой другой член команды. Если тестировщик умеет программировать – отлично. Если нет, команде придется выявить все задания, не требующие навыков программирования, но которые необходимо выполнить за спринт.
Задания, не требующие навыков программирования:
1.Установить и настроить тестовое окружение.
2.Уточнить требования.
3.Детально обсудить процесс установки.
4.Написать документы по установке (заметки к релизу, readme.txt или что там требуется в вашей компании).
5.Пообщаться с подрядчиками (например, с дизайнерами пользовательского интерфейса).
6.Улучшить скрипты автоматизированной сборки.
7.Последующее разбиение историй на задачи.
8.Собрать ключевые вопросы от разработчиков и проследить, чтобы они не остались без ответов.
©Хенрик Книберг, книга «Scrum и XP, заметки с передовой» (перевод Agile Ukraine).
http://www.crisp.se/henrik.kniberg
http://blog.crisp.se/henrikkniberg
Комментариев нет:
Отправить комментарий