Если вы думаете начать внедрять автоматизацию тестирования в свой проект, то эта статья для вас?
«Зачем нам автоматизация тестирования?» - многие полагают что для того, чтобы сэкономить на ручном тестировании. Типа ручное долго, а автоматизация быстро. Но здесь, как всегда все зависит от того, кто, как и чем её делает. Автоматизация может помочь сэкономить, а может и не помочь. Это как с рабочими делающими ремонт. Берешь хороших, получаешь дорогой ремонт и никакой экономии. Берешь плохих - получаешь все быстро, но потом еще год доделываешь и затем начинаешь новый ремонт.
Итак, было у вас только ручное тестирование. Захотелось вам автоматизацию. Какие есть варианты:
- Даем тестеровщикам инструменты и говорим: «автоматизируйте» (мы не будем обсуждать умеют ли тестировщики автоматизировать, а просто допустим что как-то умеют)
- Вешаем задачу по автоматизации на разработчиков
- Отдаем автоматизацию всей команде
Вариант 1
Доверие автоматизации тестеровщикам, явно замедлит скорость самого тестирования, т.к. отладка тестов, поддержание их в рабочем состоянии и анализ падений будут отнимать львиную долю времени, выделенного под тестирование. Как результат – придется замедлить разработку, дав больше времени на тестирование. Тем самым вы получаете дополнительные расходы.
Вариант 2
Повешенная на разработчика дополнительная задача, никак не делает его более счастливым, да и к тому же будет увеличивать время разработки, т.к. опять таки же тесты придется отлаживать, поддерживать в рабочем состоянии и анализировать падения. Возможно у разработчиков это займет меньше времени, но ведь они же «немного» дороже тестеровщиков. Поэтому, как результат мы имеем дополнительные расходы и не очень привлекательную задачу для разработчиков, что может сказаться на их производительности.
Вариант 3
Предположим, что автоматизация станет командной задачей, тестировщики пишут тесты, и уже тот у кого есть время, тот и автоматизирует их, будь то тестировщик или разработчик. Совместная работа сплачивает команду, но благодаря тому, что у нас будет отсутствовать владелец «Owner» автотестов, то и претензии будет сложно кому-то предъявить. И ко всему этому получаем все тот же набор задач «отладка, поддержка, анализ». Итог: расходы.
Итак мы видим, что внедряя автоматизацию мы получаем дополнительные расходы, которые могут окупиться либо не окупиться на этапе регрессионного тестирования. Все будет зависеть от того, кто и как писал эту самую автоматизацию.
От себя я хочу предложить 4-ый вариант того как можно организовать работу:
Не меняя уже устоявшийся процесс работы в команде, вы ищите автоматизаторов со стажем, которые параллельно с разработкой будут автоматизировать необходимые тесты (именно необходимые, а не все подряд). Таким образом, не уменьшая скорость разработки и тестирования, мы можем начать увеличивать покрытие автоматическими тестами. Конечно от дополнительных расходов не уйти, но данная схема является более привлекательной, т.к. у вас появляется опытная команда, ответственная за автоматизацию, работающая параллельно с разработкой и независимо от неё. При этом команда может быть как в вашем офисе, так и удаленная. Автоматизацию как сервис никто еще не отменял. ☺
Удачи и надеюсь, прочитав эту статью вам будет над чем подумать.
Комментариев нет:
Отправить комментарий