ты не прошел?)
А так, вопросы к руководителю куа. Он и руководит тестпланом, и самими тестировщиками.
Можно за пол часа с руководителем обсудить, сделать из 100 кейсов смок (если горят сроки) и много чего еще обсудить (привлечь других людей из других проектов)
смотря как процесс выстроен и какое вообще тестирование проходит. у нас к примеру разработка -> начало тестирование( создание тестплана, написание кейсов под новые фичи) и само тестирование. у нас нет такого, что вдруг появились новые динамические сценарии и +100 кейсов)
Нет. Я хочу узнать другие варианты действий всего-лишь) из крайности в крайность ты рассуждаешь)
если что, речь только о моменте с кейсами, а не то, что тестировщик должен вникать еще на этапе разработки (учавствовать в демо и т.д)
Ну, смотрите. У вас есть система пропорций. X кейсов Y времени Z ресурсов Если вам не хватает времени * ресурсы на прохождение кейсов, вы можете: - Увеличить количество времени. - Увеличить количество ресурсов. - Более правильно использовать ресурсы. - Изменить количество кейсов. Каждый из этих вариантов, если немножко поразмышлять, представляет собой возможную стратегию поведения в такой ситуации.
я это и писал выше (брать людей из других отделов, отсеивать мене важные кейсы)
Да, сорян. Не туда зареплаил. Это, конечно же, было адресовано автору исходного вопроса, ака @cedarcedar99
Ну, приоритизация это тоже ограничение скоупа в какой-то степени. Вариантов много, просто каждый из них так или иначе влияет на описанную выше пропорцию, к которой, если сильно упрощать, все сводится.
Мне кажется довольно очевидным, что «успеть сделать больше, чем планируешь» лучше, чем успеть сделать меньше. Поэтому не вижу особого смысла это отдельно проговаривать. Но в целом да, вы, конечно же, правы. Подход «протестировать сколько успеешь» - тоже есть, распространён, работает.
Обсуждают сегодня