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

а как ты предлагаешь если без кейсов?

а как ты предлагаешь если без кейсов?

Чек листы

Чек листы

+100500

и чем это лучше кейсов?

и чем это лучше кейсов?

Быстрее, проще, возни меньше

Но и конкретики меньше

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

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

Если коренные тестировщики на проекте и проект небольшой, то можно и чеклисты :)

А если молочные?

Если коренные тестировщики на проекте и проект небольшой, то можно и чеклисты :)

bus factor

и чем это лучше кейсов?

больше головой думаешь о логике тестируемого объекта

А если молочные?

Для молочных тесткейсы

больше головой думаешь о логике тестируемого объекта

а кейсы это запрещают?

а кейсы это запрещают?

по факту да

по факту да

Не

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

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

Зависит от тестировщика

Другое дело что на тест кейсы тратится 999999999 времени

И изменять их, следить за ними

Фе

Другое дело что на тест кейсы тратится 999999999 времени

но по ним потом может ознакомиться с функционалом кто угодно

но по ним потом может ознакомиться с функционалом кто угодно

Пусть лучше документацию читают)))

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

ооочень спорно.

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

+ если человек не новенький манки_тестер способен проверять не только то что написано

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

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

Но всё это упирается чисто в трату времени на щёлканье по клавишам

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

А проблема штанов их надевать. Проблема телефона его заряжать.

А проблема штанов их надевать. Проблема телефона его заряжать.

Именно

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

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

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

значит тестил манки

А голову включать не пробовали?

++

Забыли написать тесткейс на перекрывание :D

это не тесткейз на перекрывания, это Common sence

Это перекрывается кейсом :"все элементы доступны"

Блин, изменения проверяют не точечно...

это не тесткейз на перекрывания, это Common sence

Это шутка

Это перекрывается кейсом :"все элементы доступны"

Кейсом "всё работает как надо"

))))

Да хоть каким

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

Но есть нюансы

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

значит тестил манки

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

Ну не норм значит, ну

проблема ресурсов?

Или распределения задач в команде

Это не проблема кейсов, это иные проблемы

+

проблема ресурсов?

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

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

Когда релизы 2 недели

в таком случае используют чек-листы

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

https://twitter.com/spiceadventure/status/1034704489150861312?s=21

))

Да Канбан

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

Зачем разрабам тесткейсы?

И техписателям

есть такие техники как TDD

К примеру когда достаточно размытое ТЗ, в кейсах же более четко указана логика

Для тех.писов, чтобы по ним писать ПМИ

Зачем разрабам тесткейсы?

За тем же, за чем и тестировщикам. В случае падения теста можно не объяснять проблему разработчику, а кинуть линк на падение

И это тоже)

За тем же, за чем и тестировщикам. В случае падения теста можно не объяснять проблему разработчику, а кинуть линк на падение

Тогда можно не писать баги?

Ничего себе! Оказыватся, можно не писать баги. Открытие: можно не тратить время на бесполезные метрики и не заводить баги в development итерации, оставляя формальным критерием ЗЕЛЕНОСТЬ тест-сьюта в твоём Тимсити

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

Ничего себе! Оказыватся, можно не писать баги. Открытие: можно не тратить время на бесполезные метрики и не заводить баги в development итерации, оставляя формальным критерием ЗЕЛЕНОСТЬ тест-сьюта в твоём Тимсити

Можно вообще распустить QA отдел и говорить, что тестирование не нужно, не надо утрировать

Так же кейсы используют потом для автоматизации

Так же кейсы используют потом для автоматизации

Тоже аргумент в пользу тесткейсов

к слову как раз щас пишу автоматизацию посмотривая в кейсы

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

В случае с разработкой фичи любые такие временные упавшие тест-кейсы могут быть «багами» как артефактом, но это писанина ради писанины зачастую.

к слову как раз щас пишу автоматизацию посмотривая в кейсы

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

а еще можно быть полезным

а еще можно быть полезным

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

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

Это весьма печальное заявление. Я бы не хотел работать с таким коллегой

Я про «как можно меньше людей знало» и job saving programming, как днище и индикатор того, что ты неизбежно с таким подходом (или подходом коллег вокруг) сядешь в болото

Камрады, а подскажите, можно ли в жире сделать дашборд где будет видно, что вот по этим тикетам дьюдейт прошёл, а по этим нет?

https://community.atlassian.com/t5/Jira-Core-questions/Filter-Issues-by-Due-Date/qaq-p/275202

В канбане можно фильтры свои налепить, тоже через JQL

А блин, да

Спс

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

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

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

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

Я про «как можно меньше людей знало» и job saving programming, как днище и индикатор того, что ты неизбежно с таким подходом (или подходом коллег вокруг) сядешь в болото

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

Лол

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

у вас там есть таблица прогресса по багам? Набрал 100 и лвл ап?

должность != крутые баги ?

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

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

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

так это одно и то же. Замыкаешь на себя = делаешь себя незаменимым. Незаменимых мы заменим принудительно.

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

Это бас фактор и есть

Для QA такое положение дел должно быть противно по своей природе.