Сегодня хочу поговорить о тестовых стендах, окружении и тестовых данных.
За полтора года работы на проекте я прочувствовала всю боль проблем, связанных с тестовыми данными и тестовым окружением.
Тестовая база данных
Начнем с баз данных. Ранее уже рассказывала, что у меня на проекте есть 2 тестовых бд. Первая для самых 'невероятных тестов' - то есть там очень много кривых данных, созданных за годы тестирования. Вторая всегда считалась репликой прода. На ней были чистые данные, сама бд была соединена с различными тестовыми сервисами и создавать в ней кривые данные было как бы нельзя.
Так вот где-то полгода-год назад я обнаружила, что схема в первой бд отличается от прода, причем настолько сильно, что тестирование на ней теряет смысл. А все потому что разработчики во время разработки добавляют и изменяют схему бд прямыми запросами и потом не возвращают все обратно. Также на ней не отрабатывают миграции.
На второй бд работают миграции. Но в ней также не восбраняется изменять схему прямыми запросами, и по факту миграции отрабатывают некорректно или не отрабатывают вообще.
Пыталась поднять этот вопрос - всем похеру. Все, что я слышу: "Выполни запрос руками, если увидела расхождение". Иногда хочется сесть и разобраться со всеми ошибками миграций, но потом думаю: "А зачем? Через неделю все будет тоже самое".
Тестовые данные
Я стараюсь для каждого теста создавать свои тестовые данные или использовать уже созданные мною ранее. Таким образом, я уверена, что тест будет чистым и все найденные ошибки не будут связаны с кривизной данных. Однако не раз замечала, как свежесозданный мною заказ в этот же день кто-то использует и все мои тесты с прописанными мною ожидаемыми результатами летят к черту. Я, конечно, нахожу этого нехорошего человека и вежливо прошу его не трогать мои данные. В связи с этим в последнее время я создаю тестовые данные, используя и слово "тест", и свою фамилию, чтобы человек, прежде чем грохнуть мой заказ или товар, подумал дважды. Но и это не всегда останавливает людей.
Еще одна проблема с данными заключается в том, что в некоторых справочниках есть такие, которые привязаны к некоторым сервисам, и, изменяя или удаляя их, сервис просто перестает работать. Я понимаю, что иногда для тестов необходимо сделать такие изменения. Но я не понимаю, почему после тестов не вернуть все, как было??? Постусловие - это то, чем у нас не пользуются. Что-то сделал, что-то потестировал и бросил все, как есть. А потом на тесте какие-то странные ошибки... Просто свинство!
Вот еще один пример про данные. Некоторое время назад я тестировала интеграцию с одним известным маркетплейсом, у которого нет тестовой песочницы. Это значит, что тестировать приходилось на реальных заказах. Нужно было протестировать некий апдейт уже созданных заказов, но так как на тестовой бд этих заказов не было, приходилось переносить их с прода копированием напрямую в бд в определенные таблицы. Для теста нужно было, чтобы данные были в 4 таблицах, поэтому скопированы были только данные по заказам из этих таблиц. Естественно, на UI и для других модулей эти заказы были неполноценные и вызывали много ошибок. После теста я удалила из бд эти заказы так же, как и создавала: руками из 4 таблиц. Прошло пару месяцев и я заметила еще подобные заказы на тесте, но созданные уже не мной. И знаете что? Они до сих пор там! Очевидно, тестирование интеграции давно прошло, но времени их удалить у кого-то не нашлось.
Тестовое окружение
Помимо локальных стендов, которые мы поднимаем под каждую ветку доработки, у нас есть еще и тестовый стенд на сервере: на нем обычно развернута мастер ветка, но иногда на нем разворачивают ветки с какими-то доработками, еще не вошедшими в релиз, чтобы бизнес мог посмотреть и потестировать доработку сам. Как-то раз я подняла вопрос о том, чтобы обновлять этот тестовый стенд почаще, чтобы иметь под рукой всегда свежий мастер с тестовым окружением. Но в ответ услышала лишь, что из-за лени тестировщиков никто не будет поддерживать регулярное обновление этого стенда.
То есть если мне нужен мастер, я должна перезапускать проект каждый раз у себя локально. Я, конечно, понимаю, что сервера не резиновые, но такая тотальная экономия технических ресурсов и обесценивание ресурсов человеческих меня просто бесит.
Хочу подвести итог. Тестирование - процесс достаточно сложный и многокомпонентный, и его качество напрямую зависит от организации этого процесса. То есть правильное распределение технических и человеческих ресурсов, выстроенные процессы, своевременная оптимизация процессов, поддержание тестового окружения и тестовой дукементации - все это очень важно!