19. 2 программиста сделали за 1
месяц
Не нужно программировать
чтобы создать тест
Встроено и работает у всех
Легко отлаживать
Запись/воспроизведение
сценариев для других нужд
Требует поддержки
20. Как же изменился наш процесс
Конец спринта
Запускаем тесты
Тесты красные
Теперь мы точно знаем: что то сломалось
Нет стабильной сборки
21. Давайте прикрутим к CI
Тесты запускаются после
вливания в master
Отчет приходит всем
разработчикам
22. Давайте прикрутим к CI
Тесты запускаются после
вливания в master
Отчет приходит всем
разработчикам
Всем пофиг
Нет стабильной сборки
24. Закрутим гайки (DoD)
Авторы тестовой системы
превратились в поддержку
Не успевали исправлять
Нет стабильной сборки
Разъяснительная работа с
разработчиками
Запуск на master + на ветках команд
26. Как сейчас
Запуск на всех CI после commit’а
Каждая фича «бетонируется» тестами
сразу после разработки (DoD)
Полный регресс 5000 тестов занимает
один час
Регрессия замкнута на программистах
Все участники проекта просто счастливы
Проект с нуля
Работаем уже год
2 SCRUM команды – растём
Agile – накоплен опыт
Unit тестирование
Внимание к качеству
Завершили эксперименты и прототипы – техническая определенность
Спринты по 2 недели – в конце сборка для аналитиков
Встали на рельсы
Стадия надувания функционалом
“Там Undo не так отрабатывает”
“Здесь привязочка не так отработала”
“А тут вдруг теперь падает”
Для примера рассмотрим 2 персонажа
Подумайте, как работает их мозг (пауза)
На уровне отдельных нейронов – всё ок.
А где проблема? (работа с залом) – в связях
Очень важно чтобы отдельные нейроны работали хорошо – иначе смерть
Но этого недостаточно
Чем больше система – тем больше роль связей
Тестируйте подсистемы.
И у нас были такие тесты.
Но их было очень мало, недостаточно. И сейчас я расскажу почему
Что тут описано? (работа с залом)
Простейший объект. Без проемов! Без подсвечиваний. Не описаны видимые рёбра. Просто стена!
А теперь представьте простейший тест.
Вы двигаете мышкой в координатах экрана, кликаете – и создаются определенные объекты в 3D пространстве.
А теперь представьте тесты на дуговые объекты, на вырезание дырок, на сопряжение стен,
Криптография какая-то.
Ну упал тест. Идите разберитесь в чём дело
Для тех кто думает что мы не пробовали. У нас были такие тесты. В этом проекте их просто мало писали.
Кейс АС/АР – аналитик рисовал в 2D кейсы, выкладывали в Wiki, в тесте писали ссылку на Wiki
Зайдем с другой стороны – с пользователя
Test Complete – был опыт
Squish – попробовали
Особенность: мало контролов, основной ввод – движения мыши
Картинки?
Зачем 4 среза?
Как писать такие тесты?
Идея встраивания ушей в приложение
Всё равно встраиваем тестовые инструменты
Логика оторвана от слоя UI (писать тесты, +мода на UI меняется, + пробовали QT и WPF)
Мы легко было встроили прослойку
3 режима
Сколько стоит 1 лицензия (900 евро TestComplete)
Инструмент замечательный
Как мы его использовали
Что делать???
Жизнь ребят круто изменилась :)
Они взвыли «За что нам это проклятие???»
Ломают все – исправляют только они
Жизнь ребят круто изменилась :)
Они взвыли «За что нам это проклятие???»
Ломают все – исправляют только они
Жизнь ребят круто изменилась :)
Они взвыли «За что нам это проклятие???»
Когда проект уже существует - лучше начать с верха пирамиды, так как это не требует реинжиниринга внутренней архитектуры
Найти баг через 1 час или через 1 неделю?
Правило “1 багфикс => 2 новых бага” работает когда время измеряется неделями
Автотестирование это:
Явная экономия на тестеро-часах
Неявная на скорости и качестве исправления багов
Разработчики должны осознать что они основные выгодоприобретатели от создания автотестов
Кейсы когда тесты запускаются долго
Никакой тестер никогда бы не создал такую тестовую систему
Только разработчики знают как эффективно протестировать их систему, чтобы тесты были быстрыми, необходимыми и достаточными
“Плохие” кейсы, когда автотестеры сидят отдельно от разработчиков
Нужно вовлекать программистов. Тогда они меньше ломают тесты, раньше узнают об ошибках, и вообще не мешают тестерам работать
Антипаттерн – тесты у Пети
Когда тесты часть процесса и DoD – только в общем репо
Agile подход поставил нас перед необходимостью решения проблемы
Кто хочет - ищет возможности, кто не хочет - ищет причины