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

Сейчас в одном функциональном департаменте предприятия работают сотни различных программных продуктов, различным образом взаимодействующих между собой. Все они должны работать как часы, но при этом от пользователя скрыт весь объем технического стека, системного и вспомогательного ПО. В таких условиях тестирование перестает быть простой «гигиенической» процедурой — программист написал код и проверил его работу [1] — а превратилось в науку, игнорирование требований которой при выпуске системы в промышленную эксплуатацию сравнимо с прыжком в пропасть с завязанными глазами.

Тестирование как наука

Еще совсем недавно если что-то ломалось, например, в банковской информационной системе, то самое страшное было — это не сдать баланс на следующий день, и у команды всегда было время на починку. Сегодня же, если банковское приложение не работает или специалист не может оформить кредит клиенту из-за ошибки во внутренней системе, то клиенты ждать не будут, а сразу уйдут, поэтому большинство систем и процессов обязаны работать в режиме, близком к реальному времени. Аналогичная ситуация складывается и для крупных производителей товаров повседневного спроса, продающихся свои изделия через магазины, гипермаркеты и т. д. У них обычно тысячи торговых представителей, которые перемещаются по всей стране и в режиме онлайн отчитываются о продажах. Если их система «ляжет», то весь бизнес как минимум встанет, а как максимум возможны намного более катастрофичные последствия [2].

Подобных примеров сегодня масса, а что, собственно, изменилось?

Почти все:

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

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

Методология тестирования — не просто рецепт плова

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

«Киты» современного тестирования

Методология современного тестирования стоит на пяти китах.

Тестирование — общая задача

Тестирование — не функция лишь ИТ-отдела, а общая задача организации. Сначала код тестирует программист-разработчик, потом тестировщик, затем бизнес-аналитик, понимающий особенности работы приложения, потом — пользователи. Причем именно последние — главные тестировщики. Передаче в промышленную эксплуатацию обязательно должен предшествовать этап UAT (User Acceptance Testing). Пользователь знает свою работу лучше и разработчика, и бизнес-аналитика. Конечно, он может не понять, почему кнопка должна быть красной, но точно знает, в какой последовательности выполняются операции и где есть вероятность ошибки. Забавный парадокс — когда пользователи начинают тестировать, они чаще всего воспринимают этот процесс как игру: стараются «взломать» систему, выполнить явно нестандартные действия и пр., часто находя такие баги, до которых профессионалы никогда бы не додумались.

Адекватность сред

С пугающей регулярностью повторяется история: «На стенде все работало, а в промышленной эксплуатации — нет!» Причина почти всегда одна — тестовая среда не соответствует реальной среде эксплуатации. Допустим, тестируется штурвал океанского лайнера, установленный на лодку в бассейне. Он работает, поворачивается, позволяет менять направления движения лодки, однако это не позволит узнать, как корабль будет держать курс при реальном шторме. Если тест-среда ИТ-системы— это «бассейн», а среда эксплуатации — «океан», то разработчиков ждут неприятные сюрпризы. Идеальная тестовая среда — клон среды эксплуатации и по парку оборудования, и по версии системного ПО, и по архитектуре, и по интеграциям, и по средствам обеспечения безопасности. Это дорого, но без этого тестирование невозможно.

Отдельная головная боль — онлайн-системы. Как эмулировать банковский процессинг, обрабатывающий тысячи транзакций в секунду? Как создать тестовый биллинг для телекома? Решение всех этих задач требует и ресурсов, и серьезных знаний в области программной инженерии. Итак: тестовая среда должна быть по параметрам и производительности идентична среде эксплуатации; необходимо эмулировать не только работу тестируемой системы, но и ее взаимодействие с другими; в среде pre-production тестирование обязательно с реальными данными.

Автоматизация

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

Что касается собственно автотестов, то современные инструменты позволяют массово покрывать весь код автоматическими проверками, но ключевой вопрос — глубина и точность покрытия. Тестирования кода реализации базовых операций и простых сценариев уверенно автоматизируются, но стоит ситуации чуть усложниться — добавить неочевидное условие ветвления или комбинацию действий, и автотесты часто оказываются бессильны. А есть еще сложные сценарии, которые непросто описать и свести к однозначным алгоритмам. Именно поэтому пользовательское тестирование было и остается важнейшим элементом: люди выявляют то, что никогда не будет заложено в алгоритм, — неочевидные UX-проблемы и концептуальные ошибки, а также особенности пользовательского пути (Customer Journey Map, CJM). Разработчик мыслит задачей, логикой кода и идеальным сценарием, а конечный пользователь действует интуитивно и вполне может пойти «не той тропой», и система должна быть к этому готова. Это как история с тропинками во дворах мегаполисов — архитекторы могут спроектировать идеальный маршрут и воплотить в жизнь, но лучше подождать, пока люди сами протопчут наиболее удобный путь, и уже там положить асфальт.

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

