Функциональное тестирование: Базовый уровень. HH тест.

Функциональное тестирование является ключевым этапом в процессе разработки программного обеспечения. Оно направлено на проверку того, что программный продукт соответствует требованиям и ожиданиям пользователей. В данной статье мы рассмотрим базовые подходы к функциональному тестированию на платформе HeadHunter, одной из ведущих онлайн-площадок для поиска работы и подбора персонала. Мы погрузимся в практические аспекты тестирования функционала, чтобы понять, как обеспечивается высокое качество сервиса для миллионов пользователей.

Вопрос №1:

На каких уровнях может выполняться функциональное тестирование?

Варианты ответа:

На всех уровнях за исключением приемочного тестирования
На всех уровнях, кроме уровня компонентного тестирования
На всех уровнях, кроме уровня интеграционного тестирования
Только на уровне системного тестирования
На всех уровнях тестирования

Обоснование:

Функциональное тестирование направлено на проверку того, насколько система или её компоненты соответствуют функциональным требованиям. Оно может проводиться на различных уровнях тестирования:

Компонентное тестирование (Unit testing): Функциональное тестирование здесь может быть ограничено, но всё же оно используется для проверки базовой функциональности отдельных модулей.
Интеграционное тестирование: Проверяются взаимодействия между модулями, что часто включает функциональные проверки.
Системное тестирование: Здесь функциональное тестирование — основное направление, так как проверяется работа всей системы.
Приемочное тестирование: Оценка системы с точки зрения требований заказчика или конечного пользователя также включает функциональные аспекты.

Таким образом, функциональное тестирование может выполняться на всех уровнях тестирования, в зависимости от контекста и целей.

📌Правильный ответ:

5. На всех уровнях тестирования

Вопрос №2:

К какому методу относится функциональное тестирование на основе бизнес-требований?

Варианты ответа:

Тестирование на основе структуры
Тестирование методом прозрачного ящика
Тестирование методом предугадывания ошибок
Тестирование методом черного ящика
Тестирование методом белого ящика

Обоснование:

Функциональное тестирование направлено на проверку системы или её компонентов на соответствие функциональным требованиям, которые обычно формулируются в бизнес-спецификациях. Для этого подхода характерен метод "черного ящика", при котором тестировщик проверяет функциональность, не зная внутренней структуры или реализации кода.

Метод "черного ящика" позволяет сосредоточиться на входных данных, выходных результатах и бизнес-логике, что соответствует тестированию на основе бизнес-требований. Остальные методы менее применимы в данном контексте:

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

📌Правильный ответ:

4. Тестирование методом черного ящика

Вопрос №3:

Тестировщику нужно проверить работу нового модуля программы согласно имеющейся спецификации требований. Спецификация содержит описание алгоритма работы программы. Какое тестирование ему необходимо провести?

Варианты ответа:

Функциональное тестирование
Исследовательское тестирование
Статическое тестирование
Регрессионное тестирование
Тестирование надежности

Обоснование:

Когда есть спецификация требований, которая описывает алгоритм работы программы, необходимо проверить, соответствует ли поведение системы этим требованиям. Это задача функционального тестирования, которое направлено на проверку правильности работы функциональности программы в соответствии с описанными требованиями.

Другие виды тестирования:

Исследовательское тестирование проводится без заранее составленного плана или спецификации.
Статическое тестирование предполагает анализ документации или кода без выполнения программы.
Регрессионное тестирование проверяет, не вызвали ли изменения в коде сбои в уже работающем функционале.
Тестирование надежности проверяет стабильность системы под определенной нагрузкой, что выходит за рамки проверки соответствия спецификации.

📌Правильный ответ:

1. Функциональное тестирование

Вопрос №4:

Что из перечисленного относится к функциональному тестированию?

Варианты ответа:

Тестирование правильности расчетов с использованием различных единиц измерения
Статическое тестирование путем анализа исходного кода и документации
Тестирование совместимости веб-форм с различными версиями браузеров
Тестирование производительности посредством использования JMeter
Конфигурационное тестирование приложения под различными версиями OS Linux

Обоснование:

Функциональное тестирование направлено на проверку того, насколько система выполняет заявленные функции согласно требованиям. Оно включает проверки, связанные с корректностью выполнения операций, отображением данных, расчетами и обработкой пользовательских действий.

