LY
нет, например Testrail
Size: a a a
2020 September 24
OK
Вопрос с документацией можно решить иначе - наверняка у вас есть TMS. Если при прогоне тестов будут выводиться/актуализироваться сценарии (через API TMS) то вопрос актуализации документации станет гораздо проще.
есть получше - https://testomat.io/
M
а не)
R(
Ребята, а можно еще раз что плохого в огурце? У нас в компании по 1 автоматизатору, а проект огромный + плохая коммуникация между всеми отделами, мне показалось, что подход огуречный дает возможность клевых отчетов и понимания что автоматизировано.
У проектов автоматизации может быть и без того много зависимостей.
Огурец это слой представления -- написанное по огурцу это как код назвали а не что он собственно делает.
Как выше сказал Лев, если автоматизацию пишут сами автоматизаторы (и огурец тоже), то он ничем особо не помогает.
Совершенно сплошь и рядом огуречные сценарии растягиваются на 15+ строк, и в таких случаях, несмотря на то что сценарий написан вроде "человеческим языком", что он делает понятно, а как именно, и почему именно так, и ради чего он это делает, и что в этом сценарии ключевое -- непонятно, сами по себе огуречные степы это ещё одно "как мы сами это назвали".
Поначалу кажется что это да, не больно -- но эти степы тоже надо писать, группировать-структурировать, поддерживать и -=избегать дублирования=-. Чтобы избегать дублирования, потом когда их становится много, прежде чем написать ещё что-то надо перечитать всё что уже написано, попытаться понять что из этого можно приспособить а что надо новое писать. Та ещё морока.
Если просто написать комментарий что проверка делает и зачем, это может быть полезнее огуречных степов без такого комментария.
На отчёты огуречные я нормально насмотрелся, ничего особо помогающего в них не заметил. Самое полезное что я в них вижу это ошибки ассертов и стэктрейс -- что можно прекрасно иметь и без огурца.
Надёжность проектов огурец не повышает: вполне может оказаться так что половину времени придётся смотреть в консольный лог Дженкинса, а не огурца, -- почему отчёт огурца вообще не собрался.
Огурец это слой представления -- написанное по огурцу это как код назвали а не что он собственно делает.
Как выше сказал Лев, если автоматизацию пишут сами автоматизаторы (и огурец тоже), то он ничем особо не помогает.
Совершенно сплошь и рядом огуречные сценарии растягиваются на 15+ строк, и в таких случаях, несмотря на то что сценарий написан вроде "человеческим языком", что он делает понятно, а как именно, и почему именно так, и ради чего он это делает, и что в этом сценарии ключевое -- непонятно, сами по себе огуречные степы это ещё одно "как мы сами это назвали".
Поначалу кажется что это да, не больно -- но эти степы тоже надо писать, группировать-структурировать, поддерживать и -=избегать дублирования=-. Чтобы избегать дублирования, потом когда их становится много, прежде чем написать ещё что-то надо перечитать всё что уже написано, попытаться понять что из этого можно приспособить а что надо новое писать. Та ещё морока.
Если просто написать комментарий что проверка делает и зачем, это может быть полезнее огуречных степов без такого комментария.
На отчёты огуречные я нормально насмотрелся, ничего особо помогающего в них не заметил. Самое полезное что я в них вижу это ошибки ассертов и стэктрейс -- что можно прекрасно иметь и без огурца.
Надёжность проектов огурец не повышает: вполне может оказаться так что половину времени придётся смотреть в консольный лог Дженкинса, а не огурца, -- почему отчёт огурца вообще не собрался.
M
Jira, Jenkins, автоматизатор в слак копирует отчеты(все очень плохо)
M
У проектов автоматизации может быть и без того много зависимостей.
Огурец это слой представления -- написанное по огурцу это как код назвали а не что он собственно делает.
Как выше сказал Лев, если автоматизацию пишут сами автоматизаторы (и огурец тоже), то он ничем особо не помогает.
Совершенно сплошь и рядом огуречные сценарии растягиваются на 15+ строк, и в таких случаях, несмотря на то что сценарий написан вроде "человеческим языком", что он делает понятно, а как именно, и почему именно так, и ради чего он это делает, и что в этом сценарии ключевое -- непонятно, сами по себе огуречные степы это ещё одно "как мы сами это назвали".
Поначалу кажется что это да, не больно -- но эти степы тоже надо писать, группировать-структурировать, поддерживать и -=избегать дублирования=-. Чтобы избегать дублирования, потом когда их становится много, прежде чем написать ещё что-то надо перечитать всё что уже написано, попытаться понять что из этого можно приспособить а что надо новое писать. Та ещё морока.
Если просто написать комментарий что проверка делает и зачем, это может быть полезнее огуречных степов без такого комментария.
На отчёты огуречные я нормально насмотрелся, ничего особо помогающего в них не заметил. Самое полезное что я в них вижу это ошибки ассертов и стэктрейс -- что можно прекрасно иметь и без огурца.
Надёжность проектов огурец не повышает: вполне может оказаться так что половину времени придётся смотреть в консольный лог Дженкинса, а не огурца, -- почему отчёт огурца вообще не собрался.
Огурец это слой представления -- написанное по огурцу это как код назвали а не что он собственно делает.
Как выше сказал Лев, если автоматизацию пишут сами автоматизаторы (и огурец тоже), то он ничем особо не помогает.
Совершенно сплошь и рядом огуречные сценарии растягиваются на 15+ строк, и в таких случаях, несмотря на то что сценарий написан вроде "человеческим языком", что он делает понятно, а как именно, и почему именно так, и ради чего он это делает, и что в этом сценарии ключевое -- непонятно, сами по себе огуречные степы это ещё одно "как мы сами это назвали".
Поначалу кажется что это да, не больно -- но эти степы тоже надо писать, группировать-структурировать, поддерживать и -=избегать дублирования=-. Чтобы избегать дублирования, потом когда их становится много, прежде чем написать ещё что-то надо перечитать всё что уже написано, попытаться понять что из этого можно приспособить а что надо новое писать. Та ещё морока.
Если просто написать комментарий что проверка делает и зачем, это может быть полезнее огуречных степов без такого комментария.
На отчёты огуречные я нормально насмотрелся, ничего особо помогающего в них не заметил. Самое полезное что я в них вижу это ошибки ассертов и стэктрейс -- что можно прекрасно иметь и без огурца.
Надёжность проектов огурец не повышает: вполне может оказаться так что половину времени придётся смотреть в консольный лог Дженкинса, а не огурца, -- почему отчёт огурца вообще не собрался.
Спасибо большое за развернутый ответ!
LY
есть получше - https://testomat.io/
Так это ещё в разработке. И не бесплатно ) Обычно TMS у всех уже есть, и ещё одну "специально для автотестов" покупать не будут. Но идея мне нравится )
OK
Так это ещё в разработке. И не бесплатно ) Обычно TMS у всех уже есть, и ещё одну "специально для автотестов" покупать не будут. Но идея мне нравится )
TMS тоже не бесплатно чаще всего
LY
Конечно, но она уже есть и оплачена. И к примеру есть отличный Kiwi, который опенсорс.
M
я походу одна работаю в самой отсталой компании мира😅
OK
Конечно, но она уже есть и оплачена. И к примеру есть отличный Kiwi, который опенсорс.
Почему я раньше его не видел, вот и обменялись годными тулами, спасибо!
R(
Конечно, но она уже есть и оплачена. И к примеру есть отличный Kiwi, который опенсорс.
Практически использовали его, коллега? Сам по себе или с интеграциями? Интересуюсь практическими отзывами на оный.
LY
Практически использовали его, коллега? Сам по себе или с интеграциями? Интересуюсь практическими отзывами на оный.
Да, и продолжаю. Фактически основан на Django, и несложно "допилить" если что-то специфическое нужно.
R(
Jira, Jenkins, автоматизатор в слак копирует отчеты(все очень плохо)
А кто заставляет копировать отчёты в слак и зачем? :) Я работал в компаниях со слаком, никто отчёты туда не копировал.
M
А кто заставляет копировать отчёты в слак и зачем? :) Я работал в компаниях со слаком, никто отчёты туда не копировал.
Мне уже стыдно делиться как что у нас в компании)...копируют чтобы апдейтить менеджеров о результатах автотестов.
A
Всем привет
Такой вопрос, как в pytest запустить тесты сразу во всех браузерах (прошли тесты на хроме и дальше запустились на фаерфоксе)?
Сейчас пока запускаю с ключом —browser где указываю какой браузер запустить, но не особо удобно менять каждый раз https://pastebin.com/uFJd6Kgv
Такой вопрос, как в pytest запустить тесты сразу во всех браузерах (прошли тесты на хроме и дальше запустились на фаерфоксе)?
Сейчас пока запускаю с ключом —browser где указываю какой браузер запустить, но не особо удобно менять каждый раз https://pastebin.com/uFJd6Kgv
B
У проектов автоматизации может быть и без того много зависимостей.
Огурец это слой представления -- написанное по огурцу это как код назвали а не что он собственно делает.
Как выше сказал Лев, если автоматизацию пишут сами автоматизаторы (и огурец тоже), то он ничем особо не помогает.
Совершенно сплошь и рядом огуречные сценарии растягиваются на 15+ строк, и в таких случаях, несмотря на то что сценарий написан вроде "человеческим языком", что он делает понятно, а как именно, и почему именно так, и ради чего он это делает, и что в этом сценарии ключевое -- непонятно, сами по себе огуречные степы это ещё одно "как мы сами это назвали".
Поначалу кажется что это да, не больно -- но эти степы тоже надо писать, группировать-структурировать, поддерживать и -=избегать дублирования=-. Чтобы избегать дублирования, потом когда их становится много, прежде чем написать ещё что-то надо перечитать всё что уже написано, попытаться понять что из этого можно приспособить а что надо новое писать. Та ещё морока.
Если просто написать комментарий что проверка делает и зачем, это может быть полезнее огуречных степов без такого комментария.
На отчёты огуречные я нормально насмотрелся, ничего особо помогающего в них не заметил. Самое полезное что я в них вижу это ошибки ассертов и стэктрейс -- что можно прекрасно иметь и без огурца.
Надёжность проектов огурец не повышает: вполне может оказаться так что половину времени придётся смотреть в консольный лог Дженкинса, а не огурца, -- почему отчёт огурца вообще не собрался.
Огурец это слой представления -- написанное по огурцу это как код назвали а не что он собственно делает.
Как выше сказал Лев, если автоматизацию пишут сами автоматизаторы (и огурец тоже), то он ничем особо не помогает.
Совершенно сплошь и рядом огуречные сценарии растягиваются на 15+ строк, и в таких случаях, несмотря на то что сценарий написан вроде "человеческим языком", что он делает понятно, а как именно, и почему именно так, и ради чего он это делает, и что в этом сценарии ключевое -- непонятно, сами по себе огуречные степы это ещё одно "как мы сами это назвали".
Поначалу кажется что это да, не больно -- но эти степы тоже надо писать, группировать-структурировать, поддерживать и -=избегать дублирования=-. Чтобы избегать дублирования, потом когда их становится много, прежде чем написать ещё что-то надо перечитать всё что уже написано, попытаться понять что из этого можно приспособить а что надо новое писать. Та ещё морока.
Если просто написать комментарий что проверка делает и зачем, это может быть полезнее огуречных степов без такого комментария.
На отчёты огуречные я нормально насмотрелся, ничего особо помогающего в них не заметил. Самое полезное что я в них вижу это ошибки ассертов и стэктрейс -- что можно прекрасно иметь и без огурца.
Надёжность проектов огурец не повышает: вполне может оказаться так что половину времени придётся смотреть в консольный лог Дженкинса, а не огурца, -- почему отчёт огурца вообще не собрался.
Не очень понял претензии: непонятно что проверяет сценарий. Обычно это написано в названии сценария. Зато видишь весь сценарий целиком и на каком шаге упал. В консоль можно не заглядывать, к отчёту прикладываются все тестовые артефакты, включая логи, скрины.
Насчёт степов - с этим согласен. Сложно придумать понятные,не дублирующие, непротиворечивые степы.
Насчёт степов - с этим согласен. Сложно придумать понятные,не дублирующие, непротиворечивые степы.
B
не ной. завтра еще бдд обсудим и пейдж обжекты! потерпи!
Как в воду глядел
OK
Мне уже стыдно делиться как что у нас в компании)...копируют чтобы апдейтить менеджеров о результатах автотестов.
та все нормально, тут у многих свои скелеты в шкафу
S1
У слака же наверняка апи есть, можно подключить чтобы отчёты автоматом туда кидались)