Жизненный цикл ПО
2026-02-26 18:49 Diff
https://ru.hexlet.io/courses/software-testing-lifecycle/lessons/product-software/theory_unit

Ранее в курсе мы обсуждали, как команды разрабатывают продукты от идеи до релиза. Но есть ли жизнь после выхода в продакшен? Об этом мы поговорим в этом уроке. Мы изучим фазу сопровождения продукта, которая начинается сразу после релиза.

Что такое сопровождение

Фаза сопровождения или поддержки (Post-Go-Live support) — это этап, на котором программное обеспечение впервые сталкивается с реальными пользователями.

Можно сказать, что это продолжение тестирования, потому что протестировать всё заранее невозможно. Само количество тестов бесконечно, так как нельзя предугадать все действия пользователей. Более того, на ПО влияют и остальные факторы: нагрузка, последовательности и одновременность действий, инфраструктура и так далее.

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

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

Что может входить в сопровождение

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

Ответы на вопросы. Компания-разработчик объясняет заказчику, как работает продукт, где находится какая-то кнопка, и так далее.

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

С реконфигурацией есть одна распространенная сложность — чем больше параметров, тем сложнее тестирование. Если параметров очень много, то сложно убедиться, что продукт работает корректно.

Рассмотрим такой пример. Представим, что у нас есть 10 параметров:

  • 3 поля с числами от 0 до 2 000 000
  • 3 поля со строковыми данными, длиной не более 255 и только маленькими латинскими буквами
  • 2 выпадающих списка с 5 значениями внутри каждый
  • 2 поля с галочками (чек-боксы)

Выглядит не так сложно, но на практике мы столкнемся с огромным количеством вариаций:

  • 3 поля по 2 000 000 вариантов
  • 3 поля с 6630 вариантами (255 умножаем на 26)
  • 2 поля с 5 вариантами
  • 2 поля с 2 вариантами

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

Помощь с багами и инцидентами. Чаще всего компания-разработчик помогает заказчику бороться с ошибками в готовой программе.

Причем в сопровождение входит борьба и с инцидентами, и с дефектами. Разберемся подробнее, чем отличаются эти понятия:

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

Как происходит реагирование на инциденты

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

Но на инцидент нужно как-то отреагировать. Мы открываем Jira или другую трекинговую систему и заносим в нее инцидент «Продакшен упал».

Далее начинаем выяснять, что случилось и почему:

  • Представим, что сервер отключился, потому что мышь перегрызла провод в серверной. Тогда инцидент не связан с дефектом в системе
  • Представим, что программное обеспечение зависло из-за выполнения какой-то операции. Тогда инцидент вызван багом в программном обеспечении, то есть в ПО проявился неизвестный нам дефект

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

  • Что делать, чтобы исправить последствия инцидента? Это приоритетный вопрос, потому что нужно как можно быстрее восстановить работу системы
  • Почему инцидент произошел? В чем основная причина?

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

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

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

Чтобы упростить задачу, разработчики оставляют себе подсказки в логах системы:

  • Выводят в лог ошибки и исключения интерпретатора
  • Записывают внутренние проверки правильности значений — «Ожидали значение Х, а получилось Y, могла произойти ошибка»

Такие строки в логах могут помочь разработчикам локализовать проблему в коде.

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

  • Статистика активностей
  • Журнал действий
  • Оповещения по уровням серьезности (alert severity levels)
  • Логи с выполняемыми действиями пользователей

Такие системы мониторинга помогают команде проекта либо предотвратить инцидент, либо быстрее разобраться в его причинах.