В статье перечислены основные методы тестирования ( Кроссбраузерное, бизнес-требований, функциональное и т.д.). На самом деле, их намного больше - более 36. Другие варианты тестов обозначены в абзаце со стратегиями тестирования. Если интересно более детально эта тема раскрыта в статье: https://tquality.ru/blog/vidy-testirovaniya-programmnogo-obespecheniya/
Подскажите. Вот у вас продукт, который разрабатывается несколько лет. Какова вероятность, что регрессионное тестирование вообще помещается в разумные рамки в пределах спринта? И что делают разработчики, пока идет регресс, ведь по скраму добрасывать новые задачи нельзя.
Вероятность 100%. Даже несмотря на длительную разработку продукта, необходимый объем регрессионного тестирования можно выполнить в пределах спринта, так как под регрессию выбираются модули/функциональности, затронутые изменениями в коде.
При этом уложиться в срок поможет автоматизация, а также чёткое планирование и распределение задач между всеми членами команды.
А пока идет регрессионное тестирование, разработчики могут заняться задачами из следующей версии, которые также добавляются в спринт.
Вот это ведь уже опять же не скрам.
Здесь может возникнуть конфликт приоритетов: либо строго следовать правилам и процессам (но есть риск терять в качестве и часто беспокоиться о простое разработчиков), либо поставить качество на первое место и заранее планировать, насколько это возможно.
Спасибо за вашу обратную связь!
Спасибо за вашу обратную связь!
Здравствуйте! Спасибо, мы учтём это при написании следующих материалов.
В статье перечислены основные методы тестирования ( Кроссбраузерное, бизнес-требований, функциональное и т.д.). На самом деле, их намного больше - более 36. Другие варианты тестов обозначены в абзаце со стратегиями тестирования. Если интересно более детально эта тема раскрыта в статье: https://tquality.ru/blog/vidy-testirovaniya-programmnogo-obespecheniya/
Вероятность 100%. Даже несмотря на длительную разработку продукта, необходимый объем регрессионного тестирования можно выполнить в пределах спринта, так как под регрессию выбираются модули/функциональности, затронутые изменениями в коде.
При этом уложиться в срок поможет автоматизация, а также чёткое планирование и распределение задач между всеми членами команды.
А пока идет регрессионное тестирование, разработчики могут заняться задачами из следующей версии, которые также добавляются в спринт.
Здесь может возникнуть конфликт приоритетов: либо строго следовать правилам и процессам (но есть риск терять в качестве и часто беспокоиться о простое разработчиков), либо поставить качество на первое место и заранее планировать, насколько это возможно.