← вся теориятеория к собесу · Теория тестирования

Виды тестирования

Функция «среднее по списку» из двух строк. На списке [1, 2, 3] возвращает 2.0 - тест зелёный. На пустом списке падает делением на ноль, на списке с текстом внутри - ошибкой типов, на пустом значении вместо списка - тоже падает. Один тест счастливого пути прошёл, три коротких проверки уронили функцию.

Стержень: зрелость тестировщика видна по негативным сценариям, а исследовательское тестирование - это работа по чартеру, а не хаотичные клики.

// Формулировки: «чем чёрный ящик отличается от белого?», «чем ретест отличается от регресса?», «что такое исследовательское тестирование?».

Позитив, негатив и оси классификации

Тот замер выше - это позитивный и негативные тесты. Позитивный проверяет, что система делает своё дело на правильных данных: счастливый путь. Негативный проверяет, что она делает с неправильными: пустой ввод, текст вместо числа, отсутствующее значение, обрыв сети. Три негативные проверки нашли три падения там, где позитивная показывала зелёное.

Именно негатив отличает зрелого тестировщика: система «работает» ровно до первой ошибки пользователя, а он ошибётся - вставит пробел, скопирует лишний знак, нажмёт кнопку дважды.

// Оси классификации складываются просто. Функциональное - что система делает (сходится ли поведение с требованиями), нефункциональное - как: быстро ли, надёжно ли, безопасно ли, удобно ли. По объёму знаний о внутренностях - чёрный ящик (тесты пишутся от спецификации, то есть от документа с требованиями, а код при этом не виден), белый (тесты от кода и его ветвей), серый (устройство видно частично, типично для проверки стыков).

негативный тест: проверка поведения на неправильном вводе или сбое
чёрный / белый ящик: тесты от спецификации / тесты от устройства кода

Статическое: находит то, что не выполнялось

У меня была функция отправки уведомлений с тремя ветками: письмо, сообщение на телефон, всё остальное. В ветке про телефон опечатка в названии поля - написано phon вместо phone. Я прогнал две ветки из трёх: зелено. Вызвал третью - падение с ошибкой «у объекта нет поля phon». Тест был бы честный и зелёный ровно до дня, когда кто-то отправит сообщение на телефон.

А теперь то же самое без запуска: разбор текста программы занял 0,19 миллисекунды и сразу выдал список полей, к которым обращается код: email, phon. Опечатка видна глазами, ничего запускать не пришлось. Это статическое тестирование - поиск дефектов без выполнения кода: ревью требований и кода, автоматические анализаторы. Динамическое - это уже с выполнением: прогон кейсов, исследовательские сессии.

// Дефекты, найденные статикой, самые дешёвые: их ловят до того, как написан код, собрана сборка и потрачено время на прогон. Поэтому ревью требований - в буквальном смысле самый выгодный вид тестирования, а строчку «прочитать спецификацию» из плана убирают первой и зря.

статическое тестирование: поиск дефектов без запуска: ревью и анализаторы кода
динамическое тестирование: поиск дефектов через выполнение программы

Ретест и регресс: разница на живом примере

Пришёл баг: поиск не находит человека, если в имени затесался лишний пробел. Разработчик чинит одной строкой - обрезает пробелы по краям. Ретест: беру ровно тот сценарий, что падал, ввожу имя с пробелом, поиск находит. Баг закрыт, отчитались.

А я проверил соседние варианты того же ввода. Имя с невидимым знаком нулевой ширины на конце - такие приезжают при копировании из почты и мессенджеров - поиск падает: обрезание пробелов его не убирает, потому что формально это не пробел. Имя, где первая буква латинская A вместо русской А, - тоже падает. Правка закрыла один случай из трёх, и без проверки вокруг это выяснил бы пользователь.

// Вот и вся разница. Ретест - тот же самый сценарий, который падал: починили ли. Регресс - проверки вокруг изменённого места: не сломала ли починка соседнее и не осталась ли дыра рядом. Делать надо оба, и второй чаще забывают.

ретест: повтор ровно того сценария, который падал
регресс вокруг фикса: проверки соседних случаев и зависимой логики после правки

Исследовательское тестирование

Как я вообще догадался попробовать невидимый знак и латинскую букву? Не из спецификации - там написано «поиск по имени». Такие догадки даёт исследовательское тестирование: я одновременно изучаю продукт и проверяю его, и следующий шаг выбираю по тому, что увидел на предыдущем.

