Продолжаем изучать виды тестирований. Их достаточно много, поэтому я разбил их по классификациям, чтобы проще было запомнить. Обязательно ознакомьтесь с прошлой статьёй!
✅Классификация по принципам работы с приложением
Классификация по принципам работы с приложением включает следующие основные виды тестирования:
🟢Позитивное тестирование – использование только корректных данных и сценариев для проверки работоспособности приложения.
Позитивное тестирование (Positive Testing) направлено на проверку корректной работы приложения при использовании правильных и ожидаемых данных. Оно имитирует действия конечного пользователя, который использует продукт согласно инструкции. Цель такого тестирования — убедиться, что приложение выполняет свои функции в соответствии с требованиями и спецификациями.
В процессе тестирования специалист внимательно изучает требования и рекомендации по использованию приложения. Так, при проверке формы регистрации в приложении он вводит в неё верные данные и активирует кнопку «Зарегистрироваться».
Примеры позитивного тестирования:
- Ввод корректных данных в форму регистрации;
- Переход по ссылкам, которые должны вести на нужные страницы;
- Выполнение операций, предусмотренных функционалом приложения.
🟢Негативное тестирование – проверка реакции приложения на некорректные данные и условия, которые могут привести к ошибкам или сбоям.
Негативное тестирование (Negative Testing), напротив, проверяет реакцию приложения на ввод некорректных данных или выполнение действий, которые могут привести к ошибкам или сбоям. Это позволяет выявить уязвимости и дефекты, которые могут быть использованы злоумышленниками или привести к нежелательным последствиям для пользователей.
Примеры негативного тестирования:
- Ввод символов в поля, предназначенные для чисел;
- Попытка зарегистрироваться с уже занятым именем пользователя;
- Отправка формы без заполнения обязательных полей.
В процессе тестирования необходимо помнить, что негативное тестирование — это не попытка нарушить работу системы, а способ проверить, как система обрабатывает некорректные действия пользователя.
Например, если пользователь при регистрации укажет email без символа @, приложение должно вывести сообщение об ошибке. Если же сообщение об ошибке не появится и пользователь будет зарегистрирован, это будет считаться дефектом.
Или, например, если банковское приложение для выдачи кредита требует, чтобы возраст заёмщика был больше или равен 18, негативным тестом будет проверка возраста 15 лет. Успешным завершением в таком случае будет сообщение о невозможности выдать кредит из-за возраста, не соответствующего требованиям.
При проведении тестирования сначала всегда выполняются позитивные тесты. Это необходимо, чтобы убедиться, что основные функции приложения работают правильно. И только после этого можно переходить к негативным проверкам, которых обычно бывает гораздо больше, чем позитивных.
✅Классификация по уровню функционального тестирования
🟢Дымовое тестирование (Smoke test, Intake test, Build verification test) направлено на проверку самой главной, самой важной, самой ключевой функциональности, неработоспособность которой делает бессмысленной саму идею использования приложения. Дымовое тестирование проводится после выхода нового билда, чтобы определить общий уровень качества приложения и принять решение о целесообразности выполнения тестирования критического пути и расширенного тестирования.
Пример дымового тестирования:
Предположим, вы разрабатываете веб-сайт электронной коммерции. Дымовое тестирование может включать в себя проверку следующих основных функций:
- Возможность входа в учетную запись.
- Просмотр категорий товаров.
- Добавление товара в корзину.
- Оформление заказа.
- Просмотр страницы с информацией о доставке и оплате.
Если эти ключевые функции работают должным образом, это дает основание полагать, что более сложные и специфические функции сайта также будут работать корректно, и можно переходить к дальнейшему тестированию.
🟢Тестирование критического пути (Critical path test) направлено на исследование функциональности, используемой типичными пользователями в типичной повседневной деятельности. Если по каким-то причинам приложение не выполняет эти функции или выполняет их некорректно, очень многие пользователи не смогут достичь множества своих целей.
Пример тестирования критического пути:
Для интернет-магазина, критическим путём может быть процесс оформления заказа. Пользователь должен иметь возможность легко найти нужный товар, добавить его в корзину, заполнить информацию о доставке и оплате, и завершить оформление заказа. Эти шаги являются наиболее важными для большинства пользователей, поскольку они непосредственно ведут к покупке товара.
🟢Расширенное тестирование (Extended test) направлено на исследование всей заявленной в требованиях функциональности — даже той, которая низко ранжирована по степени важности. При этом здесь также учитывается, какая функциональность является более важной, а какая — менее важной. Но при наличии достаточного количества времени и иных ресурсов тест-кейсы этого уровня могут затронуть даже самые низкоприоритетные требования.
Только при наличии достаточного количества времени можно провести расширенное тестирование. Оно фокусируется на редких и нестандартных способах использования приложения, которые не рассматривались на более ранних этапах.
Ошибки, найденные в ходе такого тестирования, обычно не критичны и не мешают нормально использовать приложение.
Пример расширенного тестирования:
Представим, что вы разрабатываете мобильное приложение для управления личными финансами. На уровне расширенного тестирования вы можете исследовать следующие аспекты:
- Нетипичное использование: Что произойдет, если пользователь попытается перевести деньги самому себе с помощью QR-кода?
- Экзотические сценарии: Как поведет себя приложение, если пользователь изменит свой часовой пояс на противоположный конец света и попытается совершить транзакцию?
- Крайние случаи: Что будет, если пользователь попытается создать более 1000 счетов одновременно?
Эти сценарии могут показаться маловероятными, но они помогают выявить потенциальные проблемы, которые могут возникнуть у небольшого числа пользователей в необычных ситуациях.
✅Классификация в зависимости от исполнителей
В зависимости от исполнителей, тестирование программного обеспечения можно разделить на два основных типа:
🟢Альфа-тестирование — это этап тестирования, который проводится внутри организации-разработчика. На этом этапе в тестировании участвуют сотрудники компании, которые разрабатывали продукт. Цель альфа-тестирования — убедиться, что продукт соответствует требованиям и готов к передаче на бета-тестирование.
После завершения модульного, интеграционного и системного тестирования, когда продукт уже практически готов к выходу на рынок, но всё ещё нуждается в доработке, проводится альфа-тестирование. Оно представляет собой моделирование реального использования продукта пользователями, но осуществляется либо группой тестирования, либо другими сотрудниками компании-разработчика в закрытой тестовой среде, например, на внутренних тестовых стендах компании, недоступных для внешних пользователей. По завершении альфа-тестирования выпускается бета-версия продукта, которая отправляется на бета-тестирование (внешнее или публичное тестирование).
🟢Бета-тестирование — это этап тестирования, который проводится среди ограниченной группы пользователей, не являющихся сотрудниками компании-разработчика. Бета-тестирование позволяет собрать обратную связь от реальных пользователей о продукте, выявить возможные проблемы и недочёты перед выпуском продукта на рынок.
Чтобы провести бета-тестирование, продукт должен быть достаточно стабильным для передачи пользователям, но при этом сохраняется вероятность возникновения проблем и обнаружения недостатков. Поэтому продукт сначала предоставляется небольшой группе реальных пользователей для проверки его работоспособности и получения обратной связи.
Бета-тестирование часто используется при тестировании игр, включая открытое бета-тестирование (ОБТ). В таких случаях могут привлекаться либо все желающие (например, подавшие заявку), либо определённые люди, имеющие опыт работы с программами (играми) подобного типа. Зачастую у компаний есть контакты людей, с которыми они регулярно сотрудничают при проведении бета-тестирования.
Последовательность выполнения тестирования следующая:
- Модульное тестирование
- Интеграционное тестирование
- Системное тестирование
- Альфа тестирование
- Бета тестирование
✅Тестирование связанное с изменениями в коде
В процессе разработки приложения код постоянно изменяется — как при добавлении нового функционала, так и при исправлении ошибок. В связи с этим возникает необходимость повторно тестировать уже проверенную часть приложения, в которую были внесены изменения. В зависимости от характера изменений проводят либо регрессионное, либо повторное тестирование.
🟢Регрессионное тестирование — это процесс проверки уже протестированной функциональности приложения после внесения изменений в его код. Цель такого тестирования — удостовериться, что изменения не привнесли новые ошибки в области, которые не менялись.
В современной практике разработки, где широко используется инкрементно-итерационная модель, регрессионное тестирование составляет значительную часть всех проверок и играет ключевую роль в обеспечении качества продукта.
Пример регрессионного тестирования
Предположим, что у нас есть веб-приложение с функцией авторизации. В результате изменений в коде был исправлен баг с некорректной обработкой пароля. В таком случае регрессионное тестирование может включать следующие тесты:
- ввод корректных данных для авторизации;
- ввод некорректных данных для авторизации;
- ввод пустых полей;
- тестирование функции «Забыли пароль».
После проведения регрессионного тестирования мы убедимся, что исправление ошибки не повлияло на другие функции авторизации.
🟢Повторное/подтверждающее тестирование (re-testing/confirmation testing) - выполняются тестовые сценарии, которые помогли выявить ошибки при последнем запуске. Целью является проверка, действительно ли ошибки были исправлены. То есть, подтверждается, что после внесения изменений в код приложения, оно работает в соответствии с требованиями в той части, где был обнаружен и исправлен дефект.
Пример повторного тестирования:
Предположим, что в интернет-магазине обнаружена ошибка: при оформлении заказа не сохраняется адрес доставки. Эта ошибка была исправлена разработчиком. Теперь необходимо провести повторное тестирование, чтобы убедиться, что проблема действительно решена.
Для этого необходимо выполнить следующие шаги:
- Запустить тестовый сценарий, который ранее выявлял ошибку.
- Убедиться, что при оформлении заказа адрес доставки сохраняется корректно.
Если адрес доставки сохраняется правильно, значит, ошибка была успешно исправлена.
Практически во всех процессах тестирования продуктов необходимо проводить повторное тестирование. После исправления ошибки разработчиком тестировщик должен ещё раз проверить проблемный участок, выполнив сценарий, в котором была обнаружена ошибка.
Повторное и регрессионное тестирование — это два разных вида тестирования. При повторном тестировании проверяется, что после исправления кода функция, которая раньше не работала, теперь работает корректно. Регрессионное тестирование направлено на проверку того, что изменения, внесённые в один модуль или компонент, не нарушили работу функций в других модулях или компонентах, которые уже были протестированы и работали правильно.
Регрессионное тестирование может проводиться многократно, и его объём увеличивается с добавлением новых функций и модулей в систему. Поэтому, как и дымовое тестирование, регрессионное тестирование часто автоматизируют.
✅Подходы к тестированию
🟢Тестирование, основанное на использовании тест-кейсов (scripted testing, test case based testing), представляет собой формализованный метод, предполагающий проверку программного обеспечения с помощью заранее подготовленных тестовых сценариев и другой документации. Этот подход широко применяется в проектах по разработке ПО, поскольку он позволяет упорядочить процесс тестирования и обеспечить его контроль.
🟢Исследовательское тестирование (exploratory testing) — это метод, который предполагает гибкий подход к тестированию приложения. Тестировщик начинает работу с выбранным сценарием, но в процессе выполнения может его доработать, чтобы более глубоко исследовать приложение.
В отличие от тестирования на основе тест-кейсов, где сценарии разрабатываются заранее, в исследовательском тестировании они создаются непосредственно в процессе работы. Тестировщик выполняет тесты, анализирует результаты и на их основе принимает решение о необходимости доработки или изменения сценария.
Результаты исследовательского тестирования помогают лучше понять особенности работы компонента или системы и разработать тестовые сценарии для проверки ещё не охваченных областей.
Исследовательское тестирование проводится сессиями, что позволяет эффективно организовать процесс. Такой подход подразумевает, что тестирование осуществляется в течение определенного периода времени. В ходе каждой сессии тестировщик руководствуется конкретной концепцией тестирования, которая включает в себя цели, а также фиксирует выполненные действия и обнаруженные факты.
Этот метод особенно полезен в ситуациях, когда документация недостаточна или вовсе отсутствует, сроки ограничены, а также в качестве дополнения к другим, более формальным методам тестирования.
Для успешного проведения исследовательского тестирования специалисту необходимо обладать высоким уровнем профессионализма и глубоким пониманием тестируемого приложения.
🟢Свободное (интуитивное) тестирование (ad hoc testing) — это неформальный подход, который не предусматривает использование заранее подготовленных тест-кейсов, чек-листов или сценариев. Тестировщик полагается исключительно на свои знания и интуицию, чтобы спонтанно проверять различные аспекты приложения.
Обычно предполагается, что тестировщик плохо знаком с приложением, которое тестирует. Этот вид тестирования применяется редко и только в качестве дополнения к полностью или частично формализованному тестированию, когда необходимо проверить функции приложения, для которых нет готовых тест-кейсов или они ещё не были созданы.
В следующей статье мы продолжим изучать виды тестирования!
Если у вас есть вопросы или вы просто хотите стать частью команды тестировщиков, то переходи в ТГ канал, где можем пообщаться с единомышленниками и найти много интересных и полезных знаний!Также если вам нужна индивидуальная консультация, менторство и помощь в создании проекта пишите в ТГ канал!
