Короткие итерации меняют правила контроля качества. В классическом каскаде тестировщики получали готовую систему за месяц до сдачи и проверяли её отдельной фазой. В Scrum-команде, которая закрывает спринт за две недели, такой роскоши нет: код пишут, проверяют и показывают заказчику внутри одного цикла. Если тестирование остаётся «хвостом» спринта, оно либо съедает разработку, либо переносится на следующую итерацию и долг по качеству растёт быстрее, чем сама система.

За год через короткие итерации прошло несколько крупных проектов – от учётных контуров до ведомственных порталов, где разработка бизнес-систем велась без отдельной фазы тестирования. Ниже – то, что реально удерживает качество, а не просто отчётность по нему.

Тестирование внутри спринта, а не после него

Главное правило: задача не закрыта, пока не покрыта тестами. Тестировщик заходит в работу не на последнем дне спринта, а вместе с разработчиком – обсуждает критерии приёмки до начала кодирования. Так требование сразу формулируется проверяемо: не «система должна корректно считать НДС», а конкретный сценарий с входными данными и ожидаемым результатом.

Это меняет состав команды. Тестировщик перестаёт быть приёмщиком в конце конвейера и становится соавтором требований. На госпроектах это особенно ценно: формулировки из техзадания приходится превращать в десятки приёмочных сценариев, и делать это лучше до того, как разработчик уйдёт писать неверную логику.

Автоматизация как условие, а не опция

При двухнедельном ритме ручная регрессия нежизнеспособна. К пятой итерации накапливается столько функциональности, что полный ручной прогон занимает дни – а гонять его нужно каждый спринт, потому что любая правка ломает то, что вчера работало.

Мы строим тестирование пирамидой. В основании – модульные тесты, которые разработчик пишет на свой код и гоняет на каждой сборке. Над ними – интеграционные проверки на стыках модулей и обращениях к базе. Сверху, узким слоем, – автоматизированные приёмочные сценарии для веба. Для веб-клиентов это отдельная боль: разнобой браузеров заставляет проверять интерфейс в нескольких средах. Здесь помогает дисциплина вёрстки на согласованных стандартах – мы уже писали про ставку на HTML5 для кросс-платформенности, и единая кодовая база заметно сокращает матрицу тестов.

Связка непрерывной сборки и автотестов даёт команде обратную связь за минуты. Сломанная сборка – это стоп-сигнал: пока тесты красные, новый код в ветку не идёт.

Что проверять руками

Автоматика ловит регрессии, но не оценивает удобство и не находит того, чего никто не предусмотрел в сценариях. Поисковое (exploratory) тестирование остаётся за человеком: тестировщик ходит по системе свободно, ломает её нестандартными действиями и проверяет граничные случаи. Особенно это важно для новых типов взаимодействия – например, для бесконтактных интерфейсов: эксперименты вроде распознавания движений на Kinect показывают, что формальными сценариями такие сценарии не закрыть, нужен живой прогон руками.

Демонстрация в конце спринта – тоже элемент контроля качества. Заказчик видит работающий инкремент, а не отчёт, и ошибки в понимании требований всплывают через две недели, а не через полгода приёмки.

Вывод

Качество в коротких итерациях держится на трёх опорах: критерии приёмки формулируем до кода, регрессию автоматизируем полностью, удобство и неожиданное проверяем руками. Тогда каждый спринт отдаёт заказчику проверенный кусок системы, а не обещание протестировать позже. Уходящий год это подтвердил – подробнее в наших итогах 2010-го.