Тестирование крупных проектов командой из одного...
description
Transcript of Тестирование крупных проектов командой из одного...
![Page 1: Тестирование крупных проектов командой из одного тестировщика](https://reader035.fdocuments.net/reader035/viewer/2022062220/558c94cad8b42a13258b45ca/html5/thumbnails/1.jpg)
Как не сойти с ума тестируя большой проект в одиночку
Igor Bondarenko. Intetics Co.
![Page 2: Тестирование крупных проектов командой из одного тестировщика](https://reader035.fdocuments.net/reader035/viewer/2022062220/558c94cad8b42a13258b45ca/html5/thumbnails/2.jpg)
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 тестировщик
Можно ли назвать проект «большим»
![Page 3: Тестирование крупных проектов командой из одного тестировщика](https://reader035.fdocuments.net/reader035/viewer/2022062220/558c94cad8b42a13258b45ca/html5/thumbnails/3.jpg)
Главные проблемы на старте
• 1. Отсутствие проектной документации• 2. Полное отсутствие тестовой документации• 3. Большой объем регресии: 20 человекочасов на
итерацию
(при десятидневной итерации)• 4. Автоматизация отсутствует впринципе• 5. Нефункциональные требования никогда не
проверялись
![Page 4: Тестирование крупных проектов командой из одного тестировщика](https://reader035.fdocuments.net/reader035/viewer/2022062220/558c94cad8b42a13258b45ca/html5/thumbnails/4.jpg)
Решение проблем
![Page 5: Тестирование крупных проектов командой из одного тестировщика](https://reader035.fdocuments.net/reader035/viewer/2022062220/558c94cad8b42a13258b45ca/html5/thumbnails/5.jpg)
Документация: проблемы
1. Невнятные User Stories2. Документация минует систему хранения
(Confluence)3. Нежелание писать документы для
«одноразовой» функциональности
![Page 6: Тестирование крупных проектов командой из одного тестировщика](https://reader035.fdocuments.net/reader035/viewer/2022062220/558c94cad8b42a13258b45ca/html5/thumbnails/6.jpg)
Невнятные User Stories
Причина: Неумение писать спецификации
Цель: Получение функциональной спецификации от заказчика
Способы решения:- Демонстрация устраивающих команду
спецификаций- Обучение заказчика- Реализация функциональности со спекой за
меньшие сроки
![Page 7: Тестирование крупных проектов командой из одного тестировщика](https://reader035.fdocuments.net/reader035/viewer/2022062220/558c94cad8b42a13258b45ca/html5/thumbnails/7.jpg)
Документация минует систему хранения
Причина: Необходимость отправки документации по частям партнерам
Цель: Хранение всей документации в одном месте, возможность быстро отслеживать изменения
Способы решения:- Разработка единого шаблона документации- Документ изначально создается в Confluence-Создание Word шаблона фирменного стиля-Предоставление доступа партнерам к системе хранения документации
![Page 8: Тестирование крупных проектов командой из одного тестировщика](https://reader035.fdocuments.net/reader035/viewer/2022062220/558c94cad8b42a13258b45ca/html5/thumbnails/8.jpg)
«Одноразовая» функциональность
Причина: Спецификация не составляется, если изменения не планируются
Цель: Иметь описание работы функционала
Решение:-Анализ каждой «одноразовой» функциональности-Разбиение глобальной User Story на составляющие-Полное покрытие функциональности детальными тестовыми сценариями
![Page 9: Тестирование крупных проектов командой из одного тестировщика](https://reader035.fdocuments.net/reader035/viewer/2022062220/558c94cad8b42a13258b45ca/html5/thumbnails/9.jpg)
Тестовые сценарии
Основные проблемы:- Отсутствие времени на написание- Дорогостоящая поддержка
Решение:- Checklists forever!- Тесткейсы только если отсутствует спецификация
![Page 10: Тестирование крупных проектов командой из одного тестировщика](https://reader035.fdocuments.net/reader035/viewer/2022062220/558c94cad8b42a13258b45ca/html5/thumbnails/10.jpg)
Функциональное тестирование
Основные проблемы:
1. Трудозатраты на регрессию
2. Ручные тесты
3. Отсутствие исследовательского и нефункционального тестирования
Цель:
Реорганизация процесса тестирования для выделения необходимого времени
![Page 11: Тестирование крупных проектов командой из одного тестировщика](https://reader035.fdocuments.net/reader035/viewer/2022062220/558c94cad8b42a13258b45ca/html5/thumbnails/11.jpg)
Ручное тестирование
1. Переход от тесткейсов к чеклистам
Плюсы:-Сокращение времени на написание-Проще поддерживать-Позволяют начать тестирование раньше
2. Исключение тестирования в конце итерации
3. Подключаем исследовательское тестирование к «скриптовому»
![Page 12: Тестирование крупных проектов командой из одного тестировщика](https://reader035.fdocuments.net/reader035/viewer/2022062220/558c94cad8b42a13258b45ca/html5/thumbnails/12.jpg)
Автоматизация
Проблема:
Полное отсутствие автоматизированных тестов
![Page 13: Тестирование крупных проектов командой из одного тестировщика](https://reader035.fdocuments.net/reader035/viewer/2022062220/558c94cad8b42a13258b45ca/html5/thumbnails/13.jpg)
Выбор инструмента
HP Selenium
Имеется опыт использования Опыта нет
Разработчики отказываются писать тесты
Низкий порог вхождения
IDE
Возможность писать тесты на Java
Вовлечение разработчиков
Гибкий
![Page 14: Тестирование крупных проектов командой из одного тестировщика](https://reader035.fdocuments.net/reader035/viewer/2022062220/558c94cad8b42a13258b45ca/html5/thumbnails/14.jpg)
«Некрасивые тесты»
Наличие «некрасивого» автотеста значительно лучше, нежели его отсутсвие
![Page 15: Тестирование крупных проектов командой из одного тестировщика](https://reader035.fdocuments.net/reader035/viewer/2022062220/558c94cad8b42a13258b45ca/html5/thumbnails/15.jpg)
Положительное влияние «некрасивых тестов»
Плюсы таких тестов в начале проекта:
1. Быстро создаются
2. Предоставляют быструю обратную связь
2а. Помогают вовлечь разработчиков в тестирование
3. Являются заготовками для будущих «красивых» тестов
![Page 16: Тестирование крупных проектов командой из одного тестировщика](https://reader035.fdocuments.net/reader035/viewer/2022062220/558c94cad8b42a13258b45ca/html5/thumbnails/16.jpg)
SoapUI: спасение утопающих
1. Низкий порог вхождения
2. Возможность быстро создать test suite для запуска полного теста в один клик
3. Тесты можно включить в CI
4. Возможность разрабатывать тесты используя Mocks параллельно с имплементацией
5. Возможность создания Load и Security тестов
![Page 17: Тестирование крупных проектов командой из одного тестировщика](https://reader035.fdocuments.net/reader035/viewer/2022062220/558c94cad8b42a13258b45ca/html5/thumbnails/17.jpg)
![Page 18: Тестирование крупных проектов командой из одного тестировщика](https://reader035.fdocuments.net/reader035/viewer/2022062220/558c94cad8b42a13258b45ca/html5/thumbnails/18.jpg)
Вовлечение разработчиков:демонстрация
Цель: «Подсадить» программистов на тестирование
1. Демонстрация работы автотестов и объяснение основого смысла:- Быстрая обратная связь- Возможность быстро и самостоятельно проверить
качество перед коммитом
2. Демонстрация Selenium IDE
![Page 19: Тестирование крупных проектов командой из одного тестировщика](https://reader035.fdocuments.net/reader035/viewer/2022062220/558c94cad8b42a13258b45ca/html5/thumbnails/19.jpg)
Вовлечение разработчиков:
обучение1. Возвращаем «подсевших» на качество разработчиков в
родную стихию:- Переход от IDE к RC или WebDriver- Выделение времени на перевод старых тестов с IDE на
Java
2. SoapUI тесты для неподдатливых:- Обучение созданию- Расширение возможностей с Groovy- CI
![Page 20: Тестирование крупных проектов командой из одного тестировщика](https://reader035.fdocuments.net/reader035/viewer/2022062220/558c94cad8b42a13258b45ca/html5/thumbnails/20.jpg)
Результаты
1. Покрытие 75% функциональности автотестами
2. Полный переход от Selenium IDE к RC, а затем WebDriver за год
3. Создание тестов по сценариям заказчика для всех веб сервисов
4. Команда разработки полноценно вовлечена в процесс обеспечения качества
![Page 21: Тестирование крупных проектов командой из одного тестировщика](https://reader035.fdocuments.net/reader035/viewer/2022062220/558c94cad8b42a13258b45ca/html5/thumbnails/21.jpg)
Общий итог
1. Приложение покрыто тестами на всех уровнях
2. Проектная документация всегда up to date
3. Время регрессионного тестирования сократилось до 4 часов
4. Тестирование больше не «сваливается» на конец итерации
5. В процесс тестирования вовлечена вся команда.
6. Количество customers defects с 5 в неделю сократилось до 1 в 2-3 месяца.
7. Высвободилось время для проверки нефункциональных требований
![Page 22: Тестирование крупных проектов командой из одного тестировщика](https://reader035.fdocuments.net/reader035/viewer/2022062220/558c94cad8b42a13258b45ca/html5/thumbnails/22.jpg)
Количественные показатели
![Page 23: Тестирование крупных проектов командой из одного тестировщика](https://reader035.fdocuments.net/reader035/viewer/2022062220/558c94cad8b42a13258b45ca/html5/thumbnails/23.jpg)
Ключевые факторы успеха
1. Личная заинтересованность тестировщика в результате
2. Документация всегда должна быть в актуальном состоянии
3. Тесты должны быть быстрыми в создании и легкими в поддержке
4. Комплексная автоматизация тестирования на всех уровнях
5. В процесс обеспечени качества должна быть вовлечена вся команда