Функциональное тестирование для начинающих: учимся проверять, что программа делает, а не ломает
В этой статье мы простыми словами разберём, что такое функциональное тестирование. Представь, что ты проверяешь, закрывается ли дверь после того, как вставил ключ. То же самое делает тестировщик, только с программой — он проверяет, работает ли функция так, как задумано.
Мы шаг за шагом разберём тестовое задание базового уровня и объясним каждый вопрос. Это пригодится, если ты хочешь устроиться на первую IT-должность: даже джунам (начинающим) часто дают такие задачи на собеседованиях.
Вопрос 1. На каких уровнях может выполняться функциональное тестирование?
1. На всех уровнях, кроме приемочного тестирования
2. На завершающих уровнях проекта
3. На всех уровнях, кроме компонентного тестирования
4. На уровне системного тестирования
5. На всех уровнях тестирования
Функциональное тестирование проверяет, что делает система, то есть её функции — соответствуют ли они требованиям. При этом такие проверки можно делать на любом уровне:
Если говорить проще, тестировщики могут проверять функции «кусочков кода» отдельно (модуль), как эти кусочки работают вместе (интеграция), как работает вся система целиком (системное) и как это всё нравится заказчику (приёмочное).
Ответы вроде «на всех уровнях, кроме...» не подходят, потому что функциональное тестирование действительно используется на всех уровнях тестирования. Это и есть стандартная практика.
Выбранный ответ: На всех уровнях тестирования.
Вопрос 2. К какому методу относится функциональное тестирование на основе бизнес-требований?
1. Тестирование методом предугадывания ошибок
2. Тестирование на основе структуры
3. Тестирование методом черного ящика
4. Тестирование методом прозрачного ящика
5. Тестирование методом белого ящика
Когда мы говорим о тестировании по бизнес-требованиям, нас не волнует как внутри написан код — нас интересует только, что делает программа снаружи. Это и есть метод «черного ящика»:
Мы не заглядываем в структуру программы, поэтому методы вроде «тестирование на основе структуры» или «метод белого ящика» здесь не подходят.
А такие варианты как «предугадывание ошибок» или «прозрачный ящик» не являются классическими методами тестирования.
Выбранный ответ: Тестирование методом черного ящика.
Вопрос 3. Тестировщику нужно проверить работу нового модуля программы согласно имеющейся спецификации требований. Какое тестирование необходимо провести?
4. Исследовательское тестирование
5. Функциональное тестирование
Тут важно обратить внимание на два слова:
- «согласно спецификации требований» — значит, проверяем, выполняет ли программа то, что прописано в требованиях.
- «новый модуль программы» — нам пока не нужно заботиться, не сломали ли мы что-то старое (это бы было регрессионное тестирование).
- Статическое тестирование — это чтение кода, документации без запуска программы. Здесь явно нужно проверить работу модуля в действии.
- Тестирование надежности — проверяет, как система работает под нагрузкой, в долгой работе, при сбоях.
- Исследовательское — когда требований нет или они слабые, и нужно самому придумать, как проверять.
- Функциональное тестирование — проверяем, соответствует ли программа функциональным требованиям (описанным в спецификации).
Выбранный ответ: Функциональное тестирование.
Вопрос 4. Что из перечисленного относится к функциональному тестированию?
1. Тестирование правильности расчетов с использованием различных единиц измерения
2. Конфигурационное тестирование приложения под различными версиями OS Linux
3. Статическое тестирование путем анализа исходного кода и документации
4. Тестирование совместимости веб-формы с различными версиями браузеров
5. Тестирование производительности посредством использования JMeter
Функциональное тестирование — это проверка того, что делает программа, то есть соответствует ли её поведение требованиям. Оно никак не связано с тем, как быстро работает система (это производительность), на каких конфигурациях она запускается (это конфигурационное), или на каких браузерах (это совместимость).
- Тестирование правильности расчетов с использованием различных единиц измерения — классический пример функционального тестирования. Мы проверяем, правильно ли программа считает, выдаёт ли она корректный результат при разных входных данных.
- Статический анализ — это чтение кода, не запуск программы.
- Проверка на разных версиях ОС, браузеров — это конфигурационное или тестирование совместимости.
- JMeter — для нагрузки, то есть тестирования производительности.
Выбранный ответ: Тестирование правильности расчетов с использованием различных единиц измерения.
Вопрос 5. Перед выполнением теста…
1. Можно иметь его неполное описание, если выполнять его будет опытный тестировщик
2. Необходимо обязательно сначала выполнить чек-лист для этого теста
3. Достаточно описать тест на уровне идеи, если продуктовые риски данного функционала невысоки
4. Необходимо обязательно описать последовательность шагов теста
5. Необходимо иметь перечень скриншотов для каждого шага теста
Главная цель подготовки теста — сделать так, чтобы кто угодно мог его воспроизвести и понять, что именно нужно проверить.
- Если тест плохо описан, даже опытный тестировщик может сделать не то, или потратить кучу времени на уточнения.
- Необязательно всегда иметь чек-лист или скриншоты для каждого шага — это избыточно.
- Описание теста лишь «на уровне идей» годится только если риск невысок, а это не всегда так. Для нормальной практики нужно явное описание.
«Необходимо обязательно описать последовательность шагов теста» — это стандартная практика, которая обеспечивает воспроизводимость теста и прозрачность результатов. Даже если кто-то другой возьмет этот тест позже, он сможет выполнить его точно так же.
Выбранный ответ: Необходимо обязательно описать последовательность шагов теста.
Вопрос 6. Что из перечисленного НЕ может проверяться в процессе функционального тестирования?
1. Взаимодействие между компонентами системы
2. Взаимодействие системы с другими приложениями
4. Построение и выдача отчетов
5. Работа отдельных компонент системы
Функциональное тестирование отвечает на вопрос: «Что система делает?» — то есть как она выполняет свои функции, которые важны пользователям и бизнесу.
- Проверить взаимодействие компонентов, взаимодействие с другими приложениями, построение и выдачу отчетов, работу отдельных компонентов — это всё можно и нужно в функциональном тестировании.
- А вот структура кода приложения — это уже вопрос как система устроена внутри, и это область структурного тестирования (например, белого ящика), а не функционального.
«Если ты спрашиваешь маму, как ей нравится новый чайник, она скажет — наливает ли он воду и как кипятит. А не посмотрит, как у него устроен трубчатый электронагреватель и т.д. Вот и функциональное тестирование интересует результат, а не конструкцию кода.»
Выбранный ответ: Структура кода приложения.
Вопрос 7. Какое из следующих требований можно проверить путем проведения функционального тестирования?
1. Время загрузки данных из справочников на форму не должно превышать 5 секунд
2. Система должна быть интуитивно понятна пользователям
3. Система должна позволять хранить 10 млн. карточек клиентов
4. Требуемая доступность системы - 23 часа в день
5. Система должна позволять вводить в поле «Кодовое слово» буквы [А-Я] и цифры [О-9]
Функциональное тестирование — это про то, что система позволяет делать, соответствует ли поведение заявленным правилам и бизнес-требованиям.
- Время загрузки данных — это уже производительность (не функциональное).
- Интуитивность для пользователя — это вообще UX, субъективно и чаще проверяется исследованием или юзабилити-тестами.
- Возможность хранить 10 млн карточек — скорее объемная или нагрузочная характеристика.
- Доступность 23 часа в день — проверяется мониторингами (надёжность и доступность).
- А вот «система должна позволять вводить в поле „Кодовое слово“ буквы [А-Я] и цифры [0-9]» — это именно функциональная проверка.
Здесь четко задается правило работы поля ввода, и это то, что проверяют функциональные тесты.
«Тут мы проверяем, разрешает ли программа вводить правильные символы. То есть функцию ввода. Это классический пример функционального теста.»
Выбранный ответ: Система должна позволять вводить в поле «Кодовое слово» буквы [А-Я] и цифры [0-9].
Вопрос 8. Какое из утверждений верно?
1. Функциональные тесты можно выполнить как ручным, так и автоматическим способом, а нефункциональные - только автоматическим
2. Функциональные тесты можно выполнить только на системном и приемочном уровнях тестирования, а нефункциональные тесты - на компонентном и интеграционном
3. Функциональные тесты можно выполнить на любом уровне тестирования, а нефункциональные тесты - на любом уровне тестирования, кроме интеграционного
4. Функциональные тесты можно выполнить на любом уровне тестирования, а нефункциональные тесты ограничены уровнем компонентного тестирования
5. Выполнение функциональных и нефункциональных тестов допустимо на любом уровне тестирования
Нужно вспомнить базовый принцип:
- Функциональные тесты (что система делает) и нефункциональные тесты (как хорошо она это делает — скорость, удобство, безопасность и т.д.) могут выполняться на любом уровне: компонентном, интеграционном, системном, приёмочном.
- Их можно делать и вручную, и автоматически. Никаких искусственных ограничений тут нет.
Поэтому единственный вариант, который это чётко утверждает — последний:
«Выполнение функциональных и нефункциональных тестов допустимо на любом уровне тестирования»
Остальные утверждения вводят искусственные ограничения (например, что нефункциональные тесты только автоматические, или только на компонентном уровне, или функциональные нельзя на приёмочном), что не соответствует практике.
«Не важно, тестируем мы маленький кусочек кода, соединение этих кусочков, всю систему или показываем её клиенту — можем проверять и что она делает, и насколько быстро/удобно/надёжно. Никто не запрещает.»
Выбранный ответ: Выполнение функциональных и нефункциональных тестов допустимо на любом уровне тестирования.
Вопрос 9. Почему важно начинать тестирование на ранних стадиях разработки?
1. Это помогает выявить, какие функции программы будут наименее востребованы у пользователей
2. Это позволяет обнаружить и исправить дефекты с минимальными затратами
3. Раннее тестирование невозможно провести до появления кода
4. Это предотвращает появление дефектов в будущем
5. Только оно позволяет вовремя выявить и исправить ошибки на уровне кода
Самая простая и понятная причина — это экономия денег и времени. Чем раньше найдешь ошибку, тем дешевле и быстрее её исправить. Если ошибка пролезет в релиз — она может стоить десятки тысяч.
Это известное правило в тестировании: «стоимость исправления дефекта растет экспоненциально с этапом разработки».
- Выявление наименее востребованных функций — это задача бизнес-анализа, а не тестирования.
- Раннее тестирование вполне возможно даже до появления кода — например, можно проверить требования, схемы, модели.
- «Предотвращает появление дефектов» звучит красиво, но неправда — тесты их находят, но не предотвращают.
- «Только оно позволяет выявить ошибки на уровне кода» — тоже неверно, ошибки на уровне кода можно найти и позднее (просто дороже).
«Чем раньше заметишь дырку в штанах, тем меньше ткани придётся пришивать. В программировании так же.»
Выбранный ответ: Это позволяет обнаружить и исправить дефекты с минимальными затратами.
Вопрос 10. Что из перечисленного наиболее точно описывает цель тестирования приложения?
1. Продемонстрировать 100% работоспособности приложения
2. Убедиться, что разработчики не допустили ошибок в коде приложения
3. Продемонстрировать, что оставшиеся дефекты не вызовут отказов
4. Получить информацию о готовности приложения
5. Продемонстрировать отсутствие дефектов после завершения тестирования приложения
Важно помнить, что тестирование не гарантирует отсутствие дефектов и уж точно не показывает 100% работоспособность.
Оно также не создано, чтобы «убедиться, что разработчики не ошиблись» — это негативная формулировка, плюс в реальности ошибки всегда есть.
Цель тестирования — дать заинтересованным сторонам (менеджерам, владельцам продукта, заказчикам) информацию о состоянии качества приложения, чтобы они могли принять решение: выпускать ли продукт, какие риски принять, где нужны доработки.
«Тестирование — это не про гарантию, а про сбор фактов. Ты просто узнаешь, готово ли приложение к работе или нет.»
Выбранный ответ: Получить информацию о готовности приложения.
Вопрос 11. Когда НЕ применяется регрессионное тестирование?
1. При негативном тестировании
2. При тестировании требований
3. При тестировании функционала
4. При тестировании нефункциональных характеристик
5. При проверке корректности кода приложения (код-ревью)
Регрессионное тестирование — это проверка того, что изменения в коде не сломали уже работающий функционал.
Его применяют для функционала, нефункциональных характеристик, в рамках негативных сценариев — короче, везде, где надо убедиться, что что-то, что работало, по-прежнему работает после изменений.
А вот проверка корректности кода (код-ревью) — это вообще не исполнение программы, а чтение кода другим разработчиком. Это статическая практика, а регрессия — динамическая.
То есть при код-ревью регрессионное тестирование не применяется, потому что код-ревью и регрессия — разные процессы.
Чтобы объяснить простым языком:
«Регрессионное тестирование — это когда запускаешь программу, чтобы убедиться, что ничего старое не сломалось. А код-ревью — просто читаешь код глазами. Тут тесты не запускаешь.»
Выбранный ответ: При проверке корректности кода приложения (код-ревью).
Вопрос 12. Детализация ситуации, в которой дефект воспроизводится…
1. Рекомендуется до регистрации дефекта, так как это ускорит локализацию и исправление ошибки в коде
2. Необходима и выполняется аналитиком до регистрации дефекта
3. Выполняется инженером по автоматизации при разработке скрипта для верификации дефекта
4. Выполняется разработчиком при исправлении дефекта
5. Не оправдывает себя, быстрая регистрация дефекта гораздо важнее
Когда тестировщик находит баг, важно не просто сказать «не работает», а подробно расписать, в каких условиях это произошло — шаги, данные, окружение. Это поможет разработчику быстро воспроизвести баг и исправить.
Поэтому детализация рекомендуется до регистрации дефекта, чтобы регистрация сразу была качественной. Это экономит время всей команды: не приходится гоняться за дополнительной информацией.
Варианты про аналитика, инженера автоматизации или разработчика здесь неуместны — именно тестировщик обычно описывает дефект.
А идея «быстрее зарегистрировать без деталей» плоха: потом всё равно придется возвращаться и уточнять.
Если объяснить на пальцах, то: «Чем подробнее сразу опишешь, как поймать баг, тем быстрее его починят. А значит, твоя работа ценнее.»
Выбранный ответ: Рекомендуется до регистрации дефекта, так как это ускорит локализацию и исправление ошибки в коде.
Вопрос 13. Что является синонимом тестирования методом черного ящика?
1. Тестирование методом прозрачного ящика
2. Тестирование на основе спецификации
4. Подтверждающее тестирование
Метод черного ящика означает, что мы не заглядываем внутрь программы, нас интересует только вход → выход.
Другими словами, мы проверяем, соответствует ли поведение системы требованиям и спецификациям, не заботясь, как именно это реализовано в коде.
Поэтому синонимом «тестирования методом черного ящика» является:
«Тестирование на основе спецификации»
- «Прозрачный ящик» — это скорее игра слов, обычно применяют термин «white-box», то есть тестирование с анализом структуры.
- Статическое тестирование и тестирование кода — это про чтение или разбор кода (не исполняя программу), это белый ящик.
- Подтверждающее тестирование (confirmation testing) — вообще другой термин, значит проверку исправленных багов.
«Если тестируешь, глядя на документы с требованиями, а не в сам код — это и есть черный ящик.»
Выбранный ответ: Тестирование на основе спецификации.
Вопрос 14. На каком уровне тестирования проводится проверка взаимодействия сайта интернет-магазина с внешним платёжным сервисом?
5. Интеграционное тестирование
Здесь ключевое слово — «взаимодействие».
Когда тестировщик проверяет, как разные части системы работают вместе (например, сайт и платёжный шлюз), это называется интеграционное тестирование.
- Модульное и компонентное тестирование проверяют отдельные кусочки кода изолированно.
- Системное тестирование — это уже проверка всей системы целиком, включая нефункциональные характеристики.
- Альфа-тестирование — это вообще этап у заказчика или внутри компании перед бета-тестом.
Чтобы объяснить совсем просто: «Мы проверяем, как сайт болтает с платёжкой. То есть, как два разных компонента соединяются. Это интеграция.»
Выбранный ответ: Интеграционное тестирование.
Вопрос 15. Что является целью регрессионного тестирования?
1. Проверка неизмененного функционала после внесения изменений в смежную функциональную область
2. Проверка работоспособности программы в новых операционных системах
3. Проверка только того функционала программы, в который были внесены изменения
4. Проверка нового функционала программы
5. Проверка только критичного функционала программы
Регрессионное тестирование — это проверка того, что после внесения изменений в программу старый (неизмененный) функционал всё ещё работает правильно.
То есть задача — убедиться, что новые исправления или фичи не сломали то, что уже раньше было протестировано и работало.
- Проверка только нового функционала — это функциональное тестирование нового кода.
- Проверка на новых ОС — это конфигурационное или совместимости.
- Проверка только того функционала, в который внесены изменения — это подтверждающее тестирование (confirmation).
- Проверка только критичного функционала — это стратегия приоритезации, но не сама цель регрессии.
А регрессия всегда про «неизмененный код», который мог пострадать от изменений в других местах.
«Цель регрессии — проверить, что старое работает, несмотря на новые правки.»
Выбранный ответ: Проверка неизмененного функционала после внесения изменений в смежную функциональную область.
Заключение
После этой статьи ты узнаешь основы функционального тестирования и поймёшь, зачем проверять даже самые простые сценарии работы программы. Это поможет тебе уверенно пройти базовые задания на собеседованиях и сделать первый шаг к работе в IT.