Ответ
Фундаментальные принципы тестирования — это семь аксиом, сформулированных в стандартах ISTQB/ISO, которые описывают суть и ограничения процесса тестирования. Их понимание критично для построения эффективной стратегии QA.
Список принципов с пояснениями:
-
Тестирование демонстрирует наличие дефектов, а не их отсутствие.
- Почему: Мы можем найти много багов, но никогда не сможем доказать, что их не осталось. Цель — снизить риск наличия критичных дефектов до приемлемого уровня, а не достичь "нулевого бага".
-
Исчерпывающее тестирование невозможно.
- Почему: Количество комбинаций входных данных, путей выполнения и состояний системы астрономически велико. Нужно применять техники анализа рисков и определения приоритетов (например, тест-дизайн на основе классов эквивалентности и граничных значений) для тестирования самого важного.
- Пример: Для поля "возраст" от 18 до 65 достаточно проверить значения 17, 18, 19, 64, 65, 66, а не все 48 чисел.
-
Раннее тестирование.
- Почему: Стоимость исправления дефекта растёт экспоненциально со временем его нахождения. Баг в требованиях, найденный на этапе код-ревью, исправить в 10-100 раз дешевле, чем тот же баг, найденный пользователем в продакшене.
- Практика: Внедрение статического тестирования (ревью требований, архитектуры, кода) и написание тестов параллельно с разработкой (TDD).
-
Кластеризация дефектов (Defect Clustering).
- Почему: Дефекты часто распределены неравномерно. Небольшое количество модулей ("сложных" или часто изменяемых) обычно содержит большинство проблем. Это следствие принципа Парето (20% модулей → 80% багов).
- Практика: Фокусировка тестовых усилий на модулях с высокой цикломатической сложностью, частыми изменениями или историей сбоев.
-
Парадокс пестицида (Pesticide Paradox).
- Почему: Если постоянно выполнять один и тот же набор тестов, они перестанут находить новые дефекты, так как система к ним "иммунизируется".
- Практика: Регулярный анализ и актуализация тестового набора: удаление устаревших тестов, добавление новых (исследовательское тестирование, тесты на новые сценарии), изменение данных и параметров.
-
Тестирование зависит от контекста (Testing is context dependent).
- Почему: Подходы к тестированию интернет-банка (безопасность, точность) и мобильной игры (производительность, UX) кардинально различаются. Нет универсального "лучшего" метода.
- Практика: Выбор методологии (Agile, V-Model), типов тестов (нагрузочные, security) и инструментов должен основываться на домене продукта, рисках и бизнес-требованиях.
-
Заблуждение об отсутствии ошибок (Absence-of-errors fallacy).
- Почему: Безупречно работающая с технической точки зрения система может быть бесполезной, если не соответствует потребностям пользователя или бизнес-целям.
- Практика: Тестирование должно включать валидацию ("строим ли мы правильный продукт?") наравне с верификацией ("строим ли мы продукт правильно?"). Фокус на user stories, usability и соответствие требованиям заказчика.
Ответ 18+ 🔞
А, слушай, смотри, эти ваши фундаментальные принципы тестирования! Семь штук, блядь, как семь смертных грехов, только для тестировщиков. ISTQB их выдумал, чтобы мы, распиздяи, головой думали, а не просто кнопки тыкали. Ёпта, сейчас разжую, как есть.
Вот они, эти аксиомы, в которых вся наша жизнь:
-
Тестирование показывает, что баги ЕСТЬ, а не что их НЕТ.
- В чём прикол: Мы можем найти овердохуища косяков, но доказать, что их вообще не осталось — это, блядь, как доказать, что Деда Мороза нет. Невозможно! Задача — не сделать идеально, а сделать так, чтобы риск пиздеца был приемлемым. Нашли критичный баг — молодцы. Не нашли — ну, может, повезло, а может, просто плохо искали.
-
Протестировать всё — это пиздец какая утопия.
- Почему: Да потому что комбинаций — хуева туча! Представь одно поле "возраст". Можно, конечно, тупо вбивать 18, 19, 20... до 65. Но это же ебать как долго и тупо!
- Пример нормального подхода: Возраст от 18 до 65. Берем граничные значения: 17 (отказ), 18 (ок), 19 (ок), 64 (ок), 65 (ок), 66 (отказ). Всё, блядь! Шесть проверок вместо сорока восьми. Это и есть здравый смысл, а не выебистика.
-
Тестировать надо начинать РАНЬШЕ, чем тебе кажется.
- Почему: Потому что цена бага растёт, как на дрожжах. Косяк в ТЗ, найденный, пока программист только кофе пьёт, исправить — раз плюнуть. Этот же косяк, но найденный тётей Клавой в продакшене, обойдётся компании в хренову тучу денег и нервов. В 100 раз дороже, ёпта!
- Что делать: Лезь в требования, когда их пишут. Смотри код, пока его пишут. Не жди, пока всё свалят в одну кучу и скажут "тестируй".
-
Баги любят тусоваться кучками (Кластеризация дефектов).
- Почему: Это закон природы, блядь! Обычно 80% всех косяков сидит в 20% модулей. Где-то один модуль — просто рассадник говна, а другой — чистый, как слеза младенца.
- Практика: Ищи эти "проблемные" места. Где код сложный? Где его постоянно меняют? Где уже были падения? Вот туда и направляй всю свою ебаную мощь тестирования. Не распыляйся.
-
Парадокс пестицида (или "система привыкает к тестам").
- Почему: Если ты изо дня в день гоняешь одни и те же тесты, они перестают находить что-то новое. Система к ним "привыкает", как тараканы к отраве.
- Что делать: Не будь консервой, блядь! Пересматривай свои тесты. Старые и бесполезные — нахуй. Добавляй новые сценарии, меняй данные, походи по краям, поисследуй. Иначе просто будешь тратить время впустую.
-
Тестирование зависит от контекста. Нет одного рецепта на все случаи.
- Почему: Ты что будешь одинаково тестировать, я не знаю, военный шифровальщик и мобильную змейку? Да ни хуя! В первом случае — безопасность на первом месте, во втором — чтобы не лагало и было весело.
- Практика: Сначала пойми, ЧТО ты тестируешь, а потом уже выбирай, КАК. Инструменты, типы тестов, подходы — всё это подбирается под конкретную задачу. Нельзя тупо взять чек-лист с прошлого проекта и тыкать им везде.
-
Заблуждение: "Нет багов — значит, всё отлично".
- Почему: А вот это, блядь, самый коварный пункт! Можно сделать идеальный с технической точки зрения продукт, который нихуя не нужен пользователю. Ноль багов, но и ноль смысла.
- Что делать: Не забывай про валидацию. Задавай вопрос не только "Работает ли оно как задумано?" (верификация), но и "А то ли мы, сука, задумали?" (валидация). Соответствует ли это реальным хотелкам пользователя? Удобно ли? Решает ли их проблемы? Иначе получится шедевр в вакууме, который никому не упёрся.
Вот и вся философия, если без соплей. Понимаешь эти принципы — уже не просто кнопкодав, а думающий специалист. Не понимаешь — ну, что ж, удачи в бесконечном тыкании, пока начальство не спросит: "А нахуя мы тебе зарплату платим?".