3 сценария когда автоматизация может быть применима (или не может)

Вот некоторые сценарии, в которых автоматизация, как правило, применима:

Повторяющиеся тесты

Human designed to think and automation to workСистема, на которой должны выполняться периодические тесты - является хорошим кандидатом для автоматизации. Возьмем в качестве примера, проект поддержки, в котором должны выполняться регрессионные тесты для каждого запроса (PR/CR). Ручное тестирование, как правило, будет громоздким и обязательно возможно приведет к ряду ошибок. В таком случае, автоматизация тестирования может оказаться весьма эффективным средством минимизации затрат на выполнение тестирования.

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

  • Сколько повторений тестов ожидается и как долго они будут использоваться?
  • Насколько дорогой инструмент автоматизации?
  • Сколько времени/ресурсов потребуется на создание тестов? Автоматизация - не всегда запись/повторение, и для того, что бы построить хорошую автоматизацию необходимо прорабатывать дизайн и написать фреймворк.
  • Ожидаются ли постоянные изменения в скриптах?
  • Требуют ли тестировщики прохождения тренингов?

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

Невыполнимые ручные тесты

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

Низкая критичность и вероятность человеческого фактора

Автоматизация может выполнять некоторые задачи намного лучше, чем можно положиться на человека. Например, если дать инструменту автоматизации и человеку сравнить и проверить два файла Excel с 10,000 строк данных. Я думаю, что ответ очевидный, кто может сделать это быстрее и без ошибок. Но конечно же, люди гораздо лучше для другого рода тестирования. Человек может заметить ошибки в документации. Или проверить GUI, который может смотреться слишком загроможденным!

Автоматизация ограничивается тестированием, которое запрограммировано. Не все, что человеческий ум может наблюдать / анализировать, может быть запрограммировано, и потому, автоматизация будет пропускать некоторые ошибки. Главный вопрос: насколько такие ошибки важны для вас? Нестабильная система может быть не готова к автоматизации, так как серьезные "ручные" ошибки могут быть проигнорированы. Автоматизация лучше подходит для систем, в которых ожидается меньше "человеческих" ошибок и они не так критичны.

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

Мне очень нравится принцип 20/80.

Применительно к работе, обычно бывает так:

  • 80% пользователей используют 20% возможностей
  • 80% работы делается за 20% времени (оставшиеся 20% работы за оставшиеся 80% времени)
  • ... :-)

ИМХО, надо начинать с покрытия тестами эти самые главные 20% системы...

1 лайк

Я тоже безумно благодарен итальянскому математику, который придумал правило 80/20. Правило действительно очень хорошо ложиться под задачу выбора покрытия и критичности. Зачастую даже, остальные 20% покрывать не приходиться, так как на них постоянно не хватает времени (по крайней мере, в моей практике это так) :) .