Всем привет! Я старший специалист по тестированию в ITFB Group. Сегодня хочу поделиться с вами практическим опытом нашей команды — как нам удалось достичь нулевого количества инцидентов в продакшене за отчётный период.
Это не теория, а реальная история из проекта крупного банка, где мы внедрили систему процессов, позволившую минимизировать риски. Если вам интересен практический подход к предотвращению сбоев, давайте разберём его вместе.
Инцидент в проде — вещь довольно неприятная не только для пользователей, но и для компании и всей команды в целом. Чем больше досадных ошибок найдут пользователи, тем ниже будет рейтинг компании, а также премии и моральный дух команды разработки продукта.
Всем известна аксиома: не существует какого-либо продукта без ошибок. Но можно ли свести их к минимуму?
Начнём с определений: что же такое инцидент, ошибка, дефект, сбой.
Инцидент (incident, deviation) — любое сообщение о сбое/отказе или дефекте системы, поступившее от пользователя через службу технической поддержки.
Ошибка (error, mistake) — действие человека, приводящее к некорректным результатам.
Дефект (defect, bug, problem, fault) — любое отклонение изготовленной продукции (в нашем случае ПО) от требований, установленных нормативно-технической документацией (определение ГОСТ 15467-79).
Сбой — самоустраняющийся или однократный отказ, устраняемый незначительным вмешательством.
Отказ — событие, заключающееся в нарушении работоспособного состояния приложения.
Очевидно, что на ошибки, связанные с человеческим фактором, повлиять крайне сложно. Но в наших руках — уменьшить вероятность возникновения инцидентов в промышленной среде, тем самым минимизируя появление дефектов и предотвращая отказы и сбои.
В данной статье хотелось бы поделиться реальным опытом работы проектной команды крупного российского банка, у которой за отчётный период 2024 года не было ни одного инцидента в промышленной среде.
При этом следует уточнить: за этот период не было сбоев и отказов, зафиксированных пользователями через СТП (службу технической поддержки) и внесённых в баг-трекер. Однако могли присутствовать незначительные дефекты и ошибки.
О продукте:
Продукт: приложение крупного российского банка (мобильные версии iOS, Android, а также веб-версия).
Частота релизов: раз в две недели.
Предметная область: кредитование.
Команда тестирования: 4 человека + 4 на регрессионное тестирование.
Топ-10 используемых приёмов:
1. Груминг
Каждый спринт проводился командный предгруминг, на котором разбирались верхнеуровневые бизнес-требования по новым задачам, а затем груминг, где рассматривались бизнес-требования и системная аналитика. Это обязательное мероприятие перед взятием задачи в разработку, на котором присутствуют представители всех направлений: менеджер, аналитики, разработчики, тестировщики, дизайнеры.
Данный метод позволяет:
подробно разобрать задачу на этапе планирования,
минимизировать будущие ошибки,
сэкономить время и ресурсы на разработку и тестирование.
2. Порядок в тестировании
Тестовая модель поддерживалась в актуальном состоянии:
своевременно добавлялись новые артефакты (тест-кейсы, чек-листы, результаты тестов),
удалялись устаревшие данные.
Чистота — залог здоровья не только в доме, но и в тестовой документации!
3. Артефакты как помощь тестировщику
На этапе ознакомления с требованиями:
составлялся чек-лист,
писались подробные тест-кейсы,
создавались матрицы трассируемости требований (для сложных задач).
Это во много раз упрощает проверку задач, в том числе новыми сотрудниками, повышает наглядность проведения необходимых проверок, дает возможность проводить перекрестное ревью. При составлении артефактов активно применялись техники тест-дизайна.
4. Один глаз — хорошо, а несколько — лучше
Окончательный список проверок отправлялся на ревью опытным коллегам-тестировщикам и аналитикам. Перекрёстное ревью помогает выявить то, что мог упустить один человек. Особенно полезно для новых сотрудников, ещё не знакомых с предметной областью.
5. Быстрая коммуникация
Применение быстрой коммуникации с менеджментом, системным аналитиком, разработчиками, смежными командами при возникновении проблем при тестировании или обнаружении багов значительно облегчает процесс тестирования. За один общий звонок можно решить больше проблем, чем если заводить много багов в баг-трэкере. Поэтому зачастую можно не спешить открывать баг-трэкер, а собраться предварительно на общий звонок для решения проблем и определения «подводных камней». Особенно это актуально при наличии межкомандной или межсистемной интеграции.
6. Семь раз проверь — один раз отрежь
Каждая задача проходила три цикла проверок:
Dev-тестирование (полное и расширенное),
Preprod-тестирование (регрессия перед релизом),
Тестбой (смоук-тестирование после регресса).
При таком подходе шанс пропустить критический баг стремится к нулю.
7. Регресс как залог прогресса
Перед каждым релизом (раз в две недели) проводилось полное регрессионное тестирование силами автотестов и ручных тестировщиков.
8. Держим руку на пульсе
Важно быть всегда на связи с технической поддержкой. Специалисты поддержки были активными участниками общекомандных рабочих чатов, в которые они оперативно писали пожелания клиентов не в официальном формате, Далее пожелания передавались менеджерам, которые могли планировать следующие доработки, учитывая полученный клиентский опыт.
9. Подведение итогов
По окончании каждого спринта проводилось ретро. На нем можно было обсудить:
возникшие во время спринта вопросы и проблемы;
обозначить пути их решения;
поставить оценку прошедшему спринту;
поблагодарить команду.
Каждое следующее ретро начиналось с ревью выявленных на прошлом ретро проблем. Это позволяет решать проблемы по мере их возникновения и не забывать говорить спасибо своим коллегам.
10. Главней всего — погода в доме
Но все вышеперечисленные пункты могу не сработать, если не будет главного – хорошей атмосферы в команде. Да, можно найти грамотных сотрудников, проводить тщательное тестирование, собирать совещания, но самым главным секретом являются именно простые человеческие отношения. Доброта, внимание, неформальные онлайн и оффлайн игры, беседы, поздравления с праздниками, взаимная поддержка – вот то, что является связующим звеном всех членов команды и делает их не только коллегами, но и небольшой рабочей семьей.