Из предложенных вариантов функциональному тестированию соответствует:

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

Остальные варианты:

Статическое тестирование (анализ исходного кода) не связано с выполнением программы.
Тестирование совместимости относится к проверке корректности работы в различных средах, что является отдельным видом тестирования.
Тестирование производительности и конфигурационное тестирование также являются отдельными направлениями (не функциональными).

📌Правильный ответ:

1. Тестирование правильности расчетов с использованием различных единиц измерения

Вопрос №5:

Перед выполнением теста...

Варианты ответа:

Необходимо обязательно описать последовательность шагов теста
Достаточно описать тест на уровне идеи, если продуктовые риски данного функционала невысоки
Необходимо иметь перечень скриншотов для каждого шага теста
Необходимо обязательно сначала выполнить чек-лист для этого теста
Можно иметь его неполное описание, если выполнять его будет опытный тестировщик

Обоснование:

Перед выполнением теста важно подготовить все необходимые инструкции, чтобы любой тестировщик мог точно воспроизвести проверку независимо от своего опыта. Это особенно важно для систематического тестирования и последующего анализа ошибок. Полное описание шагов теста снижает вероятность ошибки и обеспечивает повторяемость результата.

Другие варианты:

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

📌Правильный ответ:

1. Необходимо обязательно описать последовательность шагов теста

Вопрос №6:

Что из перечисленного НЕ может проверяться в процессе функционального тестирования?

Варианты ответа:

Взаимодействие системы с другими приложениями
Структура кода приложения
Взаимодействие между компонентами системы
Работа отдельных компонентов системы
Построение и выдача отчетов

Обоснование:

Функциональное тестирование направлено на проверку поведения системы и её соответствия функциональным требованиям. Оно фокусируется на результатах выполнения функций, а не на внутренних аспектах реализации, таких как структура кода.

Из перечисленного:

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

📌Правильный ответ:

2. Структура кода приложения

Вопрос №7:

Какое из следующих требований можно проверить путем проведения функционального тестирования?

Варианты ответа:

Система должна быть интуитивно понятна пользователям
Система должна позволять вводить в поле «Кодовое слово» буквы [А-Я] и цифры [0-9]
Время загрузки данных из справочников на форму не должно превышать 5 секунд
Требуемая доступность системы — 23 часа в день
Система должна позволять хранить 10 млн. карточек клиентов

Обоснование:

Функциональное тестирование проверяет поведение системы в соответствии с функциональными требованиями. Оно фокусируется на проверке того, что система делает, а не на том, как она это делает.

Требование о вводе данных в поле («Кодовое слово») проверяет корректность работы функциональности ввода данных, что является прямой задачей функционального тестирования.
Интуитивная понятность — субъективное требование, связанное с юзабилити.
Время загрузки данных относится к нефункциональному тестированию производительности.
Доступность системы относится к нефункциональному тестированию надежности.
Хранение 10 млн. карточек проверяется нагрузочным тестированием, а не функциональным.

📌Правильный ответ:

2. Система должна позволять вводить в поле «Кодовое слово» буквы [А-Я] и цифры [0-9]

Вопрос №8:

Какое из утверждений верно?

Варианты ответа:

Функциональное тестирование может выполняться как ручным, так и автоматическим способом, а нефункциональное — только автоматическим
Функциональное и нефункциональное тестирование можно выполнить на любом уровне тестирования, а тестирование белого ящика — только на компонентном и интеграционном
Выполнение функционального и нефункционального тестирования, как и тестирования белого ящика, допустимо на любом уровне тестирования
Функциональные и нефункциональные тесты можно выполнить только на системном и приемочном уровнях тестирования, а тестирование белого ящика — на компонентном и интеграционном
Функциональное тестирование можно выполнить на любом уровне тестирования, а тестирование белого ящика ограничено уровнем компонентного тестирования

Обоснование:

Функциональное тестирование может выполняться как ручным, так и автоматическим способом. Нефункциональное тестирование (например, тестирование производительности или надежности) может выполняться как вручную, так и с использованием автоматизированных инструментов. Следовательно, утверждение 1 неверно.
Белый ящик применяется преимущественно на компонентном и интеграционном уровнях, где есть доступ к внутренней структуре системы. Однако функциональное и нефункциональное тестирование действительно можно выполнить на любом уровне тестирования. Таким образом, утверждение 2 — верно.
Утверждение 3 некорректно, так как тестирование белого ящика ограничено уровнями, где доступна информация о внутренней реализации.
Утверждение 4 ограничивает функциональные тесты системным и приемочным уровнями, что неправильно, так как их можно проводить на всех уровнях.
Утверждение 5 ошибочно, так как функциональное тестирование действительно возможно на любом уровне, но тестирование белого ящика не ограничено только компонентным уровнем.

