Сейчас ричард придет и вжух вжухом всех

Ссылочку на флудилку можно?

В описании есть

привет) а кто-нибудь юзает qtest с jira?

Это тема для флудилки.

а что-то из флудилки выперли :( наверное недостаточно флудоусердия

а что-то из флудилки выперли :( наверное недостаточно флудоусердия

Ее забанили

Новая по тому же адресу

В описании

Ее забанили

ааа, спасибо )

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

Не работает критичный функционал. или может не допилена фича

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

Нет

А как это - вернуть билд в девелопмент?

мне тоже интересно

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

У занудства нет выходных ;)

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

просто у нас если он ушёл в тестинг, то обратно он не вернется. Баги будут вешаться на US, чиниться-верифаиться, ретест полный не будет происходить.

Не работает критичный функционал. или может не допилена фича

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

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

Есть северити багов и "критерий пропуска в прод".

Есть северити багов и "критерий пропуска в прод".

А при чём тут выход в прод? Северити - все ниже критикал, или там один критикал. Мажоры-миноры - целый вагон, под 30. Я спрашивал, отправляется ли тогда у вас сторя в девеломнет обратно или нет)

А как это - вернуть билд в девелопмент?

Оговорка по Фрейду, сторя, не билд)

Есть северити багов и "критерий пропуска в прод".

я спрашивал, если у вас не "критерий пропуска в прод", а "критерий возвращения обратно в девеломпент"))

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

DoD aka Acceptance criteria не поможет?

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

А зачем прекращать тестирование до фикса багов? Так же как зачем куда-то что-то возвращать, как будто бы его оттуда забрали, как ребёнка из детсадика. Не раскрыта тема того, почему тестировать и исправлять баги нельзя параллельно.

А зачем прекращать тестирование до фикса багов? Так же как зачем куда-то что-то возвращать, как будто бы его оттуда забрали, как ребёнка из детсадика. Не раскрыта тема того, почему тестировать и исправлять баги нельзя параллельно.

>А зачем прекращать тестирование до фикса багов? Слишком много багов - слишком много измений на их починку. Много изменений - есть шанс, что затронется другой функционал в неожиданном месте. Я не буду уверен, что заявленная по требованиям функциональность работает. Кстати, так и получилось. На 20-ом починенном баге отломалась p0 функциональность, которая была проверена неделю назад. Для себя я делаю вывод, что сторя сырая, и надо заново пройти весь тест-ран по ней чтобы быть уверенным, что сторя соответсвует требованиям. >Так же как зачем куда-то что-то возвращать, как будто бы его оттуда забрали, как ребёнка из детсадика. Таки забрали. Статус сменили в Jira, сторя на стороне куа. >Не раскрыта тема того, почему тестировать и исправлять баги нельзя параллельно. Можно. Но кажется, что в данном случае придется заново перепроходить тест-план - слишком много багов. Если багов много, их чинят кусочками в течении недели, к примеру. И за эту неделю код в самом начале недели и код после багфикса - совсем разный код. Тот факт, что в самом начале недели кейсы были нормально пройдены не гарантирует, что они будут пройдены к концу багфикса. А в авто регрессию кейсы ещё не поставленны, какая регрессия, сторя ещё в тестировании. То есть баги не будут выловленны проходом автотестов.

Не понимаю, а если мы "вернём обратно в разработку", то будет гарантировано, что пофикшенные баги снова не всплывут? В чем разница.

Не понимаю, а если мы "вернём обратно в разработку", то будет гарантировано, что пофикшенные баги снова не всплывут? В чем разница.

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

Просто когда очень много багов на сторе - тестировать её тоже самое, что тестировать сторю которая не была передана в тестирование, то есть не была готова.

мы ж не тестируем сторю, которая еще не готова?)

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

Вы тестируете конечно стори, которая неготова. Если бы она была бы готова, то в ней не находились бы баги.

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

По воркфлоу автотесты пишутся после завершения тестирования. Ну вот так вот у нас, да. >Вы тестируете конечно стори, которая неготова. Если бы она была бы готова, то в ней не находились бы баги. Ну не передергивайте. Так мы начнём говорить про тестирование стори, которая вообще не начиналась)) Готовность стори это разве "в ней не находятся баги"?

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

И да, не весь продукт, а только одну сторю. Просто есть ли смысл тестировать, что очень с большой долей вероятности сможет поменять на 70% свой код, к примеру? Ну ок, на на 70, на 20

