понедельник, 12 октября 2015 г.

Стоимость автоматизации без цифр

Если вы думаете начать внедрять автоматизацию тестирования в свой проект, то эта статья для вас?

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

Итак, было у вас только ручное тестирование. Захотелось вам автоматизацию. Какие есть варианты:

  1. Даем тестировщикам инструменты и говорим: «автоматизируйте» (мы не будем обсуждать умеют ли тестировщики автоматизировать, а просто допустим что как-то умеют)
  2. Вешаем задачу по автоматизации на разработчиков
  3. Отдаем автоматизацию всей команде
Начнем последовательный разбор каждого из вариантов.

Вариант 1

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

Вариант 2

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

Вариант 3

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

Итак мы видим, что внедряя автоматизацию мы получаем дополнительные расходы, которые могут окупиться либо не окупиться на этапе регрессионного тестирования. Все будет зависеть от того, кто и как писал эту самую автоматизацию.

От себя я хочу предложить 4-ый вариант того как можно организовать работу:

Не меняя уже устоявшийся процесс работы в команде, вы ищите автоматизаторов со стажем, которые параллельно с разработкой будут автоматизировать необходимые тесты (именно необходимые, а не все подряд). Таким образом, не уменьшая скорость разработки и тестирования, мы можем начать увеличивать покрытие автоматическими тестами. Конечно от дополнительных расходов не уйти, но данная схема является более привлекательной, т.к. у вас появляется опытная команда, ответственная за автоматизацию, работающая параллельно с разработкой и независимо от неё. При этом команда может быть как в вашем офисе, так и удаленная. Автоматизацию как сервис никто еще не отменял. ☺

Удачи и надеюсь, прочитав эту статью вам будет над чем подумать.

Отправить комментарий

Условия копирования публикаций:

Все публикации в данном блоге являются частной собственностью авторов. Любое копирование информации допускается только при условии указания имени автора и активной ссылки на источник.