📌Правильный ответ:

2. Функциональное и нефункциональное тестирование можно выполнить на любом уровне тестирования, а тестирование белого ящика — только на компонентном и интеграционном

Вопрос №9:

Почему важно начинать тестирование на ранних стадиях разработки?

Варианты ответа:

Только оно позволяет вовремя выявить и исправить ошибки на уровне кода
Это предотвращает появление дефектов в будущем
Раннее тестирование невозможно провести до появления кода
Это помогает выявить, какие функции программы будут наименее востребованы у пользователей
Это позволяет обнаружить и исправить дефекты с минимальными затратами

Обоснование:

Начало тестирования на ранних стадиях разработки помогает минимизировать затраты на исправление дефектов. Чем раньше обнаружен дефект, тем меньше времени, усилий и средств требуется на его устранение. Например, дефект, найденный на стадии проектирования, обходится дешевле, чем на стадии тестирования готового продукта. Это также способствует повышению качества конечного продукта.

Другие варианты:

Утверждение 1 частично верно, но тестирование на ранних стадиях охватывает не только код, но и требования и проектирование.
Утверждение 2 ошибочно, так как тестирование не предотвращает дефекты, а выявляет их.
Утверждение 3 неверно, так как тестирование требований и проектирования возможно до появления кода.
Утверждение 4 связано с исследованиями юзабилити или анализа требований, но не относится к раннему тестированию.

📌Правильный ответ:

5. Это позволяет обнаружить и исправить дефекты с минимальными затратами

Вопрос №10:

Что из перечисленного ниже наиболее точно описывает цель тестирования приложения?

Варианты ответа:

Получить информацию о готовности приложения
Убедиться, что разработчики не допустили ошибок в коде приложения
Продемонстрировать отсутствие дефектов после завершения тестирования приложения
Продемонстрировать 100% работоспособности приложения
Продемонстрировать, что оставшиеся дефекты не вызовут отказов

Обоснование:

Цель тестирования состоит в том, чтобы выявить дефекты, определить качество приложения и дать информацию о его готовности для релиза. Тестирование не гарантирует отсутствие дефектов или 100% работоспособность, а направлено на минимизацию рисков и выявление информации о текущем состоянии системы.

Получить информацию о готовности приложения — наиболее точное описание, так как это основная цель тестирования.
Утверждение 2 (убедиться в отсутствии ошибок в коде) неточно, так как тестирование направлено на выявление ошибок, а не их предотвращение.
Утверждение 3 (отсутствие дефектов) не соответствует действительности, так как тестирование никогда не гарантирует их полного отсутствия.
Утверждение 4 (100% работоспособность) нереалистично, так как это недостижимо.
Утверждение 5 касается управления рисками, но не охватывает общую цель тестирования.

📌Правильный ответ:

1. Получить информацию о готовности приложения

Вопрос №11:

В каких случаях НЕ применяется регрессионное тестирование?

Варианты ответа:

Тестирование исправления дефекта
Тестирование структуры
Тестирование безопасности
Тестирование наработки на отказ
Тестирование нефункциональных характеристик

Обоснование:

Регрессионное тестирование применяется для проверки того, что внесенные изменения или исправления дефектов не привели к появлению новых ошибок в уже работающем функционале. Это тестирование направлено на подтверждение стабильности функциональности после модификаций.

Тестирование исправления дефекта — типичный случай для регрессионного тестирования.
Тестирование структуры относится к анализу внутреннего кода или архитектуры и не связано с проверкой работоспособности после изменений, поэтому регрессионное тестирование здесь не применяется.
Тестирование безопасности и тестирование наработки на отказ относятся к специализированным видам нефункционального тестирования и обычно не связаны с регрессионным тестированием напрямую.
Тестирование нефункциональных характеристик иногда включает элементы регрессионного тестирования, но оно не является основной задачей.

📌Правильный ответ:

2. Тестирование структуры

Вопрос №12:

