Home

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

В прошлый раз мы рассмотрели, чего бизнес хочет от разработки. А чего бизнес хочет от той части разработки, которую мы называем тестированием?

Иногда говорят, что бизнесу от тестирования нужна уверенность — подтверждение того, что всё в порядке. Это понятно: уверенность — приятное чувство для дизайнеров, разработчиков, менеджеров и всех остальных. Но уверенность и спокойствие — это не цель бизнеса. Цель бизнеса — ценный, беспроблемный продукт.

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

Каково фактическое состояние нашего продукта?

Есть ли проблемы, которые угрожают ценности продукта или успешному завершению работы в срок?

Ответственная команда разработки должна понимать, тот ли у неё продукт, который она хотела получить — или не хотела. Если в нем есть проблема, угрожающая своевременному завершению работы, менеджер, отвечающий за эту работу, должен знать об этой проблеме, чтобы её можно было решить и контролировать. Путь к такому осознанию начинается с признания риска, что нас могут ввести в заблуждение, и что проблемы могут ускользнуть от нашего внимания.

Где могут возникать проблемы? В любом продукте. Как я упоминал в начале этой серии, под продуктом мы понимаем всё, что кем-то создано. Это может быть функциональность в приложении; спецификация, её описывающая; прототип; пользовательская история; однострочное изменение; набор идей о том, кто наши пользователи; сборка или релиз; план проекта; рабочий процесс. Наша работа тоже продукт — от всего проекта в целом до любой части, над которой мы работаем внутри него, на любом уровне детализации.

Какие именно проблемы могут возникать? Для разработчиков программного обеспечения относительно легко думать о проблемах как об ошибках в коде, которые приводят к неправильному результату работы функций. Такие проблемы важны, потому что если функция выдаёт неправильный результат, то, скорее всего, какое-то требование не будет выполнено. Ошибки такого рода относительно просто обнаружить с помощью проверок выходных данных, которые создаются в процессе разработки и могут запускаться после каждого изменения. Эти проверки дают чёткий бинарный результат — да/нет, пройдено/не пройдено; зелёный/красный. Более того, они обеспечивают быструю обратную связь, позволяя разработчикам оперативно исправлять ошибки кода и не давая им зарываться глубже. Здравое управление разработкой будет настаивать на подобном тестировании, выявляющем проблемы в функциях продукта.

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

Рассмотрим ситуацию: некоторые сторонники юнит-тестирования настаивают на том, что если тест требует взаимодействия с базой данных, это не юнит-тест; следовательно, юнит-тест должен взаимодействовать с мок-объектом базы данных, а не с реальной базой. Я, пожалуй, с этим соглашусь. Однако должно быть ясно, что если мок не идеально отражает реальную базу данных — всё её содержимое, профиль производительности и все возможные взаимодействия — существует риск, что юнит-тест не выявит проблем реальной базы. И это приемлемо для целей юнит-тестирования, направленного на ошибки кода, не связанные с взаимодействием с базой данных.

Аналогично, автоматизированные проверки на уровне API очень хороши для обнаружения проблем, вызванных изменениями в функциях, вызываемых через API. Такие проверки могут быть чрезвычайно полезны, но поскольку создаются они теми, кто находится внутри команды разработки, они часто подвержены «проклятию знания». Они создаются людьми внутри команды и, как правило, не отражают реального опыта внешнего программиста, который впервые сталкивается с API. Эти проверки мало говорят о путанице и фрустрации, с которыми столкнётся программист из-за плохой документации, упрощённых примеров и непонятных кодов ошибок. И это тоже приемлемо для целей тестирования на уровне API, направленного на ошибки кода в базовых функциях.

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

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

Созданный продукт должен удовлетворять множеству требований, основанных на различных измерениях качества, для широкой аудитории пользователей и других заинтересованных лиц. В рамках подхода Rapid Software Testing мы рассматриваем такие качества, как функциональность, надёжность, удобство использования, харизма, безопасность, масштабируемость, совместимость, производительность и инсталлируемость — всё это имеет непосредственное значение для пользователей. Такие проблемы ведут к потере времени, денег или данных клиентов, а также к задержкам и убыткам у их заказчиков. В итоге это может привести к разочарованию или гневу пользователей, плохой репутации или общественному возмущению.

Существуют также критерии качества, которые имеют косвенное значение для пользователей и более прямое — для бизнеса. Сейчас для программистов текущей команды всё может быть нормально, но другие разработчики могут столкнуться с проблемами в будущем — связанными с поддерживаемостью, переносимостью и локализацией. Проблемы, незамеченные программистами, могут обернуться трудностями для других сотрудников внутри организации — для службы поддержки, администраторов баз данных и тестировщиков.

Когда какой-либо аспект качества существенно снижен или отсутствует для того, чье мнение важно, этот человек справедливо заявит, что продукт не работает так, как он ожидает. Последствия всего этого — повышение затрат, снижение ценности, потеря репутации и уменьшение прибыли для бизнеса. Здравое управление разработкой и бизнесом требует такого тестирования, которое выявляет не только ошибки в коде, но и проблемы, связанные со всеми явными и неявными требованиями, со всеми релевантными критериями качества, а также с риском того, что эти требования не будут удовлетворены для какой-либо значимой персоны или группы.

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

Давайте вспомним четыре вида бизнес-рисков, которые я выделил в предыдущей статье.

Каждый из этих рисков вызывает четыре вида вопросов и четыре подхода к тестированию.

• Когда мы с оптимизмом представляем успех, существует риск, что мы можем не до конца понимать, чего именно хотят клиенты или бизнес от продукта, а также что именно нам нужно сделать, чтобы его создать. Уверены ли мы, что знаем, чего все хотят от продукта? Это побуждает к проверке и тестированию, ориентированным на наши намерения.
• При усердной работе над созданием продукта существует риск допустить относительно легко выявляемые и предотвращаемые ошибки. Мы действительно создаём то, что планировали создать? Это требует внимания к поддержанию дисциплины в программировании и соответствующему тестированию.
• Предвидя провалы, мы понимаем, что знание, что именно делать, и избегание ошибок могут быть сложнее, чем кажется, и поэтому может понадобиться более глубокое тестирование. При этом есть риск, что поиск тонких и трудноуловимых проблем окажется сложнее и дольше, чем хотелось бы бизнесу. Готовы ли мы тестировать эффективно? Это побуждает нас задуматься о тестируемости.
• Пока продукт не создан, наше знание о том, как он работает на самом деле, основано на теории. Даже если мы тщательно спроектировали и реализовали продукт, есть риск, что важные проблемы могли ускользнуть от нашего внимания. В продукте могут быть баги, которые мешают нуждам и ожиданиям пользователей, или он может порождать новые проблемы. Достаточно ли мы тестировали, чтобы узнать обо всех важных и трудноуловимых ошибках? При наличии риска необходимо тестировать глубоко и ответственно. Такой подход можно назвать тестированием реализованного продукта и выявлением появившихся проблем.

В следующей статье этой серии мы подробно рассмотрим каждый из этих фреймов — намерение, дисциплину, тестируемость и реализацию.

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