Мне кажется мы про разные ситуации говорим, и обе рабочие. Ваш вариант сильнее там, где есть кому его поставить и поддерживать. Но это ведь всегда часы разработчика, а они самый дефицитный ресурс в команде, и отнимать их приходится у продуктовых задач. Во многих командах такой размен просто не проходит, и схема остаётся в планах на следующий квартал.
Я исхожу из того, что тестировщик или аналитик приходит на проект где ничего этого нет и в ближайшие полгода не появится, а проверять надо сегодня. У такого человека часто нет ни прав ставить софт на рабочую машину, ни доступа в репозиторий, ни времени между задачами. Не потому что он слабее, а потому что его работа устроена иначе. И выбор у него получается не между схемой и мышкой, а между мышкой и сверкой глазами.
Мне поэтому и было важно сделать так, чтобы человек открыл, вставил ответ и через пару минут получил проверки, без окружения и без единой строчки кода. Не вместо нормальной схемы, а как то, что доступно прямо сейчас и своими силами.
А у вас на проектах есть такие люди, кто проверяет API руками? Интересно чем они обходятся, пока спека не появилась.
Полностью согласен, это правильная архитектура, спецификация как источник истины, клиенты и модели генерируются из неё, расхождение почти исчезает.
Только это решение уровня команды бекенда, а не тестировщика. Чтобы спека появилась и поддерживалась, нужно, чтобы разработчики раскидали аннотации, настроили генерацию на сборке и держали это в рабочем состоянии. Тестировщик или аналитик такое не внедряет — он приходит на проект, где этого нет и ждать полгода не может.
Плюс у автогенерации из кода есть своя оговорка она описывает то, что код делает, а не то, что он должен делать по требованиям. Поле price в спеку попадёт честно и законно, потому что оно в модели есть. Расхождение «код против документации» такая схема как раз не ловит.
Что до самих проверок — их можно получить и без написания кода. Скармливаешь OpenAPI-спеку или просто пример ответа, и набор проверок по полям с типами собирается автоматически, дальше правишь его мышкой под то, что написано в требованиях. Ровно ради этого всё и делалось для аналитиков и ручных тестировщиков, у которых спека если и есть, то на неё некому опереться в тестах.
к сожалению в одном посту, показать не могу полный функционал
Да, согласен, у меня рядом с whitelist стоят проверки типа, (возможно можно как-то лучше сделать отчет или со временем будет запоминаться такой формат) для каждого поля и точное сравнение значений, "CREATED" против "CREATE" ловится именно ими на скриншоте. По сути это та же схема, только собранная мышкой, а не описанная в JSON.
Мне кажется мы про разные ситуации говорим, и обе рабочие. Ваш вариант сильнее там, где есть кому его поставить и поддерживать. Но это ведь всегда часы разработчика, а они самый дефицитный ресурс в команде, и отнимать их приходится у продуктовых задач. Во многих командах такой размен просто не проходит, и схема остаётся в планах на следующий квартал.
Я исхожу из того, что тестировщик или аналитик приходит на проект где ничего этого нет и в ближайшие полгода не появится, а проверять надо сегодня. У такого человека часто нет ни прав ставить софт на рабочую машину, ни доступа в репозиторий, ни времени между задачами. Не потому что он слабее, а потому что его работа устроена иначе. И выбор у него получается не между схемой и мышкой, а между мышкой и сверкой глазами.
Мне поэтому и было важно сделать так, чтобы человек открыл, вставил ответ и через пару минут получил проверки, без окружения и без единой строчки кода. Не вместо нормальной схемы, а как то, что доступно прямо сейчас и своими силами.
А у вас на проектах есть такие люди, кто проверяет API руками? Интересно чем они обходятся, пока спека не появилась.
Полностью согласен, это правильная архитектура, спецификация как источник истины, клиенты и модели генерируются из неё, расхождение почти исчезает.
Только это решение уровня команды бекенда, а не тестировщика. Чтобы спека появилась и поддерживалась, нужно, чтобы разработчики раскидали аннотации, настроили генерацию на сборке и держали это в рабочем состоянии. Тестировщик или аналитик такое не внедряет — он приходит на проект, где этого нет и ждать полгода не может.
Плюс у автогенерации из кода есть своя оговорка она описывает то, что код делает, а не то, что он должен делать по требованиям. Поле price в спеку попадёт честно и законно, потому что оно в модели есть. Расхождение «код против документации» такая схема как раз не ловит.
Что до самих проверок — их можно получить и без написания кода. Скармливаешь OpenAPI-спеку или просто пример ответа, и набор проверок по полям с типами собирается автоматически, дальше правишь его мышкой под то, что написано в требованиях. Ровно ради этого всё и делалось для аналитиков и ручных тестировщиков, у которых спека если и есть, то на неё некому опереться в тестах.
к сожалению в одном посту, показать не могу полный функционал
Да, согласен, у меня рядом с whitelist стоят проверки типа, (возможно можно как-то лучше сделать отчет или со временем будет запоминаться такой формат) для каждого поля и точное сравнение значений, "CREATED" против "CREATE" ловится именно ими на скриншоте. По сути это та же схема, только собранная мышкой, а не описанная в JSON.
вычеркиваем из иишки для народа!
Идеально было бы совместить аналитика и тестировщика в одном человеке
Было бы интересно в скором времени послушать теорию тестирования с ии