Неделю назад мы начали разговор о методологиях SDLC. Разобрали традиционные модели разработки, где процесс строго регламентирован. Но если водопад и V-модель — это про чёткий план, то современные подходы к разработке — про гибкость, адаптацию и итерации. В этой части разберём популярные гибкие методологии, а также менее формальные модели, которые тоже встречаются в реальных проектах. Тестировщикам здесь приходится работать в постоянном движении — без сценариев «по бумажке», но с быстрым фидбеком и реальной ценностью.
Спиральная модель (Spiral)
Считается, что это частный случай итеративно-инкрементной модели. Однако, полностью рабочий продукт создаётся постепенно, без создания MVP. Иными словами, продукт создается шаг за шагом и на каждом шаге тестировщики проводят тестирование инкремента, а по мере их добавления проводят регрессионное тестирование.
Особенностью тестирования в данной модели является упор на автоматизацию тестов, что позволяет быстро получать обратную связь и проводить регрессионное тестирование.
📍 Применяется спиральная модель при разработке сложных программных систем: банки, ОС, авиационное ПО. Задача — как можно быстрее показать работающий результат, пусть и с неполным функционалом. Исходя из этого специалисты могут при тестировании проходить в основном позитивные сценарии, а негативные — лишь при наличии времени на тестирование.
Модель большого взрыва (Big Bang)
В данной модели только сам разработчик выполняет тестирование продукта в соответствии со своим пониманием продукта. Тестовая документация не составляется.
Без планирования, без требований, без документации.
Тестирования как отдельного процесса — просто нет.
📍 Используется в студенческих проектах, быстрых пилотах, во фрилансе и в редких стартапах.
Гибкая модель (Agile)
В Agile разработка ПО разбивается на итерации. Каждая итерация увеличивает функциональность продукта.
📍 Особенность Agile — тестирование может происходить в любой момент разработки.
Для данной методологии характерны два основных фреймворка – Scrum и Kanban.
- В Scrum итерации называются спринтами. Каждый спринт длится 2-4 недели. Тестирование проводится в каждом спринте.
- В Kanban спринтов нет и тестирование происходит по мере создания новой функциональности.
Я работал в проекте по разработке автоматизированной системы электронных паспортов транспортных средств (для Республики Беларусь), а также в проекте по доработке функционала Белорусской универсальной товарной биржи. В обоих проектах команда придерживалась фреймворка Scrum и работала по 2-х недельным спринтам.
В начале каждого спринта мы выбирали из бэклога задачи, которые планировали к реализации. Проводили эстимацию трудозатрат, где обязательно определяли время, необходимое на тестирование. В первые дни спринта, когда код новой функциональности только начинал писаться у меня была одна главная задача – провести регресс системы и убедиться, что функциональность, добавленная в прошлом спринте, ничего «не поломала». Далее на всём протяжении спринта, если не было иных более приоритетных задач, готовилась тестовая документация для покрытия тестами разрабатываемой функциональности.
После создания новой функциональности она проверялась на предмет соответствия спецификации. При необходимости оформлялись баг-репорты и в последующем проводилось повторное тестирование. Стоит отметить, что создание тестовой документации являлось менее значимой задачей и приоритет отдавался непосредственному тестированию либо проверке исправления баг-репортов, либо регрессу. Примерно с середины проекта мы начинали готовить пользовательскую документацию (инструкции), а также пользовательские сценарии (как правило, только положительные проверки), на основании которых заказчик принимал проект.
Заключение
Гибкие методологии — это не хаос, как часто о них отзываются, а возможность адаптироваться под реальные запросы бизнеса. А тестировщик в таких проектах — не просто контролёр, а часть команды, которая помогает находить оптимальные решения на каждом этапе.
Как мы видим, тестирование для разных методологий может осуществляться на этих этапах в различном объёме. Но самое главное – оно является неотъемлемой частью любого жизненного цикла разработки ПО. Оно однозначно помогает предотвратить вероятные неточности в работе продукта и быть уверенным, что он высокого уровня качества. А высокое качество продукта повышает авторитет и конкурентоспособность компании, привлекает новых клиентов.
Очевидно, что тестирование стоит на страже интересов пользователей, не позволяя появиться недоработанному продукту. Оно также стоит на страже финансовых интересов заказчика, находя на ранних этапах разработки ошибки в работе системы и тем самым позволяя заказчику экономить деньги и время на их исправление.
И пусть в таких проектах документация часто появляется «по ходу пьесы», зато баги ловятся раньше, а качество улучшается итерация за итерацией.
