Catching The Bugs

Тестирование в темноте (Testing In The Dark)

Когда-то попалась мне в руки книга Блэка Рекса «Ключевые процессы тестирования: планирование, подготовка, проведение, совершенствование». Там я и обнаружил ссылку на статью «Testing In The Dark», которая меня заинтересовала и я решил сделать ее перевод.

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

Буду рад любым замечаниям относительно качества перевода.

Тестирование в темноте

Практичный подход при работе с недокументированными требованиями программного обеспечения.

Оригинал: Testing in the Dark. A pragmatic approach to overcoming undocumented requirements. By Johanna Rothman and Brian Lawrence.

Ключевые моменты:

• Определение требований
• Определение критериев качества
• Советы для достижения успеха

Целенаправленным шагом, в вашу комнату входит менеджер проекта. «Этот диск содержит последнюю и лучшую сборку нашего ПО. Пожалуйста, протестируй его сегодня». Вы отвечаете: «Хорошо, но что оно делает?» Менеджер останавливается на полпути и говорит: «Да, ничего особенного».

Знакомо? Мы попадаем в данную ситуацию и как работники и как консультанты. И мы видели, как тестировщики берут диск, вставляют его в привод и начинают тестировать.

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

Давайте попробуем снять черную повязку с глаз.

Даже для коротких по срокам (две недели) проектов по тестированию мы используем данную методологию. Согласно следующим подходам:

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

Определение требований

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

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

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

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

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

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

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

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

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

Вы должны выяснить, что обсуждалось на данных собраниях. Какие решения были приняты? Действительно ли все требования были реализованы в продукте?

Шаг 1: Сбор информации

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

Мы можем использовать множество путей, чтобы выяснить проектные решения:

• Прочесть документацию. Найдите пользовательскую документацию. Изучите ее чтобы увидеть, можете ли вы понять, что происходит. Изучите дистрибутив программы на предмет полезных материалов. Найдите рекламные материалы. Выясните, что будут ожидать пользователи после того, как они запустят программу.
• Изучить архитектуру продукта. Найдите тех, кто предположительно понимает архитектуру продукта и попросите, чтобы вам ее объяснили. Пусть эти люди покажут на практике, что они действительно понимают, что продукт имеет ту архитектуру, о которой они вам рассказывают. Чаще всего, верхний предел продукта определяется его архитектурой. Найдите слабые звенья в цепочке.
• Запустить продукт. Изучите его производительность и надежность.
• Спросить разработчиков. Спросите руководителя проекта разработки, какой разработчик отвечал за какую часть проекта. После этого вы можете узнать, что выполняет каждый модуль продукта и как разработчик принимал решения относительно разработки. Пригласите на обед ключевых разработчиков проекта, возьмите с собой записную книжку. Если вы боитесь из-за того, что ваш уровень знаний ниже, чем у разработчиков, возьмите кого-нибудь, кто сможет говорить с ними на равных и задавать вопросы. Возможно, это будет полезно вашим карьерным целям и вы сами сможете обзавестись достаточными знаниями, чтобы говорить с разработчиками на равных.
• Спросить менеджера проекта. У ПМ могут быть электронные или бумажные копии документов, которые вы можете просмотреть.

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

Шаг 2: Преобразуйте «фичи» в требования.

Теперь у вас есть некоторый материал, который вы можете преобразовать в требования.

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

• Быть доступной пять дней в неделю.
• Предоставлять возможность вести расписание.
• Запрещать не санкционированный и гостевой доступ.
• Система простая в настройке и расширении.
• В системе предусмотрены модули для отчетов.

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

Что значит для вас «Быть доступной пять дней в неделю»? Это надежность. Кто-то говорит, что их устройству требуется поддержка вашего программного обеспечения в течении всей рабочей недели. Надежность – это качество данной системы.

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

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

Таблица 1: Пример требований
Тип	Спецификация требований
Пользователи	Оператор – человек, который администрирует систему
	Гость – пользователь имеющей гостевой доступ. Не относится к обычным пользователям.
	Злоумышленник – кто-то, кому не позволено иметь доступ к системе. Данные пользователи не допустимы.
Качества	Надежность – доступность системы, работает 24 часа по рабочим дням.
	Безопасность – только авторизованные пользователи могут получить доступ к системе.
	Комплексность – система объединяет вместе различные компоненты.
	Удаленный доступ – есть возможность получить доступ к системе используя не только стандартный интерфейс.
	Простая в установке – установка системы проста и интуитивно понятна.
Функции	Обратная связь – операторы и пользователи при взаимодействии с системой получают от нее отклик.
	Отчеты – собирать данные и выдавать отчеты.
	Расписание – показывать будущие события.
	Планирование – управление системными событиями.

