Ребята из Luxoft Training подготовили перевод статьи о тест-дизайне одного из первых разработчиков популярной сегодня методологии тестирования и автоматизации на основе ключевых слов — Ханса Бувальды.
Ханс Бувальда приобрел обширный опыт за свою профессиональную карьеру в качестве разработчика программного обеспечения, менеджера и генерального консультанта ведущих компаний и организаций по всему миру.
Предложенные им методы тестирования (основанные на действиях и в стиле мыльной оперы) помогли многим клиентам разработать масштабируемые и легко поддерживаемые решения для большого объема сложных задач тестирования.
Ганс часто выступает в качестве докладчика на международных конференциях.
Он также является соавтором книги Интегрированное проектирование и автоматизация тестирования .
Успешное тестирование программного обеспечения в первую очередь зависит от дизайна теста.
Хороший дизайн теста не только обеспечивает хорошее покрытие, но и повышает эффективность тестирования.
Проектирование тестов должно быть основано на принципе «компактности и эффективности», а объем тестирования должен быть легко управляемым и в то же время достаточным для выявления ошибок до выпуска или обновления системы.
Проектирование тестов — наиболее важный фактор, определяющий успешную автоматизацию тестирования, хотя он и не так очевиден.
Раньше я думал, что успешная автоматизация зависит от хорошего программирования или «покупки правильного инструмента».
Потребовались годы работы, чтобы понять: дизайн тестов — главный драйвер успешной автоматизации.
В тест-дизайне необходимо достичь трех основных целей, как в легенде о короле Артуре и рыцарях Круглого стола: «Три Святых Грааля тест-дизайна» должны столкнуться с огромными трудностями, как и в случае с поиском Святой Грааль рыцарей короля Артура.
Итак, в этой статье я представлю три Грааля, на которые следует обратить внимание при разработке тестов.
Терминология, используемая в этой статье, основана на методологии тестирования на основе действий (ABT), используемой LogiGear для тестирования и автоматизации тестирования.
Более подробную информацию о методологии ABT можно найти на веб-сайте LogiGear. В методологии ABT тестовые случаи группируются в таблицы, называемые тестовыми единицами.
Они описывают тесты как последовательности «тестовых строк», каждая из которых начинается в столбце А с какого-то «действия», а остальные столбцы содержат аргументы.
В ABT основное внимание уделяется не автоматизации тестовых случаев, а автоматизации отдельных действий, которые при необходимости можно использовать повторно.
Три цели тестового дизайна
Есть три наиболее важные цели проектирования тестов.
1. Эффективная декомпозиция теста
Первый шаг — разбить тесты на управляемые части, которые в ABT называются тестовыми единицами.На этом этапе мы пока не описываем тест-кейсы, а просто обозначаем «главы», в которые их следует включить.
Такая разбивка эффективна, если каждый результирующий тестовый модуль имеет четко определенное и целенаправленное содержание, отличное от других модулей.
Содержание тестового модуля дополнительно определяет, какими должны быть включенные в него тестовые примеры.
2. Правильный подход к каждому тестовому модулю
После завершения разбивки теста каждый отдельный тестовый модуль становится своего рода мини-проектом.Исходя из содержания тестового модуля, необходимо определить, какой подход будет использован при его разработке.
Под подходом понимается определение набора методов тестирования, используемых для создания тестовых примеров (например, анализ граничных значений, таблицы решений и т. д.), а также набора людей, участвующих в создании и/или оценке тестов.
Например, в случае тестового модуля тестирование расчета премий по страховым полисам может потребовать участия сотрудников отдела страхования.
3. Правильный уровень детализации тестов
Возможность поддержки автоматизированных тестов во многом зависит от достижения третьей цели.При создании тестового сценария следует выбирать только те высокоуровневые элементы, которые имеют отношение к тесту.
Например, с точки зрения конечного пользователя «войти в систему» или «изменить номер телефона клиента» — это одно действие; поэтому нет необходимости указывать в тестовом сценарии какие-либо элементы более низкого уровня, такие как нажатия кнопок и ввод данных.
На этом этапе эти низкоуровневые элементы следует «спрятать» в отдельных, повторно используемых функциях автоматизации, общих для всех тестов.
Благодаря этому тесты становятся более компактными и читабельными, но самое главное — они ремонтопригодны, так как нет необходимости менять низкоуровневые элементы по одному в каждом отдельном тесте при внесении изменений в базовую систему.
Элементы низкого уровня затем можно переопределить (или изменить порядок их автоматизации) только один раз, а затем повторно использовать во всех тестах.
В методологии АБТ этот (третий) принцип проявляется на «уровне» активностей, которые предполагается использовать в тестовом модуле.
Например, для базы данных страховой компании мы можем написать тесты, используя только действия «высокого уровня», такие как «создать полис» и «проверить премию», тогда как для диалогового тестирования мы можем использовать действия «низкого уровня» (например, «нажать кнопку» ), чтобы проверить нажатие кнопки ОК.
Заключение
Независимо от выбранной вами методологии, потратив некоторое время на размышления о дизайне теста перед написанием первого тестового сценария, вы значительно улучшите качество и эффективность ваших тестов в дальнейшем.22 ноября Ханс Бувальда приезжает в Москву с мастер-классом» Пять ключевых факторов успешной автоматизации тестирования ".
Другие статьи Ханса Бувальды можно найти здесь.
Здесь .
Теги: #тестирование ПО #тесты #тестирование #тестирование ИТ-систем #Тестирование веб-сервисов #Тестирование мобильных приложений
-
Поглощение На Практике: Реальная История
19 Oct, 24 -
Голосуйте Сердцем
19 Oct, 24 -
10 Лучших Инструментов Тестирования Api
19 Oct, 24 -
Реализация Видеорекламы В Интернете.
19 Oct, 24