Это не хаотичные клики. У сессии есть чартер - записанная цель на 40-90 минут вроде «проверить поиск на грязных данных из внешних источников», есть тайм-бокс (жёсткие рамки по времени, чтобы не залипнуть), есть заметки по ходу и короткий вывод в конце. Тогда результат воспроизводим и его можно передать другому.

// Скриптованное тестирование по заранее написанным кейсам и исследовательское не конкуренты: первое даёт повторяемость и покрытие требований, второе находит то, что в кейсы не попало, потому что об этом никто не подумал. Сильные команды держат оба, а не выбирают.

исследовательское тестирование: изучение и проверка одновременно, следующий шаг - по увиденному
чартер: записанная цель сессии плюс рамка по времени

Как отвечать: «Чем ретест отличается от регрессионного тестирования?»

Это две разные проверки после исправления бага, и нужны обе. Ретест - подтверждение самого фикса: беру ровно тот сценарий, который падал, повторяю его на новой сборке, убеждаюсь, что баг закрыт. Регресс - проверка, что починка не наделала бед вокруг: тот же код мог задеть соседнюю логику. Разница отлично видна на живом случае. Был баг: поиск не находил имя с лишним пробелом. Починили обрезанием пробелов. Ретест прошёл. А проверка вокруг показала, что имя с невидимым знаком, который прилетает при копировании из почты, всё ещё роняет поиск, и имя с латинской буквой вместо русской тоже: правка закрыла один случай из трёх. Если бы я ограничился ретестом, оставшиеся два нашёл бы пользователь. Поэтому после ретеста я всегда прохожу зависимую область, а при частых релизах регресс автоматизирую, руками его просто не успеть. Коротко: ретест смотрит на починенное место, регресс - на всё, что могло от этой починки пострадать.

Почему это сильный ответ: оси разведены и подкреплены конкретным случаем, где ретест зелёный, а регресс вокруг находит два незакрытых варианта; названо, кто что смотрит и почему регресс уходит в автоматизацию.

На чём валят

−Проверять только счастливый путь: три негативных ввода уронили функцию, которая была зелёной.
−Называть исследовательское тестирование хаотичными кликами - без чартера и заметок результат невоспроизводим.
−Сделать ретест и не пройти вокруг: правка закрыла один случай из трёх, остальные найдёт пользователь.
−Выкидывать ревью требований и кода: самые дешёвые дефекты ловятся до запуска.
−Проверять во всех браузерах поровну, когда почти вся аудитория сидит в одном.

Проверьте себя

Пять вопросов из банка по этой подтеме. Всего их 12, остальные разбираются в тренажёре.

