Pull to refresh
4
0
Send message

Сможет ли это решить проблему? У вас потенциально 5–7 автотестеров-разработчиков, почему бы их не использовать? За качество вы же все отвечаете.

Но решать, конечно, вам.

Пришлось пожертвовать одной платформой (это мобильное приложение), так как веб был более важнее (по словам бизнес-аналитиков). Разработчики iOS и Android терпеливо ждали тестирования функционала.

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

Почему бы не посадить на тестирование dev команду? Фронты вполне могут покрывать автотестами ui и проводить приемку.
Не совсем понимаю, зачем так "насиловать" тестировщика

Добрый день !

1) почему именно Java? Сравнивали с другими языками? Какие плюсы?

2) какие сложности были в процессе обучения ? Хватило ли времени на обучение?

3) какого уровня специалисты вышли (джун, мидл)? Как они развивались дальше? Появился ли у них опытный тимлид?

4) что стало с их зп?

Добрый вечер. Спасибо статью!

В python из коробки неудобно пользоваться словарём, особенно при большой вложенности. Используете ли вы библиотеки, например attrs, marshmallows и подобные ? Как вы валидируете ответ в response, например обязательные поля, тип и длину ?

Добрый день! А такой вопрос - не стал ли ваш фреймфорк узким местом для ваших клиентов? И не придётся ли им каждый раз, при изменении системы, возвращаться к вам?

Был такой вариант, при котором они могли бы отдать тестирование своим разработчикам, думаю, плюс/минус они смогли бы написать e2e сценарии и своб систему они знают лучше (кто где после себя оставляет в базе)?

А рассматривали варианты, сделать

тестового пользователя, для условных get запросов, через тестовый фреймворк и дёргать его там , а не через бд? Или хранить пользователя в своей бд и оттуда его брать? Хранить id пользователя в файле при запуске тестов, если тесты особенно параллельны. И так далее.

Просто не было понятно, почему вы пришли к такому решению с redis, ещё и не совсем надёжном, так как с ваших слов кто-то может из тестеров "поломать" пользователя. Почему не рассматривалм "стандартные" решения для вашей проблемы и если рассматривали, то к чему пришли/какие проблемы были?

Я тогда не совсем понял, какую задачу вы решали (

Раньше на каждый чих вы создавали нового пользователя и это было долго. Поэтому вы переиспользуете старых пользователей, которые "чистые" и их можно брать для тестов ?

Добрый день! Я правильно понимаю, что для тестов вы используете только Postman, без авто ?

спасибо. очень жду, жаль, что поздно уивидел объявление

Добрый день. Аможно где-то в записи посмотреть ?

Забить можно на всё, было бы желание)

Но с графаной вы в разы гибче настраиваете дашбоард, который приносит (для меня) пользу, а не дашборд ради дашборда

Спасибо. А почему не рассматривали вариант решить эту задачу через, например, Allure TestOps и строить дашборды и статистику там ?

Нам нужны не тестировщики в общем смысле, а, скорее, профессионалы в написании кодов по автотестам.

Золотые слова. А то из каждого утюга, что тестирование это просто, жми на кнопку и получай 300к

Может попросить тестировать/писать тесты разработчиков ?)

«Модульных тестов всегда больше, чем тестов с других уровней.»

Почему ?

Для чего тестировщику (особенно начинающему) знать Android Studio, XCode ?

Я выше писал, поддерживал ~5к апи тестов с различными версиями. Сначала тоже делал абстракции на абстракцию, потом все сильно упрощал, т.к. чем больше кода, тем сложнее стало в нем разбираться и метод "в лоб", сильно упростил написание и сопровождение тестов.

Мне трудно представить, что бы тот же фронт, например, писали в лоб, без использования MVC (не берем в расчет библиотеки) - на выходе будет неподдерживаемая каша. Но у вас в фирме приняли такое решение, это работает, ок)

Предлагалось, как вы ниже и написали, использовать задавание урла в 1 месте. В вашем же примере данной статьи, вы показываете о задании в каждом тесте/инициализации клиента.

Статья не про "куда нам деть url" ) Код в статье можно и нужно улучшать, но я бы начал с архитектуры, а потом думал об  url

Чтобы что? Боитесь, что requests надо будет заменять?

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

Но вы ведь его повторяете в своих тестах (в репозитории) описывая свои модели и у вас появляется теперь 2 вещи, где описана структура ответов от API и в случае проблемы, какой из реализаций доверять больше?

Например, в сваггере могут не описать 400 ошибки (и их модели) или копипастнуть. Если бы мой код лежал в одной репе с бэком(на питоне), то я просто бы забрал модели и переиспользовал бы их.

Information

Rating
Does not participate
Registered
Activity