«Вайб-кодинг» (vibe coding), или создание кода с помощью ИИ на основе краткого описания задачи, сулит ускорение прототипирования и получения рабочих фрагментов, но в реальных корпоративных системах такой подход вызывает множество вопросов. Мы его не используем.

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

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

Регресс — призрак из прошлого

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

Регрессионные ошибки бывают очень удивительные. Например, в программе, которую используют сотрудники правительства одного российского города, разработчики поправили мелкий баг в интерфейсе, в результате чего изменилась цветовая гамма экранных панелей.Оказалось, правка случайно сбросила пользовательские настройки по брендбуку, но система подхватила стандартную палитру, глубоко зашитую в коде. Такие ошибки как призраки из прошлого — все о них слышали, но поймать их практически не удается. Но у пользователя такие ошибки вызывают негативное эмоциональное ощущение — «все валится», а значит, и доверять всей системе нельзя.

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

Как с этим бороться:

  • периодически проводить полное регрессионное тестирование;
  • автотесты эффективно использовать именно для проверки работоспособности старого функционала;
  • учитывать не только функциональные, но и нефункциональные характеристики работы системы (например, производительность);

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

Работа с приоритетами

Все баги одинаковы, но некоторые «одинаковее». Представим ситуацию, когда пользователи приносят шестьдесят страниц Excel с замечаниями мелким шрифтом. На вопрос «Что здесь критично?» ответ — «Все!».

Без приоритизации тестирование превращается в сизифов труд, поэтому опытные руководители используют простой прием: «Что случится, если мы это не исправим на следующей неделе?» Если нет внятного ответа, то приоритет ошибки понижается. Но здесь кроется подвох — то, что для айтишника «мелочь», для пользователя может быть катастрофой и наоборот. Можно предложить следующие критерии классификации багов: влияние на бизнес-процессы, например, существенное увеличение времени операции или отклика; количество пользователей, страдающих от ошибки; наличие альтернативных путей получения нужной функциональности; восприятие пользователями (а вдруг это не ошибка, а новая функциональность?).

Принцип разумной достаточности

Самая продвинутая методология бессмысленна, если нет понимая, зачем тестировать. Ответ прост — чтобы бизнес работал. Например, в банке выстроили следующую систему бизнес-мониторинга — если ИТ-система «упала», но бизнес-показатели не изменились (клиентов обслужили столько же, транзакции прошли и пр.), то ошибка не критична. Такая позиция отсекает до 80% споров между бизнесом и ИТ. Если время оформления кредита занимало 12 минут, а теперь 13 — это неприятно, но не критично. Если же время выросло до часа, то нарушен бизнес-процесс.

***

Современное тестирование — это не про то, как найти больше багов (как известно, в любой программе всегда найдется хотя бы одна ошибка [3]), а про то, как построить процесс, предотвращающий критические сбои и позволяющий бизнесу работать эффективно.

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

Литература

1. Бертран Мейер. Семь принципов тестирования программ // Открытые системы.СУБД. — 2008. — № 7. — С. 52–54. URL: https://www.osp.ru/os/2008/07/5478839 (дата обращения: 31.12.2025).

2. Валерий Аджиев. Мифы о безопасном ПО: уроки знаменитых катастроф // Открытые системы.СУБД. — 1998. — № 6. — С. 21–30. URL: https://www.osp.ru/os/1998/06/179592 (дата обращения: 31.12.2025).

3. Руслан Смелянский. «Чудеса» Льва Королева // Открытые системы.СУБД. — 2016. — № 3. — С. 41–43. URL: https://www.osp.ru/os/2016/03/13050260 (дата обращения: 31.12.2025).

Александр Тютюнник (atutunnik@ luxms.ru) — директор по развитию бизнеса, ГК Luxms; Сергей Степаненко (islands@glorium.ru) — директор по развитию бизнеса, ГК «Софтлайн» (Москва).