Пирамида тестирования, уровни и виды тестирования

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

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

Піраміда тестування на практиці. Як працює QA в Jiji

В классической и наиболее распространённой модели пирамиды тестирования выделяются 3 основных уровня. Первый уровень — это юнит-тесты (Unit testing), которые проверяют отдельные небольшие компоненты или функции и должны составлять основную часть тестов. Второй уровень включает интеграционные тесты (Integration testing), направленные на проверку взаимодействия между несколькими модулями или компонентами. Третий уровень — системные тесты (System testing), которые охватывают проверку всей системы целиком. Тем не менее, согласно стандарту ISTQB и некоторым авторитетным источникам, пирамиду тестирования можно рассматривать как состоящую из четырёх уровней. В этой более детализированной модели к трем перечисленным добавляется приёмочное тестирование (Acceptance testing) или E2E тесты (End-to-End), которые выполняются с точки зрения пользователя и служат для проверки соответствия системы бизнес-требованиям, включая проверку графического интерфейса (GUI тесты).

Главные уровни в пирамиде тестирования такие:

1. Юнит-тесты (Unit testing) — проверка отдельных небольших компонентов или функций. Они наиболее многочисленные и быстрые. Юнист тест создаёт разработчик и он же занимается его тестирование, а не QA Engineer.
2. Интеграционные тесты (Integration testing) — тестирование взаимодействия между несколькими модулями или компонентами. Возможно подключение для тестов QA Engineer.
3. Системные тесты (System testing) — проверка всего комплекса приложения целиком. Уровень тестирования, на котором мы проводим тестирование целой системы или приложения, который полностью разработан и уже готов к потенциальному релизу. На этом уровне мы тестируем систему, приложение в целом, проводим тестирование на всех необходимых браузерах или операционных системах (если десктоп-приложение) и проводим все необходимые типы тестирования, такие как: функциональное, тестирование безопасности, тестирование юзабилити, тестирование производительности, тестирование нагрузки и т.д.
4. E2E тестирование (End-to-End тесты), Приемочные тесты (Acceptance testing)/ GUI тесты — тесты, выполняемые с точки зрения пользователя, проходят ли система по требованиям. Тестирование графического интерфейс пользователя - полностью отвечает QA Engineer.

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

Пирамида тестирования, в том числе, помогает наглядно объяснить причины, почему количество Unit тестов должно быть больше чем интеграционных. Части треугольника закрашенные разными цветами подразумевают количество необходимых тестов данной категории, чем больше площадь, тем больше тестов. Чем ниже находятся на пирамиде тесты, тем:

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

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

Уровень тестирования – активности тестирования, объединенные в группу исходя из общих характеристик, связанных с SDLC. Уровни тестирования над чем происходит тестирования.

В Тестировании ПО можно выделить 4 типовых уровня. В общепринятом мнении 4 уровня тестирования, но существует уровень операционное тестирование, которое находится между системным тестом и E2E приемочным тестом.

1. Компонентное (модульное) тестирование (Component testing or Unit testing) - модуль – это самая маленькая функциональная часть программы или приложения, которая не может функционировать отдельно, а только в сочетании с другими модулями. Однако после разработки этого модуля мы уже можем приступить к тестированию и найти несоответствия с нашими требованиями. Модульное тестирование состоит в тестировании этого отдельного модуля как части программы, имея в виду, что это только модуль, и он не может существовать самостоятельно и быть частью приложения программы.
2. Интеграционное тестирование (Integration Testing) - следующий уровень тестирования, проводимый после Модульного тестирования. После того, как отдельные модули нашего приложения были протестированы, нам следует провести Интеграционное Тестирование, чтобы убедиться, что наши модули успешно функционируют в связке друг с другом. То есть тестируем 2 и более связанных модуля, чтобы проверить, прошла ли интергация успешно и без явных багов.
3. Системное тестирование (System Testing) - уровень тестирования, на котором мы проводим тестирование целой системы или приложения, который полностью разработан и уже готов к потенциальному релизу. На этом уровне мы тестируем систему, приложение в целом, проводим тестирование на всех необходимых браузерах или операционных системах (если десктоп-приложение) и проводим все необходимые типы тестирования, такие как: функциональное, тестирование безопасности, тестирование юзабилити, тестирование производительности, тестирование нагрузки и т.д.
4. Приемное тестирование (Acceptance Testing) - после успешного завершения Системного Тестирования, продукт проходит уровень Приемного Тестирования, обычно проводимого заказчиком или любыми другими заинтересованными лицами, с целью убеждения, что продукт выглядит так и работает так, как требовалось с самого начала и описано в требованиях к продукту. Приемное тестирование также может проводиться после каждого из вышеописанных уровней тестирования.

