и посмотреть медиа
TestGrow - тестирование ПО
и посмотреть медиа
Канал платформы по тестированию ПО. Материалы для тестировщиков.
Канал платформы по тестированию ПО. Материалы для тестировщиков.
AI бот для озвучки текста и клонирования голоса в Telegram. Создавай аудио с помощью нейросети быстро и просто.
Ресурс платформы TestGrow по тестированию софта. Полезные материалы и советы для QA специалистов.
Немного мыслей про 100% покрытие всего и вся! Частенько слышу такие вопросы от бизнес-заказчиков, разработчиков, продуктов и многих других, типа, а можем ли мы покрыть все сценарии тестами, чтобы ну ж точно быть уверенными в качестве? И что интересно, частота таких вопросов как я заметил зависит еще и от того, как часто ошибки попадают на продуктив. Честно говоря, полное покрытие - это антиутопия, то есть в целом невозможно. Даже если просто посчитать для небольшой форме с 10 полями количество комбинаций входных данных стремится к бесконечности. А если добавить сюда состояния системы, разные браузеры, устройства, версии API, то становится еще грустнее. Но тут важно понимать, что задача тестирования не в том, чтобы проверить вообще все, а в том, чтобы найти оптимальный баланс между покрытием и реальными рисками. Поэтому тестировать нужно не все подряд, а то, что действительно важно для бизнеса и пользователей. И такие ошибки я кстати часто вижу у новичков, которые заряженные стемятся проверить вообще все, даже если это не нужно. В данном случае нужно понимать, какие сценарии критичны, где чаще всего могут появится ошибки. И вот эти зоны сначала покрываются тестами максимально плотно. При этом никто не говорит, что редкие случае не надо тестировать, да, их тоже желательно проверить, но если на это нет времени, то можно пойти на осознанный риск и пропустить их. Еще один случай, который часто вижу, когда команда верит, что раз у них 90% покрытия автотестами, то все отлично. А потом выясняется, что эти 90% проверяют только хеппи-пас тесты или используют заходкоженные данные, которые уже давно не актуальны (как раз пару месяцев назад в одной из команд внезапно осознали, что почти год тестили на неактуальных данных автотестами). И как результат возникают ошибки на проде вроде в тех местах, где тесты были продены. Поэтому я за то, чтобы относиться к покрытию тестами не как к цели, а как к инструменту управления рисками. Нужно понимать, что ты покрыл, что сознательно не покрыл и какие последствия это может иметь. И главное, не аппелировать метрикой покрытия, а реально оценивать качество того, что проверяется. А как у вас ситуация? Частенько приходится объяснять другим подразделениям про то, как строится покрытие тестов? 👇 Все мои проекты: TG канал по тестированию AI | Курс по оценке и тестированию AI | Курс по тест-менеджменту | Youtube channel | Практика по тестированию | Платформа TestGrow | База знаний
Открыть канал и посмотреть медиаТолько зарегистрированные пользователи могут делиться своим мнением.
Станьте первым, кто поделится своим впечатлением об этом ресурсе!