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