и посмотреть медиа
TestGrow - software testing
и посмотреть медиа
Channel of the software testing platform. Materials for testers.
Channel of the software testing platform. Materials for testers.
AI bot for text-to-speech and voice cloning in Telegram. Create audio using neural network quickly and easily.
Resource of the TestGrow platform for software testing. Useful materials and tips for QA specialists.
Немного мыслей про 100% покрытие всего и вся! Частенько слышу такие вопросы от бизнес-заказчиков, разработчиков, продуктов и многих других, типа, а можем ли мы покрыть все сценарии тестами, чтобы ну ж точно быть уверенными в качестве? И что интересно, частота таких вопросов как я заметил зависит еще и от того, как часто ошибки попадают на продуктив. Честно говоря, полное покрытие - это антиутопия, то есть в целом невозможно. Даже если просто посчитать для небольшой форме с 10 полями количество комбинаций входных данных стремится к бесконечности. А если добавить сюда состояния системы, разные браузеры, устройства, версии API, то становится еще грустнее. Но тут важно понимать, что задача тестирования не в том, чтобы проверить вообще все, а в том, чтобы найти оптимальный баланс между покрытием и реальными рисками. Поэтому тестировать нужно не все подряд, а то, что действительно важно для бизнеса и пользователей. И такие ошибки я кстати часто вижу у новичков, которые заряженные стемятся проверить вообще все, даже если это не нужно. В данном случае нужно понимать, какие сценарии критичны, где чаще всего могут появится ошибки. И вот эти зоны сначала покрываются тестами максимально плотно. При этом никто не говорит, что редкие случае не надо тестировать, да, их тоже желательно проверить, но если на это нет времени, то можно пойти на осознанный риск и пропустить их. Еще один случай, который часто вижу, когда команда верит, что раз у них 90% покрытия автотестами, то все отлично. А потом выясняется, что эти 90% проверяют только хеппи-пас тесты или используют заходкоженные данные, которые уже давно не актуальны (как раз пару месяцев назад в одной из команд внезапно осознали, что почти год тестили на неактуальных данных автотестами). И как результат возникают ошибки на проде вроде в тех местах, где тесты были продены. Поэтому я за то, чтобы относиться к покрытию тестами не как к цели, а как к инструменту управления рисками. Нужно понимать, что ты покрыл, что сознательно не покрыл и какие последствия это может иметь. И главное, не аппелировать метрикой покрытия, а реально оценивать качество того, что проверяется. А как у вас ситуация? Частенько приходится объяснять другим подразделениям про то, как строится покрытие тестов? 👇 Все мои проекты: TG канал по тестированию AI | Курс по оценке и тестированию AI | Курс по тест-менеджменту | Youtube channel | Практика по тестированию | Платформа TestGrow | База знаний
Открыть канал и посмотреть медиаOnly registered users can share their opinion.
Be the first to share your impression of this resource!