Мне кажется мы про разные ситуации говорим, и обе рабочие. Ваш вариант сильнее там, где есть кому его поставить и поддерживать. Но это ведь всегда часы разработчика, а они самый дефицитный ресурс в команде, и отнимать их приходится у продуктовых задач. Во многих командах такой размен просто не проходит, и схема остаётся в планах на следующий квартал.
Я исхожу из того, что тестировщик или аналитик приходит на проект где ничего этого нет и в ближайшие полгода не появится, а проверять надо сегодня. У такого человека часто нет ни прав ставить софт на рабочую машину, ни доступа в репозиторий, ни времени между задачами. Не потому что он слабее, а потому что его работа устроена иначе. И выбор у него получается не между схемой и мышкой, а между мышкой и сверкой глазами.
Мне поэтому и было важно сделать так, чтобы человек открыл, вставил ответ и через пару минут получил проверки, без окружения и без единой строчки кода. Не вместо нормальной схемы, а как то, что доступно прямо сейчас и своими силами.
А у вас на проектах есть такие люди, кто проверяет API руками? Интересно чем они обходятся, пока спека не появилась.
Полностью согласен, это правильная архитектура, спецификация как источник истины, клиенты и модели генерируются из неё, расхождение почти исчезает.
Только это решение уровня команды бекенда, а не тестировщика. Чтобы спека появилась и поддерживалась, нужно, чтобы разработчики раскидали аннотации, настроили генерацию на сборке и держали это в рабочем состоянии. Тестировщик или аналитик такое не внедряет — он приходит на проект, где этого нет и ждать полгода не может.
Плюс у автогенерации из кода есть своя оговорка она описывает то, что код делает, а не то, что он должен делать по требованиям. Поле price в спеку попадёт честно и законно, потому что оно в модели есть. Расхождение «код против документации» такая схема как раз не ловит.
Что до самих проверок — их можно получить и без написания кода. Скармливаешь OpenAPI-спеку или просто пример ответа, и набор проверок по полям с типами собирается автоматически, дальше правишь его мышкой под то, что написано в требованиях. Ровно ради этого всё и делалось для аналитиков и ручных тестировщиков, у которых спека если и есть, то на неё некому опереться в тестах.
к сожалению в одном посту, показать не могу полный функционал
Да, согласен, у меня рядом с whitelist стоят проверки типа, (возможно можно как-то лучше сделать отчет или со временем будет запоминаться такой формат) для каждого поля и точное сравнение значений, "CREATED" против "CREATE" ловится именно ими на скриншоте. По сути это та же схема, только собранная мышкой, а не описанная в JSON.
Если в общих чертах то автогенератор обходит дерево json или xml и на каждый лист выписывает проверку — путь, оператор, ожидаемое значение и тип данных, а на объекты добавляет whitelist состава, чтобы ловить лишние поля, еще можно глубину ограничивать генерации проверок, чтобы выбирать только нужные шаги. Про локальную модель согласен, тогда мой довод про внешний чат к вам не относится. Но такой путь требует ML-инженера в штате, и это как раз то, чего в большинстве QA-команд нет. Ручной тестировщик не может собрать себе локальную модель за пару вечеров, и на выходе у него всё равно код, который кто-то должен сопровождать.
Также заметил, что оно под Windows 10 / 11, это однопользовательская программа и нужна лицензия на винду? Насколько я понимаю никакой интеграции в линуксовые CI/CD.
Да, всё верно, в дальнейшем есть в планах реализовать интеграции с CI/CD и не только.
Я пытаюсь понять чем ваше решение может быть интересно и кому.
Ваш сценарий предполагает, что в команде уже есть инженер на Python, настроенный CI и локальная модель и организация может это себе позволить. Там, где это есть, вы правы. Но чаще картина другая — тестировщик или аналитик без Python, автотестов нет и в ближайший год не будет, ответ сверяется с документацией глазами в Postman, а логи читаются отдельно руками. Их альтернатива не pytest, а внимательность и время. Для них: собрать проверку кликами, прогнать её заново на следующем спринте, передать коллеге без Python и увидеть запрос вместе с логами в одном сценарии.
Сейчас любой желающий может попробовать бесплатную ограниченную ЗБТ-версию. Затем, после окончания ЗБТ, фикса найденных багов, непокрытых важных сценариев и иных необходимых фич по обратной связи от людей, будет бесплатная двухнедельная ограниченная версия после скачивания, а дальше, если понравилось, можно снять ограничение и оплатить.
Для вашего сценария интересная связка. Я не пытаюсь её заменить, к сожалению, не смог показать всё в одном посте. Есть функция автогенератор, в который можно вставить curl или тела запросов/ответов, и сразу генерируются проверки, включая типы данных, whitelist для поиска лишних параметров, затем можно донастроить проверки под документацию (если необходимо). Также, если рассматривать работу в закрытом контуре, настоящий JSON нельзя отправить во внешний чат, а своего Python-инженера и CI под тесты там часто нет. Инструмент для этого случая, а не для команды с pytest и разрешённым LLM.
Опять же, не нужно что-то настраивать для приложения, просто portable-сборка, вставил ответ, получил проверки.
Мне кажется мы про разные ситуации говорим, и обе рабочие. Ваш вариант сильнее там, где есть кому его поставить и поддерживать. Но это ведь всегда часы разработчика, а они самый дефицитный ресурс в команде, и отнимать их приходится у продуктовых задач. Во многих командах такой размен просто не проходит, и схема остаётся в планах на следующий квартал.
Я исхожу из того, что тестировщик или аналитик приходит на проект где ничего этого нет и в ближайшие полгода не появится, а проверять надо сегодня. У такого человека часто нет ни прав ставить софт на рабочую машину, ни доступа в репозиторий, ни времени между задачами. Не потому что он слабее, а потому что его работа устроена иначе. И выбор у него получается не между схемой и мышкой, а между мышкой и сверкой глазами.
Мне поэтому и было важно сделать так, чтобы человек открыл, вставил ответ и через пару минут получил проверки, без окружения и без единой строчки кода. Не вместо нормальной схемы, а как то, что доступно прямо сейчас и своими силами.
А у вас на проектах есть такие люди, кто проверяет API руками? Интересно чем они обходятся, пока спека не появилась.
Полностью согласен, это правильная архитектура, спецификация как источник истины, клиенты и модели генерируются из неё, расхождение почти исчезает.
Только это решение уровня команды бекенда, а не тестировщика. Чтобы спека появилась и поддерживалась, нужно, чтобы разработчики раскидали аннотации, настроили генерацию на сборке и держали это в рабочем состоянии. Тестировщик или аналитик такое не внедряет — он приходит на проект, где этого нет и ждать полгода не может.
Плюс у автогенерации из кода есть своя оговорка она описывает то, что код делает, а не то, что он должен делать по требованиям. Поле price в спеку попадёт честно и законно, потому что оно в модели есть. Расхождение «код против документации» такая схема как раз не ловит.
Что до самих проверок — их можно получить и без написания кода. Скармливаешь OpenAPI-спеку или просто пример ответа, и набор проверок по полям с типами собирается автоматически, дальше правишь его мышкой под то, что написано в требованиях. Ровно ради этого всё и делалось для аналитиков и ручных тестировщиков, у которых спека если и есть, то на неё некому опереться в тестах.
к сожалению в одном посту, показать не могу полный функционал
Да, согласен, у меня рядом с whitelist стоят проверки типа, (возможно можно как-то лучше сделать отчет или со временем будет запоминаться такой формат) для каждого поля и точное сравнение значений, "CREATED" против "CREATE" ловится именно ими на скриншоте. По сути это та же схема, только собранная мышкой, а не описанная в JSON.
справедливо, ответил резче, чем стоило, реакций действительно ноль, но по переходам на сайт видно, что читают — поэтому и продолжаю писать
Если в общих чертах то автогенератор обходит дерево json или xml и на каждый лист выписывает проверку — путь, оператор, ожидаемое значение и тип данных, а на объекты добавляет whitelist состава, чтобы ловить лишние поля, еще можно глубину ограничивать генерации проверок, чтобы выбирать только нужные шаги.
Про локальную модель согласен, тогда мой довод про внешний чат к вам не относится. Но такой путь требует ML-инженера в штате, и это как раз то, чего в большинстве QA-команд нет. Ручной тестировщик не может собрать себе локальную модель за пару вечеров, и на выходе у него всё равно код, который кто-то должен сопровождать.
Да, всё верно, в дальнейшем есть в планах реализовать интеграции с CI/CD и не только.
Ваш сценарий предполагает, что в команде уже есть инженер на Python, настроенный CI и локальная модель и организация может это себе позволить. Там, где это есть, вы правы. Но чаще картина другая — тестировщик или аналитик без Python, автотестов нет и в ближайший год не будет, ответ сверяется с документацией глазами в Postman, а логи читаются отдельно руками. Их альтернатива не pytest, а внимательность и время. Для них: собрать проверку кликами, прогнать её заново на следующем спринте, передать коллеге без Python и увидеть запрос вместе с логами в одном сценарии.
Сейчас любой желающий может попробовать бесплатную ограниченную ЗБТ-версию. Затем, после окончания ЗБТ, фикса найденных багов, непокрытых важных сценариев и иных необходимых фич по обратной связи от людей, будет бесплатная двухнедельная ограниченная версия после скачивания, а дальше, если понравилось, можно снять ограничение и оплатить.
Для вашего сценария интересная связка. Я не пытаюсь её заменить, к сожалению, не смог показать всё в одном посте. Есть функция автогенератор, в который можно вставить curl или тела запросов/ответов, и сразу генерируются проверки, включая типы данных, whitelist для поиска лишних параметров, затем можно донастроить проверки под документацию (если необходимо). Также, если рассматривать работу в закрытом контуре, настоящий JSON нельзя отправить во внешний чат, а своего Python-инженера и CI под тесты там часто нет. Инструмент для этого случая, а не для команды с pytest и разрешённым LLM.
Опять же, не нужно что-то настраивать для приложения, просто portable-сборка, вставил ответ, получил проверки.
вычеркиваем из иишки для народа!
А вы пишите, потому что вам интересно приложение или больше поспорить?
Идеально было бы совместить аналитика и тестировщика в одном человеке
Было бы интересно в скором времени послушать теорию тестирования с ии