Logo
TGCATALOG
Каталог Подборки Блог
TestGrow - тестирование ПО

TestGrow - тестирование ПО

Канал платформы по тестированию ПО. Материалы для тестировщиков.

Нет оценок
329
25.10.2026
329
25.10.2026
Нет оценок
329
25.10.2026
Безопасный переход через бот
О канале

Канал платформы по тестированию ПО. Материалы для тестировщиков.

Подписчиков 5,246
Тематика Технологии
Язык Русский
Ссылка t.me/QAtestgrow

Также рекомендуем

Kekaton AI | Озвучка и клон голоса
Kekaton AI | Озвучка и клон голоса
Бот

AI бот для озвучки текста и клонирования голоса в Telegram. Создавай аудио с помощью нейросети быстро и просто.

Описание

Ресурс платформы TestGrow по тестированию софта. Полезные материалы и советы для QA специалистов.

Последние посты

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

Отзывы о канале TestGrow - тестирование ПО

Авторизуйтесь, чтобы оставить отзыв

Только зарегистрированные пользователи могут делиться своим мнением.

Пока нет отзывов

Станьте первым, кто поделится своим впечатлением об этом ресурсе!

Похожие ресурсы

Loading
Переход на светлую тему
Главная Каталог Подборки Блог Вход