Продолжая усваивать и закреплять теорию, полезно разобраться в классификациях тестирования. В разных источниках их представлено бесконечное количество. Если есть желание максимально подробно изучить этот вопрос, милости прошу почитать книгу Святослава Куликова. Я же приведу самые основные и часто встречающиеся на собеседованиях и в работе, опираясь на вышеуказанное издание.
Начнём с самого простого, а именно с программного кода нашего приложения.
I. По запуску кода на исполнение.
1. Статическое (static testing). Без запуска. Чаще всего начинается на ранних стадиях жизненного цикла ПО и заключается в тестировании документации. Также к статическому тестированию относится код-ревью - инспекция/вычитка программного кода (без его запуска на выполнение) на соответствие принятым в компании стандартам. Статическое тестирование является частью процесса верификации (насколько продукт соответствует требованиям и спецификации)
2. Динамическое (dynamic testing). С запуском. Динамическое тестирование предполагает запуск ранее написанного и скомпилированного кода и является частью процесса валидации ПО (насколько продукт соответствует ожиданиям конечного пользователя). Все дальнейшие классификации видов тестирования относятся к динамическому тестированию.
Ни одно техническое интервью не обходится без вопроса про черноящичное и белоящичное тестирование. Вот что означают эти термины.
II. Классификация по доступу к коду и архитектуре приложения.
1. Метод белого ящика (white box testing) - у тестировщика есть доступ к внутренней структуре и коду, и есть необходимые знания для понимания увиденного. Может быть как статическим, так и динамическим.
2. Метод чёрного ящика (black box testing) - у тестировщика нет доступа к коду, либо недостаточно знаний для его понимания, либо он намеренно его игнорирует. Другое понимание: тестировщик оказывает на приложение воздействие (и проверяет реакцию) тем же способом, каким на него воздействовали бы пользователи или другие приложения в реальных условиях эксплуатации.
3. Метод серого ящика (grey box testing) - комбинация первых двух методов. Обычно считается, что при тестировании разных частей приложения (у некоторых из них есть доступ к коду, у других - нет), используются методы белого и чёрного ящиков. При этом всё приложение тестируется методом серого ящика. Другое определение: внутренняя структура тестируемого объекта известна частично и выясняется по мере исследования.
Одна из самых очевидных классификаций.
III. Классификация по степени автоматизации.
1. Ручное (manual testing) - тест-кейсы выполняются человеком вручную без использования средств автоматизации.
2. Автоматизированное (automated testing) - набор техник, подходов и инструментов, позволяющих исключить участие человека из выполнения некоторых задач. Стоит отметить, что автоматизированное тестирование может быть и статическим: например, проверка кода на наличие синтаксических ошибок.
Одно из важнейших разделений тестирования ПО.
IV. Классификация по уровню детализации приложения.
1. Модульное (компонентное) (unit testing) - проверка отдельных небольших частей приложения, которые можно исследовать изолировано от подобных частей. Могут проверяться отдельные функции, классы, библиотеки.
2. Интеграционное (integration testing) - проверка взаимодействия между несколькими частями приложения, каждая из которых проверена на стадии компонентного тестирования. Даже если отдельные части идеальны, на стыке их взаимодействия могут возникнуть проблемы.
3. Системное (system testing, end-to-end) - проверка всего приложения, как единое целое.
В зависимости от того, какой набор функций нашего приложения мы тестируем, выделяется следующая классификация.
V. Классификация по степени важности тестируемых функций.
1. Дымовое (smoke test) - проводится после выхода нового билда для определения общего уровня качества. Пороговое значение метрики прохождения тест-кейсов выставляется 100% или близко к этому (все тесты должны завершиться успешно).
2. Тестирование критического пути (critical path test) - существует большинство пользователей, которые чаще всего используют некоторое подмножество функций приложения. Именно эти функции мы должны проверить в первую очередь, после удачного прохождения смоук-теста. Пороговое значение метрики успешного прохождения высокое: 70-80-90%.
3. Расширенное (extended test) - исследование всей заявленной в требованиях функциональности. Также исследуются нетипичные, маловероятные, экзотические сценарии. Пороговое значение метрики успешного прохождения достаточно низкое - около 50%.
Разделение по серьезности ваших намерений в желании сломать приложение.
VI. Классификация по принципам работы с приложением.
1. Позитивное (positive testing) - все действия выполняются по инструкции, без ввода неверных данных. Если позитивные тесты завершаются ошибкой - это тревожный знак.
2. Негативное (negative testing) - проверка приложения при вводе некорректных значений и неправильном поведении. Негативных тест-кейсов всегда намного больше.
Распространенных классификаций осталось не так уж и много, но следующая - очень важная и объемная.
VII. Классификация по целям и задачам.
1. Функциональное тестирование (functional testing) - проверка корректности работы функциональности приложения.
2. Нефункциональное тестирование (non-functional testing) - проверка нефункциональных особенностей: удобство использования, совместимость, производительность и т.д.
3. Инсталляционное тестирование (installation testing) - выявление дефектов, влияющих на протекание установки приложения.
4. Регрессионное тестирование (regression testing) - тестирование проверяет не появились ли новые дефекты после устранения ранее обнаруженных.
5. Повторное тестирование (re-testing) - выполнение тест-кейсов, которые ранее обнаружили дефекты с целью подтверждения устранения дефектов.
6. Приемочное тестирование (acceptance testing) - тестирование, направленное на проверку приложения с точки зрения конечного пользователя/заказчика и вынесения решения, принимает ли заказчик работу у исполнителя. Подвиды:
* производственное приемочное - исследование полноты и качества реализации с точки зрения готовности приложения к передаче заказчику. Выполняется проектной командой;
* операционное приемочное - с точки зрения выполнения инсталляции, потребления ресурсов, совместимости;
* итоговое приемочное - тестирование конечными пользователями/заказчиком в реальных условиях эксплуатации. Выносится решение, требуются ли доработки и готово ли к эксплуатации.
7. Операционное тестирование (operational testing) - тестирование в реальной или приближенной к реальной операционной среде (ОС, СУБД, серверы, веб-серверы и т.д.)
8. Тестирование удобства использования (usability testing) - направлено на исследование того, насколько конечному пользователю понятно, как работать с продуктом, и насколько ему нравится пользоваться продуктом.
9. Тестирование доступности (accessibility testing) - исследование пригодности продукта для использования людьми с ограниченными возможностями.
10. Тестирование интерфейса (interface testing) - проверка интерфейсов приложения или его компонентов. Сюда относятся GUI (графический интерфейс), CLI (командная строка) и API (программный интерфейс приложения).
11. Тестирование безопасности (security testing) - проверка способности приложения противостоять действиям злоумышленников (получение доступа к данным и функциям).
12. Тестирование интернационализации (internationalisation testing) - проверка готовности продукта к работе с использованием различных языков и с учетом различных культурных особенностей.
13. Тестирование локализации (localisation testing) - проверка корректности и качества адаптации продукта к использованию на том или ином языке и с учетом культурных особенностей.
14. Тестирование совместимости (compatibility testing) - проверка способности приложения работать в указанном окружении. Проверяется совместимость с аппаратной платформой, ОС, браузерами, мобильными устройствами и т.д.)
15. Тестирование данных и баз данных (data quality testing) - исследование полноты, непротиворечивости, целостности, структурированности данных.
16. Тестирование использования ресурсов (resource utilisation testing) - проверка эффективности использования приложением доступных ему ресурсов.
17. Сравнительное тестирование (comparison testing) - сравнительный анализ преимуществ и недостатков по отношению к конкурентам.
18. Демонстрационное тестирование (qualification testing) - демонстрация заказчику продукта с целью подтверждения соответствия продукта всем заявленным требованиям.
19. Исчерпывающее тестирование (exhaustive testing) - тестирование с применением всех возможных комбинаций всех возможных входных данных.
20. Тестирование надежности (reliability testing) - тестирование способности приложения выполнять свои функции на протяжении заданного времени в заданных условиях.
21. Тестирование восстанавливаемости (recoverability testing) - тестирование способности приложения восстанавливать свои функции и заданный уровень производительности в случае возникновения критической ситуации.
22. Тестирование отказоустойчивости (failover testing) - эмуляция или реальное создание критической ситуации с целью проверки способности приложения задействовать механизмы, предотвращающие повреждение данных, нарушение работоспособности и пр.
23. Тестирование производительности (performance testing) - исследование показателей скорости реакции приложения на внешние воздействия при различной нагрузке. Подвиды:
* нагрузочное (load testing) - проверка способности приложения сохранять заданные показатели качества при нагрузке в допустимых пределах и некотором превышении этих пределов;
* тестирование масштабируемости (scalability testing) - проверка способности увеличивать показатели производительности с увеличением количества доступных ресурсов;
* объемное (volume testing) - проверка производительности при обработке больших объемов данных;
* стрессовое (stress testing) - проверка поведения приложения при нештатных изменениях нагрузки, значительно превышающих расчетный уровень;
* конкурентное (concurrency testing) - проверка поведения приложения при поступлении большого количества одновременно поступающих запросов.
В зависимости от того, кто тестирует приложение, немного греческого алфавита.
VIII. Классификация по привлечению конечных пользователей.
1. Альфа-тестирование (alpha-testing) - основное тестирование выполняется командой-разработчиком, возможно частичное привлечение конечных пользователей.
2. Бета-тестирование (beta-testing) - тестирование с активным привлечением конечных пользователей вне организации-разработчика.
3. Гамма-тестирование (gamma-testing) - финальная стадия тестирования перед выпуском продукта, направленная на исправление незначительных дефектов, выявленных на стадии бета-тестирования.
Подготовка перед тестированием может быть основательной, а может и отсутствовать вовсе.
IX. Классификация по степени формализации.
1. Тестирование на основе тест-кейсов (test-cases based testing) - тестирование происходит на основе заранее подготовленной документации: тест-кейсов или тестовых наборов.
2. Исследовательское тестирование (exploratory testing) - тестировщик выполняет работу с приложением по выбранному сценарию, который дорабатывается в процессе с целью более полного исследования приложения.
3. Свободное интуитивное тестирование (ad hoc testing) - тестировщик опирается на профессионализм и интуицию, не использует ни тест-кейсов, ни сценариев, ни чек-листов. Спонтанно выполняются действия, способные привести к ошибке.
В следующий раз мы обсудим техники тест-дизайна, которые помогут создать минимальное количество тест-кейсов для выявления максимального количества дефектов.