Существует множество видов тестирования, которые QA-инженер применяет в зависимости от целей и задач. Основные виды тестирования можно разделить на функциональные и нефункциональные.

Функциональное тестирование – один из видов тестирования, направленного на проверку соответствия функциональных требований ПО к его реальным характеристикам. Основной задачей функционального тестирования является подтверждение того, что разрабатываемый программный продукт имеет весь функционал, необходимый заказчику. Функциональные виды тестирования включают в себя 4 вида:

1. Функциональное тестирование (Functional testing) — проверка, что программное обеспечение выполняет все необходимые функции согласно спецификации.
2. Тестирование графического пользовательского интерфейса (GUI Testing): шрифт, размер, цвет и поведение их. GUI частный случай (UI). Консистентное поведение (consistent behavior) – это постоянство и предсказуемость реакций интерфейса или системы, когда все элементы работают одинаково в подобных ситуациях, обеспечивая пользователю понятность и комфорт при взаимодействии.
3. Тестирование безопасности (Security Testing) — проверка защиты системы от атак и уязвимостей.
4. Тестирование взаимодействия (Interoperability Testing) — проверка совместимости с другими системами или компонентами.

1. Тестирование продуктивности
2. Тестирование удобства использования (Usability Testing) — проверка удобства и понятности интерфейса для пользователя. Сюда входит: User eXperince (UX) - совокупность ощущений, впечатлений и эмоций пользователя при взаимодействии с продуктом, сайтом или сервисом; User interface (UI) - совокупность всех элементов, через которые происходит взаимодействие пользователя с веб-ресурсом или программой.
3. Тестирование отказоустойчивости и восстановления (Failover and recovery testing), например при внезапном выключении электричества ваши данные в приложении должны сохраниться. Проверяет тестируемый продукт с точки зрения способности противостоять и успешно восстанавливаться после возможных сбоев, возникших в связи с ошибками программного обеспечения, отказами оборудования или проблемами связи (например, отказ сети).
4. Конфигурационное тестирование (Configuration testing): Специальный вид тестирования, направленный на проверку работы программного обеспечения при различных конфигурациях системы (заявленных платформ, поддерживаемых драйверов, при разных конфигурациях компьютеров и т.п.).
5. Тестирование установки (Installation Testing) — проверка процесса установки, обновления и удаление (в случае мобильных приложений) ПО.
6. Тестирование локализации (Localization Testing) — проверка адаптации программы под конкретные языковые и культурные особенности.

1. Нагрузочное тестирование (Perfomance and Load Testing) — проверка поведения системы под высокой нагрузкой. Оценка скорости, отзывчивости и стабильности работы. Это автоматизированное тестирование, имитирующее работу определенного количества бизнес-пользователей на любом общем (разделяемом ими) ресурсе.
2. Стресс-тестирование (Stress Testing) — тестирование на предельных возможностях системы. Позволяет проверить, насколько приложение и система в целом трудоспособны в условиях стресса, а также оценить способность системы к регенерации, т.е. до нормального состояния после прекращения влияния стресса. Стрессом в этом контексте может быть повышение интенсивности выполнения операций к очень высоким значениям или аварийное изменение конфигурации сервера.
3. Тестирование стабильности / надежности (Stability / reliability testing) - Задачей тестирования стабильности (надежности) есть проверка работоспособности приложению во время длительного (многочасового) тестирование с средним уровнем погрузки.
4. Объемное тестирование (Volume testing) - тестирование баз данных, оценка продуктивности базы данных. Задачей объемного тестирование есть получение оценки производительности при увеличении объемов данных в базе данных приложения.

