Контроль качества в компании 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• Прогоняются автотесты производительности• Обновляются тест-матрицы• Найденные недочеты – отдельные баги

А релиз всё ближе

Регрессия

• Проводится на релизном бранче• Полнота охвата зависит от даты предыдущего релиза• Выполняется по готовым кейсам• Свободное тестирование• Быстрый фикс критичных багов

Бета-тестирование

• Установка реальным клиентам• Баги из реальной жизни• Быстрая обработка найденных недочетов

Ура! Релиз!

А что дальше?

• Разработка нового функционала• Обработка запросов от клиентов• Автотесты, пока разработчики пишут новые фичи

Спасибо за внимание!