Контроль качетсва в компании iiko
TRANSCRIPT
Контроль качества в компании iiko.
Входные данные
• Небольшая компания• Коробочный продукт• Релиз 1 раз в 1-3 месяца• Продуктовые команды• В команде 2-4 тестировщика, 2-10 разработчиков
Разработка в персональных ветках
Что делают тестировщики компании
• Тестируют продукт • Разворачивают и поддерживают тестовые стенды• Пишут и поддерживают автотесты• Поддерживают автотестовый фреймворк• Самостоятельно администрируют свои сервисы• Ставят задачи на тестирование• Делятся своими знаниями• Формируют команду тестирования• Дружат с разработчиками (и не только )
Как-то так
Чего не делают тестировщики компании
• Не пишут Unit - тесты• Не пишут production – код• Не молчат о проблемах
Инструменты
Инструменты
Этапы контроля качества
1. Code Review1a. Автоматическое тестирование кода
2. Тестирование обновления базы3. Unit-тесты4. Тестирование в ветке 4а. Автоматическое тестирование в ветке5. Тестирование в develop
5a. Автоматическое тестирование в develop.6. Beta-testing
Code review и тестирование кода
• Код видит минимум 2 разработчика: автор и reviewer• Пройденное review - обязательное условие для
передачи в тестирование• Автоматическое тестирование валидности кода• Review автотестов
Unit тесты
• Пишутся разработчиками• ~ 15000 тестов• Успешный проход – обязательное условие передачи в
тестирование• TDD (иногда )
Тестирование в бранче
• Успеть посмотреть, пока разработчик в теме• Доп. квест «добудь требования»• Смотрится затронутая фиксом область и немного
вокруг• Из бранча задача выходит тогда, когда не останется
серьёзных замечаний• Оставшиеся баги заводятся в багтрекере и фиксятся в
рабочем порядке• Бранч от бранча в случае разработки большой фичи• Автотесты или хотя бы задача на них
А если бранчей слишком много?
1. Правильная организация работы
• Параллельное тестирование нескольких фич• Шаблоны стендов• Соотношение разработчики-тестировщики
хотя бы 3:1
2. Автотесты в ветке
• Гарантируют, что основной функционал жив• Можно писать автотесты в одной ветке с основной
задачей.• Готовый стенд для быстрого тестирования• Не заменяют ручное тестирование в ветке (за редким
исключением)
3. Commit сразу в develop
• Очень простые изменения– Нет смысла городить ветку ради изменения шрифта на 1 кнопке
• Разработчик уверен в изменениях• Merge сразу после review
Ура! Merge!
• Ручное тестирование совместимости• Проверка, что код попал везде, куда должен был• Прогоняются автотесты функционала в develop и
release• Прогоняются автотесты производительности• Обновляются тест-матрицы• Найденные недочеты – отдельные баги
А релиз всё ближе
Регрессия
• Проводится на релизном бранче• Полнота охвата зависит от даты предыдущего релиза• Выполняется по готовым кейсам• Свободное тестирование• Быстрый фикс критичных багов
Бета-тестирование
• Установка реальным клиентам• Баги из реальной жизни• Быстрая обработка найденных недочетов
Ура! Релиз!
А что дальше?
• Разработка нового функционала• Обработка запросов от клиентов• Автотесты, пока разработчики пишут новые фичи
Спасибо за внимание!