5 июля 2011 г.

Прям беда какая-то, не знаю что поделать ...

Беру баг на валидэйт.
Удостоверяюсь что изменения поправленны/добавленны .

Но не закрываю. Долго.
Т.к. начинаю обыскивать все смежные области в надежде что-то сломать, отыскать, покарёжить, взломать, найти несоотвествие, и тд и тп ... И нахожу, иногда.

Что взять за грань, когда хватит тестировать смежные области? Это же, блин, долго и долго ((((

9 комментариев:

  1. долго - это сколько? часы, дни?

    ОтветитьУдалить
  2. часы.
    но для проекта это малопозволительно. говорят: "скорей закрывай". А я, блин, боюс баг пропустить ((

    ОтветитьУдалить
  3. кстати да, ситуация патовая
    сам не знаю что с этим делать, обычно достаю программистов с вопросом куда лазили и что могли сломать

    ОтветитьУдалить
  4. заканчивать надо тогда и только тогда когда потраченные усилия меньше полезности от этого усилия. грубо говоря когда рои становиться меньше 1.

    ОтветитьУдалить
  5. 1) Можно "паралельные" тесты вынести в регрессию
    2) Можно проставить приоритеты и поделится рисками с проект менеджером - согласен ли он добавить время
    3) Можно в следующий раз увеличить оценку тестирования добавив цикл Explaratory Testing

    ОтветитьУдалить
  6. А зачем ты в одну кучу сваливаешь все. Это две разные задачи - перепроверка бага и поиск регрессий. Проверил саму багу, вот именно так как она была заведена - закрой или верни разработчикам. Сломалось что то еще? Смело заводи новый репорт и линкуй с закрытой багой.

    Дополнительные проверки лучше заводить в основной план, при первом репорте баги - там же, выствылять приоритет кейсов. Пока же понимания продукта нет (а в целом только из-за этого трудно определить границы, я думаю), то тратить часы на поиск неизвестно чего не нужно - мало эффективно. Эрик в этом плане правильную мысль высказал, но беда в том, что для множества ситуаций никто не сможет определить затронутую область. Тут скорее придется идти от обратного - сначала написать регрессионные кейсы для баги и потом сесть с разработчиками и провести ревью. Через несколько итераций получишь хороший фидбек и понимание, что может быть затронуто. А пока этого нет лучше сосредоточиться на задаче - быстро проверить фиксы и после этого заниматься регрессией и все остальным.

    ОтветитьУдалить
  7. Поддержу предыдущего оратора.
    Надо разделять follow-up и regression testing.

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

    ОтветитьУдалить
  8. Всё зависит от проекта, кое-где без хорошенького прохода по смежным областям не один баг пропустишь. Я бы обсудил вопрос с менеджером, приведя примерную статистику найденных таким образом багов и обязательно времени, которое в среднем тратится тобой на такого рода тестирование.
    Пусть уже он даст тебе ответ на этот вопрос, чтобы избежать непонимания и проблем с ответственностью за пропущенные баги в будущем.

    ОтветитьУдалить
  9. В тех случаях, когда изменения могли явно затронуть какие-то другие области, разработчики мне сами обычно оставляют пометку: проверь это и то.
    Можно попытаться сделать "беглый" осмотр смежных областей, не углубляясь. Работает - ок, более подробно - уже регрессионное.

    ОтветитьУдалить