Собственно навеяно этим http://blog.shumoos.com/archives/268
Чтобы там ответить нужно регистрироваться, а мне лень напишу здесь, тем боле что автор текста, по всей видимости ярый противник автоматизации, наверняка отпишется Я на самом деле не очень поняла, почему уважаемый SALar против именно автоматизации регресии )
Видела своими глазами несколько провальных попыток автоматизировать регрессию на проекте, еще больше слышала.
Вот, на мой взгляд, маркеры предвещающие провальную автоматизацию:
- В команде все пробуют заняться автоматизацией впервые
- Отсутствие этапа создания архитектуры автотестов, либо не учли все важное
- В качестве ведущего (то есть принимающего решения) специалиста по автоматизации выбирают человека с навыками программиста уровня джуниора или ниже
- Автоматизаторы работают сами по себе, практически не пересекаясь по задачам с ручными тестировщиками
- Тесты, записанные с помощью рекордера.
А вот что должно быть, чтобы автоматизация взлетела
- Отказаться от обычных рекордеров полностью. Если уж так хочется привлечь к автоматизации людей без навыков программирования, это должен быть кастомизированный под конкретный проект рекордер
- В команде автоматизаторов должен быть человек, который уже прошел по всем граблям и знает что бывает, когда на проекте сотни автотестов
- На этапе архитектуры привлекаются тим лиды команды разработки и решаются такие вопросы:
- Определение способов оптимального взаимодействия тестируемой и тестирующей программ
- Как сделать чтобы "изменения тестов не отставали от изменения кода"
- Как упростить работу по определению причин падения тестов
- Как свести к минимуму ложные падения, и вообще какой процент ложных падений допустим исходя из планируемого количества автотестов
- Как распараллеливать тесты, как создавать нагрузку на приложение
- Этапы создания автотестов, критерии успешности этапа
- Как интегрировать ручное тестирование и автотестирование
- джуниоры вполне могут писать код автотестов, но их должен ревьюерить человек с более высокой квалификацией
- Автоматизация должна сразу же приносить пользу, интегрироваться с задачами ручных тестировщиков на начальном этапе(например создание тестовых сред или создание нагрузки) Специалисты по автоматизации тоже тестировщики и должны принимать участие в тестировании новых фич, тестируя в полуавтоматизированном режиме. Если они не могут, не хотят, полностью вручную быстрее, то гнать их в шею
Что до меня, в последнем проекте были соблюдены не все эти правила, опыт сын ошибок, так или иначе потому автоматизация получилась средненькая, уже не fail, но еще не совсем win. Надеюсь в следующем проекте будет лучше