Виды и типы тестирования: подробный разбор

Сначала картинки

Важнейшие типы и виды тестирования, в простой форме:

Более подробно:

Еще более сложная классификация (кликабельно). Это самая правильная классификация из замеченных:

Еще один вариант этой классификации:

Итак. Виды тестирования удобно делить на две группы: функциональное и нефункциональное.

(В некоторых справочниках встречается еще третий тип — эксплуатационное тестирование (maintenance testing), выполняемое при сопровождении уже работающего продукта).

Функциональное тестирование — виды

Быстрое определение: это тестирование основных, «рабочих» функций приложения/сайта; ради этих функций приложение, собственно, создавалось.

Более общее определение, с точки зрения QA: проверка выполнения функциональных требований к приложению, зафиксированных ранее. 

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

В «функциональную группу» входят такие виды (типы):

  • Юнит-тестирование (модульное)
  • Интеграционное
  • Сквозное (E2E, end-to-end)
  • Smoke (смок-тестирование)
  • Санитарное (sanity)
  • Регрессионное
  • Приемочное (приемка пользователями)
  • Системное
  • Тестирование интерфейса

Функциональные тесты могут выполняться вручную, или могут вполне успешно автоматизироваться

Часто применяемые инструменты функционального тестирования, с которые тестировщик должен уметь работать (или хотя бы ознакомиться поверхностно): 

Selenium — инструмент тестировщика №1, овладеть им — кажется, решающий момент в трудоустройстве, по крайней мере сейчас, в 2023 году. Стремящийся стать QA-джуном должен знать (как минимум), о чем спрашивают на собеседовании по Selenium.

Далее рассмотрим типы нефункционального тестирования.

Нефункциональное тестирование — виды

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

Обычно такое тестирование делают после функционального, как менее приоритетное (но тоже важное). Оно может значительно улучшить качество приложения, объективно и субъективно, возвысить его над конкурентами, а не только «отполировать внешний вид», как было принято в предыдущие десятилетия. Нефункциональное — это не о том, работает ли софт или нет, это о том, КАК он работает и как он выглядит.

Автоматизация применяется, и очень широко, поскольку нефункциональные тесты весьма сложны и длительны. Чаще всего автоматизируется тестирование производительности.

Виды (типы) нефункционального тестирования:

  • Тестирование производительности
  • Нагрузочное
  • Безопасности
  • Тестирование на отказ
  • Совместимости
  • Юзабилити-тестирование
  • Масштабируемости
  • Объемное тестирование
  • Стресс-тестирование
  • Удобства сопровождения
  • Совместимости
  • Общей эффективности
  • Надежности
  • Выносливости
  • Тестирование восстановления после катастрофического отказа
  • Тестирование локализации и интернационализации

Далее перечислены основные типы (виды) тестирования (без деления на функциональные/нефункциональные).

Типы тестирования: общий список

Юнит-тестирование 

Другое название, менее распространенное, но более интуитивное — «модульное тестирование». Также встречается название «компонентное тестирование».

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

Подробнее по теме:

Что такое юнит-тестирование?

Очень подробный гайд по юнит-тестированию

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

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

Часто используемые инструменты юнит- и интеграционного тестирования: 

Подробнее по интеграционному тестированию:

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

Юнит-тесты vs интеграционные тесты

Сквозное тестирование

E2E-тестирование это подтип функционального, проверка всей системы «из конца в конец», end-to-end, поэтому такое название. Таких тестов еще меньше количественно, но они еще сложнее чем интеграционные и тем более модульные (и требуют больше опыта от тестировщика).  

Инструменты, которые нужно освоить, чтобы претендовать на позицию E2E-QA: 

Сквозное (end-to-end-тестирование) — гайд

Тестирование интерфейса

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

Инструменты GUI-тестирования: 

Тестированию GUI посвящен отдельный большой материал

Тестирование доступности

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

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

Более подробно о таком специфическом типе тестирования — отдельный материал.

Альфа-тестирование

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

Альфа-тестирование проводят в девелоперском окружении (а не в реальном пользовательском). Для имитации пользовательского окружения создается виртуальное окружение.

𝛼 Что такое альфа-тестирование?

Бета-тестирование

Бета-тестирование проводится после альфа-, и перед запуском продукта. Для бета-тестирования нужно реальное пользовательское окружение. Выбирается ограниченное количество реальных пользователей-«добровольцев» (клиентов), которые, не будучи специалистами в QA, тестируют продукт на свое усмотрение. Затем они дают фидбек, и конструктивную критику, после чего разработчики, при необходимости, вносят изменения в так называемую бета-версию продукта. Далее исправленный и доработанный продукт поступает на релиз, то есть становится доступен всем пользователям.

β Что такое бета-тестирование?

Ad-hoc-тестирование

Еще называемое интуитивным, поскольку проводится в «интуитивной» манере, на усмотрение тестировщика, без тест-кейсов, планов и другой оформляемой документации. Несистематичность — отличающий признак ад-хок-тестирования. 

Хотя искать баги без тест-кейсов может быть сложно, опытный тестировщик легко находит баги таким «свободным поиском», и нередко быстрее, чем «формализованным» способом. 

Отдельный материал по ad-hoc.

Тестирование совместимости

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

Например, Windows-приложение должно быть совместимым со всеми распространенными версиями ОС Windows. Если это веб-приложение, оно должно без проблем открываться во всех распространенных браузерах. Android-приложение нужно протестировать во всех распространенных в данный момент версиях ОС Android.

