нет

а все увидел в описании отдельный чатик спс

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

а почему выводдится "фолз" понятно из кода

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

в академиях учат, что один тест - одна проверка. не аксиома, но чем меньше проверок в тесте - тем лучше. читаемость отчета сильно повышается и проще ошибку локализовать. в вашем случае - будете дооооолго искать в логе, что и почему свалилось

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

Лучше тестировать поведение системы, а не код. Если после выдачи этого false тестируемый сценарий считается проваленным - ронять тест. Если это не мешает выполнению сценария - не ронять.

Лучше тестировать поведение системы, а не код. Если после выдачи этого false тестируемый сценарий считается проваленным - ронять тест. Если это не мешает выполнению сценария - не ронять.

по сути это будет багом, и тест может проходить даже если будет этот баг

Я бы разделил это на два теста, в таком случае.

это условие есть в одном тесте (в общем это тест регистрации) и его нельзя выделить отдельно, потому что эта проверка части регистрации

это условие есть в одном тесте (в общем это тест регистрации) и его нельзя выделить отдельно, потому что эта проверка части регистрации

Проверьте отдельным тестом до этого бага. Второй тест запустите на полный сценарий. таким образом вы проверите конкретный ваш баг первым тестом. а вторым проверите сценарий целиком.

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

А никто не находил настройку в Хроме, что дев-панелька по умолчанию открывалась с отмеченной галочкой preserve log в Network? для консоли такое есть

А никто не находил настройку в Хроме, что дев-панелька по умолчанию открывалась с отмеченной галочкой preserve log в Network? для консоли такое есть

вот кстати да, тоже нужно это

Есть в настройках галочка такая, но в случае Консоли она делает этот пункт всегда отмеченным, а в случае Нетворка - всё равно каждый раз нужно ставить

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

а у вас каждый тест логинится отдельно?)

а у вас каждый тест логинится отдельно?)

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

хай кто-нибудь SQLi Labs использовал для того чтобы научиться SQL инъекциям?

хай кто-нибудь SQLi Labs использовал для того чтобы научиться SQL инъекциям?

попробуй почитать SQL Injection от А до Я

там слишком старые материалы, с тем же успехом можешь почитать документы от PT Security или посмотреть презенташки с тех же SQA Days или QA Fest Этого хватит для общего понимания того как используют подобную уязимость, однако методы борьбы уже изменились

и прогонять перечисленные там тесты скорее бессмысленно или можно на ранних стадиях проекта

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

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

в смысле - новых на проекте, или новичков в тестировани?

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

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

у нас пока не настолько сложные проекты, чтобы по ним надо было писать тест-кейсы) мне сейас надо написать документ, который человек поймет и сможет сразу начать работать

блин ну что-то вроде должностной инструкции)

1) все линки куда надо будет доступ и как его получить (тестовые среды, дженкинс, гит и т.д.)

блин ну что-то вроде должностной инструкции)

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

презентация, которая вкратце расскзаывает суть проекта, архитектуру

Если у вас автотесты "читабельны"- это хорошая альтернатива тест-кейсам. И обычно все линки по продукту ( на всех окружениях) там тоже имеются.

Если у вас автотесты "читабельны"- это хорошая альтернатива тест-кейсам. И обычно все линки по продукту ( на всех окружениях) там тоже имеются.

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

Behave в автотестах в таких случаях спасает) ну или хотя бы комментарии,что на каком шаге происходит.

Behave в автотестах в таких случаях спасает) ну или хотя бы комментарии,что на каком шаге происходит.

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

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

Ох, это мой сон ))

Ох, это мой сон ))

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

до сих пор обидно(

Боже, опять бдд, манкитестеры и имплементаторы автотестов.

а чем плохо бдд?

звучит как "ой всё"

Ой всё.

@shooandendlessagony Где то там была стена текста про бдд.

Если коротко, то случаев когда он полезен критически мало, а пихают его в каждую щель.

Кстати, там вполне адекватненько написано, я читал)

ага, и это всего лишь чье то мнение

но, статьи не читал, не могу обсудить)

я лично в своей работе использую KDT

вполне устраивает

люди разиваются, тестирование идет

Ммм...подробнее...что вы под KDT подразумеваете?

Как оно у вас реализовано и работает?

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

https://en.wikipedia.org/wiki/Keyword-driven_testing

Да, спасибо, это я знаю)

Robot framework или какая-то IDE?

робот

тесты пишутся в пайчарме с плагином

тоже прикольная вещь) просто многие IDE для тестирования, Katalon или TestComplete, к примеру - имеют свои реализации KDT, вот и уточнял)

А не проще людей за неделю научить пайтону для полноценной работы с автотестами?

Вместо обучения их бессмысленным и беспощадным оберткам.

"помогло переложить всю работу по написанию автотестов на ручных тестировщиков" — оксюморон, однако

А не проще людей за неделю научить пайтону для полноценной работы с автотестами?

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

ERROR: S client not available

А не проще людей за неделю научить пайтону для полноценной работы с автотестами?

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

а так - он пишет тот же сценарий в Джире, к примеру, только с некоторыми ограничениями, но это сценарий потом работает как автотест

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

я))0

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

Ну, около десятка обучал лично, и еще несколько десятков знаю.

А зачем опыт бэк разработки и знание ооп для написания автотестов на пайтоне?

А что, там рокетсаенс какой-то?

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

Окей, значит мы с вами просто работаем с разными категориями людей. :)

при чем тут рокет сайенс? подходы разные, имхо второе сложнее

Все что нужно, чтобы не писать бдд - это что есть класс страницы и у нее есть методы через точку. Все, он уже может дойти до странички и клацнуть по кнопке

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

потому что геркин это тоже язык, и его тоже нужно выучить

при чем тут рокет сайенс? подходы разные, имхо второе сложнее

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

Поэтому слова BDD и вызывают стойкую реакцию "ой всё" у тех, кто понимает, что автотест написать на готовом фреймворке - это просто, а правильно написанный автотест сам по себе ну ооочень понятен и читабелен.

кмк тут больше спор о вкусе фломастеров

Ну не совсем. Вот это вот BDD нахрен не пригодится нигде потом, а опыт написания автотестов нормальных - везде.

Умея второе - первое ты легко сделаешь.

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

ну ок)

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

так то и на джаве не сложно будет писать

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

мозг

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

юзаю Winium - он слишком древний

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

вопрос по бесплатным или платынм?)

так то и на джаве не сложно будет писать

ну так то Шуу прав. Либо давай подробнее опишим условия в которыз рассматривается выбор: БДД или Автотетсы+Фреймворк

вопрос по бесплатным или платынм?)

не имеет значения, прост интересен ваш опыт

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

autoit

не имеет значения, прост интересен ваш опыт

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