Home

Оригинальная публикация: Test Framing
Автор:Michael Bolton
Перевод: Михаил Павлов

Несколько месяцев назад Джеймс Бах рассказал мне об идее обоснования тестов (test framing). Он определил это как один из необходимых навыков тестировщика и проделал определенную работу по уточнению этой идеи, выполнив обоснование тестов в качестве упражнения вместе с одним из своих онлайн-учеников.

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

Основная идея состоит в следующем. В любой момент тестирования

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

Обоснование тестов это способность проследить и/или построить логическую цепочку, которая связывает цель тестирования с тестами. Следуя естественному маршруту, логическая цепочка будет затрагивать элементы внутри списка, приведенного выше. Цель обоснования тестов состоит в том, чтобы уметь отвечать на вопросы типа:

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

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

Это не строгая формальная система, но она эвристически и корректно структурирована. Вот довольно наглядный пример.

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

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

Связка высказываний: ЕСЛИ это поле ввода не является ограниченным, И ЕСЛИ оно вследствие этого переполняет буфер, СЛЕДОВАТЕЛЬНО, существует риск потери данных ИЛИ неверного поведения программы.

Высказывание: Чем больше размер набора данных, пересылаемого в это поле ввода, тем больше вероятность стирания программного кода или данных.

Связка: СЛЕДОВАТЕЛЬНО, чем больше набор данных, тем выше вероятность возникновения наблюдаемой проблемы.

Связка: ЕСЛИ я размещаю в этом поле очень длинную строку, я с большей вероятностью смогу наблюдать проблему.

Вывод (тест): СЛЕДОВАТЕЛЬНО я попробую скопировать очень длинную строку в это поле ввода И пронаблюдаю за признаками повреждений, например, мусором в записях, которые я видел раньше в нетронутом виде, или утечкой памяти, или падением программы или другим необычным поведением.

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

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

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

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

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

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