Хитрости функционального тестирования: думаем на два шага вперёд
Представь, что у тебя сложная система с кучей взаимосвязанных частей. Нужно проверить, что после очередной правки работает всё, что должно, и не появилось скрытых ошибок. Это уже не просто проверка кнопок, а настоящая охота на баги.
В этой статье пошагово разберём тестовое задание продвинутого уровня, где вопросы сложнее и ближе к реальной работе мидла или даже тимлида. Объясним каждый момент так, чтобы ты смог подготовиться к «боевым» задачам в проекте или сложным собеседованиям.
Вопрос 1. Проект находится на этапе компонентного тестирования. Тестировщику поставлена задача проверить работу модулей A и B. Что именно ему необходимо проверить?
1. Задача поставлена некорректно. Работа отдельных модулей системы должна проверяться на этапе системного тестирования.
2. Корректность выполнения в системе бизнес-процессов, в работе которых задействованы данные модули
3. Корректность работы указанных модулей, а также интеграцию этих модулей с внешними сервисами и системами
4. Корректность работы указанных модулей, а также интеграцию между ними
5. Только корректность работы указанных модулей
Компонентное тестирование (или модульное) — это проверка работы отдельных модулей в изоляции.
Здесь ещё не проверяют, как модуль стыкуется с другими модулями (это уже интеграция) и не тестируют бизнес-процессы целиком (это системное тестирование).
1. «Задача поставлена некорректно...» — это неправильно. Проверка отдельных модулей и есть задача компонентного тестирования. Здесь наоборот, задача поставлена корректно.
2. «Корректность выполнения в системе бизнес-процессов...» — это уже уровень системного тестирования. Не подходит.
3. «Корректность работы указанных модулей, а также интеграцию этих модулей с внешними сервисами...» — это интеграционное тестирование, тоже не компонентное.
4. «Корректность работы указанных модулей, а также интеграцию между ними» — опять интеграция, не подходит для компонентного уровня.
5. «Только корректность работы указанных модулей» — вот это ровно то, что нужно на этапе компонентного тестирования.
«На этом этапе мы смотрим, правильно ли работает каждый модуль по отдельности, не как они вместе работают.»
Выбранный ответ: Только корректность работы указанных модулей.
Вопрос 2. В каком случае целесообразно использовать метод тестирования серого ящика?
1. Когда нет необходимости в тестировании безопасности
2. Когда требуется проверить выполнение операторов в коде
3. Когда тестировщик не имеет доступа к проектной документации
4. Когда необходимо проверить уязвимости системы, имея доступ к внутренним данным и логике
5. Когда проект находится на начальной стадии разработки
Серый ящик (gray-box) — это когда тестировщик знает внутренние структуры или данные, но не весь исходный код. Обычно используется для:
· анализа работы программы с учётом известной архитектуры или схем баз данных.
1. «Когда нет необходимости в тестировании безопасности» — не подходит, наоборот, серый ящик часто берут для уязвимостей.
2. «Когда требуется проверить выполнение операторов в коде» — это чистый white-box, потому что нужен полный доступ к коду.
3. «Когда тестировщик не имеет доступа к проектной документации» — это скорее ситуация для black-box, он вообще ничего не знает.
4. «Когда необходимо проверить уязвимости системы, имея доступ к внутренним данным и логике» — вот это классика серого ящика: тестировщик знает структуры данных или схемы БД, но не весь код. Отличный ответ.
5. «Когда проект на начальной стадии разработки» — это вообще никак не связано с выбором black, gray или white-box.
«Серый ящик — это когда тебе чуть приоткрыли внутренности системы, чтобы искать уязвимости или ошибки, используя эту информацию.»
Выбранный ответ: Когда необходимо проверить уязвимости системы, имея доступ к внутренним данным и логике.
Вопрос 3. Вам поручили протестировать модуль выбора вариантов доставки, который активирует бесплатную доставку при покупке от 500 долларов. Какую технику тест-дизайна использовать, чтобы учесть все возможные комбинации условий?
4. Тестирование на основе рисков
5. Таблица переходов состояний
- учесть все возможные комбинации условий,
- условий у нас как минимум два: сумма заказа (до 500 и от 500) и тип доставки (платная/бесплатная).
- Таблицы решений (decision table), где записывают все комбинации входных условий и ожидаемый результат.
Попарное тестирование (pairwise) подходит, если у нас много параметров, а тут всего два — таблица решений лучше для полного охвата.
Таблица переходов состояний — используется, когда важно тестировать последовательности переходов (например, логин → корзина → оплата).
Модульное тестирование — это уровень, а не техника выбора тестов.
Тестирование на основе рисков помогает приоритизировать, а не охватить ВСЕ комбинации.
«Мы рисуем таблицу, где по строкам — разные суммы заказа, а по столбцам — варианты доставки. И для каждой клеточки пишем, что должно произойти.»
Выбранный ответ: Таблица решений.
Вопрос 4. Какое тестирование, как правило, проводится на территории заказчика?
1. Интеграционное тестирование
2. Тестирование производительности
Приемочное тестирование (acceptance testing) часто проводится на стороне заказчика. Цель — убедиться, что ПО готово для использования в реальных условиях и отвечает их требованиям. Это может быть и на территории заказчика, и в их инфраструктуре.
Альфа-тестирование чаще всего у разработчика, иногда в их стенах вместе с заказчиком.
Бета-тестирование — у конечных пользователей.
Остальные (интеграционное, системное, производительность) обычно проводят в компании-разработчике.
«Приемочное тестирование — это когда заказчик сам проверяет у себя, что всё работает, и только потом соглашается платить деньги.»
Выбранный ответ: Приемочное тестирование.
Вопрос 5. Продолжите утверждение:
«Исчерпывающее тестирование…»
1. Нецелесообразно и невозможно
2. Целесообразно, но невозможно
3. Нецелесообразно, но возможно
4. Целесообразно и возможно только с использованием автоматизированного тестирования
5. Всегда целесообразно и возможно
Проверить все возможные комбинации входных данных, условий и сценариев просто нереально для любой, даже небольшой системы.
- По сути, это ещё и нецелесообразно. Если теоретически даже можно было бы это сделать, затраты на время и ресурсы были бы колоссальными, а пользы мало.
«Тестировать всё-всё-всё нельзя. Это дорого, бесконечно и глупо.»
Выбранный ответ: Нецелесообразно и невозможно.
Вопрос 6. Что из перечисленного является хорошей практикой применения дымового тестирования?
1. Проведение дымового тестирования каждой новой сборки ПО до передачи ее на следующие этапы тестирования
2. Проведение автоматизированного дымового тестирования вместо пользовательского приемочного тестирования
3. Проведение дымового тестирования только нового функционала
4. Проведение автоматизированного дымового тестирования вместо системного интеграционного тестирования
5. Проведение дымового тестирования после регрессионного тестирования
Дымовое тестирование (smoke testing) — это поверхностная проверка, чтобы понять, можно ли вообще запускать дальнейшие, более глубокие тесты.
Его главная задача — убедиться, что сборка в целом стабильна, и можно тратить время на детальные тесты.
1. «Проведение дымового тестирования каждой новой сборки ПО до передачи ее на следующие этапы тестирования» — это и есть textbook best practice. Убедились, что билд не падает при запуске, потом уже передаём на регрессию, функциональные и т.д.
2. «Вместо пользовательского приемочного» — грубейшая ошибка. Приемка — отдельная вещь.
3. «Только нового функционала» — дымовое всегда охватывает всю систему «по верхам».
4. «Вместо системного интеграционного» — тоже нет, дымовое предваряет эти тесты, а не заменяет.
5. «После регрессионного» — наоборот, перед ним.
«Дымовое тестирование — это быстрая проверка, что программа не развалилась, прежде чем тратить часы на подробные проверки.»
Выбранный ответ: Проведение дымового тестирования каждой новой сборки ПО до передачи ее на следующие этапы тестирования.
Вопрос 7. Какое из утверждений касательно объема тестирования верно?
1. Можно не тестировать то, что мы не успеваем тестировать
2. Можно не тестировать те области, где риски качества еще не были сформированы
3. Нужно обязательно выполнить все разработанные тесты
4. Не нужно тестировать те области, где эффект от тестирования не оправдывает затраты на него
5. Можно не тестировать то, за что не платит заказчик
Тестирование всегда ограничено временем, бюджетом и рисками.
Главная цель — оптимизация покрытия, а не «протестировать всё ради галочки».
Поэтому в практике часто применяют принцип:
«Не нужно тестировать там, где эффект от тестирования не оправдает затрат.»
- «Можно не тестировать то, что мы не успеваем» — это плохая практика, а не правило.
- «Можно не тестировать, где риски ещё не сформированы» — нет, потому что риски могут быть неизвестны, а баги там все равно критичны.
- «Нужно обязательно выполнить все разработанные тесты» — это вообще противоречит гибкому управлению качеством.
- «Не нужно тестировать те области, где эффект от тестирования не оправдывает затраты на него» — это классический принцип управления качеством по рискам и ROI (return on investment).
- «Можно не тестировать то, за что не платит заказчик» — некорректно и неэтично.
«Тестировать всё подряд глупо. Лучше проверить то, где баги могут сильно ударить по бизнесу.»
Выбранный ответ:
Не нужно тестировать те области, где эффект от тестирования не оправдывает затраты на него.
Вопрос 8. Что значит термин «отказ программного обеспечения»?
2. Событие, при котором компонент или система не соответствуют требованиям
3. Действие разработчика, которое привело к возникновению в программе дефекта
4. Дефект, обнаруженный тестировщиком во время тестирования программы
5. Дефект, обнаруженный в требованиях до перевода их в код
Терминология в ISTQB (и вообще в теории тестирования) четко различает:
- Ошибка (error) — это действие человека (например, программист ошибся в коде).
- Дефект (defect, bug) — это ошибка в коде программы.
- Отказ (failure) — это когда программа уже в работе (во время выполнения) не соответствует ожиданиям или требованиям, т.е. проявляется дефект.
«Отказ — это событие, когда программа ведет себя неправильно в процессе работы.»
- «Ошибка в коде программы» — это дефект (bug).
- «Событие, при котором компонент или система не соответствуют требованиям» — точно описывает отказ в работе ПО.
- «Действие разработчика» — это ошибка (human error), но не отказ.
- «Дефект, обнаруженный тестировщиком» — это тоже дефект, а не отказ.
- «Дефект в требованиях» — это ошибка в требованиях (requirements defect).
«Отказ — это когда программа сломалась прямо на глазах. А не просто ошибка в коде.»
Выбранный ответ:
Событие, при котором компонент или система не соответствуют требованиям.
Вопрос 9. Негативный тест проверяет, что приложение...
1. Корректно выполняет, что не должно выполнять
2. Заносит в лог требуемую информацию
3. Выдает корректные сообщения об ошибках во входных данных
4. Не делает того, что реализовал разработчик
5. При недопустимых входных данных выполняет не то, что должно выполнять
Негативное тестирование (negative testing) — это когда мы проверяем, как система справляется с неправильными, недопустимыми входами или условиями, и не выполняет того, что выполнять не должна.
По сути, мы пытаемся сломать систему, дать ей «плохие данные», и ждём, что она корректно откажет.
- «При недопустимых входных данных выполняет не то, что должно выполнять» — формулировка корявая, но смысл верный: мы специально подсовываем недопустимые данные, чтобы убедиться, что приложение не ведет себя как при нормальном вводе.
- «Корректно выполняет, что не должно выполнять» — логическая каша.
- «Заносит в лог» — это проверка логирования, не обязательно негативная.
- «Выдает сообщения об ошибках во входных данных» — частный случай негативного, но не общий.
- «Не делает того, что реализовал разработчик» — бессмысленно.
«Негативные тесты проверяют, что программа не глотает мусор и не делает то, чего не должна.»
Выбранный ответ:
При недопустимых входных данных выполняет не то, что должно выполнять.
Вопрос 10. Тестировщик получил новую версию продукта на тестирование. Какая информация ему НЕ нужна для проверки исправленных дефектов?
1. Описание шагов тестовых сценариев, ранее приводивших к появлению сбоя в программном продукте
3. Информация о том, какие функции системы могли быть затронуты при исправлении дефектов
4. Ожидаемый результат по каждому из тестовых сценариев
5. Информация о том, какие программные модули системы могли быть затронуты при исправлении дефектов
Когда тестировщик проверяет исправленные дефекты (то есть делает подтверждающее тестирование / retesting), ему важно знать:
- какие были дефекты (список багов),
- какие шаги их воспроизводят (чтобы проверить),
- какие ожидались результаты (чтобы сравнить с фактическим),
- и какие функции / модули могли быть затронуты — это помогает понять область, где может вылезти регрессия.
А вот какие функции и модули системы могли быть затронуты, наоборот, важны для регрессионного тестирования (проверить, что исправления не сломали что-то ещё). Для простой проверки исправленного бага это необязательная информация. Там важно только воспроизвести старый баг и убедиться, что он больше не проявляется.
«Когда мы проверяем, что баг исправили, нам нужно знать, что за баг был, как его вызвать и что должно получиться. А список всех функций, которые могут пострадать, больше нужен для другой задачи — для регрессии.»
Выбранный ответ:
Информация о том, какие функции системы могли быть затронуты при исправлении дефектов.
Вопрос 11. Какой вид тестирования планирует выполнить тестировщик при тестировании следующей версии?
- Тестировщик сначала повторяет те же сценарии (TC117, TC236, TC92), которые ранее нашли баги, чтобы убедиться, что баги исправлены. Это и есть подтверждающее тестирование (retesting) — но в рамках терминологии задач часто включают это в регрессию.
- Затем он запускает остальные сценарии, чтобы проверить, что новая версия не сломала то, что уже работало. Это и есть классическое регрессионное тестирование.
- Тестирование сборки — это просто проверка, что билд собрался и вообще запускается (обычно smoke).
- Модульное и статическое — работают на уровне кода, а здесь уже готовая система.
- Дымовое тестирование — поверхностная проверка, что система в принципе работает (запускается, открываются формы).
- А здесь тестировщик проверяет именно, что исправленные баги больше не проявляются, и система в целом осталась стабильной — это и есть регрессионное тестирование.
«Он проверяет, что старые ошибки теперь исправлены и что в других местах ничего не сломалось. Это и есть регрессия — контроль, что после исправлений всё работает, как раньше.»
Выбранный ответ: Регрессионное тестирование.
Вопрос 12. Что из перечисленного может являться объектом пользовательского приемочного тестирования системы?
2. Поддержка бизнес-процессов полностью интегрированной системой
4. Проектная документация по системе
5. Интерфейсы взаимодействия между отдельными модулями системы
Пользовательское приемочное тестирование (UAT) — это когда заказчик или пользователи смотрят на систему в целом, чтобы понять: поддерживает ли она их реальные бизнес-процессы, для которых ее вообще заказывали.
Их не интересует, как устроена база данных, отдельные кнопки или как связаны модули между собой. Им важно: «Помогает ли система автоматизировать нашу работу так, как надо?»
- Базы данных, интерфейсы между модулями, отдельные функции — это более низкий уровень проверки (компонентное, интеграционное, системное тестирование).
- Проектная документация вообще не тестируется таким образом.
- А поддержка бизнес-процессов полностью интегрированной системой — это ровно то, что проверяют при приемочном тестировании.
«Приемочное тестирование — это как примерка костюма в ателье. Заказчик смотрит: удобно ли сидит, подходит ли по случаю. Он не проверяет отдельные нитки, швы или ткань, а смотрит — можно ли в этом идти на банкет. Так и тут: главное, выполняются ли наши бизнес-процессы.»
Выбранный ответ:
Поддержка бизнес-процессов полностью интегрированной системой.
Вопрос 13. В каком случае необходимо использовать матрицу трассировки требований?
1. Только если предыдущие сборки системы уже внедрены в эксплуатацию и у нас есть результаты предыдущих итераций тестирования
2. В случае, когда на проекте работает опытная команда тестирования
3. Если команда проекта работает по каскадной модели разработки ПО
4. Когда число тест-кейсов больше количества требований
5. Когда проект имеет высокую сложность и большое количество требований
Матрица трассировки требований (traceability matrix) — это таблица, в которой связывают каждое требование с соответствующими тест-кейсами.
Она нужна, чтобы убедиться: всё, что заказали, действительно протестировано, и наоборот — чтобы на тестирование не ушли силы на то, чего в требованиях нет.
Это как в большом списке покупок для стройки: ставишь галочки, что уже купил, чтобы не забыть и не купить два раза одно и то же.
- Неважно, работает команда по каскаду, Scrum или Kanban.
- Не имеет смысла только если тест-кейсов больше требований — это как раз показывает, что много тестов на одно требование (позитивные и негативные сценарии).
- Опыт команды здесь тоже не ключевой — даже опытные могут что-то упустить без матрицы.
- И это не связано с тем, что уже было внедрение.
«Матрица трассировки — это твой чек-лист для ремонта: чтобы проверить, все ли заказала и ничего не забыли. Чем больше у тебя дел и чем дороже ремонт — тем нужнее такой список.»
Выбранный ответ:
Когда проект имеет высокую сложность и большое количество требований.
Вопрос 14. Каким будет ожидаемый результат для сценария:
«Клиент имеет подарочный купон и совершил покупку на сумму 3 000»?
1. Клиент получает подарок и не получает скидки
2. Клиент получает скидку и не получает подарка
3. Клиент не получает подарка и получает скидку на будущую покупку
4. Таблица не имеет варианта решения для данного условия
5. Клиент получает и подарок, и скидку
1. Смотрим условия из сценария:
· Дата покупки совпадает с днем рождения → не сказано, значит Нет
· Совершена покупка на сумму 5 000 и более → Нет, т.к. только 3 000
2. Теперь ищем в таблице решений правила, которые совпадают:
Правило 1: купон — Да, день рождения — Да, сумма ≥5 000 — Да → нам не подходит
Правило 2: купон — Да, день рождения — Нет, сумма ≥5 000 — Да → тоже не подходит, сумма меньше
Правило 3: купон — Нет, день рождения — Нет, сумма ≥5 000 — Нет → тоже мимо, у нас есть купон
Правило 4: купон — Да, день рождения — Нет, сумма ≥5 000 — Нет → подходит идеально
3. Смотрим, какие действия при Правиле 4:
«Так как у клиента есть купон и он купил на сумму меньше 5 000, то по таблице решений он получает только скидку 10%, а подарка не будет.»
Выбранный ответ:
Клиент получает скидку и не получает подарка.
Вопрос 15. Расположите исполнителей по возрастанию уровня их независимости (объективности) при тестировании
Чем меньше человек вовлечен в разработку того, что он тестирует, тем более независим и объективен.
А чем сильнее он связан с кодом (например, сам писал), тем меньше независимости: он может что-то не заметить, потому что «глаз замылился».
Г. Разработчик — автор модуля
Наименее независим. Это его код, он к нему привык и может даже неосознанно оправдывать ошибки.
А. Разработчик компании, НЕ автор этого модуля (автор соседнего кода)
Чуть независимее. Но все же он в той же команде и косвенно вовлечен.
В. Тестировщик компании-разработчика
Ещё более независим — он вообще не писал код, его задача находить ошибки.
Б. Тестировщик сторонней компании (аутсорсер)
Самый независимый. Не связан интересами компании-разработчика, смотрит как внешний эксперт.
Вопрос 16. Во время проведения приёмочного тестирования представители заказчика используют функциональность системы для определения её пригодности. Какую активность они при этом выполняют?
2. Только исследовательское тестирование
3. Следование программе и методике испытаний
Верификация — это про то, правильно ли продукт реализован согласно спецификациям. Проверяют: «Мы построили систему правильно?»
Валидация — это про то, правильно ли продукт решает задачу пользователя. Проверяют: «Мы построили правильную систему?»
Когда заказчик проводит приёмочное тестирование, он смотрит: подходит ли система для его бизнес-задач и реально ли её можно использовать. Это классический пример валидации, потому что проверяется пригодность системы для конечного пользователя.
Вывод: Здесь выполняется только валидация.
Верификацию обычно делает разработчик или QA-команда на этапе раньше.
Выбранный ответ: Только валидацию
Вопрос 17. На каком этапе жизненного цикла разработки ПО тестировщику следует подключаться к процессу рецензирования проектной документации?
1. Ни на каком, рецензирование не относится к задачам тестировщика
2. Как только стала доступна самая первая версия целевого документа
3. Как только по целевому документу был разработан соответствующий ему модуль системы
4. Как только целевой документ принят и согласован заказчиком
5. Как только программный продукт успешно прошел приемо-сдаточные испытания
Тестировщики подключаются к проекту как можно раньше, чтобы:
Это позволяет сэкономить массу времени и денег, потому что ошибка, найденная на этапе написания требований, обходится в сотни раз дешевле, чем найденная после релиза.
Значит, тестировщик должен подключаться сразу, как только появилась первая версия целевого документа (например, ТЗ или спецификации).
Как только стала доступна самая первая версия целевого документа
Вопрос 18. Какой класс дефекта вы выберете?
2. Дефект отображения интерфейса
5. Дефект удобства использования
Ты тестируешь приложение, которое не реагирует на кнопку «Оформить заказ» только на некоторых устройствах.
Если бы не реагировало вообще, это скорее функциональный баг.
Но тут речь именно о том, что на разных устройствах ведёт себя по-разному.
Это означает проблему совместимости: приложение должно одинаково работать на всех поддерживаемых устройствах. А тут какая-то платформа или модель телефона вызывает сбой.
Чтобы объяснить это «по-простому», представь, что ты строишь детскую горку, которая подходит только для детей в зелёных ботинках. Для всех остальных она не работает. Так быть не должно — значит, проблема совместимости.
Выбранный ответ: Дефект совместимости
1. Разница между верификацией и валидацией
Вопрос мог звучать так: «Что делают заказчики на этапе приёмочного тестирования — верификацию или валидацию?»
Верификация (verification) = «строим продукт правильно» (проверяем, соответствует ли продукт спецификациям, документам).
Валидация (validation) = «строим правильный продукт» (подходит ли он пользователю, решает ли задачу).
На приёмке заказчик всегда выполняет валидацию (иногда дополнительно упоминается следование программе испытаний, но валидация — ключ).
2. Где нужно использовать матрицу трассировки требований
Например: «В каком случае необходимо использовать матрицу трассировки?»
Здесь скорее всего правильный ответ — когда проект сложный и требований много, чтобы не потерять связь «требование ↔ тест-кейс».
3. При какой ситуации делают регрессионное тестирование
Подвох: могли быть варианты типа «при передаче продукта в эксплуатацию» или «когда тест-кейсы Pass в обоих прогонах».
На деле регрессия = тестирование уже проверенного функционала, чтобы убедиться, что исправления не сломали старое.
4. Какой дефект — это кнопка «Оформить заказ» не реагирует на некоторых устройствах
Тут легко ошибиться между «дефект интерфейса» и «дефект совместимости».
Вероятно: дефект совместимости, потому что кнопка не реагирует на некоторых устройствах (значит на разных платформах / версиях ОС).
5. Когда подключать тестировщика к рецензированию документации
Подвох в том, что скорее всего правильным ответом является — «как только появилась самая первая версия документа», а не после согласования или реализации.
Заключение
Ты научишься видеть взаимосвязи в функционале и проверять программу не только «по чек-листу», но и с оглядкой на риски. Эти навыки помогут тебе стать сильнее в профессии и готовиться к позициям с большей ответственностью — например, старшего тестировщика или ведущего специалиста.