Это только небольшая часть требований к системе. Помните, что данные требования гораздо более полезны, если они специфицированы достаточным образом, чтобы быть тестопригодными.

Например, давайте посмотрим на требование надежности. Одним из измерений надежности – это средняя наработка на отказ (MTBF – Mean Time Between Failure), которое определяется количеством времени безотказной работы системы (время до первого сбоя системы). 12 часов и 720 часов наработки на отказ, являются существенно различающимися величинами. Это рабочий день против рабочего месяца. Определив однажды желаемые величины наработки на отказ, вы будете иметь специфицированные и измеряемые величины, которые вы можете протестировать.

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

Дайте определение качества для данного проекта

Вы определили требования к проекту и теперь вы знаете, что должны протестировать. Теперь вы должны определить, как тщательно вы должны протестировать каждое требование.

Первичная цель каждого программного проекта – это повысить ценность компании. Ваши цели при тестировании должны сопутствовать данным целям проекта. Определение качества для программного продукта поможет вам спланировать сколько внимания уделять каждой области тестирования в проекте.

Для программного продукта могут быть определены три цели (Robert Grady, Practical Software Metrics for Project Management and Process Improvement, Prentice Hall, 1992):

• Минимизировать время выхода на рынок. Выпустить продукт так скоро, как это возможно.
• Повысить удовлетворенность заказчика, выпустив продукт с широким набором свойств.
• Минимизировать кол-во дефектов.

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

Таблица 2: Ранжирование требований
Тип	Спецификация требований	Критично для времени выхода на рынок
Пользователи	Оператор – человек, который администрирует систему	Да
	Гость – пользователь имеющий гостевой доступ. Не относится к обычным пользователям.	Нет
	Злоумышленник – кто-то, кому не позволено иметь доступ к системе. Данные пользователи не допустимы.	Да
Качества	Надежность – доступность системы, работает 24 часа по рабочим дням.	Да
	Безопасность – только авторизованные пользователи могут получить доступ к системе.	Да
	Комплексность – система объединяет вместе различные компоненты.	Нет
	Удаленный доступ – есть возможность получить доступ к системе используя не только стандартный интерфейс.	Да
	Простая в установке – установка системы проста и интуитивно понятна.	Нет
Функции	Обратная связь – операторы и пользователи при взаимодействии с системой получают от нее отклик.	Нет
	Отчеты – собирать данные и выдавать отчеты.	Да
	Расписание – показывать будущие события.	Нет
	Планирование – управление системными событиями.	Нет

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

Как человек, который тестирует в темноте, вы должны найти комбинацию требований, которые представляют критичный набор свойств, требуемый вашими заказчиками.

Определите план тестирования, включая критерии выпуска

Теперь вы уже знаете, что вы должны тестировать и знаете, что должны предоставить пользователям. Теперь вы можете определить план тестирования и критерии выпуска продукта.

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

Определите наиболее важные критерии выпуска и обсудите их черновые варианты вместе с командой проекта. На совещании вы должны задать всего два вопроса:

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

Критерии для первичного выпуска системы для нашего примера могут быть такими:

• Качество: надежность, работа в режиме 5*24.
• Функции: Позволять создавать отчеты за недельный период.
• Пользователи: Полная функциональность для операторов системы.

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

Определение критериев выпуска проливает свет на предположения и опасения которые теперь становятся подконтрольными.

Советы для достижения успеха

Выход из темноты влечет за собой определение того, что вы должны сделать и того, как вы собираетесь это делать.

Мы испытали трудности, когда начали делать это и выяснили, что данные советы будут полезны, чтобы проект стал удачным.

Определите, что руководство желает получить от вложения денег и времени

Если вы работаете с проектом, в котором руководство хочет знать, соответствует ли их продукт требованию работы 5х24 часа, то вы можете объяснить, какие вам ресурсы необходимы и сколько времени потребуется, чтобы провести соответствующее тестирование. Если вы проранжировали требования в вашем плане тестирования, то руководство может видеть, сколько времени и на что вы будете его тратить. Руководство может определить свои интересы, и вы можете позаботиться о том, чтобы удовлетворить их интерес. Если ожидается несколько выпусков программного продукта, вы можете запланировать тестирование после выпуска, чтобы понять, как реализованы другие требования.

Критерии выпуска относятся ко всему проекту

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

Выпустите продукт соответствующий критериям выпуска.

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

“Темная сторона”

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

Предположение 1: тестирование в темноте – это работающая альтернатива.

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

Предположение 2: возможно общение.

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

Предположение 3: люди действительно хотят знать правду.

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

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

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

Ведите себя к свету!

2 Responses to “Тестирование в темноте (Testing In The Dark)”