Home

Автор: Майкл Болтон (Michael Bolton)

Оригинал статьи: http://www.developsense.com/blog/2017/10/at-least-four-things-for-testers-to-do-in-planning-meetings/

Перевод: Ольга Алифанова

Сейчас много говорят про DevOps, Agile-разработку и «сдвиг влево». Очевидно, эти процессные модели совершили открытие: тестировщики могут не только тестировать готовый продукт, и они могут и должны быть вовлечены в каждую стадию разработки.

Это не новость для курса «Rapid Software Testing». Мы изначально отвергли идею, что продукт должен быть завершен/соответствовать определенному уровню качества или неким «приемочным критериям», чтобы перейти в тестирование. Мы приветствуем возможность протестировать что угодно, выданное нам. Мы с радостью начнем тестирование с момента зарождения идеи продукта до момента, наступившего спустя долгое время после релиза.

Если тестировщиков приглашают на планерку, то продукт для тестирования еще отсутствует как класс. Что же нам там делать?

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

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

Мы пришли, чтобы ратовать за тестируемость. Тестируемость может появиться и случайно, без нашей помощи. Задача ответственного тестировщика – убедиться, что тестируемость внедрена намеренно, умышленно. Отметим, что тестируемость не относится исключительно к неотъемлемым свойствам продукта. Факторы, относящиеся к проекту, концепциям ценности, и нашему пониманию отрыва от рисков, тоже влияют на тестируемость. Тестируемость также субъективна по отношению к нам, нашим знаниям и навыкам, и нашим взаимоотношениям с командой. Часть нашей работы во время подготовки к разработке – это просьбы о помощи, необходимой нам для более мощного тестирования.

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

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

Мы, как тестировщики, стараемся выявить проблемы в том, о чем говорят люди на совещании. Мы пытаемся определить преграды, которые помешают пользователю достичь цели; то, что может сделать продукт неэффективным, непродуктивным или непривлекательным. Мы думаем о том, что помешает достичь бизнес-цели или похоронит наши сроки. Мы переключаемся между деталями и общей картиной. Мы стараемся выяснить, почему наши критерии готовности могут быть неадекватными – можем ли мы впасть в самообман, веря, что все готово, хотя на самом деле это не так? Мы стараемся оспорить утверждение, что все хорошо, если где-то кроется плохое.

Мы пришли, чтобы утвердить себя в роли тестировщиков. Роль – это эвристика, помогающая управлять временем, фокусом внимания и ответственностью. Роль тестировщика – это обязательство предоставить ценные и необходимые ресурсы; концентрироваться на поиске проблем, в идеале – как можно раньше, пока они еще невелики, чтобы предотвратить их превращение в большие затруднения. Это создание продукта и проекта, которые позволяют быстро и недорого исследовать и изучать их. Это оспаривание идей и артефактов, известных нам о продукте и его дизайне. Все эти задачи сложны как социально, так и психологически, эмоционально, политически. Если мы не можем достойно с ними справиться, то роль, сконцентрированная на проблемах и вопросах, будет расценена как разрушительная, а не как неотъемлемая часть процесса создания прекрасного.

В курсе Rapid Software Testing мы не утверждаем, что кому-то необходимо играть роль тестировщика или называться так. Мы верим, что наличие человека, ответственного за роль тестировщика, помогает сконцентрироваться на задаче предоставления полезной обратной связи. Это ресурс, а не препятствие для проекта. Это требует поддержки близкой социальной дистанции вкупе с поддержкой приличного критического расстояния.

Конечно, все эти четыре вышеупомянутых занятия верны для любой модели разработки. Ими можно заниматься не только на планерках, но и в любой момент общения с командой, в любой момент развития проекта, и на любом уровне детализации или формализации. DevOps, Agile, «сдвиг влево» - это контексты. Но тестирование всегда остается тестированием.

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