В ИТ существует огромное количество проектов. И все они разные, потому что у каждого проекта свои особенности:

• разные заказчики со своими задачами и ожиданиями;
• разные команды, которые создают эти приложения.

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

Для этого существуют методологии разработки ПО - набор правил, этапов и подходов к организации работы. Их ещё называют моделями или процессами.

Но не бывает одной универсальной методологии. Сфера ИТ постоянно развивается, поэтому в разные периоды появлялись разные методы разработки.

Прежде чем перейти к конкретным подходам, стоит упомянуть общий принцип. Любая методология опирается на SDLC (Software Development Life Cycle - жизненный цикл разработки ПО).

Этапы SDLC

1. Планирование (Planning) - постановка целей, определение бюджета, сроков и ресурсов.
2. Анализ требований (Requirements Analysis) - сбор и документирование всех требований к продукту.
3. Проектирование (Design) - разработка архитектуры, дизайна и других технических деталей.
4. Разработка (Development) - написание кода по подготовленному плану.
5. Тестирование (Testing) - проверка соответствия требованиям, поиск ошибок (багов).
6. Развертывание (Deployment) - внедрение готового продукта в рабочую среду.
7. Поддержка (Maintenance) - обслуживание, исправление проблем, улучшения.

Как именно проходят эти этапы, какова их длительность и порядок - зависит от выбранной методологии.

Основные методологии

Waterfall (водопадная, каскадная модель)

Это первая широко описанная и применяемая методология. И она до сих пор актуальна - особенно там, где нужно строгое следование требованиям: в медицинских, военных, государственных проектах.

Суть модели проста: все этапы SDLC идут строго друг за другом. Возврат к уже завершённому этапу не предусмотрен. То есть сначала фиксируются требования, затем проектирование, потом разработка, тестирование и поддержка.

Как видно наглядно на картинке, в основе модели лежат все фазы SDLC, которые идут строго друг за другом.

Главный минус для тестировщиков: тестирование начинается только во второй половине проекта и достигает максимума уже в самом конце.

Итерационные модели

Следующим шагом стали итерационные (и инкрементальные) модели. Яркий пример - Rational Unified Process (RUP).

Здесь те же этапы SDLC, но они повторяются несколько раз. Каждый цикл - это итерация. Итераций может быть несколько, пока проект не будет завершён.

Главное преимущество - тестирование начинается уже на ранних этапах и продолжается на протяжении всего проекта.

Сегодня такие модели применяются реже, их скорее можно считать переходным этапом к следующей группе методологий.

Agile (аджайл)

Agile - это не просто методология, а целая философия разработки ПО. Несмотря на перевод слова ("гибкий"), внутри есть чёткие правила, практики, ценности и принципы.
Agile включает целую группу конкретных подходов: Scrum, Kanban, Scrumban и другие. Сегодня большинство проектов работают именно по ним.

Здесь также есть итерации, только называются они спринтами. Дополнительно присутствуют роли, артефакты и обязательные (и не очень) церемонии.

Согласитесь, очень похоже на итерационный подход, только вместо итерации появляется спринт.
Подробно останавливаться сейчас не будем, это стоит отдельной статьи. А про церемонии она уже была.

По сути, это развитие итерационного подхода, только более структурированного.

Зачем тестировщику знать методологии?

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

Таким образом, знание методологий - это обязательная часть работы тестировщика. Оно помогает выполнять задачи в срок, лучше понимать проект и взаимодействовать с командой. А в будущем, занимая руководящие позиции, тестировщик сможет влиять на процессы и улучшать продукт.