Классический вопрос обоснования необходимости автоматизации тестирования(и не только) -
"Что мы с этого будем иметь? Сколько сэкономим, сколько заработаем, скольких уволим и сколько можно будет перевести в премии?". И как всегда есть очевидные, известные и не очень вещи. Обычно пишут об эффективности автоматизации функционального тестирования как некоей загадочной величине пропорциональной отношению затрат на ручное тестирование к затратам на автоматизированное. И что включать в каждый вид затрат - тут каждый сам себе художник и научрук.
"Что мы с этого будем иметь? Сколько сэкономим, сколько заработаем, скольких уволим и сколько можно будет перевести в премии?". И как всегда есть очевидные, известные и не очень вещи. Обычно пишут об эффективности автоматизации функционального тестирования как некоей загадочной величине пропорциональной отношению затрат на ручное тестирование к затратам на автоматизированное. И что включать в каждый вид затрат - тут каждый сам себе художник и научрук.
На мой выпуклый
военно-морской в затратах на автоматизацию
следует в том числе учитывать:
- людей: кто,
когда, с какой мотивацией и под какой
стимуляцией будет всё это делать,
развивать и поддерживать;
-
документированность: насколько быстро
можно получить ответы на внезапные
вопросы,
нужно ли
разрабатывать сценарии или использовать
готовые и проверенные тестослучаи для
ручного тестирования, каков вообще
порог вхождения в проект(в месяцах).
Здесь же можно упомянуть и общую зрелость
проекта — если всё работает «не-так»,
то автоматизация вряд ли будет быстрой
и эффективной;
- архитектуру
и структуру. Проистекает из вопроса
"что покрываем?". Навскидку:
а. микросервисы
или монолит;
б. сервисы
на основе бинарных протоколов или РЕСТ
какой-нибудь;
в. нужно
воздействовать на одну систему или
несколько.
- технологии
тестируемого: есть ли вообще инструменты
позволяющие это автоматизировать
(пример - мордочки на флеше которые не
всякий популярный инструмент возьмёт);
- технологии
тестового решения. Например использовать
Селениум или Сикули это две большие
разницы в затратах и на разработку и на
поддержку;
- данные:
стабы, моки или живые данные? Как
генерировать и валидировать тестовые
данные(особенно в случае критических
систем(медицина, авиация))? Если моки-стабы,
то есть ли что-то готовое или нужно будет
писать своё?
- безопасников
- дадут ли доступ и добро на манипуляции
с системой, тестовые сборки с
"дополнительными"(отладочными)
функциями?
- среды:
всяко-разные, начиная от где это запускать
и где разворачивать тестируемое. Далеко
не всегда можно получить стенды вот так
сразу, возможно придётся подождать
годик-два;
- СИ: строить
с ноля или интегрироваться в существующее
решение?
- 3-и стороны:
не всем наши усилия могут нравиться,
некоторые могут посчитать, что отбиваем
хлеб, забираем масло и плюём в душу. А уж палки в
колёса ставить могут просто рефлекторно.
Вышеперечисленное
конечно же требует творческого расширения,
углубления и всяческого дополнения. На
то она и затравка.
Ссылки
россыпью:
