Книга: Идеальный программист. Как стать профессионалом разработки ПО
Кто и когда пишет приемочные тесты?
Кто и когда пишет приемочные тесты?
В идеальном мире ключевые участники проекта и служба контроля качества сотрудничают в написании этих тестов, а разработчики проверяют их на логическую непротиворечивость. В реальном мире ключевые участники редко находят время или желание погружаться на нужный уровень детализации, поэтому они перепоручают эту обязанность бизнес-аналитикам, специалистам по контролю качества или даже разработчикам. Если окажется, что тесты должны писать разработчики, по крайней мере проследите за тем, чтобы это были не те разработчики, которые занимаются реализацией тестируемой функциональности.
Бизнес-аналитики обычно пишут «оптимистичные» версии тестов, потому что эти тесты описывают аспекты, обладающие коммерческой ценностью. Служба контроля качества обычно пишет «пессимистичные» тесты с проверкой всевозможных граничных условий, исключений и аномальных случаев. И это понятно, потому что задача контроля качества – думать о том, что может пойти не так.
Согласно принципу «поздней точности» приемочные тесты следует писать как можно позднее, обычно за несколько дней до реализации. В проектах на базе гибких методологий тесты пишутся после выбора функций для следующей итерации или спринта.
Первые приемочные тесты должны быть готовы к первому дню итерации. Новые тесты должны появляться ежедневно вплоть до середины итерации, когда готовы должны быть все тесты. Если к середине итерации некоторые приемочные тесты еще не готовы, переведите нескольких разработчиков на их срочную доработку. Если это происходит часто, включите в команду дополнительных бизнес-аналитиков и/или специалистов по контролю качества.
- Преждевременная точность
- Принцип неопределенности
- Стремление к точности оценки
- Поздняя неоднозначность
- Приемочные тесты
- Что такое «выполнено»?
- Взаимодействие сторон
- Автоматизация
- Дополнительная работа
- Кто и когда пишет приемочные тесты?
- Роль разработчика
- Обсуждение тестов и пассивно-агрессивная позиция
- Приемочные тесты и модульные тесты
- Графические интерфейсы и другие сложности
- Выбор интерфейса для тестирования
- Непрерывная интеграция
- Стоп-сигнал
- Когда нужен постскриптум в бизнес-тексте?
- Покупатель на крючке. Руководство по созданию продуктов, формирующих привычки
- Кто такой тест-менеджер
- Факторы выгоды
- Иерархия объектов в InterBase
- Кто сказал: «Яндекс»?
- Жизненные циклы продуктов
- Имена объектов длиной 68 символов
- 2.5. Разработка технического задания на проведение детального анализа рынка при работе над инновационным проектом. Основ...
- Модули констукторов заданий
- Факторы помощи
- Создание объектов Collection