Детализация ситуации, в которой дефект воспроизводится...

Варианты ответа:

Выполняется инженером по автоматизации при разработке скрипта для верификации дефекта
Рекомендуется до регистрации дефекта, так как это ускорит локализацию и исправление ошибки в коде
Не оправдывает себя, быстрая регистрация дефекта гораздо важнее
Выполняется разработчиком при исправлении дефекта
Необходима и выполняется аналитиком до регистрации дефекта

Обоснование:

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

Вариант 2 наиболее точен: описывать дефект необходимо до его регистрации в системе, чтобы сэкономить время на дальнейших этапах исправления.
Вариант 1 некорректен, так как автоматизация скриптов применяется после идентификации дефекта.
Вариант 3 (быстрая регистрация важнее) не учитывает времени, которое будет потрачено на уточнение дефекта.
Вариант 4 не описывает процесс, предшествующий исправлению, и не включает роль тестировщика.
Вариант 5 неверен, поскольку аналитик не всегда выполняет эту задачу, она чаще ложится на тестировщика.

📌Правильный ответ:

2. Рекомендуется до регистрации дефекта, так как это ускорит локализацию и исправление ошибки в коде

Вопрос №13:

Что является синонимом тестирования методом черного ящика?

Варианты ответа:

Тестирование кода
Тестирование методом прозрачного ящика
Тестирование на основе спецификации
Статическое тестирование
Подтверждающее тестирование

Обоснование:

Тестирование методом черного ящика предполагает проверку функциональности системы без знаний её внутренней структуры и реализации. Тестировщик ориентируется на входные данные, ожидаемые результаты и спецификацию требований. Это тестирование на основе спецификации, где проверяется, соответствует ли система заявленным функциональным требованиям.

Тестирование кода относится к методу белого ящика, так как требует знаний о внутренней структуре системы.
Метод прозрачного ящика является промежуточным подходом и требует частичного знания внутренней логики.
Статическое тестирование — это анализ без выполнения программы, что не относится к черному ящику.
Подтверждающее тестирование направлено на проверку исправления дефекта и не является синонимом метода черного ящика.

📌Правильный ответ:

3. Тестирование на основе спецификации

Вопрос №14:

Тестировщик производит проверку взаимодействия сайта интернет-магазина с внешним платежным сервисом. На каком уровне тестирования проводится эта проверка?

Варианты ответа:

Альфа тестирование
Компонентное тестирование
Модульное тестирование
Системное тестирование
Интеграционное тестирование

Обоснование:

Проверка взаимодействия между компонентами системы, включая внешние сервисы (например, платежные системы), относится к интеграционному тестированию. На этом уровне проверяется корректность взаимодействия отдельных модулей, систем или сервисов между собой.

Альфа тестирование проводится на позднем этапе разработки в условиях, близких к эксплуатации, но не фокусируется на интеграции.
Компонентное тестирование проверяет отдельные компоненты в изоляции, а не их взаимодействие с другими системами.
Модульное тестирование относится к тестированию отдельных модулей (аналогично компонентному).
Системное тестирование проверяет систему в целом, включая функциональность и нефункциональные требования, но не акцентируется на взаимодействии между отдельными модулями.

📌Правильный ответ:

5. Интеграционное тестирование

Вопрос №15:

Что из перечисленного можно отнести к регрессионному тестированию?

Варианты ответа:

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

Обоснование:

Регрессионное тестирование направлено на проверку, что внесенные изменения (например, добавление нового функционала, исправление дефектов или обновление модулей) не вызвали регрессии, то есть новых ошибок в существующем функционале.

Вариант 1: Проверка смежных областей функционала является частью регрессионного тестирования, так как изменения в одной части системы могут затронуть другие.
Вариант 2: Проверка совместимости с новыми операционными системами относится к тестированию совместимости, а не регрессионному.
Вариант 3: Проверка работы модулей после обновлений также может быть частью регрессионного тестирования.
Вариант 4: Проверка критичного функционала часто входит в смоук-тестирование, но не является основной задачей регрессионного тестирования.
Вариант 5: Проверка нового функционала и исправленных дефектов — это ключевая задача регрессионного тестирования.

📌Правильный ответ:

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

Прохождение базового теста на платформе HeadHunter- успешно завершен, в следующей статье я попытаюсь пройти тест на средний уровень функционального тестирования.