В свое время, когда мы только запускали API, всё было скромно: небольшая команда, комфортные требования, да и бизнес не требовал от нас подвигов. Но всё коренным образом изменилось, когда API разрослось до 30 серверных компонент в трёх датацентрах, а бизнес «порекомендовал» успевать с ответом в 200 мс и выкатывать релизы раз в неделю. На фоне роста проекта, росла команда и остро встали вопросы «как экологично встроить тестирование в большую scrum-команду большого проекта».
Мы сфокусировались на трёх важных моментах:
Планирование
Большая команда → «большое» планирование. Тестирование планируется отдельно или вместе с разработчиками? Нужна ли выделенная роль крайнего за тестирование на проекте?
Релиз
Нужен ли крайний за релиз и кто отвечает за интеграционные зависимости? Когда надо остановиться и заморозить фичи? Кто и как мониторит продукт после релиза?
Автоматизация — наше всё ;)
Как не «захлебнуться» в регрессии: unit-тесты, json-схема. Как правильно выбрать фичи для автоматизации и как встроить автоматизацию в процесс тестирования.
29. Тестирование / Unit Tests
1. Наколбасил? – Запусти Unit Tests!
2. Взял задачу в тестирование? –
Запусти Unit Tests!
30. Тестирование / Unit Tests
1. Наколбасил? → Запусти Unit Tests!
2. Взял задачу в тестирование? →
Запусти Unit Tests!
3. Регрессируешь? → Запусти Unit
Tests!
39. /**
* StationSearch. Единовременное использование
*project и where
*
* 1. Получаем некорретное значение с помощью метода
*getIncorrectValues и запоминаем его
* 2. Параметру where присваиваем некорректное
* значение из п.1
* 3. Делаем запрос
* 4. Проверяем значения полей, содержащихся в ответе:
* a. версия API равна указанной в запросе;
* b. код отевета = 400;
*
* @author Ogarkova Anastasia <a.ogarkova@2gis.ru>
* @since 26.03.2012
*/
40.
41. Тестирование / Резюме
• Unit Tests;
• Functional AutoTests;
• Автоматизация тестирования документации;
• Автоматизация внутренней документации.