Если у вас туда сюда передают - то нет смысла. А если работают вместе - то конечно есть. Разработчик всегда хочет знать, о каких сюрпризах в коде он еще не в курсе, а не только когда "всё закончит".

Если у вас туда сюда передают - то нет смысла. А если работают вместе - то конечно есть. Разработчик всегда хочет знать, о каких сюрпризах в коде он еще не в курсе, а не только когда "всё закончит".

Золотые слова. От команды разработки очень сильно зависит.

Шаг в правильную сторону - добавлять тестировщиков в команду разработки.

Шаг в правильную сторону - добавлять тестировщиков в команду разработки.

Я говорил совсем не про это. Извиняюсь, что не сумел точно объяснить, что хотел спросить. Сторю отдали в тестирование. Тестирование длилось,допустим день. Найдено 30 багов. Тестировать осталось ещё пару дней - много конфигураций и внешних зависимостей. Так вот. Мне кажется, что будет выгодней прекратить тестирование и отдать сторю на доработку. Потому что фикс большого количества багов может затронуть функционал, который уже был проверен в первый день тестирования. Что означает, что надо будет потратить 3 дня на тестирование + 3 дня на ретест - иначе не будет уверенности, что стория выполняет требования, что уже проверенный функционал не будет случайно затронут при багфиксе. Если прекратить тестирование и отдать её на доработку - будет потрачено 1 день + 3 дня на ретест.

Вот я и спрашивал, делается ли так у людей) Можно ли остановить тестирование и отправить на доработку

Можно, кто ж запретит.

Особенно у людей - как оно только не делается...

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

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

... и фиксить параллельно

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

А есть гарантия, что к концу тестирования пофикшеные баги не заафектят уже проверенный функционал? Это и есть проблема)

это тестирование. хотите гарантий - купите тостер (с)

вот плюс 1

А есть гарантия, что к концу тестирования пофикшеные баги не заафектят уже проверенный функционал? Это и есть проблема)

Регрессионное тестирование?

это тестирование. хотите гарантий - купите тостер (с)

или проверьте повторно. Вопрос был про стоимость тестирования)

Регрессионное тестирование?

сторя ещё не сдана, какая регрессия?

Если хотите уменьшить стоимость тестирования - не тестируйте.

... и купите тостер.

Если хотите уменьшить стоимость тестирования - не тестируйте.

Ну зачем же опять так передергивать. И не разрабатыйте, да? У тестирование есть стоимость. И можно протестировать дороже, можно дешевле

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

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

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

Смотря какие баги и сколько времени у вас есть

В общем, все остались при своём мнении))) Всем спасибо А я всё же соглашусь с одним из критериев остановки тестирования от Michael Bolton http://www.developsense.com/articles/2008-02-HowMuchIsEnough.pdf Dead Horse: When the application is down for the count, there’s no point in continuing to test. Anything we see after this is likely to be a side effect of things that we’ve already discovered, or our system is corrupted and the integrity of the test is compromised, as the developers will quickly point out when we try to report. Moreover, the problems that we’ve already discovered will lead to bug fixes, and those changes will require more testing later. Might we see an even more dramatic or damaging problem if we proceed a little further?

Ну зачем же опять так передергивать. И не разрабатыйте, да? У тестирование есть стоимость. И можно протестировать дороже, можно дешевле

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

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

Кто сказал, что отдельно считаются?

я не говорил про "отдельно считаются", вам показалось - или я криво написал. Это я могу, да)

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

Лично я никогда не останавливаю тестирование

тестирование - это часть разработки

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

тестирование заканчивают, когда проект закрылся

У вас аутсорс?

если не аутсорс - то тестирование у вас ничего не стоит. Каждый тестировщик, вероятно получает зарплату каждый месяц, которая примерно постоянная. И вот тестировал ли он 3 дня, 13 или 23, как правило не влияет на зарплату. Затраты на тестирование считаются суммированием зарплаты всех тестировщиков, а не тем, сколько дней было затрачено на регрессию.

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

Тестирование может остановиться, из-за блокеров , а не из-за большого количества. Что мешает не брать все баги в один релиз, но продолжать тестировать.

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

Тестирование может остановиться, из-за блокеров , а не из-за большого количества. Что мешает не брать все баги в один релиз, но продолжать тестировать.

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

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

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

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

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

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

+1