#types1 / 5
Что такое дымовое (smoke) тестирование и когда его проводят?
A)Исчерпывающая глубокая проверка всех функций и граничных случаев продукта перед его релизом
B)Быстрая поверхностная проверка ключевых функций после сборки: жив ли билд вообще
C)Проверка того, что старая функциональность не сломалась после внесения изменений в код
D)Нагрузочная проверка стабильности системы при длительной работе под предельной нагрузкой
показать ответ и разбор
+B)Быстрая поверхностная проверка ключевых функций после сборки: жив ли билд вообще
// разбор: Smoke-тестирование — короткий набор проверок самых важных функций, прогоняемый сразу после получения новой сборки. Цель — убедиться, что билд стабилен и пригоден для дальнейшего тестирования: запускается ли приложение, работают ли критичные пути (логин, основной сценарий). Если дым не прошёл, сборку заворачивают обратно разработчикам, не тратя время QA на глубокое тестирование заведомо сломанного билда. Название — из электроники («включили — задымилось или нет»). Часто smoke автоматизируют и вешают на каждый билд/деплой как быстрый барьер-фильтр перед основным прогоном.
#types2 / 5
Чем sanity-тестирование отличается от smoke?
A)Sanity проверяет весь билд целиком, а smoke — одну конкретную исправленную функцию
B)Это полные синонимы, обозначающие одну и ту же поверхностную проверку новой сборки продукта
C)Smoke — вширь «жив ли весь билд»; sanity — вглубь по конкретному фиксу или фиче
D)Sanity — это разновидность нагрузочного тестирования, а smoke относится к функциональному
показать ответ и разбор
+C)Smoke — вширь «жив ли весь билд»; sanity — вглубь по конкретному фиксу или фиче
// разбор: Оба — быстрые проверки, но с разным фокусом. Smoke широкий и мелкий: пробегает по ключевым функциям всего приложения, подтверждая, что сборка в принципе работоспособна. Sanity узкий и более глубокий: после точечного изменения (починили баг, добавили небольшую функцию) проверяет именно затронутую область — действительно ли фикс работает и не сломал ли очевидное рядом, — не прогоняя весь продукт. Грубо: smoke отвечает «стоит ли вообще тестировать этот билд», sanity — «имеет ли смысл углубляться в эту конкретную доработку». На практике границу иногда размывают, но фокус (вширь против вглубь по узкой области) — ключевое различие.
#types3 / 5
Зачем нужно регрессионное тестирование?
A)Проверить, что новая функция работает так, как описано в требованиях к ней
B)Убедиться, что исправленный дефект действительно устранён и больше не воспроизводится
C)Проверить поведение системы при экстремальной нагрузке и большом числе пользователей
D)Убедиться, что новые изменения не сломали ранее работавшую функциональность
показать ответ и разбор
+D)Убедиться, что новые изменения не сломали ранее работавшую функциональность
// разбор: Любое изменение кода — новая функция, исправление бага, рефакторинг — может непреднамеренно сломать то, что раньше работало (побочный эффект, регрессия). Регрессионное тестирование перепрогоняет ранее пройденные проверки на затронутых и связанных участках, чтобы поймать такие поломки. Это одна из самых частых и объёмных активностей, поэтому её обычно автоматизируют: ручной прогон всей регрессии на каждый релиз слишком дорог и медленен. Регрессию приоритизируют по риску (что критично и что вероятнее задето изменением), потому что гонять весь набор каждый раз часто нереально по времени.
#types4 / 5
Чем re-test (повторное тестирование) отличается от регрессионного тестирования?
A)Re-test проверяет, что сам баг устранён; регресс — что фикс не сломал другое
B)Это синонимы: и re-test, и регрессия означают повторный прогон одних и тех же тест-кейсов
C)Re-test проверяет побочные эффекты фикса, а регрессия — что сам исправленный баг исчез
D)Re-test выполняют до исправления дефекта, а регрессию — вместо его повторной проверки
показать ответ и разбор
+A)Re-test проверяет, что сам баг устранён; регресс — что фикс не сломал другое
// разбор: После того как разработчик починил дефект, тестировщик делает две разные вещи. Re-test (confirmation testing): повторить ровно те шаги из баг-репорта, что раньше приводили к ошибке, и убедиться, что теперь дефекта нет — подтверждение фикса. Регрессия: проверить, что это исправление не создало побочных поломок в связанных местах, которые раньше работали. Re-test всегда идёт по конкретному воспроизведению бага и обязателен для каждого фикса; регрессия шире и покрывает окружение изменения. Пропустить регрессию после «мелкого» фикса — классическая причина того, что починка одного ломает другое.
#types5 / 5
Чем различаются тестирование чёрного, белого и серого ящика?
A)Чёрный ящик тестирует код изнутри, а белый — внешнее поведение без доступа к коду
B)Чёрный ящик — по поведению без кода; белый — по коду; серый — частичное знание устройства
C)Различие в цвете интерфейса приложения, которое проверяет тестировщик по макету
D)Серый ящик означает тестирование вообще без каких-либо требований и знаний о системе
показать ответ и разбор
+B)Чёрный ящик — по поведению без кода; белый — по коду; серый — частичное знание устройства
// разбор: Классификация по уровню знания о внутреннем устройстве. Чёрный ящик: тестировщик знает только требования и внешнее поведение (вход→выход), код не видит — так проверяют функции с позиции пользователя (техники: классы эквивалентности, граничные значения). Белый ящик: доступна внутренняя структура и код, тесты строят по путям выполнения, ветвлениям, покрытию — типично для unit-тестов, пишет разработчик. Серый ящик — промежуточный: частичное знание внутреннего устройства (схема БД, архитектура, API-контракты) при проверке снаружи, что помогает точнее целить тесты. Уровень доступа определяет применимые техники дизайна тестов.

дальше

Теорию прочитали. Навык ставится повторением

В Сеньорчике эта подтема идёт в ежедневных сессиях: движок возвращает её, пока ответы не станут уверенными, и ведёт прогресс отдельно по каждой подтеме. Теория внутри тоже бесплатна, лимит только на количество вопросов в день.

Открыть тренажёр Вся тема: Теория тестирования