Мы с нетерпением ждём разработчика или разработчицу, которые вольются в нашу команду и помогут нам поставлять новые фичи и улучшения во фронтенд Allure TestOps. Allure TestOps — это система для управления тестированием, генерации отчетов о прохождении тестов и движок для сбора аналитики в рамках одной платформы.
Мы ex-Яндекс команда, работающая в России и США под брендом Qameta Software. Наша продуктовая линейка стартовала с популярного опенсорсного фреймоворка Allure Report, которым пользуются более 1000 компаний по всему миру. А сейчас мы сфокусированы на универсальном решении для тестирования Allure TestOps, позволяющим управлять всеми связанными с тестированием вещами в одном месте. Это как Figma, только для тестировщиков.
Наши пользователи — это команды разработки IT-продуктов. Основная ценность нашего продукта для команды разработки — возможность хранить, запускать и анализировать как ручные, так и автоматические тесты в одном месте. Для бизнеса — мы ускоряем выход качественных IT-продуктов на рынок.
Сейчас у нас стабильно растущий клиентский портфель: среди 100+ клиентов Allure TestOps есть крупные компании из России, Европы и США. Но наша задача — сделать платформу стандартом де-факто в мире тестирования. Поэтому в ближайших планах дальнейшее развитие платформы: больше фич и больше конфигураций, заточенных под разные команды.
У нас много нетривиальных задач, и есть возможность писать софт, улучшающий жизнь коллег по цеху.
Также у нас в опенсорсе есть js библиотеки для интеграций с тестовыми фреймворками, над которыми тоже можно поработать и засветиться в опенсорс комьюнити. Кстати, у нас больше 2000 звездочек на гитхабе.
Сейчас в команде фронтендом занимаются два опытных разработчика, вместе с которыми интерфейсы проектирует UX-дизайнер, работаем по макетам из Figma.
Наш стэк на фронте — React + TypeScript, Jest + Testing Library, Storybook, подробнее можно посмотреть по package.json. Наш стэк на бэкенде — Java c Spring Cloud, postgres, микросервисы.
У нас довольно гибкий бэкенд, который можно быстро адаптировать к нуждам фронта, поэтому фронтенд стараемся делать в виде тонкого клиента. Чаще всего фронт разрабатывается вперед и со своей стороны определяет требования к бэкенду, что позволяет избежать сложного стейт-менеджмента на клиенте.
Кодовая база уже довольно большая, но мы держим ее в порядке и любим рефакторить.