QA_Bible
  • Введение
  • FAQ для новичков
    • Ответы на самые популярные вопросы новичков в чатах
    • Качества и навыки, которыми нужно обладать тестировщику?
    • Что должен знать и уметь Junior? Что спросят на собеседовании?
    • С чего начать обучение и куда развиваться?
    • Как составить резюме?
    • Где искать работу?
    • Как происходит процесс найма?
    • Как проходить собеседование?
    • Начало работы Junior-тестировщика
    • Ошибки в работе у начинающих тестировщиков
    • Как взаимодействовать с коллегами?
    • Перспективы профессии
  • Полезные ссылки
    • Список полезных ресурсов на разных платформах
    • Список ресурсов по инструментам тестировщика
  • Общее
    • QA/QC/Testing
    • Почему требуется тестирование ПО?
    • Качество ПО (Software Quality)
    • Принципы тестирования
    • Верификация и валидация (Verification and Validation)
    • Дефекты и ошибки
    • Серьезность и приоритет Дефекта (Severity & Priority)
    • Альфа- и бета- тестирование (Alpha Testing and Beta Testing)
    • Процесс тестирования (test process) (draft)
    • Техники оценки тестов/оценка трудозатрат на тестирование (Test Estimation)
    • Экономика тестирования/стоимость качества (Cost of quality)
    • Подход к тестированию (Test Approach)
    • Импакт анализ (анализ влияния, Impact Analysis)
    • Анализ первопричин (RCA - Root Cause Analysis)
    • Тестирование со сдвигом влево (Shift left testing)
    • Модель зрелости возможностей (CMM - Capability Maturity Model)
    • Тестовая среда и тестовый стенд (Test Environment/Test Bed)
    • Бизнес-логика (Business logic)
    • Политика отсутствия багов (ZBP - Zero Bug Policy)
    • Независимое тестирование (Independent testing)
    • Роли/должности в команде
    • Эвристики и мнемоники
  • Виды-методы-уровни тестирования
    • Методы тестирования (White/Black/Grey Box)
    • Тестирование методом черного ящика (Black Box Testing)
    • Тестирование методом белого ящика (White Box Testing)
    • Тестирование методом серого ящика (Grey Box Testing)
    • Статическое и динамическое тестирование (Static Testing, Dynamic Testing)
    • Пирамида / уровни тестирования (Test Pyramid / Testing Levels)
    • Модульное/юнит/компонентное тестирование (Module/Unit/Component testing)
    • Интеграционное тестирование (Integration testing)
    • Системное тестирование (System Testing)
    • Приемочное тестирование (AT - Acceptance testing)
    • Основные виды тестирования ПО
    • Функциональное тестирование (Functional/Behavioral testing)
    • Нефункциональное тестирование (Non-Functional testing)
    • Тестирование производительности (Performance testing)
    • Тестирование емкости (Capacity testing)
    • Нагрузочное тестирование (Load testing)
    • Стрессовое тестирование (Stress testing)
    • Тестирование масштабируемости (Scalability testing)
    • Объемное тестирование (Volume testing)
    • Тестирование выносливости/стабильности (Endurance/Soak/Stability testing)
    • Тестирование устойчивости (Resilience testing)
    • Тестирование надежности (Reliability Testing)
    • Тестирование на отказ и восстановление (Failover and Recovery testing)
    • Эталонное и базовое тестирование (Benchmark and Baseline Testing)
    • Тестирование хранилища (Storage testing)
    • Одновременное / многопользовательское тестирование (Concurrency/Multi-user testing)
    • Тестирование сервиса (Service Testing)
    • Тестирование безопасности (Security and Access Control testing)
    • Оценка уязвимости/защищенности (Vulnerability Assessment)
    • Фаззинг-тестирование (Fuzz testing)
    • Можно ли отнести тестирование безопасности или нагрузочное тестирование к функциональным видам тести
    • Тестирование совместимости/взаимодействия (Compatibility/Interoperability testing)
    • Конфигурационное тестирование (Configuration testing)
    • Инсталляционное тестирование (Installation Testing)
    • Тестирование на соответствие (Conformance/Compliance testing)
    • Тестирование удобства пользования (Usability testing)
    • Тестирование доступности (Accessibility testing)
    • Тестирование локализации, глобализации и интернационализации (Localization/ globalization/internatio
    • Исследовательское тестирование (Exploratory testing)
    • Свободное / Интуитивное тестирование (Adhoc, Ad-hoc Testing)
    • Тестирование поддержки (Maintenance testing)
    • Регрессионные виды тестирования (Regression testing)
    • Тестирование клиентской части и серверной (Frontend testing Vs. Backend testing)
    • Тестирование графического интерфейса/визуальное тестирование (GUI - Graphical User Interface testing
    • Тестирование API (API - Application Programming Interface)
    • A/B тестирование (A/B Testing)
    • Деструктивное и недеструктивное тестирование (DT - Destructive testing and NDT - Non Destructive tes
    • Выборочное/хаотическое тестирование (Random/monkey testing)
    • Тестирование рабочего процесса/воркфлоу (Workflow testing)
    • Тестирование документации (Documentation testing)
    • Как протестировать продукт без требований?
    • Кроссбраузерное тестирование (Cross-browser testing)
    • Тестирование, основанное на рисках (Risk-Based Testing)
    • Разница тестирования ПО и железа (Software Vs. Hardware testing)
    • Тестирование качества данных (Data Quality Testing)
  • Тест дизайн
    • Тест-дизайн и техники тест-дизайна (Test Design and Software Testing Techniques)
    • Static - Reviews
    • Static - Static Analysis
    • Dynamic - White box
    • Dynamic - Black box
    • Dynamic - Experience based
  • Тестовая документация и артефакты (Test Deliverables/test artifacts)
    • Виды тестовой документации
    • Политика качества и политика тестирования (Quality policy and Test policy)
    • Стратегия тестирования (Test strategy)
    • План тестирования (Test plan)
    • Тестовый сценарий (Test scenario)
    • Тест-кейс (Test case)
    • Чек-лист (Check List)
    • Баг-репорт (Defect/bug report)
    • Требования (Requirements)
    • Пользовательские истории (User stories)
    • Критерии приемки (Acceptance Criteria)
    • Виды отчетов (Reports)
    • Базис тестирования (Test basis)
    • Матрица трассируемости (RTM - Requirement Traceability Matrix)
    • Метрики тестирования (Software Test Metrics)
    • Тестовый оракул (Test oracle)
  • Мобильное тестирование
    • Android
      • Архитектура Android OS
      • Архитектура Android Application
      • Тестирование покупок в Android-приложениях
      • Android Developer Settings
      • Android Debug Bridge (ADB)
      • Android Studio для QA
    • iOS
      • Архитектура iOS
      • Архитектура iOS Application
      • Тестирование покупок в iOS-приложениях
      • iOS Developer Settings
    • Особенности в тестировании мобильных приложений
    • Покрытие девайсов
    • Типы мобильных приложений
    • Симуляторы и эмуляторы
    • Основные различия Android/iOS
    • Последнее обновление Android/iOS, что нового?
    • Основные проверки при тестировании мобильного приложения
    • Каким образом тестировщик получает приложение на тест?
    • Как успешно зарелизить продукт в App Store и Google Play
    • Тестирование требований к мобильным приложениям
    • Тестирование push-уведомлений
    • Тестирование дип линков (mobile deep links)
    • Тестирование сохраненных поисков
    • Тестирование рекламы
    • Тестирование просмотренных товаров
    • Middleware
    • Как проверить использование ресурсов на Android
    • Как протестировать приложение для другой страны?
  • Тестирование в разных сферах-областях (testing different domains)
    • Тестирование веб-сайта или веб-приложения (Web application)
    • Тестирование интернет-магазина (eCommerce)
    • Тестирование платежного шлюза (Payment Gateway)
    • Тестирование игр (Game testing)
    • Тестирование VR программного обеспечения
    • Тестирование мессенджера (Messenger)
    • Тестирование чат-бота (Chatbot)
    • Тестирование электронных писем (E-mail)
    • Тестирование интернета вещей (IoT - Internet of Things)
    • Тестирование облачных решений (Cloud testing)
    • Тестирование сервис-ориентированной архитектуры (SOA - Service Oriented Architecture)
    • Тестирование микросервисной архитектуры (MSA/Microservices)
    • Тестирование платформы электронного обучения (E-learning platform)
    • Тестирование систем розничной торговли (POS - Point Of Sale)
    • Тестирование банковского ПО (Banking domain applications/BFSI)
    • Тестирование страхового ПО (Insurance)
    • Тестирование в сфере телекоммуникаций (Telecom)
    • Тестирование планирования ресурсов предприятия (ERP - Enterprise Resource Planning)
    • Тестирование миграции данных (ETL)
    • Тестирование баз данных (Database)
    • Другое
  • SDLC и STLC
    • Жизненный цикл разработки ПО (SDLC - Software Development Lifecycle)
    • Жизненный цикл тестирования ПО (STLC - Software Testing Lifecycle)
    • Модели разработки ПО
    • Agile
    • Scrum
    • Подходы к разработке/тестированию (... - driven development/testing)
  • Сети и около них
    • База по сетям
    • Клиент - серверная архитектура (Client-Server Architecture)
    • Микросервисная архитектура (Microservice Architecture)
    • Эталонные модели OSI и TCP/IP
    • HTTP
    • Идентификация ресурсов в сети (Identifying resources on the Web)
    • Веб-сервис (WS - Web service)
    • REST/SOAP/gRPC
    • Socket / WebSocket
      • Сокет/веб-сокет (socket/websocket)
      • Тестирование WebSocket на клиентах
    • Хранилище на стороне клиента (Client-side storage)
    • Кэш (Cache)
    • Аутентификация и авторизация (Authentication and authorization)
    • Рендеринг в интернете (Rendering on the Web)
  • Практическая часть
    • Логические задачи
    • Тестирование полей и форм
    • Примеры задач на собеседованиях и тестовых заданий
    • Платформы для тренировок и квизы
  • Автоматизация (beta)
    • Общее
    • Полезные ссылки
    • Как стать автоматизатором и вопросы с собеседований
    • Что нужно автоматизировать?
    • Виды и инструменты автоматизации
    • Инфраструктура и пайплайн (CI/CD)
    • Процессы и автоматизация проекта с нуля
    • Лучшие практики автоматизации
    • Что такое flaky tests?
    • Мутационное тестирование (Mutation testing)
    • Параллельное тестирование (Parallel testing)
    • Подкожный тест (Subcutaneous test)
    • Разница между coupling и cohesion
    • Другое (ссылки)
  • Контакты
Powered by GitBook
On this page

Was this helpful?

Edit on GitHub
  1. Общее

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

PreviousКачество ПО (Software Quality)NextВерификация и валидация (Verification and Validation)

Last updated 5 months ago

Was this helpful?

  1. Тестирование демонстрирует наличие дефектов (Testing shows presence of defects)

  2. Исчерпывающее тестирование недостижимо (Exhaustive testing is not possible)

  3. Раннее тестирование (Early testing)

  4. Скопление/кластеризация дефектов (Defect clustering)

  5. Парадокс пестицида/тесты устаревают (Pesticide paradox/Tests wear out)

  6. Тестирование зависит от контекста (Testing is context dependent)

  7. Заблуждение об отсутствии ошибок (Absence of errors fallacy)

Принцип 1. Тестирование показывает наличие дефектов Тестирование может показать, что дефекты присутствуют, но не может доказать, что дефектов больше нет. Сколько бы успешных тестов вы не провели, вы не можете утверждать, что нет таких тестов, которые не нашли бы ошибку.

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

Принцип 3. Раннее тестирование Тестовые активности должны начинаться как можно раньше в SDLC, а именно когда сформированы требования. Этот принцип связан с понятием «цена дефекта» (cost of defect). Цена дефекта существенно растет на протяжении жизненного цикла разработки ПО. Чем раньше обнаружен дефект, тем быстрее, проще и дешевле его исправить. Дефект, найденный в требованиях, обходится дешевле всего. Еще одно важное преимущество раннего тестирования - экономия времени. Тестовые активности могут начинаться еще до того, как написана первая строчка кода. По мере того, как готовятся требования и спецификации, тестировщики могут приступать к разработке и ревью тест-кейсов. И когда появится первая тестовая версия, можно будет сразу приступать к выполнению тестов.

Принцип 4. Скопление/кластеризация дефектов

Небольшое количество модулей содержит большинство дефектов, обнаруженных на этапе предрелизного тестирования, или же демонстрируют наибольшее количество отказов на этапе эксплуатации. Многие тестировщики наблюдали такой эффект - дефекты «кучкуются». Это может происходить потому, что определенная область кода особенно сложна и запутана, или потому, что внесение изменений производит «эффект домино». Это знание часто используется для оценки рисков при планировании тестов - тестировщики фокусируются на известных «проблемных зонах». Также полезно проводить анализ первопричин (root cause analysis), чтобы предотвратить повторное появление дефектов, обнаружить причины возникновения скоплений дефектов и спрогнозировать потенциальные скопления дефектов в будущем.

Принцип 5.

Boris Beizer в своей книге Software Testing Techniques объяснил парадокс пестицида как феномен, согласно которому чем больше вы тестируете ПО, тем более невосприимчивым оно становится к имеющимся тестам, т.е.

  1. каждый метод и набор тестов, который используется для предотвращения или поиска ошибок, может оставлять часть не найденных ошибок, против которых эти методы и тесты неэффективны;

  2. имеющиеся тесты устаревают после исправления дефекта и не могут обнаружить новые.

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

Принцип 6. Тестирование зависит от контекста Тестирование выполняется по-разному, в зависимости от контекста. Например, тестирование систем, критических с точки зрения безопасности, проводится иначе, чем тестирование сайта интернет-магазина. Этот принцип тесно связан с понятием риска. Что такое риск? Риск - это потенциальная проблема. У риска есть вероятность (likelihood) - она всегда выше 0 и ниже 100% - и есть влияние (impact) - те негативные последствия, которых мы опасаемся. Анализируя риски, мы всегда взвешиваем эти два аспекта: вероятность и влияние. То же можно сказать и о мире ПО: разные системы связаны с различными уровнями риска, влияние того или иного дефекта также сильно варьируется. Одни проблемы довольно тривиальны, другие могут дорого обойтись и привести к большим потерям денег, времени, деловой репутации, а в некоторых случаях даже привести к травмам и смерти. Уровень риска влияет на выбор методологий, техник и типов тестирования. Принцип 7. Заблуждение об отсутствии ошибок Нахождение и исправление дефектов бесполезно, если построенная система неудобна для использования и не соответствует нуждам и ожиданиям пользователей. Заказчики ПО - люди и организации, которые покупают и используют его, чтобы выполнять свои повседневные задачи - на самом деле совершенно не интересуются дефектами и их количеством, кроме тех случаев, когда они непосредственно сталкиваются с нестабильностью продукта. Им также неинтересно, насколько ПО соответствует формальным требованиям, которые были задокументированы. Пользователи ПО более заинтересованы в том, чтобы оно помогало им эффективно выполнять задачи. ПО должно отвечать их потребностям, и именно с этой точки зрения они его оценивают. Даже если вы выполнили все тесты и ошибок не обнаружили, это еще не гарантия того, что ПО будет соответствовать нуждам и ожиданиям пользователей. Иначе говоря, верификация не равна валидации.

Источники:

Доп. материал:

7 принципов тестирования. ,

Исчерпывающее тестирование невозможно
Парадокс пестицида/тесты устаревают
Часть 2
3
Семь принципов тестирования. Почему они так важны и как ими пользоваться
ISTQB Syllabus v4.0, раздел 1.3 "Принципы тестирования"
Парадокс пестицида и поддержка эффективности тест-кейсов
Pesticide Paradox in Software Testing
The Cold Hard Truth About Zero-Defect Software