Home

Автор: Майкл Болтон (Michael Bolton)
Оригинал статьи
Перевод: Ольга Алифанова

Люди иногда говорят, что требования недоступны, имея в виду недоступность документации требований. Тут есть важная разница (к тому же как работают разработчики, если документированные требования отсутствуют?)

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

Требования и пожелания могут быть явными (высказанными, написанными, набросанными, нарисованными, выраженными в табличной форме, превращенными в автоматизированные проверки) и скрытыми (не высказанными, не зафиксированными). Скрытые требования и пожелания могут быть сознательными и подсознательными; люди могут уже сейчас знать о каких-то требованиях, или же осознать их сильно позже.

Эти требования могут исходить от одного человека или прорабатываться совместно, постепенно. Явные требования – это выражения чьи-либо намерений и замечаний о некоторых нуждах и пожеланиях в отношении продукта. Некоторых нуждах и пожеланиях, не всех; и намерений, а не объективной реальности.

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

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

Тестировщик сообщает о реальном поведении продукта и оценивает, представляет ли оно проблему. Многие потенциальные проблемы непредсказуемы и не документированы. Документированные требования редко учитывают возможные затруднения.

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

Умозаключения и проницательность не появляются в голове тестировщика из ниоткуда. Они растут из развитого понимания того, как люди могут использовать продукт; как они получают от него пользу; из путей, которыми продуктовые проблемы могут угрожать его ценности.

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

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

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

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

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

Отсутствие документированных требований может быть проблемой для тестирования. Отсутствие (или нехватка) такой документации может также быть проблемой, которую тестирование помогает разрешить.

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