Виды тестовые сценарии

Привет! Да-да, про тестирование ПО тут уже куча статей. Здесь я просто буду стараться структурировать как можно более полный охват данных из разных источников (чтобы по теории все основное было сразу в одном месте, и новичкам, например, было легче ориентироваться). При этом, чтобы статья не казалась слишком громоздкой, информация будет представлена без излишней детализации, как необходимая и достаточная для прохождения собеседования (согласно моему опыту), рассчитанное на стажеров/джунов.

ОСНОВНЫЕ ТЕРМИНЫ

Обеспечение качества (Quality Assurance) — изучение возможностей по изменению и улучшению процесса разработки, улучшению коммуникаций в команде, где тестирование является только одним из аспектов обеспечения качества.

Контроль качества (Quality Control) — анализ результатов тестирования и качества новых версий выпускаемого продукта.

Тестирование ПО (Software Testing) — проверка соответствия между реальным и ожидаемым поведением программы, проводится на наборе тестов, который выбирается некоторым образом.

Это одна из техник QC, включающая в себя:

• планирование работ (Test Management)

• проектирование тестов (Test Design)

• выполнение тестирования (Test Execution)

• анализ результатов (Test Analysis)

Как взаимосвязаны выше указанные термины хорошо объясняется в статье Разница между тестированием, QC и QA. Здесь я не буду слишком останавливаться на этом, потому что эта статья больше про тестирование ПО.

Основные цели тестирования:

• техническая

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

• коммерческая

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

Дефект (баг) — это несоответствие фактического результата выполнения программы ожидаемому результату.

Следует уметь различать, что:

• Error — это ошибка пользователя, то есть он пытается использовать программу иным способом (например, вводит буквы в поля, где требуется вводить цифры). В качественной программе предусмотрены такие ситуации и выдаются сообщение об ошибке (error message).

• Bug (defect) — это ошибка программиста (или дизайнера или ещё кого, кто принимает участие в разработке), то есть когда в программе, что-то идёт не так, как планировалось. Например, внутри программа построена так, что изначально не соответствует тому, что от неё ожидается.

• Failure — это сбой в работе компонента, всей программы или системы (может быть как аппаратным, так и вызванным дефектом).

Жизненный цикл бага

Атрибуты дефекта

• Серьезность (Severity) — характеризует влияние дефекта на работоспособность приложения. Выставляется тестировщиком.

Градация Серьезности дефекта

• Приоритет (Priority) — указывает на очередность выполнения задачи или устранения дефекта. Чем выше приоритет, тем быстрее нужно исправлять дефект. Выставляется менеджером, тимлидом или заказчиком.

Тест дизайн

Тест дизайн — это этап процесса тестирования ПО, на котором проектируются и создаются тестовые сценарии (тест кейсы), в соответствии с определёнными ранее критериями качества и целями тестирования.

Ответственные за тест дизайн:

• Тест аналитик — определяет «ЧТО тестировать?»

• Тест дизайнер — определяет «КАК тестировать?»

ТЕХНИКИ ТЕСТ-ДИЗАЙНА

1. Эквивалентное Разделение (Equivalence Partitioning — EP). Как пример, есть диапазон допустимых значений от 1 до 10, выбирается одно верное значение внутри интервала (например, 5) и одно неверное значение вне интервала — 0.

2. Анализ Граничных Значений (Boundary Value Analysis — BVA). Если брать пример выше, в качестве значений для позитивного тестирования берется минимальная и максимальная границы (1 и 10), и значения больше и меньше границ (0 и 11). BVA может применяться к полям, записям, файлам, или к любого рода сущностям имеющим ограничения.

3. Причина / Следствие (Cause/Effect — CE). Подразумевается ввод условий, для получения ответа от системы (следствие).

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

5. Исчерпывающее тестирование (Exhaustive Testing — ET) — подразумевается проверка всех возможные комбинации входных значений. На практике не используется.

6. Попарное тестирование (Pairwise Testing) — это техника формирования наборов тестовых данных. Используется для тестирования сущностей с большими наборами входных данных (например, фильтры, сортировки). Преимущество данной техники в том, что она сокращает общее количество тест-кейсов, тем самым уменьшая время и расходы, затраченные на тестирование. Эта техника заслуживает отдельного внимания и более подробно рассматривается здесь. Также в конце данной статьи есть инструменты для автоматизации этой техники.

7. Таблица принятия решений (decision table) — инструмент для упорядочения сложных бизнес-требований, которые должны быть реализованы в продукте. В таблицах решений представлен набор условий, одновременное выполнение которых приводит к определенному действию.

