Предложенная Майком Коном пирамида автоматизации может помочь командам найти лучший из возможных подходов к автоматизации тестирования.
Самый незамысловатый подход к автоматизации тестирования, который только можно придумать, просто взять тест-кейсы, созданные для ручного тестирования, и автоматизировать их на уровне пользовательского интерфейса (GUI), используя инструменты наподобие Selenium. В то же время, это наименее эффективный подход. Автоматические тесты на уровне UI медленны, уязвимы к любым изменениям, их трудно поддерживать.
Пирамида автоматизации Майка Кона отлично иллюстрирует более эффективный подход. Ширина каждого уровня пирамиды показывает, сколько тестов должно быть на каждом уровне по сравнению с другими.
На нижнем уровне пирамиды находятся компонентные, или юнит-тесты. Они должны составлять большинство ваших тестов. Например, чтобы протестировать класс, который вычисляет проценты с суммы, создается юнит-тест, передающий процентную ставку x и баланс y. Ожидаемый результат: корректное вычисление суммы процентов с нужной точностью.
Средний уровень занимают тесты, которые верифицируют бизнес-поведение (но не через GUI!). Такие тесты иногда называют API тестами. Если вы используете методологию «разработки через поведение» (BDD, behavior-driven development), ваши автоматические тесты будут относиться к этому уровню. Вам может понадобиться довольно большое количество тестов этого уровня, но всё равно их должно быть меньше, чем юнит-тестов. Такие тесты могут затрагивать несколько компонентов одновременно и проверять поведение продукта с точки зрения бизнеса. Пример: после вычисления процента по депозиту нужная сумма добавляется к балансу.
Верхний уровень пирамиды - автоматические тесты, которые непосредственно затрагивают пользовательский интерфейс. Их должно быть намного меньше, чем остальных. Пример такого теста: после начисления процента в банковской выписке отображается правильная, новая сумма.
И, “вишенка на тортике” - ручные тесты. Некоторые виды тестирования не могут быть автоматизированы, допустим, исследовательское тестирование или тестирование юзабилити, но в идеале стоит стремиться минимизировать объем мануальных тестов.
Еще несколько важных принципов, связанных с пирамидой автоматизации:
- Избегайте дублирования тестов на разных уровнях. Нет смысла повторять одни и те же тесты на разных уровнях. Например, если граничные значения были проверены на уровне юнит-тестов, не стоит повторять их на уровне GUI - таким образом мы вряд ли получим новую информацию.
- В целом, там, где это возможно, стоит стремиться к сдвигу тестов на более низкий уровень. Допустим, проверить вычисление процентов с отрицательной суммы наверняка возможно на “среднем уровне” или даже на уровне юнит-тестов, так зачем делать это на уровне пользовательского интерфейса? Автоматизировать тесты на более низком уровне эффективнее, это позволяет раньше обнаруживать дефекты, экономит время и деньги.
Комментарии