Регрессионное тестирование — Средний уровень
Вы уже понимаете, что такое регрессионное тестирование. Теперь пора углубиться: как выбрать тесты, что делать с негативными сценариями, как работать с приоритетами и рисками. Это уровень тех, кто не просто тестирует, а управляет качеством.
В этой статье мы вместе разберём тест среднего уровня сложности. Вы узнаете, как принимать решения: что запускать, как формировать покрытие, какие факторы влияют на выбор данных. Каждое задание разложим по полочкам и научим думать, как системный тестировщик.
Эти навыки пригодятся вам на практике: в ежедневной работе и на собеседовании, когда нужно не просто «знать», а аргументировать.
Вопрос 1:
Чем отличается повторное тестирование (retest) от регрессионного тестирования?
1. Retest проводится для проверки всей системы, регрессионное - только для исправленного дефекта
2. Retest применяется только при ручном тестировании, регрессионное - только при автоматизированном
3. Оба теста полностью идентичны и проводятся одновременно
4. Retest направлен на проверку производительности, регрессионное - на стабильность интерфейса
5. Retest проверяет конкретный дефект после его исправления, а регрессионное - влияние изменений на уже работающий функционал
Объяснение:
Представь, что у тебя чайник потёк. Ты отнесла его в ремонт, тебе сказали — починили. И ты приходишь домой и включаешь именно этот чайник, чтобы проверить — починили ли именно эту проблему. Это и есть retest — проверка конкретной неисправности после её исправления.
А теперь вообрази, что ты не только проверила чайник, но и на всякий случай проверила стиральную машину, плиту и холодильник, чтобы убедиться, что ремонт чайника случайно ничего другого не поломал. Это уже регрессионное тестирование — убедиться, что в системе всё осталось стабильным после любых изменений.
Выбранный ответ:
Retest проверяет конкретный дефект после его исправления, а регрессионное — влияние изменений на уже работающий функционал
Вопрос 2:
Приведите пример того, как можно избежать излишнего разрастания объёма регрессионного тестирования на проекте.
1. Жестко ограничить проведение регресса по времени и проходить столько кейсов, сколько тестировщики будут успевать в отведенное время
2. Исключить из регресса базовый функционал системы, т.к. он и так многократно проверен
3. Не включать в регресс новый функционал предыдущих релизов, тестируя только базовую функциональность
4. Не включать в регресс тест-кейсы с уже исправленными дефектами
5. Каждый релиз проводить приоритизацию регрессионных тест-кейсов и включать в регресс только самые критичные
Объяснение:
Представь, что у тебя есть список дел на неделю, но с каждым днём ты добавляешь в него всё больше и больше — и в какой-то момент он превращается в монстра. То же самое бывает и с регрессией: если каждый раз без разбора добавлять тесты, регресс превратится в неподъёмную задачу.
Что помогает? Приоритизация.
Это как выделить дела, без которых неделя точно развалится (например, купить еду и оплатить квартиру), и сделать только их. В тестировании это означает: выбрать только самые критичные тесты, которые обязательно нужно запускать, и не пытаться протестировать абсолютно всё.
Выбранный ответ:
Каждый релиз проводить приоритизацию регрессионных тест-кейсов и включать в регресс только самые критичные
Вопрос 3:
Какой показатель помогает оценить эффективность регрессионного тестирования?
1. Количество тестировщиков в команде
3. Количество написанных тест-кейсов
4. Процент обнаруженных регрессионных дефектов
5. Время выполнения всех тестов
Объяснение:
Представь, ты каждую неделю проверяешь, всё ли дома работает: чайник, стиралка, утюг. Если ты всё это делаешь, а поломок почти не находишь — ты начинаешь думать: а стоит ли вообще тратить время? А если после каждой проверки ты всё-таки находишь проблемки, значит проверка полезная.
Так и в тестировании: если регрессионные тесты находят ошибки — они работают.
А если ошибок почти нет — возможно, ты проверяешь не то или слишком много лишнего.
- Количество тестеров или строк кода не отражает пользу.
- Количество тест-кейсов — не значит, что они нужные.
- Время выполнения — важно, но не про эффективность в смысле пользы.
Выбранный ответ:
Процент обнаруженных регрессионных дефектов
Вопрос 4:
Когда выполняется регрессионное тестирование в процессе жизненного цикла разработки программного обеспечения?
1. Во время проведения приемочного тестирования заказчиком
2. После внесения изменений в код и завершения тестирования новой функциональности
3. До начала разработки новой функциональности
4. До выполнения юнит-тестов разработчиком
5. Сразу после написания пользовательской документации
Объяснение:
Представь, ты наконец купила себе новое кухонное устройство. Установила его — всё работает. Но через неделю ты решила что-то улучшить и поменяла настройки. Теперь ты должна снова проверить, не сломалось ли что-то в старом. Так и в программной разработке: как только в код что-то добавили или поправили — сразу нужно проверить, что остальное всё по-прежнему работает.
Это и есть момент для регрессионного тестирования — сразу после внесения изменений, чтобы не было неприятных сюрпризов.
- До начала разработки и до юнит-тестов — ещё рано.
- Приёмка — уже поздновато.
- Документация — вообще не про тестирование.
Выбранный ответ:
После внесения изменений в код и завершения тестирования новой функциональности
Вопрос 5:
Почему регрессионное тестирование играет важную роль в гибких методологиях (Agile)?
1. Потому что регрессионное тестирование заменяет модульные тесты
2. Из-за частых изменений кода в коротких итерациях
3. Потому что в Agile нет документации
4. В Agile не проводят другие виды тестирования
5. В Agile регрессионное тестирование выполняют только вручную
Объяснение:
Представь, что ты делаешь ремонт на кухне по частям: сначала пол, потом стены, потом розетки, потом плиту. И каждый раз после нового этапа ты проверяешь, не сломалось ли то, что делала до этого. Именно так работает Agile — постоянные небольшие изменения в коде.
А если ты часто что-то меняешь — важно регулярно проверять старое, чтобы не потерять то, что уже хорошо работало. Именно из-за частых изменений в коротких итерациях регрессия становится незаменимой. Это как повторный контроль на каждом шаге.
- Agile не запрещает документацию и другие виды тестирования.
- Регрессионное не заменяет юнит-тесты и бывает автоматизированным.
Выбранный ответ:
Из-за частых изменений кода в коротких итерациях
Вопрос 6:
Чем отличается тестирование работоспособности (санитарное тестирование) и регрессионное тестирование?
1. Регрессионное тестирование обычно проводится на этапе модульного тестирования, санитарное - на этапе системного тестирования
2. Санитарное тестирование необходимо для ретеста уже исправленных дефектов, регрессионное тестирование - для оценки влияния изменений на основной функционал системы
3. Регрессионное тестирование не обязательно проводить, если проводится санитарное, так как санитарное тестирование включает в себя регрессионное
4. Санитарное и регрессионное тестирование выполняют одну и ту же функцию, а именно - проверка работоспособности не затронутого изменениями функционала
5. Санитарное тестирование необходимо для проверки работоспособности системы в целом после внесенных изменений, регрессионное тестирование - для выявления, не повлияли ли внесенные изменения на уже существующие части системы
Объяснение:
Представь, что ты включаешь все основные приборы на кухне просто чтобы убедиться — они вообще включаются: чайник кипятит, плита загорается, свет горит. Это быстро, поверхностно, но даёт общее ощущение, что всё работает. Это и есть санитарное тестирование — проверка, не «сломалась ли система совсем».
А регрессионное тестирование — это как взять каждый прибор и пройтись по всем режимам: кипятить до 100, кипятить до 80, включить таймер, проверить автоотключение. То есть — детальная проверка, повлияли ли изменения в коде на уже существующий функционал.
Остальные формулировки либо путаны, либо неверно объединяют оба типа тестов.
Выбранный ответ:
Санитарное тестирование необходимо для проверки работоспособности системы в целом после внесённых изменений, регрессионное тестирование — для выявления, не повлияли ли внесённые изменения на уже существующие части системы
Вопрос 7:
Нужно ли менять тестовые данные для тестов регрессионного тестирования?
1. В регрессионном тестировании не используются тестовые данные
2. Да, тестовые данные менять необходимо для предотвращения парадокса пестицида
3. Тестовые данные нужно менять, только если они относятся к синтетическим тестовым данным
4. Да, но только если речь идет о тестовых данных, которые не относятся к тест-кейсам, покрывающим критически важный функционал
5. Нет, тестовые данные должны оставаться теми же, для обеспечения консистентности тестирования из релиза в релиз
Объяснение:
Представь, ты проверяешь чайник каждую неделю, наливая в него одну и ту же кружку воды. И всё работает. Но если ты будешь делать только так, ты можешь не заметить, что он, скажем, перестаёт греть воду, если налить больше половины. Поэтому иногда полезно менять условия проверки, чтобы не привыкать к одной и той же проверке и не «ослепнуть».
Такой эффект в тестировании называется парадокс пестицида — когда одни и те же тесты перестают находить ошибки, потому что система к ним адаптировалась. Чтобы этого не случилось, тестовые данные периодически стоит менять.
Выбранный ответ:
Да, тестовые данные менять необходимо для предотвращения парадокса пестицида
Вопрос 8:
В каких случаях можно удалять тест-кейсы из объёма регрессионного тестирования?
1. Если этот тест-кейс не покрывает критичной функциональности и по нему давно не было дефектов
2. Если тест-кейс уже автоматизирован и его прохождение не является обязательным
3. Если тест-кейс не подходит для автоматизации и из объема регрессионного тестирования он переходит в ручное
4. Если тест-кейс проверяет критичную функциональность, но не находит дефектов
5. Если тест-кейс проверяет функциональность, которая уже была проверена ранее
Объяснение:
Допустим, у тебя есть список дел, которые ты проверяешь каждую неделю: почта, плита, стиралка, и ещё список розеток в доме. Если ты годами проверяешь какую-то розетку, и она ни разу не ломалась, да ещё и ей никто не пользуется — есть смысл вычеркнуть её из списка и не тратить время.
Так и в тестировании: если тест-кейс не проверяет ничего критичного, и ошибок по нему давно не было — его можно удалить из регресса. Это помогает сократить объём и сфокусироваться на действительно важном.
Выбранный ответ:
Если этот тест-кейс не покрывает критичной функциональности и по нему давно не было дефектов
Вопрос 9:
Могут ли разрабатываться специальные тест-кейсы для проведения регрессионного тестирования?
1. Да, весь объем регрессионного тестирования всегда составляется из специальных регрессионных тест-кейсов
2. Нет, объем регрессионных тестов формируется только из тест-кейсов, которые ранее применялись для тестирования нового функционала
3. Нет, так как это увеличивает затраты на проведение регрессионного тестирования
4. Нет, регрессионное тестирование проводится без использования тест-кейсов
5. Да, имеет смысл писать специальные тест-кейсы, чтобы покрыть весь критичный функционал системы
Объяснение:
Допустим, ты готовишься к проверке электрики в доме. У тебя уже есть список, по которому ты обычно идёшь: розетки, выключатели, светильники. Но вдруг ты решаешь: «А почему бы не сделать отдельный чек-лист только для тех точек, которые нельзя забыть ни при каких обстоятельствах?» — например, розетка, от которой питается холодильник.
Вот так же и с регрессионным тестированием: имеет смысл создавать отдельные тест-кейсы, чтобы покрыть весь критичный функционал, который нельзя упустить ни в одном релизе. Эти кейсы не просто повторяют старые, а именно создаются целенаправленно для защиты стабильности.
Выбранный ответ:
Да, имеет смысл писать специальные тест-кейсы, чтобы покрыть весь критичный функционал системы
Вопрос 10:
В какой из следующих ситуаций можно отказаться от запуска регрессионного тестирования без серьёзного ущерба для качества продукта?
1. Если ожидается, что пользователи сами сообщат о проблемах
2. Если вся команда занята тестированием новой функциональности
3. Если были внесены только текстовые правки в интерфейс без изменения логики
4. Если в предыдущем релизе все регрессионные тесты прошли успешно
5. Если автоматические тесты запускались неделю назад и багов не выявили
Объяснение:
Допустим, ты редактируешь текст в документе — просто подправила заголовок, убрала лишнюю запятую. Ты ведь не станешь после этого перечитывать весь документ заново? Потому что логика и суть не поменялась, только внешний вид. Вот и в тестировании, если внесены только текстовые правки в интерфейс, а бизнес-логика не затронута, можно не запускать все регрессионные тесты заново — ничего функционального не изменилось.
Остальные варианты — слишком рискованные:
- Надеяться на пользователей — плохая идея.
- Команда занята — не оправдание.
- Успех в прошлом релизе не гарантирует успех сейчас.
- Неделя назад — уже может быть неактуально.
Выбранный ответ:
Если были внесены только текстовые правки в интерфейс без изменения логики
Вопрос 11:
Какой риск НЕ покрывает проведение регрессионного тестирования?
1. Риск возникновения дефектов в уже проверенном функционале
2. Риск возникновения дефектов, связанных с изменением инфраструктуры
3. Риск возникновения ложноположительных результатов автотестов
4. Риск возникновения дефектов, связанных с внесением изменений в код
5. Риск возникновения дефектов в основном функционале приложения
Объяснение:
Представь, ты регулярно проверяешь все бытовые приборы дома, чтобы убедиться — они работают после починки или замены чего-то. Это и есть регрессионное тестирование — проверка, что всё старое осталось в порядке после изменений.
Но если вдруг в доме поменяли проводку или поставили новый счётчик, и у тебя начались перебои с электричеством, твоя проверка чайника тут не поможет. Потому что это уже инфраструктура, а не сам прибор.
Также регрессионное тестирование не отвечает за ошибки в автотестах — если они сами глючат, это уже проблема настройки тестовой среды или самих тестов.
Выбранный ответ:
Риск возникновения дефектов, связанных с изменением инфраструктуры
На проекте, где ранее не было регрессионного тестирования, появилась задача его наладить. С чего следует начать подготовку регрессионного тестирования на проекте?
1. Составить список неисправленных дефектов
2. Подготовить тестовый стенд для регрессионного тестирования
3. Составить список тест-кейсов, покрывающих критический функционал
5. Развернуть фреймворк автотестирования
Объяснение:
Представь, ты только переехала в новый дом. Тебе говорят: «Теперь тебе нужно каждый месяц проверять, чтобы в доме всё работало — холодильник, плита, розетки». С чего ты начнёшь? Не с покупки отвёрток и даже не с ремонта, а с простого вопроса: что вообще в доме критично и должно работать всегда?
Также и в проекте: прежде чем готовить стенд, автотесты или документацию, надо понять — что важно. А это значит — составить список тест-кейсов, которые покрывают критический функционал. Без этого регресс просто не будет иметь смысла.
Выбранный ответ:
Составить список тест-кейсов, покрывающих критический функционал
Заключение
- принимать решения на основе приоритета и рисков;
- грамотно выбирать тестовые данные;
- включать в план неочевидные, но важные проверки.
Вы уже не просто исполняете тест-кейсы — вы формируете стратегию. Это шаг к позиции middle-инженера, а дальше — к ведущему специалисту по качеству. Осталось закрепить — и двигаться дальше.