Последние несколько лет я много занимаюсь своими продуктами, в основном мобильными. И почти каждый раз упираюсь в одну и ту же вещь: разработка идёт, задачи идут, релизы идут, а вокруг тестирования постепенно собирается отдельный зоопарк.

Где-то лежат тест-кейсы. Где-то прогоны. Отдельно задачи, CI, дефекты, уведомления, Swagger, документация. Каждая система делает свою работу, но весь процесс между ними всё равно держится на людях.

Можно сразу спросить: зачем вообще делать что-то своё? Есть Allure TestOps, Test IT, TestRail, Qase, Xray, DoQA, Zephyr и ещё куча решений.

Я их знаю. И не считаю, что они плохие или что рынок TMS пустой. Вопрос для меня был в другом.

Мне не нужна была просто ещё одна база, куда можно положить тест-кейсы. У меня несколько продуктов с iOS - Android клиент, куча микро-сервисов. Есть GitHub / GitHub Actions, где-то TeamCity, трекер задач, Swagger, Slack, документация.

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

Разработчик меняет часть продукта. Репозиторий знает, какие файлы затронуты. CI знает, какая сборка появилась. Трекер знает, с какой задачей это связано. А тестировщику всё равно нужно понять, что проверять, найти нужные кейсы, собрать прогон, зафиксировать результат и понять, можно ли выпускаться.

Мне хотелось связать это плотнее. Поэтому сначала я просто сделал себе маленькую TMS. Вообще без идеи что-то продавать.

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

На этом можно было остановиться. Но потом мне надоело вручную переносить контекст из YouTrack. Появилась интеграция с YouTrack.

Потом захотелось, чтобы после изменений в GitHub тестирование не начиналось с сообщения «я там что-то поменял, посмотри пожалуйста». Появились GitHub и GitHub Actions.

Потом Slack, Swagger, прогоны, регрессы, релиз чеки, история изменений, общие шаги, дефекты, отчётность, дашборды. Потом GitLab, TeamCity, Jenkins, Jira, Linear, Trello, Confluence пошли как связующие для будущих интеграций. В итоге система начала довольно хорошо понимать тот процесс, под который я её делал.

Разработчик делает изменение. Falcon получает контекст из репозитория и CI.

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

При этом я не хотел превращать Falcon в замену Jira, GitHub или CI. Я ими пользуюсь.

Мне хотелось сделать слой между ними, который отвечает именно за качество.

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

По сути получилась полноценная TMS, сделанная не от списка функций конкурентов, а от моего собственного рабочего процесса. Сейчас я понемногу начинаю показывать Falcon другим командам и хочу попробовать несколько внешних пилотов.

Не потому что срочно решил строить ещё один SaaS. Мне интереснее проверить, насколько процесс, который оказался удобен мне и моей команде, совпадает с тем, как работают другие.

Я могу сколько угодно считать интерфейс удобным, интеграции правильными, а архитектуру логичной. Но пока всё это результат моего опыта и моих задач.

Поэтому интересно услышать людей, которые работают с QA каждый день.

Где у вас сейчас живут тест-кейсы и регрессия? Насколько ваша TMS связана с разработкой и релизным процессом? Что в TestOps, TestRail, Qase, Xray, Test IT или других системах вам действительно удобно, а что вы годами просто терпите? И отдельно интересно мнение команд, которые вообще не используют TMS и живут на Jira, Confluence, таблицах или своих внутренних инструментах. В общем, Falcon неожиданно вырос из внутренней штуки для моих проектов в отдельный продукт.

Теперь интересно понять, нужен ли такой подход кому-то ещё