NA
чтобы разраб мог потом посмотреть ГЛАЗАМИ
типа понять ошибку он может только по скришноту, а вот править тесты он полезет в них сам, да?
qa не будет нужен, верно?
Size: a a a
2021 January 08
AG
чтобы разраб мог потом посмотреть ГЛАЗАМИ
Нет, не совсем так.
Если они мне понадобятся - они будут в аутпуте, вместе с другими полезными артефактами.
Не понадобятся- будут радостно складироваться в dev/null.
Если они мне понадобятся - они будут в аутпуте, вместе с другими полезными артефактами.
Не понадобятся- будут радостно складироваться в dev/null.
NA
ну как по мне - это дикий оверкил
AG
А в чем оверкилл-то?
NA
но ты на второй вопрос ответь
ошибку разраб понять может только по скриншоту?
ошибку разраб понять может только по скриншоту?
VS
Всё очень просто.
Мы решали конкретную проблему - на дебаг тестов тратилось N времени в месяц.
За несколько итераций решений «от быстрого и плохого к хорошему и сложному» пришли к решению, которое дало нужные результаты.
Является ли оно универсальным? Нет.
Помогает ли оно выделить относительно универсальные критерии оценки репортов? Да.
Мы решали конкретную проблему - на дебаг тестов тратилось N времени в месяц.
За несколько итераций решений «от быстрого и плохого к хорошему и сложному» пришли к решению, которое дало нужные результаты.
Является ли оно универсальным? Нет.
Помогает ли оно выделить относительно универсальные критерии оценки репортов? Да.
Что-то даже смотреть. Понятно что айди лучше чем другие локаторы. Почему - да потому что на 90 процентов проектаз автотесыт это ответственность автоматизаторов. И айди парктически никогда не меняется а вот если длиннющий xpath то там обязательно что-то поменяется. Вторая проблема в читаемости - сразу по коду понятно куда мы кликаем на какой элемент и не надо идти в консоль и смотреть что-то. Затем чем меньше ошибок тем больше профит для бизнеса и вместо того чтобы фиксить 2 лня упавшие тесты из-за локаторов лучше решить инфраструктурные проблемы. Вот у нас код тестов и приложения лежат вместе и чтобы даже внести мелкое изменение надо - сделать пул оеквест, получить минимум 3 апрува, получить успешный билд. Последнйи ращ когда фиксил локаторы ушло 2 дня чтобы доставить ее на прод.
NA
и он полезет править
NA
Что-то даже смотреть. Понятно что айди лучше чем другие локаторы. Почему - да потому что на 90 процентов проектаз автотесыт это ответственность автоматизаторов. И айди парктически никогда не меняется а вот если длиннющий xpath то там обязательно что-то поменяется. Вторая проблема в читаемости - сразу по коду понятно куда мы кликаем на какой элемент и не надо идти в консоль и смотреть что-то. Затем чем меньше ошибок тем больше профит для бизнеса и вместо того чтобы фиксить 2 лня упавшие тесты из-за локаторов лучше решить инфраструктурные проблемы. Вот у нас код тестов и приложения лежат вместе и чтобы даже внести мелкое изменение надо - сделать пул оеквест, получить минимум 3 апрува, получить успешный билд. Последнйи ращ когда фиксил локаторы ушло 2 дня чтобы доставить ее на прод.
спасиб, мил человек
AG
но ты на второй вопрос ответь
ошибку разраб понять может только по скриншоту?
ошибку разраб понять может только по скриншоту?
Не так.
Инфы в аутпуте теста должно быть достаточно, что бы по её совокупности было понятно что это за тест, на каких данных он гонится, где конкретно и почему он упал.
На том проекте, где это было сделано - хватало в 99% случаев.
И да, разработчики ходили и правили тесты упавшие на их PR.
Инфы в аутпуте теста должно быть достаточно, что бы по её совокупности было понятно что это за тест, на каких данных он гонится, где конкретно и почему он упал.
На том проекте, где это было сделано - хватало в 99% случаев.
И да, разработчики ходили и правили тесты упавшие на их PR.
D
Вы тут все наркоманы
Не нужно смешивать тесты на бизнес-логику с тестами на внешний вид страницы. Для первого типа тестов нужно использовать редко меняющиеся локаторы, для второго - сравнение скриншотов или полные xpath пути, если он так нравится
Не нужно смешивать тесты на бизнес-логику с тестами на внешний вид страницы. Для первого типа тестов нужно использовать редко меняющиеся локаторы, для второго - сравнение скриншотов или полные xpath пути, если он так нравится
VS
Не так.
Инфы в аутпуте теста должно быть достаточно, что бы по её совокупности было понятно что это за тест, на каких данных он гонится, где конкретно и почему он упал.
На том проекте, где это было сделано - хватало в 99% случаев.
И да, разработчики ходили и правили тесты упавшие на их PR.
Инфы в аутпуте теста должно быть достаточно, что бы по её совокупности было понятно что это за тест, на каких данных он гонится, где конкретно и почему он упал.
На том проекте, где это было сделано - хватало в 99% случаев.
И да, разработчики ходили и правили тесты упавшие на их PR.
если это продуктовая компания никто никуда ходить не будет, бизнесу важны фичи и пофиг на тесты если есть дедлайны
AG
если это продуктовая компания никто никуда ходить не будет, бизнесу важны фичи и пофиг на тесты если есть дедлайны
Ну, мы с вами работали в разных продуктовых компаниях, наверное. :)
VS
Не так.
Инфы в аутпуте теста должно быть достаточно, что бы по её совокупности было понятно что это за тест, на каких данных он гонится, где конкретно и почему он упал.
На том проекте, где это было сделано - хватало в 99% случаев.
И да, разработчики ходили и правили тесты упавшие на их PR.
Инфы в аутпуте теста должно быть достаточно, что бы по её совокупности было понятно что это за тест, на каких данных он гонится, где конкретно и почему он упал.
На том проекте, где это было сделано - хватало в 99% случаев.
И да, разработчики ходили и правили тесты упавшие на их PR.
Вот какой локатор понятнее и по какому из них сразу можно понять где его искать
VS
div:nth-child(4)>div>div:nth-child(1)>div:nth-child(3) input+div+div>div>div>div:not(.BJYnWmtuMhUU):not(#day-null)’
[data-testid=“day”]
[data-testid=“day”]
VS
Ну, мы с вами работали в разных продуктовых компаниях, наверное. :)
ну я в европейских, не знаю Вы где
VS
и да, разработчики не будут разбираться с вашими тестами а скажут сами смотрите, ваши тесты, ваши проблемы
AG
ну я в европейских, не знаю Вы где
Ну да, ну да. :)
NA
Не так.
Инфы в аутпуте теста должно быть достаточно, что бы по её совокупности было понятно что это за тест, на каких данных он гонится, где конкретно и почему он упал.
На том проекте, где это было сделано - хватало в 99% случаев.
И да, разработчики ходили и правили тесты упавшие на их PR.
Инфы в аутпуте теста должно быть достаточно, что бы по её совокупности было понятно что это за тест, на каких данных он гонится, где конкретно и почему он упал.
На том проекте, где это было сделано - хватало в 99% случаев.
И да, разработчики ходили и правили тесты упавшие на их PR.
ну просто я не вижу смысла для этого делать скриншот
если разраб знаком с тестами на том уровне, что может и реально ДЕЛАЕТ в них сам правки
обычно просто разработчика и палками не загонишь фиксить то, что он напрудил
и объективно их время стоит дороже qa-шного
если разраб знаком с тестами на том уровне, что может и реально ДЕЛАЕТ в них сам правки
обычно просто разработчика и палками не загонишь фиксить то, что он напрудил
и объективно их время стоит дороже qa-шного