Презентация доклада Игоря Бондаренко на конференции SQADays-14, Львов 8-9 ноября 2013

1. Как не сойти с ума тестируя большой
проект в одиночку
Igor Bondarenko. Intetics Co.

2. Можно ли назвать проект
«большим»
Итого:
Third party
HTML in-store
30 веб приложений
providers
webязыковых локали
app
Каждое имеет как минимум 2
(WS)
Insert
5 самописных протоколов для обмена данных с
data
Third party
Flex
providers
клиентами in store
kiosks
WS, содержащий более 50 методов (self-writed
protocols)
Объем поступающих данных: 500 000 записей в
ex
сутки
ch
Объем данных обрабатываемых за сутки: 2 000 000
an
ge
в сутки
1 тестировщик

3. Главные проблемы на
старте
• 1. Отсутствие проектной документации
• 2. Полное отсутствие тестовой документации
• 3. Большой объем регресии: 20 человекочасов на
итерацию
(при десятидневной итерации)
• 4. Автоматизация отсутствует впринципе
• 5. Нефункциональные требования никогда не
проверялись

4. Решение проблем

5. Документация:
проблемы
1. Невнятные User Stories
2. Документация минует систему хранения
(Confluence)
3. Нежелание писать документы для «одноразовой»
функциональности

6. Невнятные User Stories
Причина: Неумение писать спецификации
Цель: Получение функциональной спецификации от
заказчика
Способы решения:
- Демонстрация устраивающих команду
спецификаций
- Обучение заказчика
- Реализация функциональности со спекой за
меньшие сроки

7. Документация минует
систему хранения
Причина: Необходимость отправки документации по
частям партнерам
Цель: Хранение всей документации в одном месте,
возможность быстро отслеживать изменения
Способы решения:
- Разработка единого шаблона документации
- Документ изначально создается в Confluence
-Создание Word шаблона фирменного стиля
-Предоставление доступа партнерам к системе
хранения документации

8. «Одноразовая»
функциональность
Причина: Спецификация не составляется, если
изменения не планируются
Цель: Иметь описание работы функционала
Решение:
-Анализ каждой «одноразовой» функциональности
-Разбиение глобальной User Story на составляющие
-Полное покрытие функциональности детальными
тестовыми сценариями

9. Тестовые сценарии
Основные проблемы:
- Отсутствие времени на написание
- Дорогостоящая поддержка
Решение:
- Checklists forever!
- Тесткейсы только если отсутствует спецификация

10. Функциональное
тестирование
Основные проблемы:
1. Трудозатраты на регрессию
2. Ручные тесты
3. Отсутствие исследовательского и нефункционального
тестирования
Цель:
Реорганизация процесса тестирования для выделения
необходимого времени

11. Ручное тестирование
1. Переход от тесткейсов к чеклистам
Плюсы:
-Сокращение времени на написание
-Проще поддерживать
-Позволяют начать тестирование раньше
2. Исключение тестирования в конце итерации
3. Подключаем исследовательское тестирование к
«скриптовому»

12. Автоматизация
Проблема:
Полное отсутствие автоматизированных тестов

13. Выбор инструмента
HP
Selenium
Имеется опыт использования
Опыта нет
Разработчики отказываются
писать тесты
Низкий порог вхождения
IDE
Возможность писать тесты на
Java
Вовлечение разработчиков
Гибкий

14. «Некрасивые тесты»
Наличие «некрасивого»
автотеста значительно лучше,
нежели его отсутсвие

15. Положительное влияние
«некрасивых тестов»
Плюсы таких тестов в начале проекта:
1. Быстро создаются
2. Предоставляют быструю обратную связь
2а. Помогают вовлечь разработчиков в тестирование
3. Являются заготовками для будущих «красивых» тестов

16. SoapUI: спасение
утопающих
1. Низкий порог вхождения
2. Возможность быстро создать test suite для запуска полного
теста в один клик
3. Тесты можно включить в CI
4. Возможность разрабатывать тесты используя Mocks
параллельно с имплементацией
5. Возможность создания Load и Security тестов

18. Вовлечение разработчиков:
демонстрация
Цель: «Подсадить» программистов на тестирование
1. Демонстрация работы автотестов и объяснение основого
смысла:
- Быстрая обратная связь
- Возможность быстро и самостоятельно проверить
качество перед коммитом
2. Демонстрация Selenium IDE

19. Вовлечение разработчиков:
обучение
1. Возвращаем «подсевших» на качество разработчиков в
родную стихию:
- Переход от IDE к RC или WebDriver
- Выделение времени на перевод старых тестов с IDE на
Java
2. SoapUI тесты для неподдатливых:
- Обучение созданию
- Расширение возможностей с Groovy
- CI

20. Результаты
1. Покрытие 75% функциональности автотестами
2. Полный переход от Selenium IDE к RC, а затем WebDriver за
год
3. Создание тестов по сценариям заказчика для всех веб
сервисов
4. Команда разработки полноценно вовлечена в процесс
обеспечения качества

21. Общий итог
Приложение покрыто тестами на всех уровнях
Проектная документация всегда up to date
Время регрессионного тестирования сократилось до 4 часов
Тестирование больше не «сваливается» на конец итерации
В процесс тестирования вовлечена вся команда.
Количество customers defects с 5 в неделю сократилось до 1
в 2-3 месяца.
7. Высвободилось время для проверки нефункциональных
требований
1.
2.
3.
4.
5.
6.

22. Количественные
показатели

23. Ключевые факторы успеха
1. Личная заинтересованность тестировщика в
результате
2. Документация всегда должна быть в актуальном
состоянии
3. Тесты должны быть быстрыми в создании и легкими
в поддержке
4. Комплексная автоматизация тестирования на всех
уровнях
5. В процесс обеспечени качества должна быть
вовлечена вся команда

24. Вопросы
Email: bondarenko.ihar@yandex.ru
Skype: igor.bondarenko1