1. Дымовое тестирование (Smoke Testing) — базовые проверки перед началом более глубокого тестирования и/или проверка приложения на запуск и выполнения базовых функций. Рассматривается как краткий цикл тестов, выполняемый для подтверждение того, что после составления кода (нового или исправленного) устанавливаемое приложение стартует и выполняет основные функции.
2. Регрессионное тестирование (Regression Testing) — повторное тестирование для проверки, что исправления не нарушили (фикс бага) другую функциональность. Финальный набор тестов, где проверяется всё. Обычно автоматизируют. Regression testing – проверяется то, что исправления багов, а также какие-либо изменения в коде приложения, не повлияли на другие модули ПО и не повлекли за собой новых багов. Это вид тестирования, направленный на проверку изменений, сделанных в приложении или окружающем среде (исправление дефекта, слияние кода, миграция на другую операционную систему, базу данных, вебсервер или сервер приложения), для подтверждения того факта, что существующая ранее функциональность работает по-прежнему. Регрессионными могут быть как функциональные, так и нефункциональные тесты.
3. Повторное тестирование (Re-testing) - проверка на исправление конкретного бага, а не всей системы.
4. Тестирование сборки (Build Verification Test, BVT) это набор быстрых и базовых тестов, который выполняется при каждой новой сборке программного обеспечения. Как я понимаю, это проверка кода благодаря автоматическому тестированию и отчетности на этапе непрерывной интеграции CI/CD и делают его программисты и DevOps.
5. Санитарное тестирование (Sanity Testing) - проверка конкретной функция, что она работает согласно заявленным в спецификации требованиям. Обычно выполняется вручную. Санити – это быстрая проверка стабильности системы, иногда применяемая после основных изменений, но не непосредственно после багфикса.

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

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

Статическое тестирование — это проверка продукта без его запуска. Например, когда другой разработчик внимательно просматривает код (code review), или когда проверяют требования, документы и дизайны, чтобы найти ошибки до того, как программа начнёт работать. Статическое тестирование начинается на ранних этапах жизненного цикла ПО и, соответственно, является частью процесса верификации. Для этого типа тестирования в некоторых случаях даже не нужен компьютер – например, при проверке требований.

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

Свободное тестирование (Ad-hoc testing) - вид тестирования, который выполняется без подготовки к тестированию продукта, без определения ожидаемых результатов, проектирования тестовых сценариев. Это неформальное, импровизационное тестирование. Оно не требует никакой документации, планирования, процессов, которые следует соблюдать при выполнении тестирования.

Исследовательское тестирование (Еxploratory testing) – это одновременное изучение программного продукта, проектирование тестов и их выполнение. Это неформальный метод проектирования тестов, при котором тестировщик активно контролирует проектирование тестов, в то время как эти тесты выполняются, и использует полученную во время тестирования информацию для проектирования новых тестов.

1. Пре Альфа (Pre Alpha): Программное обеспечение является прототипом. Пользовательский интерфейс завершен, но не все функции завершены. На этом этапе программное обеспечение не публикуется.
2. Альфа (Alpha): Разработка программного обеспечения подошла к концу, и программное обеспечение внутренне проверено на наличие ошибок и проблем.
3. Бета (Beta): Программное обеспечение стабильно и выпущено ограниченному числу пользователей. Цель состоит в том, чтобы получить отзывы клиентов о продукте и внести соответствующие изменения в программное обеспечение.
4. Релиз-кандидат (Release Candidate): На основе отзывов бета-теста вносятся изменения в программное обеспечение и проверяется исправление ошибок. На этом этапе функциональность радикально не меняется. Релиз-кандидат также выставляется общественности.
5. Релиз (Release): Все работает, программное обеспечение выпущено для общего пользования.

