Ребята из Luxoft Training подготовили перевод статьи о проектировании тестов от одного из первых разработчиков популярной сегодня методологии тестирования и автоматизации на основе ключевых слов — Ганса Бувалды.

Ганс Бувалда (Hans Buwalda) за свою профессиональную карьеру приобрел огромный опыт работы в качестве разработчика ПО, менеджера и главного консультанта в ведущих компаниях и организациях в разных странах мира. Предложенные им методы тестирования (на основе действий и в стиле мыльной оперы) помогли многим заказчикам разработать масштабируемые и легко поддерживаемые решения для большого объема сложных задач по тестированию. Ганс часто выступает в качестве докладчика на международных конференциях. Также он является соавтором книги Integrated Test Design and Automation.

Успешное тестирование программного обеспечения прежде всего зависит от проектирования тестов. Качественный дизайн тестов не только обеспечивает хорошее покрытие, но и повышает эффективность тестирования. Дизайн тестов должен основываться на принципе «компактность и эффективность», а объем тестирования должен быть легко управляемым и в то же время достаточным для выявления ошибок до выпуска системы или ее обновления.

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

Существует три главные цели, к которым нужно стремиться в проектировании тестов, как в легенде о короле Артуре и рыцарях Круглого стола, – «Три Святых Грааля проектирования тестов», приходится сталкиваться с огромными трудностями, как и в случае с поиском Святого Грааля рыцарями короля Артура. Итак, в этой статье я представлю три «грааля», которые нужно найти при проектировании тестов.

Терминология, используемая в этой статье, основывается на методологии тестирования на основе действий (Action Based Testing, ABT), которая применяется компанией LogiGear для тестирования и автоматизации тестирования. Более подробную информации о методологии ABT можно найти на сайте LogiGear.

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

Три цели проектирования тестов

Можно выделить три важнейшие цели проектирования тестов.

1. Эффективная декомпозиция тестов

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

2. Правильный подход для каждого тестового модуля

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

3. Правильный уровень детализации тестов

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

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

Вывод

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

22 ноября Ганс Бувалда приезжает в Москву с мастер-классом "Пять ключевых факторов успешной автоматизации тестирования".

Больше статей от Ганса Бувалды можно найти здесь.