Ответ
Фундаментальная теория тестирования — это набор базовых принципов, которые лежат в основе процесса тестирования ПО. Она включает 7 ключевых аспектов:
- Тестирование показывает наличие дефектов, но не их отсутствие. Мы можем доказать, что баги есть, но не можем гарантировать их полное отсутствие.
- Исчерпывающее тестирование невозможно. Из-за ограничений по времени, бюджету и бесконечного числа комбинаций входных данных мы всегда тестируем выборочно.
- Раннее тестирование. Вовлечение QA-инженеров на этапах анализа требований и дизайна позволяет выявлять дефекты дешевле и быстрее.
- Кластеризация дефектов. Опыт показывает, что большинство багов сосредоточено в небольшом количестве модулей (например, в модуле оплаты или интеграции со сторонним API).
- Парадокс пестицида. Если повторять одни и те же тест-кейсы, они со временем перестают находить новые дефекты. Необходимо регулярно ревьюить и обновлять тестовое покрытие.
- Тестирование зависит от контекста. Подходы к тестированию банковского приложения, мобильной игры или медицинского устройства будут кардинально различаться.
- Заблуждение об отсутствии ошибок. Продукт может не иметь критических багов, но при этом не соответствовать ожиданиям пользователей или бизнес-требованиям.
Пример из практики: В одном из моих проектов мы обнаружили 8 критических дефектов в модуле импорта данных. Согласно принципу кластеризации, мы сфокусировали усилия на углубленном исследовательском тестировании этого модуля и нашли еще 15 проблем разной степени серьезности, в то время как другие, более стабильные модули, проверялись по регрессионному чек-листу.
Ответ 18+ 🔞
Да ладно, тебе эти фундаментальные принципы тестирования рассказывать — всё равно что слона учить на хуй сосать. Но раз уж начал, слушай сюда, как оно на самом деле работает, без этой академической пыли в глазах.
Ну вот смотри, первый принцип — тестирование показывает, что баги есть, но не доказывает, что их нет. Это, блядь, основа основ. Ты можешь неделю гонять тесты, всё зелёное, и думаешь — ну всё, красота, релизимся. А потом выходит пользователь, делает какую-то ебанутую хуйню, которую тебе в голову не пришло проверить, и всё, приехали. Мы — не боги, мы не можем гарантировать, что всё идеально. Мы можем только сказать: «Вот тут, сука, мы нашли косяки». А что ещё спрятано — хуй его знает. Доверия к этому — ноль, ебать.
Второй — исчерпывающее тестирование невозможно. Это вообще, ёпта, чистая правда. Представь, у тебя одно поле «Имя». Кажется, ну что там тестировать? А нихуя. Пустая строка, пробелы, кириллица, иероглифы, скрипт-инъекция, миллион символов… А если таких полей десять? Комбинаций — овердохуища. Поэтому мы всегда тыкаем пальцем в небо, только стараемся тыкать умно, в самые больные места.
Третий — раннее тестирование. Это когда умный тестировщик не ждёт, пока программисты всё напишут и скажут «на, тести». Нет, он лезет в требования ещё на стадии, когда их рисуют на салфетке, и орёт: «Мудаки, вы тут написали „сумма к оплате“, а что, если она отрицательная? Как система должна реагировать?». На этом этапе пофиксить дешевле в сто раз, чем когда всё уже закодировано. Кто этого не понимает — тот, извини, полупидор.
Четвёртый — кластеризация дефектов. О, это моя любимая тема. Опытным путём доказано: баги — они как тараканы. Не найдёшь одного — ищи гнездо. Обычно всё самое сочное валяется в самых сложных или самых кривых модулях. У меня был проект, модуль оплаты. Там, блядь, сначала два критика нашли. Я почуял — пахнет жареным. Сказал: «Всё, ребята, остальное по регрессу гоняйте, а я с этим модулем сейчас разберусь по-взрослому». И что ты думаешь? Выкопал ещё пятнадцать косяков, от мелких до таких, что волосы дыбом. А в других местах — тишь да гладь. Баги любят тусоваться кучками, хитрая жопа.
Пятый — парадокс пестицида. Если ты будешь из раза в раз запускать одни и те же тесты, они перестанут находить новое. Система к ним привыкает, как бактерии к антибиотику. Поэтому надо постоянно свои чек-листы и автотесты пересматривать, дополнять, менять данные. Иначе будешь как дурак, который тычет в одну точку и удивляется, что ничего не происходит.
Шестой — тестирование зависит от контекста. Это же, ёпта, очевидно! Ты не будешь тестировать игру-стрелялку так же, как систему для перевода денег в банке. В игре можно допустить падение фпс или вылет, главное — чтобы было весело. А в банковском приложении каждая копейка должна сходиться, и безопасность — на первом месте. Подход — разный, как небо и земля.
Седьмой — заблуждение об отсутствии ошибок. Это когда менеджер радостно кричит: «У нас ноль критических багов в бэклоге! Можно релизить!». А ты такой: «Постой, а продукт-то вообще нужное дело делает? Пользователь сможет им воспользоваться без инструкции на трёх листах?». Может быть, всё работает как часы, но интерфейс такой, что хоть волком вой. Или функционал не закрывает главную боль клиента. Нет багов — не значит, что продукт хорош. Это важно, как божья заповедь.
Вот тебе живой пример, как это работает: В одном проекте у нас модуль импорта данных из CSV-файлов был просто пиздец. Нашли сначала 8 критических дефектов — файл не грузится, данные криво парсятся, всё падает. По принципу кластеризации (четвёртый пункт, если что) мы на него всё внимание и бросили. Забили хуй на глубокий тест других модулей, оставили только базовый регресс. И пошли ковырять этот импорт вдоль и поперёк, исследовательским тестированием. И, ядрёна вошь, выкопали ещё 15 проблем! Одни — просто мелкие неудобства, другие — такие, что могли тихо запороть отчётность за полгода. А в других, более старых и отполированных модулях, за тот же срок — тишина, одна-две мелочи. Вот так теория в жизнь превращается.
