Автоматизированное тестирование сложного ПО

Краткий план
Как зарождалось автоматизированное тестирование
Краткий обзор средств для тестирования
Как правильно организовать процесс автоматизации для разного рода ПО?
Вечные проблемы
Баланс
Автоматизация, как еще один аспект заинтересовать подчинённых работать у вас в команде

Типичный подход менеджеров
Что тут делать? Все просто!
Записал сценарий
Проиграл сценарий на виртуальной машине
Если тест сломался, значит это баг
Cобрал баги

Оказалось все не просто
Получившийся код трудно поддерживать
Новый человек совершенно не понимает того, что написали до него
Код плохо читаем, не структурирован и плохо расширяется на другие среды
Много дублированного кода

С чего начать?

Не увлекайтесь, иначе “вагоны” покатятся в разные стороны

Человеческий фактор
Если вы не фиксируете или не проговариваете сценарии, то тесты начинают писаться ради тестов!

Используйте разные инструменты
Java/VB Script, Power Shell и т.д.
Test Complete , Coded UI, Selenium и т.д.
Load runner, Visual Studio Load Test и т.д.

Девять общих правил из жизни
Скрипты всегда более стабильны, чем UI тесты
В рамках одного теста - один язык
Общая база знаний и примеров – обязательна
Делайте “обертки” для методов, функций и т.д.
Привлекайте опытных коллег для CodeReview
Анализируйте сценарии, которые закодировал тестировщик
Один test case – один автотест
Вы тратите 50% времени на поддержку тестов? – Надо что-то менять!
Можете запустить 1000 тестов пять раз в день? Подумайте, а можете вы это все проанализировать? Каков выхлоп?

Вечные проблемы