Это конечно вопрос для руководства, почему не хватает тестировщиков. Какое-то планирование должно быть, и уже на этапе оценки все должны чесать репу на вопросе что делать с тем, что у нас времени тестировщика не хватает на все дела

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

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

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

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

Всё тестирование прекратилось, или тестрование конктетной стори?)

читаю тред и выкупаю, че за дичь. Серьезно. Давайте по существу. У вас есть юзерстори, которая подразумевает ряд сабтасков, которые, как правило, независимы (можно делать в любом порядке) или частично зависимы (некоторые таски должны идти один за другим). Результатом юзер стори являются некие milestones каждого из тасков, и итоговый результат как фича с набором некоторых фунциональных характеристик. Так? По мере тестирования вы можете находить по факту 2 вида багов: баги, которые сломали то, что должно было работать, эти баги покрываются регрессионным тестированием. баги, которые вы могли случайно обнаружить в смежных модулях системы, и которые внезапно - не являются новыми. есть 3 сторона: просто невыполненные критерии в новом куске кода, это по сути не баг, а не реализованная фича. ----- Сели вы тестировать и нашли пару багов. Часть из них - выявляется как старые баги, никак не влияющие на текущую сторю - они не должны и не будут влиять на это сторю никак. Баги, найденные из-за регреса - упавшие тесты, етс - вы выясняете с разработчиками\аналитиками\етс, какое поведение фиксировать как валидное - и либо поправляете тест планы, тесты и т.д., либо заводите баги и прикрепляете их к юзерстори. третий пункт насчет просто нереализованной новой логики - можно заводить как баг, иногда тестировщики просто обсуждают это на словах с разработчиком, где требование ТЗ не удовлетворено, в зависимости от масштаба правок. ------ Я не понимаю, что значит "вернуть сторю" - если есть баги блокеры, которые не позволяют протестировать всё по чек листу - то заводится баг-блокер. Где рокет-сайенс-то?

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

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

Это называется шаринг знания)

читаю тред и выкупаю, че за дичь. Серьезно. Давайте по существу. У вас есть юзерстори, которая подразумевает ряд сабтасков, которые, как правило, независимы (можно делать в любом порядке) или частично зависимы (некоторые таски должны идти один за другим). Результатом юзер стори являются некие milestones каждого из тасков, и итоговый результат как фича с набором некоторых фунциональных характеристик. Так? По мере тестирования вы можете находить по факту 2 вида багов: баги, которые сломали то, что должно было работать, эти баги покрываются регрессионным тестированием. баги, которые вы могли случайно обнаружить в смежных модулях системы, и которые внезапно - не являются новыми. есть 3 сторона: просто невыполненные критерии в новом куске кода, это по сути не баг, а не реализованная фича. ----- Сели вы тестировать и нашли пару багов. Часть из них - выявляется как старые баги, никак не влияющие на текущую сторю - они не должны и не будут влиять на это сторю никак. Баги, найденные из-за регреса - упавшие тесты, етс - вы выясняете с разработчиками\аналитиками\етс, какое поведение фиксировать как валидное - и либо поправляете тест планы, тесты и т.д., либо заводите баги и прикрепляете их к юзерстори. третий пункт насчет просто нереализованной новой логики - можно заводить как баг, иногда тестировщики просто обсуждают это на словах с разработчиком, где требование ТЗ не удовлетворено, в зависимости от масштаба правок. ------ Я не понимаю, что значит "вернуть сторю" - если есть баги блокеры, которые не позволяют протестировать всё по чек листу - то заводится баг-блокер. Где рокет-сайенс-то?

Читаю и понимаю, в чём проблема - у каждого свой процесс, своё воркфлоу в котором живут, и поэтому трудно понять в чём цимес собственно) Мне дичью кажется считать багами только регрессионые баги, а остальное - не реализованными фичами. Как и то, что баги можно не заводить. Не заведенный баг - вероятно не пофикшенный баг и не проверенный

Всем привет, подскажите пожалуйста, кто какой инструмент использует для автотестов на ios? А то аппиум сейчас крайней степени медленно работает .

Всем привет, подскажите пожалуйста, кто какой инструмент использует для автотестов на ios? А то аппиум сейчас крайней степени медленно работает .

ну мы смогли его ускорить раза в 3-4 и юзаем дальше

Подскажите, как?

заменой xparh на iosnspredicate

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

или в логах куча ошибок