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