ВИДЫ ТЕСТИРОВАНИЯ

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

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

• Тестирование пользовательского интерфейса (GUI Testing)  — функциональная проверка интерфейса на соответствие требованиям (размер, шрифт, цвет, consistent behavior).

• Тестирование удобства пользования (Usability Testing) — это метод тестирования, направленный на установление степени удобства использования, обучаемости, понятности и привлекательности для пользователей разрабатываемого продукта в контексте заданных условий. Сюда также входит:
  User eXperience (UX) — ощущение, испытываемое пользователем во время использования цифрового продукта, в то время как User interface — это инструмент, позволяющий осуществлять интеракцию «пользователь — веб-ресурс».

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

• Тестирование установки (Installation testing) направленно на проверку успешной инсталляции и настройки, а также обновления или удаления программного обеспечения.

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

• Тестирование взаимодействия (Interoperability Testing) — это функциональное тестирование, проверяющее способность приложения взаимодействовать с одним и более компонентами или системами и включающее в себя тестирование совместимости (compatibility testing) и интеграционное тестирование

• Тестирование на отказ и восстановление (Failover and Recovery Testing) проверяет тестируемый продукт с точки зрения способности противостоять и успешно восстанавливаться после возможных сбоев, возникших в связи с ошибками программного обеспечения, отказами оборудования или проблемами связи (например, отказ сети). Целью данного вида тестирования является проверка систем восстановления (или дублирующих основной функционал систем), которые, в случае возникновения сбоев, обеспечат сохранность и целостность данных тестируемого продукта.

• Нагрузочное тестирование — это автоматизированное тестирование, имитирующее работу определенного количества бизнес пользователей на каком-либо общем (разделяемом ими) ресурсе.

• Тестирование стабильности или надежности (Stability / Reliability Testing). Задачей тестирования стабильности (надежности) является проверка работоспособности приложения при длительном (многочасовом) тестировании со средним уровнем нагрузки.

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

• Объемное тестирование (Volume Testing). Задачей объемного тестирования является получение оценки производительности при увеличении объемов данных в базе данных приложения

По виду Тестовых Сценариев:

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

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

По Уровню Тестирования:

• Модульное тестирование (Unit Testing) Компонентное — проверяет функциональность и ищет дефекты в частях приложения, которые доступны и могут быть протестированы по-отдельности (модули программ, объекты, классы, функции и т.д.).

• Интеграционное тестирование (Integration Testing) Проверяется взаимодействие между компонентами системы после проведения компонентного тестирования.

Подходы к интеграционному тестированию

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

• Операционное тестирование (Release Testing). Даже если система удовлетворяет всем требованиям, важно убедиться в том, что она удовлетворяет нуждам пользователя и выполняет свою роль в среде своей эксплуатации. Поэтому так важно провести операционное тестирование как финальный шаг валидации. Кроме этого, тестирование в среде эксплуатации позволяет выявить и нефункциональные проблемы, такие как: конфликт с другими системами, смежными в области бизнеса или в программных и электронных окружениях и др. Очевидно, что нахождение подобных вещей на стадии внедрения — критичная и дорогостоящая проблема.

Cтатическое и динамическое тестирование

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

Исследовательское / ad-hoc тестирование

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

Разница между ad hoc и exploratory testing в том, что теоретически, ad hoc может провести кто угодно, а для проведения exploratory необходимо мастерство и владение определенными техниками.

Дымовое (Smoke) тестирование рассматривается как короткий цикл тестов, выполняемый для подтверждения того, что после сборки кода (нового или исправленного) устанавливаемое приложение, стартует и выполняет основные функции.

Тестирование сборки (Build Verification Test) — тестирование направленное на определение соответствия, выпущенной версии, критериям качества для начала тестирования. По своим целям является аналогом Дымового Тестирования, направленного на приемку новой версии в дальнейшее тестирование или эксплуатацию. Вглубь оно может проникать дальше, в зависимости от требований к качеству выпущенной версии.

Повторное тестирование — тестирование, во время которого исполняются тестовые сценарии, выявившие ошибки во время последнего запуска, для подтверждения успешности исправления этих ошибок. В чем разница между regression testing и re-testing? Re-testing — проверяется исправление багов Regression testing — проверяется то, что исправление багов, а также любые изменения в коде приложения, не повлияли на другие модули ПО и не вызвало новых багов.

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

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

ДОКУМЕНТАЦИЯ

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

