Як я за рік у вільний час зробив репорт-портал для всієї компанії

💡 Усі статті, обговорення, новини про тестування — в одному місці. Приєднуйтесь до QA спільноти!

Привiт , мене звати Андрiй , я QA Team Lead в Gameinspire, i я задовбався вiд купи iнструментiв. Скільки разів ви дивились на інструмент, яким користуєтесь щодня, і думали «та я б за вихідні зробив краще»? У мене так було майже рік — поки одного разу я не сів і не зробив.

Рік тому я щодня відкривав репорт-портал, яким ми користувались, і щоразу трохи більше його ненавидів. Платний сторонній сервіс, обмежений функціонал, доступ тільки для QA. Знайти й полагодити баг самостійно — неможливо, ми просто чекали на апдейт від вендора. А тим часом дані для тест-кейсів, автотести й аналітика жили в трьох різних місцях, які ніяк одне з одним не розмовляли.

Зараз у нас self-hosted репорт-портал, яким користується вся компанія: QA, тімліди, розробники, менеджмент. У статті розповім, чому я зрештою взявся за це сам, що там під капотом технічно і які рішення дались не так просто, як здавалось на старті.

Три причини почати

Причин було три. Перша — автоматизація: старий інструмент був нестабільним і не покривав наші вимоги, а виправити щось самостійно ми не могли в принципі. Друга — зібрати всі дані в одному місці. Спочатку це був суто мій пет-проєкт: об’єднати автоматизацію, TMS і аналітику під одним дахом. Третя — мені хотілось на практиці розібратись, як впроваджувати AI в щоденну роботу, а не тільки читати про це.

Рішення визріло приблизно за рік роботи зі старим порталом. Дрібні незручності накопичувались, підтримки в безкоштовній версії не було жодної. Врешті з’явилась одна проста думка: зроблю щось своє, що зможу повністю контролювати сам, і подбаю, щоб дані компанії були в безпеці.

Розробка йшла за класичною схемою пет-проєкту: основна робота вдень, кодинг — увечері. Я постійно спілкувався з колегами й лідами команд, щоб розуміти, яких можливостей їм бракує в старому інструменті. До того як показати MVP всім, я довго тестував портал сам — досвід у QA якраз для того й потрібен, щоб наперед бачити, де саме «вистрелить». Після релізу MVP інші команди автоматизації спробували інструмент і досить швидко перейшли на нього — виявився гнучкішим і зручнішим, ніж те, до чого звикли.

Що під капотом

Портал — self-hosted дашборд для звітів по автотестах з інтеграцією Jira, історією запусків, аналітикою й керуванням мануальними тест-кейсами. Єдина точка правди для всієї QA-активності команди.

Стек. Бекенд — Node.js на NestJS, база даних — PostgreSQL, черги фонових задач — Redis. Фронтенд — React з Ant Design. Файли (відео, скриншоти, трейси тестів) зараз лежать в об’єктному хмарному сховищі Google, раніше — у власному.

Архітектура. Один застосунок, поділений на модулі, а не набір мікросервісів — для нашого масштабу це виявилось простіше підтримувати. Важкі операції винесені у фонові черги, щоб не блокувати основний потік.

Найцікавіше рішення — як зберігаються результати тестів. Я розділив їх на два шари. «Товстий» шар містить повні результати з помилками й файлами і чиститься за розкладом — термін зберігання налаштовується окремо для кожного проєкту. «Тонкий» зберігає тільки ключове: тест, дата, статус, тривалість — і не видаляється ніколи. Зараз це приблизно 3,4 млн записів у тонкому шарі проти 135 тисяч у товстому, хоча за обсягом даних вони приблизно рівні. Логіка проста: історія кожного тесту переживає будь-яку чистку сховища, навіть якщо детальні дані вже видалені. Результати з CI надходять пачками, підтримується розбиття прогону на шарди.

Інтеграція з Jira. Зробив двосторонньою й одразу трьома каналами. Jira сама миттєво надсилає зміни. Портал додатково звіряється сам раз на 15 хвилин — про всяк випадок, якщо якесь повідомлення загубилось. Вихідні дії (наприклад, створення бага з падіння тесту) йдуть через власну чергу, яку розбирає окремий процес щохвилини. Якщо Jira тимчасово недоступна — нічого не втрачається, дія просто відправиться пізніше, а для невдалих спроб є ручний повтор.

Known Failures. Падіння автотеста можна прив’язати до відомого бага трьома способами: автотест сам повідомляє про це через позначку в коді, QA прив’язує вручну, або одразу прив’язується пачка тестів за шаблоном назви. Далі кожен новий результат з CI, що збігається з уже прив’язаним випадком, автоматично отримує мітку «відомий баг». Текст помилки перед порівнянням нормалізується — інакше та сама помилка з іншим форматуванням рахувалась би новою проблемою. Саме цей механізм прибирає потребу щоразу заново розбирати відомі баги і прискорює деплой приблизно на 10%.

MCP-сервер. Дає AI-асистенту прямий доступ до порталу — близько двадцяти дій: подивитись проєкти, прогони й конкретні падіння, створити чи відредагувати тест-кейс і сьют, залити метрики. Асистент не просто диктує текст — він сам створює кейс у потрібний сьют й прив’язує його до задачі в Jira, де автоматично з’являється коментар із номером кейса й посиланням.

Деплой. Застосунок пакується в контейнери й працює в хмарному кластері Google. Сервер та інтерфейс запущені у двох копіях кожен — щоб падіння однієї копії не клало сервіс.

Компроміси, на які я пішов свідомо

Кілька рішень додали складності заради надійності, і я не жалкую.

Дублювання історії тестів у два шари — свідомий вибір, щоб чистка сховища ніколи не стирала таймлайн тесту, навіть якщо детальні файли вже видалені. Черга для взаємодії з Jira замість прямого виклику — складніше в реалізації, зате переживає недоступність Jira без втрати даних. Перехід зі власного файлового сховища на хмарне зробив через окрему абстракцію, яка дозволяє перемкнути бекенд сховища однією настройкою — і з попередньою звіркою вмісту, а не «перенесли й сподіваємось».

Що змінилось

Раніше дані QA бачив тільки QA — тепер доступ є в усієї компанії. Раніше автотести, тест-кейси й аналітика жили окремо одне від одного — тепер усе в одному місці, є мануальні тест-рани, якими можна ділитися з клієнтами без потреби комусь логінитись. Раніше дані йшли через сторонній сервіс — тепер усе на власному хостингу, під нашим повним контролем. Раніше ми залежали від чужого продукту й чужих обмежень — тепер самі вирішуємо, що додавати і як розвивати інструмент. І з’явилась аналітика, якої раніше не було зовсім.

Що далі

Портал продовжую допилювати — зараз додаю тест-метрики для статистичного аналізу по проєктах і планую глибше інтегрувати AI. Є окрема борда, куди колеги додають задачі на покращення й баги — це тримає розвиток живим і чесним, бо я бачу, що людям реально потрібно, а не вгадую.

Якщо у вас є схожий пет-проєкт, який давно просить втілення, — не чекайте ідеальних умов. Побачив проблему — вирішив. Далі можна допилювати скільки завгодно.