Цели и семь принципов тестирования
Вы уже знаете, что QA — это не просто поиск багов, а проактивная работа над качеством. Вы понимаете, как QA встроен в жизненный цикл разработки, как работает в Agile-командах, и уже освоили ключевые soft skills — особенно аналитическое мышление и коммуникацию. Эти навыки — ваш фундамент.
Теперь пришло время поднять планку. Мы переходим к самому сердцу профессии: к целям и фундаментальным принципам тестирования.
Эти принципы — не абстрактная теория. Это правила, по которым живёт каждый QA-инженер. Они объясняют, почему мы тестируем так, а не иначе. Почему не тестируем всё подряд. Почему даже идеальное тестирование не гарантирует, что в продукте нет ошибок.
Понимание этих принципов — признак профессионала. Их спрашивают на 90% собеседований. И если вы сможете чётко и уверенно рассказать о них — это сразу выделит вас среди других кандидатов.
Давайте разбираться.
Цели тестирования: зачем вообще тестируют ПО?
Многие думают, что цель тестирования — найти как можно больше багов. Это распространённое заблуждение.
На самом деле тестирование — это процесс оценки качества программного обеспечения. Его цели шире и глубже:
-
Оценка соответствия требованиям
Проверяем, делает ли система то, что от неё ожидают. Работает ли кнопка «Оплатить»? Сохраняются ли данные? Появляется ли уведомление об ошибке при неверном пароле? -
Предотвращение дефектов
QA участвует в анализе требований, предлагает улучшения, задаёт уточняющие вопросы. Чем раньше найдена проблема — тем дешевле её исправить. -
Обеспечение уверенности в качестве
Мы не можем доказать, что в системе нет ошибок. Но можем дать команде и бизнесу уверенность: «Мы протестировали ключевые сценарии, риски оценены, продукт готов к релизу».
💡 Важно: тестирование не улучшает качество само по себе. Оно выявляет проблемы, а улучшает качество — вся команда, исправляя их.
Семь принципов тестирования: правила игры
Эти принципы — общепринятый стандарт в отрасли. Они описаны в международных стандартах (например, ISTQB) и подтверждены десятилетиями практики.
Давайте разберём каждый — с примерами из реальной работы.
1. Тестирование показывает наличие дефектов, но не их отсутствие
Самый важный и часто непонятый принцип.
Что это значит:
Если мы нашли баг — значит, он был. Если не нашли — это не значит, что его нет.
Тестирование — это как медицинский осмотр: если врач нашёл болезнь — она есть. Если не нашёл — это не значит, что вы здоровы.
Пример из практики:
Команда протестировала форму регистрации, всё работает. Запустили в продакшен. Через день приходит жалоба: при вводе имени с апострофом (например, O’Neil) приложение падает.
Баг был, но его просто не нашли.
🛑 Ошибка новичка: «Я всё протестировал — багов нет».
✅ Правильно: «Я протестировал ключевые сценарии, критичных багов не обнаружено, но 100% гарантии быть не может».
2. Исчерпывающее тестирование невозможно
Мы не можем проверить все возможные комбинации данных, действий, устройств и условий.
Даже простая форма входа с двумя полями (логин и пароль) может иметь миллионы вариантов ввода.
Что делать?
Использовать техники тест-дизайна, которые мы изучим позже — например, эквивалентное разбиение и анализ граничных значений. Они позволяют сократить количество тестов, сохранив качество покрытия.
Пример:
Поле «Возраст» принимает значения от 1 до 120.
- Тестировать все 120 значений? Нет.
- Достаточно проверить: 0 (ошибка), 1 (минимум), 50 (середина), 120 (максимум), 121 (ошибка).
Это эффективнее и логичнее.
3. Раннее тестирование
Чем раньше начинается тестирование — тем дешевле и проще исправлять ошибки.
Идеальный сценарий: QA подключается ещё на этапе анализа требований.
Пример:
Разработчики начали писать код по ТЗ, где сказано: «Пользователь может редактировать профиль».
QA задаёт вопрос: «А кто и когда может редактировать? Только владелец? Админ?»
Оказалось — в требованиях не прописано.
Если бы QA не задал вопрос — функция была бы реализована не так, как нужно. А исправлять — дороже.
💬 Это прямая связь с вашим аналитическим мышлением — вы уже знаете, как задавать правильные вопросы.
4. Параллелизм тестирования и разработки
Тестирование не ждёт окончания разработки. Оно идёт параллельно.
В Agile-командах (которые вы уже изучили) тестирование начинается сразу после постановки задачи.
Пример:
Разработчик начал писать API для регистрации.
QA уже создаёт тест-кейсы, проверяет спецификацию, готовит тестовые данные.
Когда API готов — тесты уже почти готовы к запуску.
Это ускоряет процесс и снижает риски.
5. Дефекты скапливаются в определённых областях
Баги редко распределены равномерно. Обычно они концентрируются в сложных, часто меняющихся или плохо протестированных модулях.
Пример:
Интеграция с платёжной системой — сложная зона. Там много условий: разные валюты, статусы платежей, ошибки сети.
Если в этом модуле уже были баги — стоит уделять ему больше внимания.
Что делать?
Фокусироваться на риск-ориентированном тестировании. Тратить больше времени на высокорисковые зоны.
6. Парадокс пестицида
Если вы всё время запускаете одни и те же тесты — со временем они перестают находить новые баги.
Как насекомые привыкают к пестициду, так и система «привыкает» к вашим тестам.
Что делать?
Регулярно обновлять и дополнять тестовые сценарии. Добавлять новые данные, условия, сценарии использования.
Пример:
Вы тестировали поиск по названию товара — всё работает.
Но не пробовали искать с опечатками, с лишними пробелами, с символами.
Новые тесты — новые баги.
7. Тестирование зависит от контекста
Нет универсального подхода. То, что работает в одном проекте — не подойдёт в другом.
Примеры:
- В банковском приложении критичны безопасность и точность расчётов.
- В мобильной игре — производительность и удобство интерфейса.
- В стартапе — скорость выхода на рынок, можно жертвовать полнотой тестирования.
- В государственном сервисе — полное покрытие и документирование.
🌍 Российская специфика: в локальных компаниях часто не хватает времени на тестирование. Но понимание контекста позволяет QA аргументировать: «Да, мы можем сократить тестирование, но вот эти три сценария — обязательно».
Как применять эти принципы на практике?
Эти принципы — не просто знание. Это инструменты для принятия решений.
Вот как они помогут вам на работе:
| Принцип | Как применять |
|---|---|
| Раннее тестирование | Участвуйте в планировании спринта, читайте ТЗ до разработки |
| Парадокс пестицида | Регулярно пересматривайте тест-кейсы, добавляйте новые сценарии |
| Тестирование зависит от контекста | Перед началом тестирования спрашивайте: «Что для этого проекта критично?» |
| Дефекты скапливаются | Уделяйте больше внимания модулям с историей багов |
💬 Ваши soft skills — особенно аналитика и коммуникация — позволяют вам видеть, где и как применять эти принципы. Вы не просто выполняете тесты — вы думаете.
Что дальше?
Теперь вы понимаете, зачем мы тестируем и по каким правилам это делается.
Но как выбрать, что именно тестировать?
Функциональность? Производительность? Безопасность?
В следующей теме — Виды тестирования: функциональное, регрессионное, нефункциональное — мы разберём, какие бывают направления тестирования, когда и зачем их применяют.
Вы научитесь выбирать нужный вид тестирования под конкретный контекст — и это будет уже не просто работа, а осознанная стратегия.
Готовы? Поехали.