Автор: Джефф Найман (Jeff Nyman)
Оригинал статьи: http://testerstories...lient-strategy/
Перевод: Ольга Алифанова
Цель практически всех проектов по разработке ПО – это разобраться, как именно система будет добавлять бизнесу ценность. Эта цель достигается путем постоянных переговоров, в ходе которых исследуется, разрабатывается и расширяется общее понимание того, что именно нужно создать и почему. Тестировщики должны вносить свой вклад в эти переговоры проактивно, а не заниматься исключительно чтением результатов чужих обсуждений и тупым выполнением задач, переданных в тестирование.
Эластичность и давление
Когда я говорю об эластичности, я имею в виду способность системы (неважно, людей или технологии) подстраивать функциональность перед, во время или после изменений или неувязок так, что система продолжает функционировать как в ожидаемых, так и в неожиданных условиях.
Коммуникация между командами – это способ повлиять на проектные решения приложения, сформировать список возможностей для развития и быстро принять решение, какие фичи нужно разрабатывать. Для того, чтобы этот подход был успешным, тест-команда должна быть эластичной.
Что это значит на практике? Это значит, что не нужно привязываться к куче артефактов или огромным тест-сьютам (неважно, автоматизированным или нет) – их сложно каждый раз менять по результатам вышеописанных переговоров. Если учесть, что в идеальном мире такие переговоры итеративны, тест-команды должны тащить на себе минимальный "багаж" из артефактов вроде тест-кейсов и тест-инструментов.