Основные атрибуты требований:

• Полнота — в требовании должна содержаться вся необходимая для реализации функциональности информация.

• Непротиворечивость — требование не должно содержать внутренних противоречий и противоречий другим требованиям и документам.

• Недвусмысленность — требование должно содержать однозначные формулировки.

• Проверяемость (тестопригодность) — формулировка требований таким образом, чтобы можно было выставить однозначный вердикт, выполнено все в соответствии с требованиями или нет.

• Приоритетность — у каждого требования должен быть приоритет (количественная оценка степени значимости требования).

Тест план (Test Plan) — документ, описывающий весь объем работ по тестированию ( а также необходимое в процессе работы оборудование, специальные знания, оценки рисков с вариантами их разрешения). Отвечает на вопросы:

• Что нужно тестировать?

• Как будет тестироваться?

• Когда будет тестироваться?

• Критерии начала тестирования.

• Критерии окончания тестирования.

Основные пункты из которых может состоять тест-план перечислены в стандарте IEEE 829.

Неотъемлемой частью тест-плана является Traceability matrix — Матрица соответствия требований (МСТ) — это таблица, содержащая соответствие функциональных требований (functional requirements) продукта и подготовленных тестовых сценариев (test cases). В заголовках колонок таблицы расположены требования, а в заголовках строк — тестовые сценарии. На пересечении — отметка, означающая, что требование текущей колонки покрыто тестовым сценарием текущей строки. МСТ используется для валидации покрытия продукта тестами.

Чек-лист (check list) — это документ, описывающий что должно быть протестировано. На сколько детальным будет чек-лист зависит от требований к отчетности, уровня знания продукта сотрудниками и сложности продукта. Чаще всего, в ЧЛ содержатся только действия, без ожидаемого результата. ЧЛ менее формализован, чем тестовый сценарий, ассоциируется с гибкими подходами в тестировании.

Тестовый сценарий (Test Case) — это документ, в котором содержатся условия, шаги и другие параметры для проверки реализации тестируемой функции или её части.

Тест-кейс состоит из:

• Названия

• Более подробного описания сути проводимого кейса (для более сложных кейсов)

• Описания окружения

• Указания тестируемого компонента приложения

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

• Шагов — Steps — cписок действий, переводящих систему из одного состояния в другое, для получения результата

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

• и иногда Постусловия — PostConditions — для перевода системы в первоначальное состояние, как до проведения теста (initial state)

Из тестовых сценариев, сгруппированных по некоему признаку (например, тестируемой функциональности), получаются некоторые наборы. Они могут быть как зависящими от последовательности выполнения (результат выполнения предыдущего является предварительным условием для следующего — этоTest script), так и независимыми (Test suite).

Наиболее часто выделяются наборы для:

• Smoke тестирования

• приёмо-сдаточных испытаний.

Баг Репорт (Bug Report) — это документ, описывающий ситуацию или последовательность действий приведшую к некорректной работе функциональности.

Огромное спасибо @alexlobach и @Gennadii_M за статьи! Большая часть информации взята именно оттуда.

UPD: статья пополняется. Спасибо @yakoeka

• Функциональные виды
• Нефункциональные виды
• Общий список

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

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

Более подробно и на английском:

Еще более сложная классификация (кликабельно):

Еще один вариант:

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

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

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

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

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

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

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

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

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

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

• UFT (ранее известный как QTP) 
• Selenium 
• JUnit
• SoapUI
• Watir

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• Jasmine
• Mocha

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

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

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

• Cucumber
• Protractor
• Jasmine
• Karma
• SpecFlow

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

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

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

• Monkey test for Android
• Saucelabs
• Protractor

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

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

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

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

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

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

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

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

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

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

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

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

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

Отдельный материал по 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

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

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

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

• LoadRunner
• WebLoad
• JMeter

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

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

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

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

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

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

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

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

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

• JIRA
• PractiTest
• JunoOne
• VersionOne
• TestRail
• SoapUI

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

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

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

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

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

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

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

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

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

• Arachni
• Iron Wasp
• Nogotofail
• SQLMap
• W3af
• Wapiti
• Wfuzz
• Zed Attack Proxy

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

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

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

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

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

• Optimizely
• Qualaroo
• Crazy Egg
• Usabilla
• Clicktale
• Five Second Test
• Chalkmark
• UXtweak

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

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

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

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

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

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

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

***

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

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

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

Этапы тестирования

