Home

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

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

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

Вот еще термин, над которым никто не задумывается: нефункциональные требования.

Представьте, что вы описываете практически все растущее в лесах, как «неновогодние деревья». А почти все, что вы едите, теперь «еда, которая не брокколи».

Почему вдруг требования, важные для людей, внезапно слепили в один комок и в какой-то степени лингвистически проигнорировали, обозвав «нефункциональными требованиями»? У меня есть гипотеза на этот счет.

Часть проблемы тут в социальной структуре разработки ПО. Еще часть – в том, что мы зачастую не различаем функции, свойства и требования, и это нас путает. Давайте разбираться.

Люди используют ПО для выполнения задач, коммуникации, хранения данных, обучения, развлечения, помощи в решении проблем; чтобы получить то, что им нужно или желаемо. Это мы называем требованиями.

Человеческие требования можно рассматривать через призму критериев качества. В Rapid Software Testing наш неполный чеклист пользовательских критериев качества включает мощность, надежность, удобство использования, харизму, безопасность, масштабируемость, совместимость, производительность и устанавливаемость. Ряд критериев качества также будет важным бизнесу и разработке – включая поддерживаемость, тестируемость, обслуживаемость, портируемость и локализуемость. Для каждого семейства категорий существуют подкатегории; их можно найти здесь.

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

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

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

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

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

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

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

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

Перефразирую: наши заказчики не думают в терминах функциональных или нефункциональных требований; они думают о требованиях. Так как наш бизнес заключается в доставке ценного ПО и сервисов людям, нам тоже стоит думать именно так.

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

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

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

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

Если нам нужно подчеркнуть конкретное измерение качества, мы можем сослаться на него напрямую (мощность). Если мы говорим о семействе требований, мы можем добавить прилагательное (требования к производительности, требования к доступности). Но если мы говорим в общем, в целом, давайте избавимся от «нефункционального» клейма. Прямо, просто и ясно назовем их своим именем: требования.

Хотите посмотреть видео об этом? Вот оно.

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