В интернет-магазине решили разрешить оплату бонусами: часть суммы заказа списывается с бонусного счёта, остаток уходит на карту. Между «решили» и «покупатели этим пользуются» лежит дорога: задачу обсудили, нарисовали, написали, проверили, выпустили — и потом ещё месяц чинили по жалобам. Эту дорогу называют жизненным циклом разработки, SDLC (Software Development Life Cycle).
Внутри неё у проверки своя дорожка поменьше — STLC (Software Testing Life Cycle). Она начинается не тогда, когда появилась кнопка, которую можно нажать, а гораздо раньше, и за одну задачу проходится целиком. Дальше — оба круга на той же оплате бонусами.
Большой круг — путь продукта, маленький — путь проверки. Маленький крутится внутри большого много раз и начинается не на этапе тестирования, а на этапе требований.
Как задача проходит путь от идеи до поддержки
Требования. Аналитик превращает идею «пусть бонусы можно тратить» в задачу с критериями приёмки: откуда берётся баланс, какую долю заказа он закрывает, что видит покупатель. Вы задаёте неудобные вопросы: что если бонусов больше суммы заказа, вернутся ли они при отмене, что при двойном «Оплатить».
Проектирование. Дизайнер рисует экран оплаты, разработчики решают, где хранится баланс и что при одновременных списаниях. Вы смотрите на макет глазами того, у кого всё идёт не так: пустой счёт, бонусов не хватает, обрыв сети в момент списания.
Разработка. Программисты пишут код и собирают сборку (билд) — установленную версию продукта с номером, которую можно открыть и потыкать. Вы пишете проверки, готовите данные (ноль бонусов, триста, огромный баланс) и добываете доступы к стенду.
Тестирование. Прогон проверок, заведённые баги, перепроверки — и внятный ответ на вопрос «можно выпускать или нет».
Релиз. Сборку ставят на настоящие сервера, и после выката вы проходите главный сценарий уже на реальном магазине: оплата бонусами работает, обычная не сломалась. Если всё плохо, релиз откатывают на прошлую версию. Дальше поддержка — обращения покупателей и мелкие доработки, отдельный вид работы, о нём ниже.
Названия этапов в командах отличаются, набор работ — почти нет. А вот пройти их можно по очереди и один раз или короткими кругами по две недели — это и есть модель разработки; для вас разница в одном: когда вы подключаетесь (модели, круг внутри спринта).
Свой круг внутри большого: STLC
«Потыкать» — далеко не первый шаг этой работы, а порядок удобнее запоминать по двум вопросам: что нужно на входе и что остаётся на руках.
Разбор требований. На входе — описание задачи и живой аналитик. Вы выписываете неописанное: вернутся ли бонусы при частичной отмене заказа; если они сгорают по сроку — что с ними при оформленном, но неоплаченном заказе. На руках — вопросы и ответы письменно, в комментариях к задаче, а не «договорились в коридоре» (подробнее).
Планирование. На входе — ответы с прошлого шага. Вы решаете, что проверяете, чего не трогаете и когда останавливаетесь: «проверяем оплату бонусами и обычную; доставку не трогаем; заканчиваем, когда пройдены все проверки и нет дефектов, блокирующих оплату». На руках — договорённость, которая на большой задаче вырастает в тест-план.
Дизайн проверок. На входе — понимание, что должно происходить, и договорённость про объём. На руках — тест-кейсы или чек-лист и тестовые данные: покупатели с нулевым балансом, с балансом меньше суммы заказа и больше её.
Три шага пройдены, а проверять нечего — сборки нет, и в этом весь смысл: к её приезду у вас всё готово. Пропущенный на требованиях случай расходится так же тихо: не обсудили двойное нажатие «Оплатить» — аналитик написал требование без него, дизайнер не нарисовал заблокированную кнопку, разработчик списал бонусы второй раз, вы проверили по тому же требованию. Когда «списали вдвое» придёт от покупателей, переделывать придётся всё разом (цена бага).
Стенд, доступы и приёмка сборки
Стенд (он же тестовое окружение) — отдельная копия продукта: свои сервера, база, данные. На настоящем магазине проверять нельзя: вы будете оформлять заказы от лица живых людей и списывать реальные бонусы. Часто стендов несколько: для разработчиков, для тестирования и похожий на боевой.
Три вещи выбивают заранее, а не в день прогона: адрес стенда и доступ; учётные записи и права администратора, если без них не посмотреть начисления; номер стоящей сборки — половина разговоров «у меня не воспроизводится» кончается тем, что вы и разработчик смотрели разные сборки.
Полный прогон начинать рано: сначала короткая проверка, что со сборкой можно работать — магазин открывается, вход работает, товар кладётся в корзину, экран оплаты появляется. Такой проход называют дымовой проверкой, он занимает десять-пятнадцать минут. Разваливается — сборку возвращают с описанием поломки и ждут следующую: полдня проверок на сборке без входа придётся повторить целиком.
Выполнение — это петля, а не прямая
Вы находите, что при двойном нажатии «Оплатить» бонусы списываются два раза, и заводите дефект. Разработчик чинит и переводит его в «исправлено». Вы перепроверяете этот случай на новой сборке: ушло — закрываете; не ушло или ушло наполовину — возвращаете с уточнением, что осталось. Вокруг крутится вторая петля: починка могла задеть соседнее, поэтому рядом идут проверки того, что раньше работало (статусы дефекта). Из-за петли оценка «проверю за день» врёт: день — один проход, а проходов будет столько, сколько приедет сборок.
Чем круг заканчивается и сколько раз он повторяется
Закончить работу — значит сказать вслух три вещи: что проверено, что не проверено и почему, какие риски остаются. «Оплата бонусами проверена на всех трёх типах покупателей; частичный возврат не проверял — на стенде не настроены возвраты; риск средний». Не сказали — команда считает, что проверено всё, и риски умолчания становятся вашими.
Большой круг у команды идёт месяцами, а маленький вы проходите на каждой задаче: за двухнедельный спринт он проворачивается несколько раз. На крупной задаче разбор требований — встреча на час, на «поменять текст ошибки» весь круг занимает полчаса: шаги не исчезают, они сжимаются.
После релиза: обращения и срочные починки
Обращение приходит без шагов воспроизведения: «не работает оплата бонусами, верните деньги» — без версии браузера, без времени, без номера заказа. Ваша работа — превратить это в дефект: вытащить подробности из поддержки, найти заказ, посмотреть, что было в тот момент, и составить шаги, по которым ошибка повторяется. Часто дело оказывается не в оплате: бонусы сгорели накануне.
«Не воспроизводится» здесь не повод закрыть обращение: чаще это значит, что вы пробуете на других данных. Помогает зайти под тем же типом покупателя, повторить окружение (браузер, страна, доставка) и посмотреть, что записано в системе на момент обращения.
Когда бонусы списываются, а заказ не создаётся, починку не ставят в очередь до следующего релиза, а выпускают отдельно и срочно — это хотфикс. Спешка в нём и есть опасность: делался быстро, проверялся в сжатые сроки, поэтому после него смотрят, не сломалось ли рядом.
Коротко
- SDLC — путь продукта: требования, проектирование, разработка, тестирование, релиз, поддержка. STLC — путь одной проверки внутри него, и он проходится на каждой задаче, начинаясь на требованиях: три первых шага делаются, когда кода ещё нет.
- У каждого шага есть вход и результат: нет описания, доступов или сборки — шаг не начнётся; нет вопросов, проверок или итога — шаг не закончен.
- Стенд, доступы и данные готовят заранее, а новую сборку сначала проверяют дымовой проверкой.
- Выполнение — петля «нашли → починили → перепроверили», и рядом идут проверки того, что раньше работало.
- Случай, пропущенный на требованиях, расходится по макету, коду, проверкам и поддержке — переделывать придётся всё сразу.
Что почитать дальше
- Модели разработки: waterfall, V-модель, итерации — в каком порядке команды проходят этапы.
- QA в Agile и Scrum — как маленький круг выглядит внутри двухнедельного спринта.
- Тест-план и тест-сьюты — что рождается на шаге планирования.
- Тестирование по требованиям — шаг разбора требований в деталях.