• Black-box: Проверка "черного ящика" - это метод тестирования программного обеспечения, при котором функциональность исследуется без рассмотрения кода, деталей реализации и знаний о внутреннем устройстве программного обеспечения (ПО). Тестировщики пишут тест-кейсы, опираясь только на требования и спецификации программного обеспечения. Позволяет быстро обнаружить ошибки в функциональных спецификациях. Тестировщику не требуется дополнительная квалификация. Тестирование проходит с позиции пользователя. Составлять тест-кейсы можно сразу после подготовки спецификации.
• White-box: У этого метода есть несколько названий ("стеклянный ящик", "открытый ящик" и др.), но чаще всего его все-таки называют методом "белого ящика". Проверка "белого ящика" - это метод тестирования программного обеспечения, предполагающий, что внутренняя структура, устройство и реализация системы известны тестировщику. Оптимизация кода путём нахождения скрытых ошибок. Как правило, таким видом тестирования на проектах занимаются сами программисты, ведь для использования этого метода тестировщик должен обладать достаточно высокой квалификацией.
• Gray-box: Проверка серого ящика - это метод тестирования программного продукта или приложения с частичным знанием его внутреннего устройства. Для выполнения тестирования "серого ящика" нет необходимости в доступе тестировщика к исходному коду. Тесты пишутся на основе знания алгоритма, архитектуры, внутренних состояний или других высокоуровневых описаний поведения программы. Тестировщик работает совместно с разработчиком, что позволяет на начальном этапе убрать избыточные тест-кейсы. Наибольшая эффективность применения "серого ящика" достигается при тестировании web-приложений, web-сервисов, безопасности, GUI, а также для функционального тестирования.

• L10n Локализация программного обеспечения
• i18n Интернационализация

Как можно понять из терминов «интернационализация и локализация» – это процесс придания продукту свойств определенной народности, местности, расположения. Для успешной реализации продукта во всех необходимых нам странах нужно уделять внимание не только техническому переводу элементов интерфейса на язык страны-покупателя.

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

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

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

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

Локализация это процесс адаптации программного продукта к языку и культуре клиента. Данный процесс адаптации включает в себя:

• Перевод пользовательского интерфейса.
• Перевод документации.
• Контроль формата даты и времени.
• Внимание к денежным единицам.
• Внимание к правовым особенностям.
• Раскладка клавиатуры пользователя.
• Контроль символики и цвета.
• Толкование текста, символов, знаков.
• И другие подобные аспекты.

1. Автоматизированное тестирование — использование инструментов для автоматизации выполнения тестов.
2. Ручное тестирование — выполнение тестов вручную, основанное на опыте и интуиции.

Эти виды тестирования часто комбинируют для обеспечения всесторонней проверки качества продукта и выявления багов на разных уровнях и стадиях разработки.

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

Тестирование требований: как находить ошибки в бизнес-логике фичи перед тем, как их закодят.

1. Единственность – требование описывает одну и только одну вещь.
2. Завершенность – требование полностью определено в одном месте и вся необходимая информация присутствует
3. Последовательность – требование не противоречит другим требованиям и полностью соответствует внешней документации.
4. Атомарность – требование не может быть разбито на ряд более подробных требований без потери завершенности.
5. Отслеживаемость – требование полностью или частично отвечает деловым потребностям, как заявлено заинтересованными лицами и документировано.
6. Актуальность – требование не стало устаревшим с течением времени.
7. Осуществимость – требование может быть реализовано в пределах проекта.
8. Недвусмысленность – определение не содержащее нечетких фраз.
9. Обязательность - требование представляет определенную заинтересованную личность характеристику, отсутствие которой приведет к неполноценности решения, которое не может быть проигнорировано.

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

• непонятность требований,
• частая сменяемость,
• изменения, вносимые в последний момент,
• неправильная трактовка требований.

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

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

Техники тестирования требований:

• Беглый просмотр – автор показывает свою работу коллегам, они в свою очередь дают свои рекомендации, высказывают свои вопросы и замечания.
• Технический просмотр – выполняется группой специалистов;
• Формальная инспекция – привлекается большое количество специалистов, представляет собой структурированный, систематизированный и документированный подход. Минус такого варианта – тратится много времени.

2. Вопросы. Если возникают вопросы, то можно спрашивать у представителей заказчика, более опытных колег.

3. Тест-кейсы и чек-листы. Хорошее требование должно быть проверяемым, чтобы это определить, можно использовать чек-листы или полноценные тест-кейсы. Если можно быстро придумать несколько пунктов чек-листа – это уже хороший знак.

4. Исследование поведения системы. Необходимо мысленно смоделировать процесс работы пользователя с системой, созданной по тестируемым требованиям, затем определить неоднозначные варианты определения системы.

5.Рисунки. Графическое представление дает наглядное представление приложения, на рисунке проще увидеть, что какие-то элементы не стыкуются, где-то не хватает и т.д.