Как не сойти с ума тестируя большой проект в одиночку

Igor Bondarenko. Intetics Co.

Primary DBHTML in-store

web app

Flex in store kiosks

Third party providers

(self-writed protocols)

Third party providers

(WS)Insert data

exchange

Partners DB 6

10 countries

Итого:30 веб приложений

Каждое имеет как минимум 2 языковых локали5 самописных протоколов для обмена данных с

клиентамиWS, содержащий более 50 методов

Объем поступающих данных: 500 000 записей в сутки

Объем данных обрабатываемых за сутки: 2 000 000 в сутки

1 тестировщик

Можно ли назвать проект «большим»

Главные проблемы на старте

• 1. Отсутствие проектной документации• 2. Полное отсутствие тестовой документации• 3. Большой объем регресии: 20 человекочасов на

итерацию

(при десятидневной итерации)• 4. Автоматизация отсутствует впринципе• 5. Нефункциональные требования никогда не

проверялись

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

Документация: проблемы

1. Невнятные User Stories2. Документация минует систему хранения

(Confluence)3. Нежелание писать документы для

«одноразовой» функциональности

Невнятные User Stories

Причина: Неумение писать спецификации

Цель: Получение функциональной спецификации от заказчика

Способы решения:- Демонстрация устраивающих команду

спецификаций- Обучение заказчика- Реализация функциональности со спекой за

меньшие сроки

Документация минует систему хранения

Причина: Необходимость отправки документации по частям партнерам

Цель: Хранение всей документации в одном месте, возможность быстро отслеживать изменения

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

«Одноразовая» функциональность

Причина: Спецификация не составляется, если изменения не планируются

Цель: Иметь описание работы функционала

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

Тестовые сценарии

Основные проблемы:- Отсутствие времени на написание- Дорогостоящая поддержка

Решение:- Checklists forever!- Тесткейсы только если отсутствует спецификация

Функциональное тестирование

Основные проблемы:

1. Трудозатраты на регрессию

2. Ручные тесты

3. Отсутствие исследовательского и нефункционального тестирования

Цель:

Реорганизация процесса тестирования для выделения необходимого времени

Ручное тестирование

1. Переход от тесткейсов к чеклистам

Плюсы:-Сокращение времени на написание-Проще поддерживать-Позволяют начать тестирование раньше

2. Исключение тестирования в конце итерации

3. Подключаем исследовательское тестирование к «скриптовому»

Автоматизация

Проблема:

Полное отсутствие автоматизированных тестов

Выбор инструмента

HP Selenium

Имеется опыт использования Опыта нет

Разработчики отказываются писать тесты

Низкий порог вхождения

IDE

Возможность писать тесты на Java

Вовлечение разработчиков

Гибкий

«Некрасивые тесты»

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

Положительное влияние «некрасивых тестов»

Плюсы таких тестов в начале проекта:

1. Быстро создаются

2. Предоставляют быструю обратную связь

2а. Помогают вовлечь разработчиков в тестирование

3. Являются заготовками для будущих «красивых» тестов

SoapUI: спасение утопающих

1. Низкий порог вхождения

2. Возможность быстро создать test suite для запуска полного теста в один клик

3. Тесты можно включить в CI

4. Возможность разрабатывать тесты используя Mocks параллельно с имплементацией

5. Возможность создания Load и Security тестов

Вовлечение разработчиков:демонстрация

Цель: «Подсадить» программистов на тестирование

1. Демонстрация работы автотестов и объяснение основого смысла:- Быстрая обратная связь- Возможность быстро и самостоятельно проверить

качество перед коммитом

2. Демонстрация Selenium IDE

Вовлечение разработчиков:

обучение1. Возвращаем «подсевших» на качество разработчиков в

родную стихию:- Переход от IDE к RC или WebDriver- Выделение времени на перевод старых тестов с IDE на

Java

2. SoapUI тесты для неподдатливых:- Обучение созданию- Расширение возможностей с Groovy- CI

Результаты

1. Покрытие 75% функциональности автотестами

2. Полный переход от Selenium IDE к RC, а затем WebDriver за год

3. Создание тестов по сценариям заказчика для всех веб сервисов

4. Команда разработки полноценно вовлечена в процесс обеспечения качества

Общий итог

1. Приложение покрыто тестами на всех уровнях

2. Проектная документация всегда up to date

3. Время регрессионного тестирования сократилось до 4 часов

4. Тестирование больше не «сваливается» на конец итерации

5. В процесс тестирования вовлечена вся команда.

6. Количество customers defects с 5 в неделю сократилось до 1 в 2-3 месяца.

7. Высвободилось время для проверки нефункциональных требований

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

Ключевые факторы успеха

1. Личная заинтересованность тестировщика в результате

2. Документация всегда должна быть в актуальном состоянии

3. Тесты должны быть быстрыми в создании и легкими в поддержке

4. Комплексная автоматизация тестирования на всех уровнях

5. В процесс обеспечени качества должна быть вовлечена вся команда

Вопросы

Email: bondarenko.ihar@yandex.ru

Skype: igor.bondarenko1