Хроники пикирующего бота или как важно не пропускать стадию QA в проектах
Эта статья должна была рассказать вам о проекте простого телеграм-бота, который заточен на одно простое действие: мониторинг доступности сайтов. Но, опубликовав MVP и представив проект на публику, мы заранее не провели полный объем необходимых тестов, в самый ответственный момент не смогли быстро всё исправить и вместо восторженных отзывов аудитории получили порцию хейта. Поэтому мы решили не делать из статьи простое описание механики бота, а просто ещё раз напомнить всем стартапам, да и вообще программистам, отделам и командам о важности каждого этапа разработки.
Типичный путь стартапа
Что за сервис?
Мы небольшой командой из 4 человек написали в качестве пет-проекта простой телеграм-бот для мониторинга статуса сайтови недавно дошли о стадии MVP. Этот сервис вырос из общей боли: у нас всех есть или сайты, или свои проекты, за доступностью которых нужно следить. В целом задача эта несложная: обычно не стоит многих усилий спроектировать небольшой тест внутри существующего проекта, да и таких же сервисов в интернете — десятки. Общая их проблема — в крайней запутанности, либо в наличии настроек, который нас не устраивали (вроде периодичности проверки), либо даже элементарные функции платные. При этом боль — наличие простого и условно-бесплатного функционала с оптимальным временем проверки — откликнулась у многих знакомых стартаперов.
Прототип проекта изначально был написан на питоне с помощью ChatGPT, и код от ИИ действительно заработал. Оценив первый вариант, мы решили сделать нашу программу публичной. Новая, более функциональная версия была написана на Kotlin. Окружение большого значения не имеет — просто команда специализируется на Java/Kotlin. Публичная бета сервиса находится здесь.
Что умеет бот? Пока мы предлагаем мониторить до трёх сайтов с периодичностью в 1 минуту. Если сайт/ сервис отдаёт код, отличный от 2хх, система оповещает пользователя в телеге. Ещё проект умеет показывать время отклика для каждого сайта.
Что пошло не так?
Несмотря на кажущуюся простоту, проект серьёзный и основан на тех же принципах и инструментах, которые характерны для больших сервисов. У нас есть две среды — dev и prod, настроенный pipeline в gitlab для ci/cd, разработчики — опытные ребята, занятые в больших корпорациях, в общем, всё по-взрослому. И тем более странно, что причиной неудачи стало игнорирование элементарных принципов, о которых все были прекрасно осведомлены. Наверное, для этого эффекта излишней самоуверенности уже придумали какое-нибудь название в списке законов Мёрфи, но найти его не удалось.
Итак, в нашей команде есть разработчики, маркетолог и дизайнер и нет QA. Роль QA выполняли все, вручную тестируя функции бота. Дойдя до выполнения критериев MVP, мы выложили проект в дружественный ИТ-чат, и там к сервису вопросов также не возникло. После чего команда решила накатить обновление. Это ошибка стала первой в длинной череде.
После команды /start бота происходит сохранение пользователя в таблице, скажем, person, также в качестве продвинутого UI мы определяли, какой язык у него установлен в телегаме (чтобы сразу включить английский/русский), и тоже записывали это.
Но в беклоге была задача, чтобы у пользователя появились разные другие настройки: сколько ресурсов он может добавить на проверку, как часто проверять и т.п. Для этого мы сделали отдельную таблицу person_settings. Ну и конечно, мы перенесли туда язык интерфейса бота.
Небольшое отступление: зачем вообще было заморачиваться с языком и настройками? Команда решила поработать на международную аудиторию, поэтому сервис писался изначально как English first. А сама таблица настроек представляет собой основу для дальнейшего развития сервиса, чтобы когда-нибудь сделать опции гибкими для каждого пользователя и ещё через какое-то время прийти к монетизации кастомных фишек (сервера же надо на что-то содержать, в конце концов). Это важное замечание, потому как для MVP такой функционал не был важен, но мы его изобрели, что стало ещё одним звеном в цепочке.
Для обращения к БД мы используем jdbc template, где есть сам запрос (в данном случае Insert), и также передаются параметры для него. Очевидно, нужно было удалить параметр из первой таблицы Person и запроса, что мы и сделали, позабыв про SQL, где он остался. SQL ожидал параметр, а мы его не передавали, что приводило к падению системы для новых пользователей.
Тем временем, будучи уже зарегистрированными в базе, мы не заметили баг на ревью, потому что просто проверили работоспособность сервиса без полного сброса перед продом. А если бы команда попыталась зайти под новым пользователем или были написаны автотесты, бот бы не сработал и мы об этом бы узнали. Но автотестов не было, всё шло отлично, ресурс показывал хорошую реакцию на мониторинге списка из более чем 30 сайтов, поминутно реагируя на фейлы на той стороне.
«Как вы яхту назовете»
Итак, мы были уверены в том, что сделали отличный продукт. Пришло время публичного релиза, который и состоялся через статью в одном популярном издании. Почти сразу посыпались комментарии, что сервис не работает.
Здесь также нас ждала неожиданность: по стечению обстоятельств маркетинг не синхронизировался с программистами, которые в полном составе уехали на конференцию без средств разработки. Таким образом, на насколько дней бот оказался без поддержки, оставалось только оправдываться в комментариях, ожидая снисхождения и надеясь на скорое возвращение инженеров. Материал поздно было снимать с публикации: за короткое время мы собрали более 1300 показов.
На исправление ошибки впоследствии ушла пара минут на удаление одного параметра. А вот репутацию предстоит исправлять ещё долго.
Как выглядит код, исправляющий ошибку
Вместо выводов
Команда получила отличный урок, которым теперь мы делимся с вами. Стечение обстоятельств, помноженное на уверенность в своих силах сыграло злую шутку. Наш крутой сервис с отличным «взрослым» окружением, первоклассными инженерами и в «полном фарше» не поехал, потому что в бак забыли налить бензин. Почему так случилось?
Мы нарушили много принципов разработки приложения: решили усложнить то, что работало; преждевременно начали оптимизацию; попытались реализовать всё и сразу: даже те функции, которые не были нужны на этапе MVP.
И конечно, команда пренебрегла всеобъемлющим, всесторонним тестированием, положившись на собственные силы и не приняв во внимание отсутствие в составе QA. Как оказалось, контроль качества — наиболее критичный этап разработки для нашего сервиса, который нельзя было пропускать или оставлять на произвол судьбы.
Послесловие
Урок усвоен, ошибки исправлены, а команда уже пишет автотесты. Надеемся, эта история поможет таким же как мы хобби-стартаперам в их будущих релизах. Главное: не стоит бояться ошибиться, важно — признавать наличие проблем, вовремя их устранять. Такой опыт тоже нужен.
