В TestRail есть возможность привязать к каждому шагу некий ожидаемый результат. И соответственно пофейлить тест, если сверка не выполнена. В коде конкретно этого плагина похоже немного другая концепция: проверка результата - это тоже шаг теста, а ожидаемый результат то, что ошибки не произошло. Соответственно меняется немого представление тестов в самой TMS. Теперь все содержимое написано в названии шагов и нет необходимость заходить внутрь каждого шага. Концептуально это ничего не меняет, но если нужно иное представление тестов в TMS, то видимо придется править плагин или использовать другой, если есть.
Да какая разница, это же программирование. Можно сделать что угодно. Будет выглядеть как-то так: step ("Something", () -> { expected("Result"); }); В этом нет ничего сложного)
@@eroshenkoam expected - статический метод аллюра? Не совсем понимаю, каким образом текст из expected будет отображаться в test rail или allure отчёте? Не могли бы вы пояснить, пожалуйста.
Экспорт в TestRail из алюра только через плагины? К тому же у плагина ограничение на язык программирования(Java junit 5). А если я хочу на CI код на мерджах ранить, то как это реализовать? JS
Возьмите для себя РЕАЛЬНУЮ, боевую, очень важную для вас задачу и начните пилить код. Сразу встанет много вопросов, но именно желание добить задачу и будет драйвить вас в сторону цели! К примеру, хочется купить шубу, есть 20 сайтов, на каждом из них не менее 800 шуб. Хочется отсортировать по цене, по вендору и др. характеристикам. Потом в каком-то удобном для вас виде выдать, к примеру в виде списка в CSV-файле. Для парня, можно взять N сайтов знакомств с девушками, к примеру отсортировать девушек по наличию нужных ему характеристик, далее выдать те ссылки, которые лучше всего подходят под критерии. Курсы, они полезны, но прежде всего надо любить программирование, а любишь его тогда, когда оно приносит пользу прежде всего лично тебе
Интересный подход. Кажется, что имеет право на жизнь, но в силу своей необычности применить его будет довольно сложно. Это надо, что бы этой идеей проникся тестлид, а потом уже начал внедрять это в компании беря на себя ответственность и получая все шишки. Но кто знает, возможно лет через 10 писать кейсы как то по другому уже будет моветон и прошлый век.
А это единствено адекватный подход в наше время! То что сейчас используется это очень долго, муторно и отбивает лишний раз заглядывать и менять тест.документацию . Другими словами, если мы, тестировщики, хотим расти мы обязаны менять подходы И да, чтоб тест лид проникся надо ему продать эту идею. Я уже показал очень многим этот видос и люди все больше и больше загораются этой идеей
@@eroshenkoam Если доклад нацелен на русско-говорящую аудиторию, пусть и технарей, все-таки имеет смысл применять родной для аудитории язык. Термин "ветка", "Репозиторий" и др. уже устоявшиеся термины и никаких сложностей с их пониманием нет. Да, бывает ситуации, когда сложно подобрать перевод и проще сказать по-английски, пояснив что имелось ввиду. Однако достаточно много переводов, которые уже устаялись, к примеру "Branch" это "Ветка". Если человек плохо знает английский и не способен перевести, то может ему сначала нужно заняться процессом импрува своего английского?
15:23 Тест-кейсы как код. Начало самого интересного
Красавчик!
аннотация @Manual - это некая кастомная аннотация? на первом примере - подсвечена красным.
использовать это аннотацию из коробки не получается.
53:43 степы есть, а ожидаемого результата нет, можно ли прописывать в коде ОР и чтобы он добавлялся в тестрейл как и степы?
тоже возник этот вопрос
В TestRail есть возможность привязать к каждому шагу некий ожидаемый результат. И соответственно пофейлить тест, если сверка не выполнена. В коде конкретно этого плагина похоже немного другая концепция: проверка результата - это тоже шаг теста, а ожидаемый результат то, что ошибки не произошло. Соответственно меняется немого представление тестов в самой TMS. Теперь все содержимое написано в названии шагов и нет необходимость заходить внутрь каждого шага. Концептуально это ничего не меняет, но если нужно иное представление тестов в TMS, то видимо придется править плагин или использовать другой, если есть.
Да какая разница, это же программирование. Можно сделать что угодно. Будет выглядеть как-то так:
step ("Something", () -> {
expected("Result");
});
В этом нет ничего сложного)
@@eroshenkoam expected - статический метод аллюра? Не совсем понимаю, каким образом текст из expected будет отображаться в test rail или allure отчёте? Не могли бы вы пояснить, пожалуйста.
Экспорт в TestRail из алюра только через плагины? К тому же у плагина ограничение на язык программирования(Java junit 5).
А если я хочу на CI код на мерджах ранить, то как это реализовать? JS
а какие курсы можете посоветовать для ручных тестировщиков? чтобы научиться понимать код
hexlet
Возьмите для себя РЕАЛЬНУЮ, боевую, очень важную для вас задачу и начните пилить код. Сразу встанет много вопросов, но именно желание добить задачу и будет драйвить вас в сторону цели!
К примеру, хочется купить шубу, есть 20 сайтов, на каждом из них не менее 800 шуб. Хочется отсортировать по цене, по вендору и др. характеристикам. Потом в каком-то удобном для вас виде выдать, к примеру в виде списка в CSV-файле.
Для парня, можно взять N сайтов знакомств с девушками, к примеру отсортировать девушек по наличию нужных ему характеристик, далее выдать те ссылки, которые лучше всего подходят под критерии.
Курсы, они полезны, но прежде всего надо любить программирование, а любишь его тогда, когда оно приносит пользу прежде всего лично тебе
Интересный подход. Кажется, что имеет право на жизнь, но в силу своей необычности применить его будет довольно сложно. Это надо, что бы этой идеей проникся тестлид, а потом уже начал внедрять это в компании беря на себя ответственность и получая все шишки. Но кто знает, возможно лет через 10 писать кейсы как то по другому уже будет моветон и прошлый век.
А это единствено адекватный подход в наше время! То что сейчас используется это очень долго, муторно и отбивает лишний раз заглядывать и менять тест.документацию . Другими словами, если мы, тестировщики, хотим расти мы обязаны менять подходы
И да, чтоб тест лид проникся надо ему продать эту идею. Я уже показал очень многим этот видос и люди все больше и больше загораются этой идеей
43:15 "количество джоп начало вырастать". Да, знакомо. Как говорил Конфуций: "Количество жоп растет пока не превращается в одну большую }|{O⨅ϓ" 😂
nice
Неужели у всех тест стэпы в одну строку?)
Не нужно говорить "по-русски". Это технический язык, все поймут "бранч", но мне надо задуматься, что такое "ветка"
Возможно, учту в будущем)
@@eroshenkoam
Если доклад нацелен на русско-говорящую аудиторию, пусть и технарей, все-таки имеет смысл применять родной для аудитории язык. Термин "ветка", "Репозиторий" и др. уже устоявшиеся термины и никаких сложностей с их пониманием нет.
Да, бывает ситуации, когда сложно подобрать перевод и проще сказать по-английски, пояснив что имелось ввиду. Однако достаточно много переводов, которые уже устаялись, к примеру "Branch" это "Ветка". Если человек плохо знает английский и не способен перевести, то может ему сначала нужно заняться процессом импрува своего английского?
@@ntvisigoth а в России девелоперы / тестеры не знают английский? Как они пишут код итд?
@@Lola2012ful Ну давайте вообще забудем родной язык и будем говорить по-английски? В чем проблема-то? Подумаешь язык предков забыли. Не беда ведь! :)
@@ntvisigoth надеюсь мы сделаем это как можно быстрее 🙏