Подбор устройств для тестирования совместимости

Тестирование обратной совместимости

Проверка того, что новая (обновленная) версия приложения совместима с предыдущими версиями окружения, например операционными системами, в которых работает (или браузерами, в которых открывается веб-приложение).

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

Кроссбраузерное тестирование

Или тестирование совместимости браузеров. Проверка, может ли веб-приложение (сайт) без проблем открываться во всех распространенных версиях браузеров. 

Такое тестирование, ввиду его трудоемкости, автоматизируют, применяя такие инструменты:

Более подробно об этом типе тестирования и об инструментах.

Большой материал по автоматизации такого тестирования.

Тестирование производительности

Оценка общей производительности (продуктивности) приложения, выполняемая как правило при помощи специализированных инструментов, выявляющих проблемы в этой сфере:

Этой теме посвящен отдельный раздел нашего (бесплатного) Учебника.

О тестировании веб-сервисов

Нагрузочное тестирование

На систему подается нагрузка в виде запросов/одновременных «пользователей», которая позволяет оценить, какое количество нагрузки система способна обработать до того как начнет ухудшать свою производительность.

Часто применяемые нагрузочные инструменты:

Что такое нагрузочное тестирование

Подробный обзор бесплатных инструментов нагрузочного тестирования — здесь.

Тестирование восстановления

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

Регрессионное тестирование

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

Что такое регрессионное тестирование?

Статья о проблемах с «регрессами» — здесь.

Agile-тестирование

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

Инструменты Agile QA:

Тестирование API

Как и юнит-тестирование, этот тип относится к так называемому «code level testing», то есть имеет дело непосредственно с исходным кодом приложения. Разница с юнит- в том, что юнит-тесты обычно делают разработчики, а API тестирует QA-команда.

Гайд по тестированию API

Тестирование черного ящика

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

Тестирование белого ящика

Проверка приложения со знанием его исходного кода и архитектуры.

О черном и белом ящиках, которые ждут Junior QA — здесь.

Тестирование безопасности

Как понятно из названия, такие тесты гарантируют безопасность приложения/сайта; выявляют и предотвращают «дыры» в его подсистеме безопасности. Тестировщики, специализирующиеся на таком тестировании, работают как вручную, так и инструментами:

Юзабилити-тестирование

Оценка (и последующая коррекция) общего удобства пользования приложением/сайтом. Насколько приложение юзабельно, то есть «дружественно к пользователю»? 

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

Как это делается, и много дополнительной информации по юзабилити, например чеклисты — в нашем большом гайде; Artsiom Rusau одобряет.

Инструменты проверки юзабилити:

Тестирование масштабируемости

Легко ли масштабировать приложение? То есть, легко ли, и быстро ли, расширяются его возможности в программном и аппаратном измерении? Что произойдет, если количество пользователей, объемы данных, количество транзакций — возрастут в разы? Или десятки, сотни раз.

Тестирование масштабируемости

Тестирование надежности

Насколько приложение надёжное, «выносливое»? Сколько времени оно сумеет проработать «без единого отказа», и при каких условиях происходит отказ? Что провоцирует ошибки в приложении?

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

Тестирование стабильности

Приемочное тестирование

Компания-клиент, получая готовый программный продукт, проводит приемочное тестирование (User Acceptance Testing = UAT). Оценивает, можно ли принимать софт, исходя из пользовательских требований и предпочтений. Если они не удовлетворены, или если просто клиенту не нравится что-либо в приложении, команде, работавшей над софтом, будет подан запрос на изменения.

Приемочное тестирование

***

Это не все виды и типы QA-тестирования. Более полно — в нашем Учебнике (там уже более 220 материалов по QA, и мы практически каждый день пополняем его). Как говорят, feel free, не стесняйтесь пользоваться, там удобнее все классифицировано по разделам. Любые вопросы, замечания, замеченные неточности/ошибки — смело пишите в коментах здесь, или в ТГ-канале, мы все читаем, и учитываем мнения наших читателей/подписчиков.

Подробнее об основных инструментах автоматизации тестирования можно почитать здесь — а также оценить «портрет среднего тестировщика» в 2022-2023.

Подписка на телеграм-канал, посвященный только и исключительно автоматизации QA — здесь. А официальный канал TestEngineer — здесь.

Какой была ваша первая зарплата в QA и как вы искали первую работу?

Мега обсуждение в нашем телеграм-канале о поиске первой работы. Обмен опытом и мнения.

Подписаться
Уведомить о
guest

0 комментариев
Межтекстовые Отзывы
Посмотреть все комментарии

Мы в Telegram

Наш официальный канал
Полезные материалы и тесты
Готовимся к собеседованию
Project- и Product-менеджмент

🔥 Популярное

💬 Telegram-обсуждения

Наши подписчики обсуждают, как искали первую работу в QA. Некоторые ищут ее прямо сейчас.
Наши подписчики рассказывают о том, как не бояться задавать тупые вопросы и чувствовать себя уверенно в новой команде.
Обсуждаем, куда лучше податься - в менеджмент или по технической ветке?
Говорим о конфликтных ситуациях в команде и о том, как их избежать
$1100*
медианная зарплата в QA в июне 2023

*по результатам опроса QA-инженеров в нашем телеграм-канале

Собеседование

19%*
IT-специалистов переехало или приняло решение о переезде из России по состоянию на конец марта 2022

*по результатам опроса в нашем телеграм-канале

live

Обсуждают сейчас