После чтения кучи статей про стратегию тестирования, для себя я решил, что индустрия не имеет единого мнения, что это такое, для чего и как хоть примерно это должно выглядеть. Также, как и необходимость его. Потому что хорошо составленная стратегия тестирования, повторяет/заменяет описание всего процесса разработки
Абсолютно согласен, 6 лет использовали BDD, за это время ни один не qa не сделал ни одной правки туда, ни разу их не запустил. Зато кучу реализаций примерно одного функционала было.
Не совсем понятно, а что вы тестируете то? Вы проверяете действие каких-то уже готовых пайплайнов, с помощью которых все выкатывается? Но что будет, если этот пайплайн создаст что-то дополнительное, не ожиданое? или уничтожит левый pod?
А что если в пайплан настоящего сервиса добавят что-то свое?
Metamask и Phantom можно "тыкать" в playwright без обвязок. Metamask отлично открывается как таб и окно, в которое можно перенести фокус и нажать, что надо
Хоть бы про принтер что-то написали. Готовый дом выглядит также, как и все предыдущие "печатаные" дома. Непонятно, что с жесткостью, эти слои, которые надо закрывать декором и штукатурить, круглые углы, ужас
Учитывая, что они замораживают уже умерших людей, мне кажется шансы на воскрешения в районе нуля. Да и "перевод" денег живых на счет компании выглядит немного странно (видимо это и есть бизнес модель)
Так у вас процессы плохие были, там и без "fullstack" наверняка также работали.
Я уже лет 5 работаю в таком "QA fullstack" и это клево. Во-первых постоянное развитие, во-вторых очень часто с разработчиками общаешься наравне либо даже учишь их, в-третьих ты самостоятелен и тебе не надо ждать кучу людей, чтобы поправить что-то.
Скажите, а зачем вы даете тестовое задание, чтобы что? Вам недостаточно просто поговорить? Ваши 8 пунктов говорят только о том, что у этих людей другой стиль написания тестов, чем принято в вашей компании (и вы даже про это сами говорите).
В моем понимании, единственное тестовое задание, которое может быть, это опросник/задачка, чтобы HR отсеивал совсем никаких
Как я писал выше, попробуйте мыслить не 1 тест, а "у нас тут много тестов и это все надо поддерживать"
Я выше писал, поддерживал ~5к апи тестов с различными версиями. Сначала тоже делал абстракции на абстракцию, потом все сильно упрощал, т.к. чем больше кода, тем сложнее стало в нем разбираться и метод "в лоб", сильно упростил написание и сопровождение тестов.
А как вы предлагаете решить проблему? Писать в лоб? Где та тонкая грань, когда тестов "много" (больше 5?) и стоит писать нужный код и раскидывать по всему проекту
Вы сами писали в комментариях, что разделяете тесты по логическим папкам. Зачем для этого тащить регистрацию куда-то дальше модуля проверяющего регистрацию (или всю логическую сущность в виду системы аутентификации)? Определение много/мало это лежит на коллективе, разрабатывающего эти тесты.
Так как в будущем вы будете использовать эти тесты в CI и вам надо будет прокидывать url через командную строку и/или переменную. Поэтому хардкодить не вариант
Предлагалось, как вы ниже и написали, использовать задавание урла в 1 месте. В вашем же примере данной статьи, вы показываете о задании в каждом тесте/инициализации клиента.
инверсия зависимости
Чтобы что? Боитесь, что requests надо будет заменять?
Эта модель не повторяет requests, эта наше собственная модель. В тестах мы независим от нижней реализации - requests. Где делать валидацию это вопрос для дальнейшего обсуждения, к сожалению, мне не хватит бумаги что бы за один заход рассказать как писать api тесты
Видимо не хватило этой статьи, чтобы объяснить для чего это, пока что, как и предыдущий вопрос, видится, что это для будущей замены requests.
Используем, сваггер это "книга данных", к в которую автотестор постоянно заглядывает и смотрит. В идеальной компании такой подход, когда мы доверимся полностью сваггеру и будем на основе его писать модели, сработал бы. Но я никогда не встречал "идеальный" сваггер, который 100% отражает действительность. Сваггер для меня это внешняя зависимость, а такие зависимости стараются убирать.
Но вы ведь его повторяете в своих тестах (в репозитории) описывая свои модели и у вас появляется теперь 2 вещи, где описана структура ответов от API и в случае проблемы, какой из реализаций доверять больше?
Я посмотрел ваш репозиторий, который вы указали, и там часть вопросов отпадает, реализовано (на мой взгляд) лучше.
Очень не хватает информации, почему роскосмос не отдает спутники, что говорит?
Почему это названо "как профессионал"? Вы ничего нового или крутого не показали
Почему выбран Cypress? "Это делает его отличным инструментом для автоматизации API." - ПОЧЕМУ?
Зачем используется вообще Cypress, который все таки специализируется на UI тестировании?
А дайте ссылку на fullstack framework Pinecone? Гуглится только векторная база данных. А то первая два в списке - это скорее ui фреймворки
После чтения кучи статей про стратегию тестирования, для себя я решил, что индустрия не имеет единого мнения, что это такое, для чего и как хоть примерно это должно выглядеть. Также, как и необходимость его. Потому что хорошо составленная стратегия тестирования, повторяет/заменяет описание всего процесса разработки
Абсолютно согласен, 6 лет использовали BDD, за это время ни один не qa не сделал ни одной правки туда, ни разу их не запустил. Зато кучу реализаций примерно одного функционала было.
Не совсем понятно, а что вы тестируете то? Вы проверяете действие каких-то уже готовых пайплайнов, с помощью которых все выкатывается? Но что будет, если этот пайплайн создаст что-то дополнительное, не ожиданое? или уничтожит левый pod?
А что если в пайплан настоящего сервиса добавят что-то свое?
Metamask и Phantom можно "тыкать" в playwright без обвязок. Metamask отлично открывается как таб и окно, в которое можно перенести фокус и нажать, что надо
Коляска выглядит прям очень плохой, именно как коляска. Как минимум она супер тяжелая и значит ни на какие ступеньки ее не поднять
Хоть бы про принтер что-то написали. Готовый дом выглядит также, как и все предыдущие "печатаные" дома. Непонятно, что с жесткостью, эти слои, которые надо закрывать декором и штукатурить, круглые углы, ужас
в конце есть ссылка на вб :)
Учитывая, что они замораживают уже умерших людей, мне кажется шансы на воскрешения в районе нуля. Да и "перевод" денег живых на счет компании выглядит немного странно (видимо это и есть бизнес модель)
Так у вас процессы плохие были, там и без "fullstack" наверняка также работали.
Я уже лет 5 работаю в таком "QA fullstack" и это клево. Во-первых постоянное развитие, во-вторых очень часто с разработчиками общаешься наравне либо даже учишь их, в-третьих ты самостоятелен и тебе не надо ждать кучу людей, чтобы поправить что-то.
Скажите, а где спрашивают такие вопросы про скрам? На роль скрам мастера?
но эта реставрация похожа на установку виниров и вообще на виниры? или совсем другое что-то?
Скажите, а зачем вы даете тестовое задание, чтобы что? Вам недостаточно просто поговорить? Ваши 8 пунктов говорят только о том, что у этих людей другой стиль написания тестов, чем принято в вашей компании (и вы даже про это сами говорите).
В моем понимании, единственное тестовое задание, которое может быть, это опросник/задачка, чтобы HR отсеивал совсем никаких
Не совсем из статьи, а как крепятся такие "реставрации"? По описанию технологии, очень похоже на виниры
Зачем тут postman, если используется k6?
Статья хорошая, но она не относится к QA только, у вас вполне общий подход получился
еще б их можно было где-то куптиь, хотя бы по 10 баксов
Я выше писал, поддерживал ~5к апи тестов с различными версиями. Сначала тоже делал абстракции на абстракцию, потом все сильно упрощал, т.к. чем больше кода, тем сложнее стало в нем разбираться и метод "в лоб", сильно упростил написание и сопровождение тестов.
Вы сами писали в комментариях, что разделяете тесты по логическим папкам. Зачем для этого тащить регистрацию куда-то дальше модуля проверяющего регистрацию (или всю логическую сущность в виду системы аутентификации)? Определение много/мало это лежит на коллективе, разрабатывающего эти тесты.
Предлагалось, как вы ниже и написали, использовать задавание урла в 1 месте. В вашем же примере данной статьи, вы показываете о задании в каждом тесте/инициализации клиента.
Чтобы что? Боитесь, что requests надо будет заменять?
Видимо не хватило этой статьи, чтобы объяснить для чего это, пока что, как и предыдущий вопрос, видится, что это для будущей замены requests.
Но вы ведь его повторяете в своих тестах (в репозитории) описывая свои модели и у вас появляется теперь 2 вещи, где описана структура ответов от API и в случае проблемы, какой из реализаций доверять больше?
Я посмотрел ваш репозиторий, который вы указали, и там часть вопросов отпадает, реализовано (на мой взгляд) лучше.