в идеале автотесты доолжны быть независимы друг от друга и разбиты на мелкие проверки.

в идеале

а иногда тест кейс написан таким паровозом

что его лучше разбить на десяток автотестов

продукты разные тест кейсы разные

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

в идеале автотесты доолжны быть независимы друг от друга и разбиты на мелкие проверки.

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

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

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

если это просто прекондишн для проверки и проверялся в других тестах, то я бы сказал нужно)

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

а можно просто спрятаться за чёрным ящиком, чтобы никто тебя не видел)

чет я походу ящики напутал)

Кстати, а если в том ящике пивко, то ящик правильный))

потому что тестировать порой без пивка не возможно

такое понапишут

Кстати, а если в том ящике пивко, то ящик правильный))

у нас тут есть дегустатор в чяте, интересно, чем его дегустация закончилась.

двумя пальцами в рот)

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

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

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

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

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

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

У вас в середине тесткейса проверка, и в конце еще одна проверка

это уже прям тестовый сценарий

если вы делаете проверку на купить, никаких проверок до этого

У вас в середине тесткейса проверка, и в конце еще одна проверка

проверка всмысле те действия на странице

"а третей проверяем данные и подтверждаем что все ок..на четвертой нажимаем купить,,"

Вот

Не вот

если вы делаете проверку на купить, никаких проверок до этого

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

Каждый функционал проверяется в своем тесте. Если для проверки настроек профиля вы заодно проверяете весь попутный функционал - это не есть гут

такой тест более нестабилен. И блокируется другими багами

"а третей проверяем данные и подтверждаем что все ок..на четвертой нажимаем купить,,"

в таком случае перед каждой страницей надо передавать параметры гет\ постом и проверять только функционал страницы?

100 тестов могут быть заблокированы одним багом

на который могут сказать - И так сойдет. Или это изменение новое, ожидаемое. А тесты бесполезны пока не пофиксится

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

в таком случае перед каждой страницей надо передавать параметры гет\ постом и проверять только функционал страницы?

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

продукт может их уже давно поменять а тесты останутся зелеными

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

это да

плюс были проблемы что данные приходили со сторонних серверов и один и тот же рейс мог то работать то нет)

получается в данном случае подход с длинными тестами вполне обоснован?

а потом окажется что пост изсенился и если идти через сайт полей стало 9) а с вашим постом все 10 норм

Коллеги по цеху, помните поговорку, поспешишь - людей насмешишь

Коллеги по цеху, помните поговорку, поспешишь - людей насмешишь

это жизненый слоган мой

ну, кто-то всё таки выступает за спешку, и все - Да, Да, да

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

а стоит ли такой тест-кейс автоматизировать? я просто интересуюсь

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

Главное чтоб тестов было много))) и все зеленые

а еще можно при при прогоне тестов на селениуме покрытие серверного кода считать и говорить что вот вам 1000 тестов покрытие сераерного кода 90%

а потом окажется что пост изсенился и если идти через сайт полей стало 9) а с вашим постом все 10 норм

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

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

ну если сценарий облегчает действия

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

а что подразумевается под сценарием ? Если это завязанные друг на друга действия: Открыть страницу авторизации Ввести логин Ввести пароль Засабмитить форму Проверить что есть сообщение об успешной авторизации ? или что-то более сложное: Залогинится с параметрами А Проверить что работает поиск по сайту Разлогинится Залогинится с параметрами Б ...

?

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

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

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

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

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

я бы сделал 2 кейса: Один тыкает все кликами и проверяет что есть какой-то результат другой кейс параметризованный: генерит урл и проверяет что результат поиска соответсвует сгенерированным ожиданиям

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

так календарь будет покрыт в других тестах

вот другой вопрос если календарь самописный и может при выборе 1 января 2017 года вернуть на бэк 31 декабря 2014 года

с датами и временем это вообще всегда "очень интересно" получается )

я бы сделал 2 кейса: Один тыкает все кликами и проверяет что есть какой-то результат другой кейс параметризованный: генерит урл и проверяет что результат поиска соответсвует сгенерированным ожиданиям

на основе чего тест генерит урл? где гарантия того что он делает это как актуальная версия продукта?

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

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

Я про то что вы завязываетесь в тесте на текущие состояние кода продукта, а не функционала

в итоге тестируете коня в вакууме

вроде и тесты всё покрывают, а в целом функционал не работает

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

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

Изначально речь шла про автотесты на функционал

и был вопрос о целесообразности "хаков" для сокращения шагов теста

ERROR: S client not available

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

Всё это шикарно, НО есть момент

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

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

таки, да, главное не быть их основными участниками

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

вот тогда, я бы с удовольствием выслушал бы, НАСКОЛЬКО полезным иметь раздельные тесты)

Всем привет. Кто-нибудь игры тут тестировал? В частности интересует тестирование работы джойстиков)

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

я где-то выше писал про бизнесс-смысл )

я где-то выше писал про бизнесс-смысл )

В ващем подходе с тестом на календарь какраз был упущен бизнес смысл)

вот тогда, я бы с удовольствием выслушал бы, НАСКОЛЬКО полезным иметь раздельные тесты)

наверно вам начальник спасибо скажет, ага)

я бы сделал 2 кейса: Один тыкает все кликами и проверяет что есть какой-то результат другой кейс параметризованный: генерит урл и проверяет что результат поиска соответсвует сгенерированным ожиданиям

Вот тут. У вас получается один тест смотрит что на календарик "хоть какой то результат" а второй что на вами заданный урл корректный результат.

вместо теста что при работе с календарем отображается страница с корректным результатом

вместо теста что при работе с календарем отображается страница с корректным результатом

хорошо, и какие шаги в таком тесте делаются ?

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

" укажете дату в календаре и жмякните на кнопку показать" Ожидания - отобразилась страница с рейсами на ожидаемую дату

окей, ожидание не выполнилось: что сломалось ?

какой багрепорт будет ?

тот же что и в вашем тесте рейсов по урлу

только тут урл сгенерен самим продуктом

и в тесте все операции идут в плоскости возможностей пользователя который пользуется Вашим продуктом

нет: в моих вариантах, даже с условием, что я действительно не правильно написал "проверить что что-то выдалось" - выдаст либо, что у нас не работает календарь на форме; либо что у нас не работает фильтрация по датам

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

ну значит в моем варианте нужен 3 кейс: который внесет через форму календаря значение и проверит что дата в выдаче соответсвует дате в вводе

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

предлагаю притормозить на этом :)

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

С этим вроде разногласий и не возникало. Вот понимание правильности декомпозиции и вызвало разногласия. т.е. оправдано ли использование "хаков" для подготовки входного состояния продукта для теста.

Всем привет! Народ, помогите кто знает как достать пароль из приложения .ipa ?

есть предложение админу группы нашей, можно в описании текущей группы с делать ссылку на qa-флудилку ( тут ранее упоминали её )?

не надо

не надо

думаешь многих это травмирует?

да

сорян, осознал, напишу туда тогда

есть предложение админу группы нашей, можно в описании текущей группы с делать ссылку на qa-флудилку ( тут ранее упоминали её )?

можно и пост закрепить с ссылкой на флудилку.