"на готовом фреймворке"

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

он прав только если это рассматривать со стороны развития тестера

Давай чуть подробнее, почему он не прав. В каких условиях БДД будет лучшим выбором?

роботом можно начать сразу

Давай чуть подробнее, почему он не прав. В каких условиях БДД будет лучшим выбором?

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

поменялся тестер? ну чтож, бывает, следующий

autoit

спасибо, посмотрю. конечно, хотелось бы, чтобы можно было написать тесты на c# или java

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

Т.е. робот работает сразу из коробки и ничего с ним делать не надо?

да, там куча экшенов

так пока самое удобное что пробовал руками для десктопа был TestComplete, но он шибко платный

спасибо, чуть не забыл о нём.

чтобы писать на (условно) питоне как в роботе — нужно на обучение затратить ровно столько же времени

Может бдд используют те, кому хочется автоматизировать но платить за ручников

на питоне тоже "можно начать сразу" :)

а "ручники" у вас меньше получают, чем "автоматизаторы"?

тогда использование BDD однозначно выгодно

ручники везде получают меньше чем автоматизаторы

Ну судя по вакансиям на да

во всем мире

люди пишут автотесты, но мы им говорим, что они "ручники" и платим меньше. профит!

главное, чтобы они не догадались :)

Это всё звучит как хитрая идея руководства, которое типа за меньшую ЗП получает больше профита, и продаёт это всё своему вышестоящему руководству. Такое очковтирательство наппоминает, у меня в сбертехе было когда-то давно, но это отдельная тема для другого чатика)

да ну серьезно, ленейные сценарии эт автотесты

не понял про линейные сценарии, сорян)

выгодно, это когда написал собственный фреймворк и джунам рассказываешь где там прописывать селекторы и проверки, - на выходе проект полностью покрыт автотестами за копейки)

ну...и что такое селекторы тоже)

Это всё звучит как хитрая идея руководства, которое типа за меньшую ЗП получает больше профита, и продаёт это всё своему вышестоящему руководству. Такое очковтирательство наппоминает, у меня в сбертехе было когда-то давно, но это отдельная тема для другого чатика)

ну по факту ручник пишет не автотест, а все же тестовый сценарий, просто для автотестера нет необходимости разбираться каждый раз в тестовой процедуре, максимум в 1-2 еще не имплементированых шагах, если сравнить это с тем, сколько времени нужно будет затратить на обучение этих людей языку программирования, если опыта не было или было очень мало и давно, а потом каждый раз ревьювить и править после них, то мне кажется выгода все же есть

чтобы писать на (условно) питоне как в роботе — нужно на обучение затратить ровно столько же времени

у вас какое-то искаженное представление про программирование

то, что вы научили людей писать сценарии в роботе или на геркине — это и есть программирование

они пишут на языке программирования

просто язык убогий

ну так можно взять от любого "полноценного" языка такое же убогое подмножество и выучить его, времени на это уйдет ровно столько же

а вот тема насчет "можно платить меньше" — это реально удобно, с точки зрения руководства :)

Ну а что вас удивляет то?

как-то я раньше не рассматривал BDD под таким углом...

ну так можно взять от любого "полноценного" языка такое же убогое подмножество и выучить его, времени на это уйдет ровно столько же

Можно, но тут уже всё готово, бери и пользуйся, а не придумывай сам фреймворк

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

выучить нужно не "весь язык", выучить нужно ровно такое подмножество, которое требуется для написания сценариев. это подмножество по сложности абсолютно эквивалентно геркину или роботу

что именно вы подразумеваете под "все готово" — не очень понятно

Как выше писали, "готовый фреймворк"

что скрывается за этим термином?

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

Нужно читать это "сколько денег надо будет им платить, когда они научатся, чтобы они остались" :)

я боюсь, что слова "готовый фреймворк" для разных людей имеют очень разный смысл

А что там в роботе готово? Там же нужно все равно реализовывать все эти ключевые выражения? Кто-то должен это делать.

если словом "готовый фреймворк" назвать библиотеку selenium2library для RF — это будет смешно для тех, кто под "готовым фреймворком" подразумевает набор действий, специфичных для конкретного приложения

Можно, но тут уже всё готово, бери и пользуйся, а не придумывай сам фреймворк

Это не совсем так.

