Подходы к разработке и тестированию ПО

Проверочная работа: Выбор методологий разработки и тестирования

Инструкция: Для каждой описанной ситуации определите, какой подход/подходы к разработке или тестированию наиболее целесообразно применить. Обоснуйте свой ответ, ссылаясь на цели и суть подхода.

Кейс 1: «Запутанный заказ»

Ситуация:

Команда разрабатывает сложную систему управления логистикой для международной компании. Бизнес-логика включает множество правил: расчет стоимости доставки в зависимости от таможенных пошлин, ограничений по странам, типов грузов и сезонных коэффициентов. Разработчики, аналитики и логисты часто говорят на разных языках: технари оперируют терминами «объекты» и «методы», а логисты — «коносаментами» и «инкотермсами». Это приводит к постоянным недопониманиям и ошибкам в реализации.

Задание:

1. Какой подход к проектированию поможет навести «концептуальный порядок» и создать гибкую модель, отражающую реальный бизнес?

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

Кейс 2: «Спор о качестве»

Ситуация:

В стартапе по разработке мобильного банка фронтенд- и бэкенд-команды постоянно конфликтуют. Фронтендеры жалуются, что API бэкенда постоянно меняется без предупреждения, возвращает не те данные, которые ожидались, или вовсе «падает». Бэкендеры, в свою очередь, не понимают, какие именно данные и в каком формате нужны фронту для отрисовки экранов. Разработка новых фич постоянно застревает на этапе интеграции.

Задание:

1. Какой подход к разработке позволит командам работать параллельно и независимо, минимизировав конфликты на интеграции?

1. Какой подход к тестированию поможет формализовать «контракт» между фронтендом и бэкендом и автоматически проверять его соблюдение?

Кейс 3: «Страх изменений»

Ситуация:

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

Задание:

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

1. Какой подход к тестированию идеально подойдет для проверки одного и того же алгоритма расчета комиссий для сотен различных входных параметров (сумма, тип клиента, валюта и т.д.)?

Кейс 4: «Требования-хамелеоны»

Ситуация:

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

Задание:

1. Какой подход к разработке поможет «поймать» требования и создать их однозначную, исполняемую спецификацию, понятную и заказчику, и разработчикам, и тестировщикам?

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

Кейс 5: «Фокус на главном»

Ситуация:

Команда тестирования небольшого, но быстрорастущего проекта испытывает нехватку ресурсов. Полное регрессионное тестирование перед каждым релизом занимает несколько дней, из-за чего задерживаются поставки фич. При этом 80% багов находят в 20% функциональности, которая является ключевой для пользователей (например, процесс оформления заказа).

Задание:

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

1. Какой «подход» к разработке (из изученных) является антипримером и прямой дорогой к такой ситуации, когда все делается в условиях цейтнота и хаоса?

Кейс 6: «Доверяй, но проверяй»

Ситуация:

Команда разрабатывает модуль для криптографических вычислений. Требования исключительная надежность и безопасность. Ошибка в алгоритме может привести к фатальным утечкам данных. Код пишется на языке Rust, который известен своей мощной системой типов.

Задание:

1. Какой подход к разработке позволяет использовать систему типов для формального выражения инвариантов и бизнес-правил (например, «этот параметр не может быть нулевым», «эта операция возможна только для верифицированных данных»), перенося часть проверок с этапа тестирования на этап компиляции?

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

Кейс 7: «Бесшовная интеграция»

Ситуация:

Крупный ритейлер заказывает разработку новой системы складского учёта. Система должна состоять из нескольких независимых сервисов (микросервисы): «Управление запасами», «Приёмка товара», «Отгрузка». Эти сервисы будут разрабатывать разные команды, но им необходимо постоянно обмениваться данными о состоянии товаров на складе.

Задание:

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

1. Какой подход к разработке естественным образом вытекает из выбранного подхода к проектированию и позволяет сразу определить точки взаимодействия (API) между этими сервисами?

Кейс 8: «Прототип для инвестора»

Ситуация:

Стартап в сфере EdTech получил финансирование на идею персонализированного обучения. Инвесторы ждут работающий прототип через 2 месяца, чтобы принять решение о дальнейших вливаниях. Требования очень размыты и будут уточняться после обратной связи от первых пользователей. Важно быстро показать ключевой сценарий «ученик получает рекомендацию по следующему уроку».

Задание:

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

1. Какой подход к тестированию поможет команде сосредоточиться на проверке именно этого, самого ценного для инвестора, сценария, описанного с точки зрения пользователя?

Кейс 9: «Наследие прошлого»

Ситуация:

Компания начинает большой проект по модернизации (рефакторингу) старой, но критически важной системы расчёта заработной платы. Исходный код представляет собой «спагетти-код» без единого теста. Перед тем как что-либо менять, необходимо создать safety net — защитную сетку тестов, которая позволит понять, не сломали ли вы существующую логику своими правками.

Задание:

1. Какой подход к тестированию является классическим для таких ситуаций? Он предполагает, что тесты пишутся после кода (в данном случае — уже существующего) для его регрессионной проверки.

1. Какой цикл разработки (например, Красный-Зелёный-Рефакторинг) здесь неприменим на первом этапе, и почему?

Кейс 10: «Модель вместо тысячи слов»

Ситуация:

Разрабатывается система управления сложным технологическим процессом на производстве (например, химический завод). Поведение системы строго регламентировано и зависит от состояний множества датчиков и клапанов. Логика перехода между состояниями (открыть клапан А, если давление в емкости Б выше Х и температура меньше Y) очень сложна для описания текстом и prone to errors (склонна к ошибкам).

Задание:

1. Какой подход к разработке предлагает описать поведение системы в виде формальной модели (например, диаграммы состояний), на основе которой затем может быть сгенерирован код?

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