Home

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

Часть 1
Часть 2
В прошлый раз "Фрида", моя клиентка на тренинге, спросила про разработку тест-кейсов для аудиторов и контролирующих органов. В курсе Rapid Software Testing мы считаем полезным называть это формализованным тестированием.

Тестирование формализуется вплоть до особого способа его проведения и необходимости убедиться в определенных вещах. Формализованное тестирование обычно направлено на подтверждение или демонстрацию чего-либо конкретного в продукте. В RST есть континуум формализации тестирования. Моя версия, слегка отличающаяся от версии Джеймса Баха, выглядит так:

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

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

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

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

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

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

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

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

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

Из секции 5: Важность исследовательской работы в разработке плана опорного исследования.

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

Джеймс Бах делает на этом упор в своем докладе "Грязные тайны формального тестирования", и это важный момент в RST. Разработка – итеративный процесс, потому что в начале каждого рабочего цикла мы не знаем наверняка, каковы требования, что они означают, что мы можем получить, и как мы убедимся, что мы это получили. Мы не знаем этого, пока мы не протестировали продукт – и мы не узнаем, как тестировать продукт, пока не попробуем его протестировать!

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

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

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

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

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

В следующий раз мы разберем отказ от тест-кейсов в реальном проекте по созданию медицинского прибора. Оставайтесь с нами.

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