Беру баг на валидэйт.
Удостоверяюсь что изменения поправленны/добавленны .
Но не закрываю. Долго.
Т.к. начинаю обыскивать все смежные области в надежде что-то сломать, отыскать, покарёжить, взломать, найти несоотвествие, и тд и тп ... И нахожу, иногда.
Что взять за грань, когда хватит тестировать смежные области? Это же, блин, долго и долго ((((
долго - это сколько? часы, дни?
ОтветитьУдалитьчасы.
ОтветитьУдалитьно для проекта это малопозволительно. говорят: "скорей закрывай". А я, блин, боюс баг пропустить ((
кстати да, ситуация патовая
ОтветитьУдалитьсам не знаю что с этим делать, обычно достаю программистов с вопросом куда лазили и что могли сломать
заканчивать надо тогда и только тогда когда потраченные усилия меньше полезности от этого усилия. грубо говоря когда рои становиться меньше 1.
ОтветитьУдалить1) Можно "паралельные" тесты вынести в регрессию
ОтветитьУдалить2) Можно проставить приоритеты и поделится рисками с проект менеджером - согласен ли он добавить время
3) Можно в следующий раз увеличить оценку тестирования добавив цикл Explaratory Testing
А зачем ты в одну кучу сваливаешь все. Это две разные задачи - перепроверка бага и поиск регрессий. Проверил саму багу, вот именно так как она была заведена - закрой или верни разработчикам. Сломалось что то еще? Смело заводи новый репорт и линкуй с закрытой багой.
ОтветитьУдалитьДополнительные проверки лучше заводить в основной план, при первом репорте баги - там же, выствылять приоритет кейсов. Пока же понимания продукта нет (а в целом только из-за этого трудно определить границы, я думаю), то тратить часы на поиск неизвестно чего не нужно - мало эффективно. Эрик в этом плане правильную мысль высказал, но беда в том, что для множества ситуаций никто не сможет определить затронутую область. Тут скорее придется идти от обратного - сначала написать регрессионные кейсы для баги и потом сесть с разработчиками и провести ревью. Через несколько итераций получишь хороший фидбек и понимание, что может быть затронуто. А пока этого нет лучше сосредоточиться на задаче - быстро проверить фиксы и после этого заниматься регрессией и все остальным.
Поддержу предыдущего оратора.
ОтветитьУдалитьНадо разделять follow-up и regression testing.
В первом случае мы хорошо представляем, какие области затронуты изменениями, сделанными при исправлении *данного* бага, и смотрим на них.
Во втором, смотрим на всё области или все, затронутые всеми ищменениями в тестируемой версии.
Всё зависит от проекта, кое-где без хорошенького прохода по смежным областям не один баг пропустишь. Я бы обсудил вопрос с менеджером, приведя примерную статистику найденных таким образом багов и обязательно времени, которое в среднем тратится тобой на такого рода тестирование.
ОтветитьУдалитьПусть уже он даст тебе ответ на этот вопрос, чтобы избежать непонимания и проблем с ответственностью за пропущенные баги в будущем.
В тех случаях, когда изменения могли явно затронуть какие-то другие области, разработчики мне сами обычно оставляют пометку: проверь это и то.
ОтветитьУдалитьМожно попытаться сделать "беглый" осмотр смежных областей, не углубляясь. Работает - ок, более подробно - уже регрессионное.