И сказки про робот умеющий все из коробки в духе "бери да пиши на английском сходу" - явное приувеличение.

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

новых в проекте, это будет внутренняя документация

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

люди пишут автотесты, но мы им говорим, что они "ручники" и платим меньше. профит!

в данном случае автотестеры эт разработчики фреймворка и всех экшенов

так у вас любой новчок может прийти, написать пару автотестов на готовом фреймворке и называть себя гуру

у вас все люди делятся на «тех, кто не умеет программировать» и «гуру»? промежуточные градации не рассматриваются?

так у вас любой новчок может прийти, написать пару автотестов на готовом фреймворке и называть себя гуру

и немного абсурда: любой новичок может прийти, написать приложение на nodeJS и называть себя гуру. Еще можно нырнуть в колодец "языки высокого и низкого уровня".

Привет всем! Может кто подсказать хорошие статьи/книги по управлению процессом тестирования?

Дмитрий Гетман: Привет всем! Может кто подсказать хорошие статьи/книги по управлению процессом тестирования? + или может есть телеграмм каналы для тест менеджеров / тест лидов?

Дмитрий Гетман: Привет всем! Может кто подсказать хорошие статьи/книги по управлению процессом тестирования? + или может есть телеграмм каналы для тест менеджеров / тест лидов? + может о qa в широком смысле, а не тестировании

https://www.linkedin.com/pulse/testers-dont-test-anymore-jason-arbon

привет) кто работает с robotframework+python и может рассказать про его минусы, с которыми столкнулись? обо что там шишки набивать?

ERROR: S client not available

привет) кто работает с robotframework+python и может рассказать про его минусы, с которыми столкнулись? обо что там шишки набивать?

работал с ним несколкьо лет назад, ну так себе поделка

в целом для быстрого создания тестов неопытными QA - отличная штука

еще и заказчику DDD & BDD показать

но имхо лучше просто на питоне писать сразу )

больше контроля, меньше возьни

я раньше на питоне просто и писала... но фреймворк своя не напишу. а тут они робот юзают для редкой автоматизации GUI регресса.

а для робота фреймворк напишете? думаете, это проще?

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

@RichardGears вжух?

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

Робот - это всего лишь DSL поверх обычного такого кода. Всё, что он включает в себя - матчинг действий питонячьего, или какого там, кода с фразами на псевдонатуральном языке + немного синтаксического сахара для придания этому общей структуре. Что там, что тут - придется пилить свой набор "экшенов" для конкретно своего проекта.

Когда необходимо применять нагрузочное тестирование веб сайта?

когда затраты на его проведение меньше рисков от его не проведения например

когда затраты на его проведение меньше рисков от его не проведения например

Это можно отнести к тестированию в общем Чем раньше - тем лучше

Когда необходимо применять нагрузочное тестирование веб сайта?

заблаговременно, перед пиками активности использования тестируемого продукта

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

Есть примерные варианта ответа, из которых один более подходящий 1) с самого начала разработки 2) изменить функциональные тесты на нагрузочное 3) оставить на конец проекта 4) запускать и собрать информацию о производительности

Ильдар и Константин Согласен с Вами!

3) оставить на конец проекта - но нужно ведь при разработке уже учитывать пожелания к нагрузке, нет? Чтобы в конце не решать только тем, что "надо бы накинуть еще памяти и процов". Может это конечно не так, я хз

4

5) В соответствии и бизнес потребностями.

Если вы знаете, что нас вас будет нагрузка в N - нужно удостовериться, что нагрузка N * 2 не роняет все задействованные участки системы.

Если вы знаете, что нас вас будет нагрузка в N - нужно удостовериться, что нагрузка N * 2 не роняет все задействованные участки системы.

N * 2 это откуда-то из опыта или правила хорошего тона?

N * 2 это откуда-то из опыта или правила хорошего тона?

Ну, на самом деле чем выше N, тем меньше степень умножения, но меньше, чем +30% я бы закладывать не стал.

В ситуациях, когда уровень нагрузки можно оценить только теоретически - лучше X2

Потому что теоретические оценки они такие, дают довольно большую погрешность.

Спасибо всем за обсуждение!

Всем привет, ребят. Правильно ли я понял, что хром, начиная с версии 66, показывает страницу с предупреждением на всех без исключений сайтах без https?