Блог

Всеволод Фролов
Начальник отдела управления проектами

Тестируем связанные системы

Часто встречается задача – поиск ошибки в системе, состоящей из нескольких связанных модулей. Пример – отображение на нашем сайте данных, получаемых от веб-сервиса партнера.

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

Как бы не так. Все проверено, но в связке не работает. Что же делать, что делать? Холодок по спине. Как такое может быть?

Виды ошибок

Неправильное разделение системы на модули

Это когда какой-то модуль не учитывается в качестве потенциального носителя ошибки.

В нашем случае, к примеру, это бэк-офис с настройками нашего сайта. Его не проверили. А настройка в нем переключает сайт на другой сервис партнера, который не работает.

Неоправданное доверие к модулю

Это когда модуль сознательно исключается из списка проверяемых.

От тестировщика или разработчика частенько можно услышать такую фразу: «У нас проблемы нет, так как мы ничего с прошлого обновления не трогали. А если после обновления работало, то мы не виноваты, проблема у партнера». Это такой виртуальный дебаг. В нашем случае не проверяем наш сайт, так как перед обновлением уже проверяли.

Поиск ошибки в неправильном месте

Классика жанра – завернуть хосты* и забыть об этом. Думаем, что проверяем боевой сайт, а на самом деле – тестовый.

Отсутствие знаний о системе

Это самый тяжелый случай. Так как быстро получить знания довольно сложно. Особенно о чужой системе.

Наличие неучтенных параллельных схем

Это частный случай отсутствия знаний о системе. В нашем примере может существовать сервис-обертка на нашей стороне, расположенный между сайтом и сервисом партнера. Нашу обертку не проверяем, а ошибка может быть в ней.

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

На заборе тоже написано (или снова про доверие)

Если что-то происходит на странице, это не означает, что оно отобразилось в базе. Например, на экране написано: «Вам начислено 20 баллов». Частенько мы ленимся проверить, начислилось ли 20 баллов в базе данных на самом деле.

Хорошие практики

Нужно знать, как устроена схема, которую проверяем. К сожалению, не всегда выполнимо. Часто знания о системе приходят в процессе ее отладки.

Нужно иметь инструменты для проверки. Вполне выполнимо. Примеры инструментов для веб-разработки – панель разработчика в браузере (вызывается по F12), Fiddler, SoapUI и др.

Нужно быть параноиком, никому и ничему не доверять, подозревать всех. Аналогично выполнимо, но приходит с опытом.

Если все равно не получается

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

* Изменить ip-адрес для доменного имени в файле hosts, упрощенном аналоге ДНС-сервера, который находится на вашем компьютере.