К тебе на тест попадает 2 проекта. В одном проекте необходимо проверить корректность внесенных правок, на другом - протестировать новый функционал. Какой проект ты возьмешь в работу раньше?
Запомните: важно рассуждать на собеседование, у тех кого есть опыт - рассказывать на основании своего опыта, у кого нет опыта - прочитайте пост для ознакомления.
Данный вопрос разместила в нельзяграме (подписаться), снизу ответы от подписчиков и обмен своим опытом.
1. Зависит от дедлайнов по каждому из проектов и от оценок на тестирование каждого;
2. По приоритету задачи проекта;
3. Если приоритет одинаков, то я буду проверять новую функциональность согласно видам тестирования связанные с изменением,
я считаю, что сперва new feature testing, а потом retest - проверка правок;
Вы можете иначе сказать🙃, но думаю будет дискуссия. Поясните почему?
Ответы:
1
Я бы сказал время, если ретест значит фича близка к релизу и ее нужно быстрее обработать чтобы уложится в срок/не затягивать релиз
Новый функционал обычно планируется к релизу позже
2
Я предпочту сначала ретест, чтобы если там все починено, мы могли раскатить на прод эту фичу и начать аб эксперимент)
3. Зависит от решения PM;
4. Начать с вопросов для интервьюера. Пусть даст нормальные входные данные.
«Каковы сроки на сдачу?» и др;
Ответы подписчиков из нельзяграма:
1
Зависит от приоритетов проекта(если таковые имеются), от количества правок и их срочности - может это хотфикс, тогда конечно его в приоритете, если это мелкие баги и дедлайн не скоро то можно и подождать. Тоже самое с новой фичей - какой у неё приоритет, насколько она большая? Если предположить что обе очень срочные задачи и приоритет одинаков, я возьму более мелкую сначала, потому что большая задача в любом случае займёт много времени. В общем все зависит от ответов на мои вопросы😂
2
Если правки сильно ждут на проде, это тормозит релиз, то сначала старую задачу.
Если релизов нет, то сначала новую, понаходить там багов, отдать разрабу, чтоб не скучал, а потом уже ретестом заниматься.
3
Поскольку она могла задеть имеющийся важный функционал программы, ну в общем, конечно, зависит от приоритета задач, в данном случае если приоритет одинаковый, то можно исходить из окружения, на котором ты будешь проверять, если это спец дев ветка, то корректные правки можно отодвинуть на второй план и проверить на дев ветке именно новый функционал, а после залития правок на препрод, в совокупности можно посмотреть две задачи одновременно, наверняка они имеют места смежного функционала))
4
Ретест - скорее всего, функциональность уже на проде, юзер уже ею пользуется, сможем быстрее выдать в релиз.
При тестировании новой функциональности запросто вылезут недостатки требований и баги, на уточнение и исправление багов уйдет какое-то время, из-за этого ретест может быть отложен во времени и не успеет в релиз.
Но вообще, конечно, нюансов тьма - что по объемам, цели спринта и критичности изменения.
Скорее всего я бы взяла тестировать новое, а пока жду уточнений/фиксов, спокойно в параллель бы тестировала фикс на ретесте.
5
Почитала еще ответы, согласна с ними тоже. Возможно новый функционал мизерный, а проверка дефекта это объемный ретест. Но почему считаю, что даже небольшой новый функционал займет больше времени - это в любом случае изучение ТЗ, какие-то уточнения с аналитиком и разрабами, написание тестов и тестирование. А существующий дефект это ситуация с шагами и описанием, где нужно проверить воспроизводится или нет. Если это твой же дефект, проверка занимает меньше времени…
Пишите и ваши рассуждения. Сохраняйте пост.