Сначала картинки
Важнейшие типы и виды тестирования, в простой форме:
Более подробно:
Еще более сложная классификация (кликабельно). Это самая правильная классификация из замеченных:
Еще один вариант этой классификации:
Итак. Виды тестирования удобно делить на две группы: функциональное и нефункциональное.
(В некоторых справочниках встречается еще третий тип — эксплуатационное тестирование (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-тестирование
Еще называемое интуитивным, поскольку проводится в «интуитивной» манере, на усмотрение тестировщика, без тест-кейсов, планов и другой оформляемой документации. Несистематичность — отличающий признак ад-хок-тестирования.
Хотя искать баги без тест-кейсов может быть сложно, опытный тестировщик легко находит баги таким «свободным поиском», и нередко быстрее, чем «формализованным» способом.
Тестирование совместимости
Направлено на проверку совместимости продукта с операционными системами, браузерами, сетевыми окружениями, аппаратными конфигурациями, и т.п. Приложение должно работать во всех предусмотренных в его документации окружениях.
Например, Windows-приложение должно быть совместимым со всеми распространенными версиями ОС Windows. Если это веб-приложение, оно должно без проблем открываться во всех распространенных браузерах. Android-приложение нужно протестировать во всех распространенных в данный момент версиях ОС Android.
Подбор устройств для тестирования совместимости
Тестирование обратной совместимости
Проверка того, что новая (обновленная) версия приложения совместима с предыдущими версиями окружения, например операционными системами, в которых работает (или браузерами, в которых открывается веб-приложение).
Часто приложения обновляют, чтобы соответствовать изменившимся стандартам нового окружения, или чтобы «осовременить» общий стиль и вид приложения. Теперь нужно провести тестирование обратной совместимости — ведь пользователи «старой» версии этого окружения, которых может быть очень много, не должны терять возможность пользоваться приложением.
Кроссбраузерное тестирование
Или тестирование совместимости браузеров. Проверка, может ли веб-приложение (сайт) без проблем открываться во всех распространенных версиях браузеров.
Такое тестирование, ввиду его трудоемкости, автоматизируют, применяя такие инструменты:
- CrossBrowserTesting
- LambdaTest
- Browsershots
- Experitest
- Turbo Browser Sandbox
- Ranorex Studio
- Browsera
Более подробно об этом типе тестирования и об инструментах.
Большой материал по автоматизации такого тестирования.
Тестирование производительности
Оценка общей производительности (продуктивности) приложения, выполняемая как правило при помощи специализированных инструментов, выявляющих проблемы в этой сфере:
- WebLOAD
- LoadView
- NeoLoad
- LoadNinja
- Appvance
- LoadRunner
- Apache JMeter
- Loadster
- LoadImpact
- Testing Anywhere
- SmartMeter.io
- Tricentis Flood
- Rational Performance Tester
- LoadComplete
Этой теме посвящен отдельный раздел нашего (бесплатного) Учебника.
Нагрузочное тестирование
На систему подается нагрузка в виде запросов/одновременных «пользователей», которая позволяет оценить, какое количество нагрузки система способна обработать до того как начнет ухудшать свою производительность.
Часто применяемые нагрузочные инструменты:
Что такое нагрузочное тестирование
Подробный обзор бесплатных инструментов нагрузочного тестирования — здесь.
Тестирование восстановления
Проверка, может ли система восстанавливаться после сбоев, и как это происходит — как система возвращается к нормальному функционированию. Понятно, что от сбоев не застрахована ни одна програма — поэтому возможность сбоя должна быть предусмотрена, и проведена соответствующая подготовка. Программный продукт должен восстанавливаться быстро и «без потерь».
Регрессионное тестирование
Если система корректируется в процессе создания (что неизбежно), если в ее модули/функции вносятся изменения, то обязательно проверяют, не повлияли ли эти правки на функционирование системы.
Что такое регрессионное тестирование?
Статья о проблемах с «регрессами» — здесь.
Agile-тестирование
Специфический тип QA-тестирования командой, работающей «по эджайлу», то есть с соблюдением так называемого манифеста Agile, и с учетом точки зрения пользователей в первую очередь.
Инструменты Agile QA:
Тестирование API
Как и юнит-тестирование, этот тип относится к так называемому «code level testing», то есть имеет дело непосредственно с исходным кодом приложения. Разница с юнит- в том, что юнит-тесты обычно делают разработчики, а API тестирует QA-команда.
Тестирование черного ящика
Нельзя не упомянуть в общем списке и такой тип. «Тестирование по черному ящику» это проверка функциональности без глубокого ознакомления с техническими «внутренностями» приложения, то есть не зная его исходный код и архитектуру.
Тестирование белого ящика
Проверка приложения со знанием его исходного кода и архитектуры.
О черном и белом ящиках, которые ждут Junior QA — здесь.
Тестирование безопасности
Как понятно из названия, такие тесты гарантируют безопасность приложения/сайта; выявляют и предотвращают «дыры» в его подсистеме безопасности. Тестировщики, специализирующиеся на таком тестировании, работают как вручную, так и инструментами:
Юзабилити-тестирование
Оценка (и последующая коррекция) общего удобства пользования приложением/сайтом. Насколько приложение юзабельно, то есть «дружественно к пользователю»?
Разумеется, на это нужно смотреть в первую очередь с точки зрения пользователя, а не члена ИТ-команды, и именно массового, «среднего пользователя»; поэтому к тестированию часто привлекают обычных людей-пользователей, «добровольцев» или за оплату.
Как это делается, и много дополнительной информации по юзабилити, например чеклисты — в нашем большом гайде; Artsiom Rusau одобряет.
Инструменты проверки юзабилити:
Тестирование масштабируемости
Легко ли масштабировать приложение? То есть, легко ли, и быстро ли, расширяются его возможности в программном и аппаратном измерении? Что произойдет, если количество пользователей, объемы данных, количество транзакций — возрастут в разы? Или десятки, сотни раз.
Тестирование надежности
Насколько приложение надёжное, «выносливое»? Сколько времени оно сумеет проработать «без единого отказа», и при каких условиях происходит отказ? Что провоцирует ошибки в приложении?
Например, нужно не допустить ситуации, когда важная личная информация пользователей хранится в базе данных под управлением нашего приложения, и затем, после нескольких месяцев работы, эта информация удаляется, внезапно и бесповоротно, из-за каких-то ошибок в коде приложения, вовремя не выявленных. Выявлять и устранять подобные ошибки — задача тестирования надежности (reliability testing).
Приемочное тестирование
Компания-клиент, получая готовый программный продукт, проводит приемочное тестирование (User Acceptance Testing = UAT). Оценивает, можно ли принимать софт, исходя из пользовательских требований и предпочтений. Если они не удовлетворены, или если просто клиенту не нравится что-либо в приложении, команде, работавшей над софтом, будет подан запрос на изменения.
***
Это не все виды и типы QA-тестирования. Более полно — в нашем Учебнике (там уже более 220 материалов по QA, и мы практически каждый день пополняем его). Как говорят, feel free, не стесняйтесь пользоваться, там удобнее все классифицировано по разделам. Любые вопросы, замечания, замеченные неточности/ошибки — смело пишите в коментах здесь, или в ТГ-канале, мы все читаем, и учитываем мнения наших читателей/подписчиков.
Подробнее об основных инструментах автоматизации тестирования можно почитать здесь — а также оценить «портрет среднего тестировщика» в 2022-2023.
Подписка на телеграм-канал, посвященный только и исключительно автоматизации QA — здесь. А официальный канал TestEngineer — здесь.