1️⃣ Анализ требований. Тестирование начинают на этапе разработки требований к ПО. Во время проектирования тестировщики определяют, какие аспекты архитектуры можно тестировать и с какими параметрами эти тесты работают.

2️⃣ Планирование тестирования. На этом этапе разрабатывают стратегию, план, тестовый стенд. Это нужно, чтобы упростить работу.

3️⃣ Разработка тестов. Сюда относят создание и описание процедуры тестирования, сценариев, наборов тестовых данных. 

4️⃣ Выполнение. Тестировщики выполняют программное обеспечение на основе планов и тестовых документов. Собирают список ошибок и передают команде разработчиков.

5️⃣ Отчеты о тестировании. Создают метрики и составляют окончательные отчеты, готово ли ПО к выпуску. 

6️⃣ Анализ результатов тестирования. Или анализ дефектов, который выполняет команда разработчиков вместе с клиентом. Решают, какие дефекты исправить, а какие — отклонить. Например, потому что поведение ПО на самом деле корректное, то есть ожидаемое.

7️⃣ Повторное тестирование дефекта. Когда команда разработчиков устраняет дефект, его повторно проверяют тестировщики. 

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

9️⃣ Завершение теста. К этому этапу переходят, когда решают, что тест пройден и поведение ПО соответствует критериям. Архивируют сведения об основных выходных данных, результаты, журналы и документы. Их используют в качестве справочных материалов для будущих проектов.

Этапы тестирования в разных компаниях могут отличаться. Они зависят от методологии разработки ПО. Список выше подходит для методологии «модель водопада». А в компаниях, которые применяют экстремальное программирование или «гибкую методологию», этапы могут быть другими, так как тестирование интегрировано в написание кода. Такой принцип называют «разработкой через тестирование».

«Создать процесс, в котором сложно допустить ошибку, — вот настоящая цель тестирования. Мы не можем полностью избавиться от ошибок, но можем построить работу так, что сделать сразу правильно будет легче, чем ошибиться».

Джефф Каролло

«Как тестируют в Google»

Виды тестирования

🔎 По запуску кода на исполнение

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

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

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

🔎 По доступу к коду и архитектуре

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

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

Метод «серого ящика». Совокупность двух предыдущих методов. В первом методе тестировщик не смотрит на код, не знает структуру программы, во втором — смотрит и знает. В методе «серого ящика» тестировщик знает только структуры данных приложения. Он пытается составить тестовые наборы так, чтобы выявить ошибки, связанные с неправильным использованием данных или программы.

🔎 По уровню тестирования

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

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

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

Компоненты тестируют по очереди или все вместе. Первый вариант самый удобный: можно быстрее обнаружить и исправить проблемы с интерфейсом. 

Интеграционные тесты обычно включают много кода. Это влияет на простоту локализации ошибки в случае сбоя. Чтобы решить эту проблему, разрезают большие тесты на более мелкие.

Системное. Это тестирование программной системы, чтобы оценить ее по всем требованиям.

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

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

Приемочное 

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

✅ Эксплуатационные приемочные испытания (OAT). Их используют, чтобы проверить предварительный выпуск продукта, услуги или системы. OAT — это распространенный тип нефункционального тестирования ПО. Его в основном применяют в проектах разработки и обслуживания программного обеспечения.

✅ Контрактные и нормативные приемочные испытания. Первые выполняют на основе критериев приемки контракта. Вторые — на основе нормативных документов, применяемых к программному продукту. Оба этих тестирования проводят пользователи или тестировщики.

🔎 По методу выполнения тестовых сценариев

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

Автоматизированное. Специалист использует специальные программы, чтобы пройти сценарии пользователя. Это помогает сократить время тестирования и упростить процесс. Автоматизированное тестирование не воспроизводит всё, что делает человек. Зато полезно для регрессионного тестирования, если набор сценариев разработали правильно. 

Главное о видах тестирования ПО

• Тестирование — важная часть процесса разработки программного обеспечения. Основа контроля качества и работоспособности продукта. 
• Это сложный поэтапный процесс. Перед выполнением теста анализируют требования, разрабатывают стратегию тестирования, создают и описывают процедуры.
• Есть несколько видов тестирования программного обеспечения. Например, статическое — без запуска программы, динамическое — с запуском, пассивное — на основе системных журналов. Без доступа или с доступом к коду — методы «черного и белого ящиков». С программными средствами или без них — ручное и автоматизированное.

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

Преподаватели — руководители направления тестирования в ВТБ, Skyeng. Дадут актуальные знания и помогут собрать портфолио. В конце получите диплом государственного образца.