class="p1">Процесс — это совокупность взаимосвязанных действий или задач для достижения определенного бизнес — результата или цели. Процессы не только охватывают разработку программного обеспечения, но и диктуют правила абсолютно для всех уголков компании.

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

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

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

Уровни процессов в компаниях

— Стратегический — на этом уровне определяют миссию компании, ее видение, выстраивают стратегические цели и планы на годы вперед. Самое высокое руководство вместе с отделом стратегического планирования разрабатывает долгосрочные планы с учётом всех возможных аспектов. Именно тут определяют направление развития компании, выходы на новые рынки, разработку новых программных продуктов с учетом финансовых аспектов.

— Управленческий (Тактический) — на этом уровне происходит планирование и координация конкретных инициатив и проектов в рамках стратегических целей и планов компании. Менеджеры среднего звена рассчитывают и распределяют ресурсы, контролируют качество и сроки, управляют рисками, внедряют изменения в процессы.

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

— Поддерживающий — на этом уровне обеспечивают всестороннюю поддержку функционирования компании. Сюда относится обеспечение безопасности, HR — процессы, юридическая поддержка, финансовое планирование и внутренние ИТ — службы.

— Уровень непрерывного улучшения (не всегда присутствует) — он проходит сквозь остальные и направлен на постоянное усовершенствование их процессов. Сюда могут входить советы и даже контроль менеджеров среднего звена и ниже за соблюдением инициатив по улучшению процессов. Портал для обучения сотрудников новым навыкам тоже относится к инициативе данного уровня, как и многое другое.

На вас как QA инженера будут так или иначе влиять все уровни. Сами же вы находитесь на Операционном. За ваш карьерный рост в виде новых должностей и проектов так или иначе влияют сотрудники прочих уровней:

— Стратегический уровень — тут появляются идеи новых проектов или объединения старых, из-за чего в компании могут ввести новые должности или сокращения.

— Управленческий уровень — тут рассчитывают, какие сотрудники и в каком количестве нужны в новых или существующий проектах.

— Поддерживающий уровень — тут происходит расчет зарплат и других компенсаций вашего труда.

В зависимости от процессов компании запрос на перемещение внутри нее по должностям может быть адресован как Поддерживающему уровню в виде HR специалиста, так и Операционному в виде QA менеджера.

6.2. Процессы разработки программного обеспечения

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

Процессы, как и все в мире ИТ, тоже развиваются, часть из них уже почти не применяют, а часть всё ещё популярна. Наиболее востребованными процессами разработки являются Agile методологии, чаще всего это Scrum и Kanban. Однако далеко не все компании и проекты работают именно по этим конкретным Agile процессам и по Agile подходу в принципе. В некоторых случаях такие методологии просто не применимы.

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

6.2.1. Waterfall

Waterfall — это строго последовательный процесс разработки, где каждый этап начинается только после полного завершения предыдущего. Водопадная модель хорошо подходит для проектов с четко определенными требованиями и когда изменения в процессе разработки маловероятны. QA инженеры в такой модели участвуют только на одном этапе из семи.

Особенности:

— Последовательность — этапы разработки следуют строго один за другим, без возможности перекрытия и возврата назад.

— Документирование — документация является ключевым компонентом для передачи информации между всеми этапами разработки. Поэтому на каждом этапе требуется довольно подробное документирование.

— Спецификации — все требования к проекту определяют на ранних стадиях, и любые изменения в процессе разработки могут потребовать возвращения к начальным её этапам.

— Легкая визуализация и понимание — структура модели четкая и легко понятна новым участникам команды.

Преимущества:

— Простота управления — четкая простая структура и последовательность этапов делают контроль и управление довольно легкими.

— Предсказуемость бюджета и сроков — этапы и требования максимально прозрачны, что дает возможность хорошо спланировать сроки и бюджеты.

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

Недостатки:

— Негибкость к изменениям — изменения в требованиях после старта работы над проектом могут оказаться дорогостоящими и сложными в реализации.

— Отсутствие обратной связи от пользователя — до завершения проекта нельзя понять, насколько он будет валидирован конечными пользователями, есть риск заметно не удовлетворить их потребности.

— Риск на поздних этапах — модель не предполагает возврата на предыдущие уровни, а значит, ошибки, обнаруженные на стадии тестирования, могут дорого обойтись.

Этапы:

— Сбор и анализ требований. Цель этого этапа — выявить требования пользователей к будущей системе и впоследствии создать её подробное описание.

— Системное проектирование — на этом этапе определяют архитектуру проекта и высокоуровневые компоненты.

— Детальное проектирование — создание подробных спецификаций на основе требований к каждому компоненту системы.

— Кодирование и разработка — реализация программного обеспечения в соответствии со спецификациями.

— Тестирование — проверка программного обеспечения на соответствие спецификациям и поиск ошибок.

— Развертывание — внедрение системы в prod — окружение.

— Поддержка и обслуживание — поддержка работоспособности разработанного приложения и выполнение обновлений.

6.2.2. Spiral Model

Spiral Model