На вас как 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 — это подход разработки приложений итерациями, который сочетает в себе элементы Waterfall модели и прототипирования с акцентом на управлении рисками. Спиральная модель предназначена для больших сложных проектов с высокими рисками.