Тестирование Flashcards
Что такое тестирование?
Проверка продукта на соответствие требованиям.
Тестирование - процесс в рамках жизненного цикла разработки программного обеспечения, который оценивает качество компонента или системы, а также связанных с ними рабочих продуктов. [ISTQB Glossary]
Тестирование программного обеспечения — процесс анализа программного средства и сопутствующей документации с целью выявления дефектов и повышения качества продукта. [Святослав Куликов]
Тестирование ПО — проверка соответствия между реальным и ожидаемым поведением программы [Что-то из интернета]
Контроль качества (QC) - набор действий, предназначенных для оценивания качества компонента или системы. [ISTQB Glossary]
Обеспечение качества (QA) - активности, направленные на обеспечение уверенности в том, что требования к качеству будут выполнены [ISTQB Glossary]
Давайте разберемся на примере создания мобильного приложения, потому что определения не всегда отражают суть:
- В рамках тестирования мы выполним проверки и задокументируем дефекты, убедимся, что продукт соответствует требованиям.
- В рамках контроля качества мы проанализируем полученные данные и убедимся, что соблюдены все требования, предъявляемые к качеству как продукта, так и самого процесса. Мы должны убедиться, что уровень качества нашего продукта высокий и он готов к релизу.
- В рамках обеспечения качества мы формируем процесс QA для соответствия стандартам качества на всех этапах SDLC, еще до этапа создания нашего продукта, который будет минимизировать количество дефектов и предупреждать их.
Основные отличия процессов:
- Контроль качества и тестирование (как его часть) направлены на продукт, а обеспечение качества на процесс.
- Тестирование и контроль качества являются контролирующими мерами, а обеспечение качества - превентивными, или предупреждающими.
Зачем тестировать ПО?
- Проверка на соответствие требованиям
- Выявление ошибок в коде и требованиях
- Предоставление актуальной информации о состоянии продукта на данный момент.
Какие этапы тестирования?
- Общее планирование и анализ требований
- Уточнение критериев приемки
- Уточнение стратегии тестирования
- Разработка тест-кейсов
- Выполнение тест-кейсов
- Фиксация найденных дефектов
- Анализ результатов тестирования
- Отчетность
Русов
Какие типы тестирования вы можете назвать?
- На основе тест-кейсов
- Исследовательское тестирование
- Свободное тестирование (ad hoc)
- Регрессионное (Regression testing)
- Тест работоспособности (Sanity testing)
- Дымовое (Smoke testing)
- Позитивные
- Негативные
- Статическое
- Динамическое
- Black box
- Grey box
- White box
- Компонентное
- Интеграционное
- Системное
- Ручное
- Автоматизированное
- Полуавтоматизированное
- Альфа-тестирование
- Бета-тестирование
- По доступности кода:
- Black box
- Grey box
- White box
- По исполнению кода
- Статическое
- Динамическое
- По степени формализации
- На основе тест-кейсов
- Исследовательское тестирование
- Свободное тестирование (ad hoc)
- По уровням тестирования
- Компонентное
- Интеграционное
- Системное
- По позитивности
- Позитивные
- Негативные
- По степени автоматизации
- Ручное
- Автоматизированное
- Полуавтоматизированное
- Связанное с изменениями:
- Регрессионное (Regression testing)
- Тест работоспособности (Sanity testing)
- Дымовое (Smoke testing)
- По исполнителям
- Альфа-тестирование
- Бета-тестирование
- По целям и задачам
- Инсталляционное
- Usability (удобства использования)
- Доступности (accessibility testing, A11Y)
- Безопасности
- Интернационализации (internationalization testing, i18n testing, globalization testing, localizability testing)
- Локализации (localization testing, l10n)
- Совместимости (compatibility testing, interoperability testing)
- Надёжности (reliability testing)
- Восстанавливаемости (recoverability testing)
- Отказоустойчивости (failover testing)
- Производительности (performance testing)
- Нагрузочное тестирование (load testing, capacity testing)
- Тестирование масштабируемости (scalability testing)
- Объёмное тестирование (volume testing)
- Стрессовое тестирование (stress testing)
- Конкурентное тестирование (concurrency testing)
Какие уровни тестирования знаете?
- Модульное
- Интеграционное
- Системное
- Приёмочное
Модульное тестирование (Unit Testing)
Это процесс проверки отдельных компонентов программного обеспечения, таких как функции, методы или классы. Цель этого уровня тестирования — убедиться, что каждый отдельный компонент работает корректно в изоляции от остальной части системы.
Пример: Проверка функции сложения в программе калькулятора.
Интеграционное тестирование (Integration Testing)
На нем проверяется взаимодействие между различными модулями или компонентами системы. Цель интеграционного тестирования — обнаружить дефекты в взаимодействии и передаче данных между различными частями программы.
Пример: Проверка того, как модуль калькулятора обрабатывает данные, полученные от пользовательского интерфейса.
Системное тестирование (System Testing)
Проверяется вся система в целом. Системное тестирование направлено на выявление дефектов в комплексе, включая требования к функциональности, надёжности, производительности и безопасности.
Пример: Тестирование веб-приложения в различных браузерах и на разных устройствах.
Приемочное тестирование (Acceptance Testing)
Это финальный этап тестирования, на котором проверяется, соответствует ли программа ожиданиям и требованиям конечных пользователей.
Пример: Бета-тестирование программы с участием реальных пользователей.
Какие техники тест-дизайна знаете?
- Эквивалентное разбиение
- Граничные значения
- Попарное тестирование
- Таблицы решений
- Тестирование переходов состояний
- Предугадывание ошибки
Что такое техника анализа классов эквивалентности?
Техника при которой разделяются все возможные входные данные на группы или классы таким образом, чтобы все значения внутри одного класса считались эквивалентными.
Принципы:
- Определение эквивалентных классов: Входные данные или условия тестирования разделяют на классы, внутри которых система должна вести себя одинаково. Эти классы могут быть как допустимыми (валидными), так и недопустимыми (невалидными).
- Выбор представителей: Для каждого эквивалентного класса выбирается хотя бы один представитель (тестовый случай), который будет использован в тестировании.
- Тестирование: Проводится тестирование на основе выбранных представителей каждого класса. Результаты тестирования для представителя класса экстраполируются на весь класс.
Что такое техника анализа граничных значений?
В чем ценность этой техники?
Суть: Проверяются все значения на границах эквивалентных классов
Метод анализа граничных значений является продолжением метода эквивалентного разбиения, но может быть применим, только если классы состоят из упорядоченных числовых значений. Максимальное и минимальное значение класса являются его границами [Beizer 1990]. Некорректное поведение более вероятно на границах класса, чем внутри класса. [ISTQB CTFL Syllabus 2018]
Почему она важна:
- Высокая эффективность: большое количество ошибок с минимальным количеством тестов.
- Экономия времени и ресурсов: Сосредоточение усилий на наиболее вероятных местах возникновения ошибок - сокращает время на тестирование и оптимизирует использование ресурсов.
- Улучшение качества продукта: Гарантия корректной обратоки данных на границах значений
Что такое Regression и Confirmation тестирования, какая между ними разница?
Краткая суть: проверка уже протестированного функционала для того, чтобы убедиться, что при внесении изменений ничего не поломалось
Повторное/Подтверждающее тестирование (re-testing/confirmation testing) - тестирование, во время которого исполняются тестовые сценарии, выявившие ошибки во время последнего запуска, для подтверждения успешности исправления этих ошибок.
Регрессионное тестирование (regression testing) - тестирование уже протестированной программы после модификации для уверенности в том, что процесс модификации не внес или не активизировал ошибки в областях, не подвергавшихся изменениям. Проводится после изменений в коде ПО или его окружения.
Как часто следует проводить регрессионное тестирование продукта?
При каждом изменении в системе.
Какие виды интеграционного тестирования?
- Big bang - все компоненты приложения тестируются сразу после того, как они были разработаны, без поэтапного интегрирования. Этот подход обычно используется в небольших проектах.
-
Инкрементное тестирование - разработка приложения разбивается на отдельные этапы, после завершения каждого из которых происходит интеграция уже готовых компонентов. Этот подход позволяет обнаруживать проблемы на ранних этапах и быстрее реагировать на изменения в требованиях.
- Нисходящий подход
- Восходящий подход
- Гибридный подход
Снизу вверх (Bottom Up Integration). Все низкоуровневые модули, процедуры или функции собираются воедино и затем тестируются. После чего собирается следующий уровень модулей для проведения интеграционного тестирования. Данный подход считается полезным, если все или практически все модули, разрабатываемого уровня, готовы. Также данный подход помогает определить по результатам тестирования уровень готовности приложения.
Сверху вниз (Top Down Integration). Вначале тестируются все высокоуровневые модули, и постепенно один за другим добавляются низкоуровневые. Все модули более низкого уровня симулируются заглушками с аналогичной функциональностью, затем по мере готовности они заменяются реальными активными компонентами. Таким образом мы проводим тестирование сверху вниз.
Что такое Configuration Testing?
Краткая суть:
Тестирование различных конфигураций системы - железа, драйверов, операционных систем
Конфигурационное тестирование (configuration testing) - тестирование, направленное на проверку работы ПО при различных конфигурациях системы (заявленных платформах, поддерживаемых драйверах, при различных конфигурациях компьютеров и системного ПО и т.д.).
Что такое Exploratory Testing?
Краткая суть: неформальный метод, где проектирование тестов и тестирование происходит в реальном времени. Полученная информация в ходе тестирования используется для проектирования новых и улучшенных тестов
Неформальный метод, при котором тестировщик активно контролирует проектирование тестов, в то время как эти тесты выполняются, и использует полученную информацию для проектирования новых улучшенных тестов. Такое тестирование определяется как одновременное обучение, проектирование теста и его исполнение.
Какие существуют стандарты UI?
- Material Design
- Apple Human Interface Guidelines
- Microsoft Design Language
- Bootstrap
- Materialize
Что такое Black/Grey/White Box Testing?
Краткая суть:
- Черный ящик: Нет доступа ко внутренней структуре приложения и коду. Тестирование проводится с точки зрения конечного пользователя.
- Белый ящик: Основывается на внутренней структуре системы или ее реализации (код, архитектура, принципы работы и\или потоки данных внутри системы)
- Серый ящик: доступ к базам данных, архитектурным схемам и документации API.
Тестирование белого ящика (white box testing) - тестирование, основанное на анализе внутренней структуры компонента или системы и на знании исходного кода, к которому тестировщик (как правило, это программист) имеет полный доступ.
Тестирование серого ящика (gray box testing) - тестирование, ориентированное на имитацию работы пользователей, в условиях, когда часть внутренней структуры программы известна.
Тестирование чёрного ящика (black box testing) - тестирование, основанное на анализе функциональной или нефункциональной спецификации системы, при котором программа рассматривается как объект, внутренняя структура которого неизвестна.
Что такое Performance Testing?
Краткая суть: проверка поведения системы при рабочей нагрузке: скорость, время отклика, стабильность, надежность, мастштабируемость и использование ресурсов ПО при определенной рабочей нагрузке.
Тестирование производительности (performance testing) - определение степени, с которой система выполняет заложенные в нее функции в установленных рамках на время обработки и пропускную способность. Достаточно часто при тестировании производительности проверяется сразу несколько его подвидов.
Что такое Smoke и Sanity тестирование и какая между ними разница?
Smoke - проверка стабильности билда, что он вообще работает
Sanity - более глубокая проверка важного функционала
Что такое Traceability Matrix?
Краткая суть:
Таблица для отслеживания взаимосвязей между требованиями проекта и выполненной по ним работе. (Учёт реализации требований)
Матрица соответствия требований (traceability matrix) — двумерная таблица, содержащая соответсвие функциональных требований (functional requirements) продукта и подготовленных тестовых сценариев (test cases).
В заголовках колонок таблицы расположены требования, а в заголовках строк — тестовые сценарии. На пересечении — отметка, означающая, что требование текущей колонки покрыто тестовым сценарием текущей строки.
Матрица соответсвия требований используется QA-инженерами для валидации покрытия продукта тестами. МСТ является неотъемлемой частью тест-плана.
Что такое Sanity Testing?
Sanity - подвид регрессионного тестирования, используется на более стабильных билдах для определения работоспособности определенной части приложения после внесения изменений.
Тест работоспособности (sanity test): См. тест “на дым”. (ISTQB)
Другие источники:
Sanity testing также является подмножеством регрессионного тестирования и выполняется до или вместо полной регрессии, но после smoke. Эти два подвида похожи, но в целом Sanity используется на более стабильных билдах для определения работоспособности определенной части приложения после внесения изменений.
Примечание. Санитарным это тестирование в русскоязычной среде назвалось по совершенно непонятным причинам, но гуглится только так. На самом же деле дословно переводится как тестирование на вменяемость / разумность / работоспособность / согласованность или по версии ISTQB “Тест работоспособности”.
Sanity тестирование (от англ. “sanity” — “здравомыслие”) — это вид тестирования, который проводится для подтверждения того, что после внесения небольших изменений или исправлений в программный продукт основные функции по-прежнему работают корректно. Этот тип тестирования обычно выполняется в конце тестового цикла и перед выпуском продукта для убеждения в том, что внесенные изменения не привели к возникновению новых критических ошибок в уже проверенных и работающих частях программы.
Данное тестирование часто путают с Smoke тестированием, но между ними есть различия. Smoke тестирование выполняется для проверки стабильности и работоспособности всего программного продукта или его ключевых компонентов и обычно проводится в начале тестового цикла. В то время как Sanity фокусируется на конкретных функциях или изменениях, которые были внесены в программный продукт, и проводится для подтверждения того, что эти последние изменения не нарушили основную функциональность.
Пример:
Допустим, команда разработки вносит изменения в модуль регистрации пользователей в веб-приложении. После внесения изменений QA инженер проводит Sanity тестирование этого модуля, чтобы убедиться, что регистрация по-прежнему работает корректно: пользователь может зарегистрироваться, получить подтверждение регистрации и войти в систему используя новые учетные данные.
Цели:
- Быстрая проверка: Убедиться, что после небольших изменений или исправлений в программном продукте не возникло критических проблем.
- Сосредоточение на изменениях: Проверка только тех аспектов программного продукта, которые подверглись изменениям, без проведения глубокого и всеобъемлющего тестирования.
- Экономия времени и ресурсов: Позволяет быстро оценить влияние внесенных изменений, не тратя время на полный цикл тестирования.
- Такое тестирование является важной частью процесса обеспечения качества программного продукта, так как оно позволяет быстро и эффективно подтвердить, что внесенные изменения не повлияли негативно на уже проверенную и работающую функциональность. Этот тип тестирования особенно полезен в условиях ограниченного времени и ресурсов, когда необходимо сделать быструю проверку перед выпуском продукта или передачей его на дальнейшие этапы тестирования.
Sanity тестирование — это быстрая проверка того, что после внесения небольших изменений в программное обеспечение основные функции продолжают работать корректно. Этот тип тестирования помогает подтвердить здравомыслие программного продукта перед его дальнейшим тестированием или выпуском.
Что такое End-to-End тест?
Сквозное тестирование - тестирование от начала до конца (от регистрации до финальной покупки), включая все интеграции
Сквозное тестирование - Сквозное тестирование (End-to-end, E2E, Chain testing) — используется для проверки ПО от начала до конца, а также его интеграцию с внешними интерфейсами.
Цель сквозного тестирования состоит в проверке всего программного обеспечения на предмет зависимостей, целостности данных и связи с другими системами, интерфейсами и базами данных для проверки успешного выполнения полного производственного сценария.
Пример: На примере интернет магазина, это одна объемная проверка, которая включает в себя все шаги пользователя, начиная от регистрации в системе и заканчивая покупкой товара в магазине.
Что такое тестирование безопасности?
Тестирование безопасноcти/защищённости (security testing) – тестирование ПО с целью определить его защищённость.
Основные понятия, которые должны быть охвачены тестированием: конфиденциальность, целостность и сохранность данных, аутентификация, авторизация и невозможность отказа от авторства.
Что такое тестирование на основе рисков?
Краткая суть приоритеты в тестировании устанавливаются на основе оценки рисков. Акцент на частях системы с наибольшим риском возникновения серьёзных проблем, влияющих на работоспособность продукта и удовлетворённость пользователя.
Подход позволяет оптимизировать процесс тестирования, обеспечивая наибольшую эффективность при ограниченных ресурсах.
Тестирование на основе рисков/Риск-тестирование (risk-based testing) — метод тестирования ПО, который базируется на вероятности рисков. Их вероятность определяется путем анализа, в котором учитываются сложность программы, критичность функции для бизнеса, частота ее использования и количество возможных дефектов. При тестировании на основе рисков наибольший приоритет получает проверка самых важных и потенциально имеющих недостатки функций.
Что такое динамическое тестирование?
Краткая суть: через выполнение кода (через запуск программы.
Что такое «парадокс пестицида»?
Суть: Повторное использование одних и тех же тестовых сценариев со временем становится всё менее эффективным в обнаружении новых дефектов.
эффект, при котором при регулярном прогоне тестовых сценариев ошибки перестают находиться. Происходит из-за того, что ошибки которые ловились данными тестами уже пойманы, а остальные оказываются не попадающими в тестовые сценариями.
Опишите основные фазы STLC?Дайте определение Entry и Exit Criteria.
Software Testing Life Cycle:
1. Общее планирование и анализ требований
2. Уточнение критериев приемки
3. Уточнение стратегии тестирования
4. Разработка тест-кейсов
5. Выполнение тест-кейсов
6. Фиксация найденных дефектов
7. Анализ результатов тестирования
8. Отчетность
Критерии входа: обязательные элементы, которые должны быть выполнены перед началом тестирования.
1. Выход билда для тестирования
2. 100% требований и мокапов утверждены и проверены
Критерии выхода: определяют элементы, которые должны быть выполнены до завершения тестирования.
1. Выполнение более 80 % запланированных на итерацию тест-кейсов
2. Исправлено 100% критических багов
3. Автоматизированно 80% регрессионных тест-кейсов
STLC - это процесс тестирования, который включает в себя определенную последовательность шагов, чтобы гарантировать достижение целей в области качества. В процессе STLC каждое действие выполняется планомерно и систематически. Каждый этап имеет разные цели и результаты. У разных организаций разные этапы STLC, однако основа остается прежней.
STLC имеет несколько взаимосвязанных фаз и в целом очень похож на SDLC. Эти фазы являются последовательными и называются:
- Анализ требований (Requirement Analysis): один из важнейших этапов, потому что именно на нем можно почти бесплатно исправить недостатки проекта. Этап анализа требований также определяет потенциальную потребность в автоматизированном тестировании и позволяет производить экономические расчеты затрат на рабочую силу на основе оценки проекта. На этом же этапе обсуждаются и документируются критерии начала и окончания тестирования
- Планирование тестирования (Test Planning): на этом этапе формируется план тестирования, т.е. мы определяем действия и ресурсы, которые помогут достичь целей тестирования (участники и их роли, инструменты, окружение). Во время планирования мы также пытаемся определить метрики, метод сбора и отслеживания этих метрик. План составляют исходя из требований, тестовой стратегии и анализа рисков
- Разработка тест-кейсов (Test Case Development): подразумевает использование ручного и автоматизированного тестирования для достижения полного охвата функциональности программного обеспечения, при этом процесс основан на заранее установленных требованиях. Чаще всего тест-кейсы для автоматического тестирования пишутся отдельно, так как кейсы для ручного тестирования описаны в виде шпаргалок (cheat sheets)
- Настройка тестовой среды (Test Environment Setup): в плане тестирования четко указано, какую тестовую среду следует использовать. На этом этапе STLC настраиваются операционные системы и виртуальные машины, развертываются инструменты тестирования, такие как Selenium, Katalon Studio, а также тестовая среда и базы данных проекта. Мы также обращаемся с запросами к DevOps и администраторам, если требуется поддержка
- Выполнение тестов (Test Execution): тесты выполняются на основе готовой тестовой документации и правильно настроенной тестовой среды. Все результаты тестирования регистрируются в Системе управления тестированием. Отрицательно пройденные тесты, в которых фактический результат отличается от ожидаемого, регистрируются как ошибки и передаются команде разработчиков на доработку с последующей перепроверкой после исправления
- Завершение цикла испытаний (Test Cycle Closure): окончательная генерация отчетов о тестировании для клиента. Они должны включать затраченное время, процент обнаруженных ошибок и положительных результатов тестирования, общее количество обнаруженных и исправленных ошибок. Что касается отдела тестирования, то это момент для анализа его работы, подведения итогов, анализа его продуктивности и возможности внести предложения по улучшению качества тестирования.
Критерии входа: Критерии входа содержат обязательные элементы, которые должны быть выполнены перед началом тестирования.
1. Выход билда для тестирования
2. 100% требований и мокапов утверждены и проверены
Критерии выхода: Критерии выхода определяют элементы, которые должны быть выполнены до завершения тестирования.
1. Выполнение более 80 % запланированных на итерацию тест-кейсов
2. Исправлено 100% критических багов
3. Автоматизированно 80% регрессионных тест-кейсов
Что такое Bug, Error, Failure, Fault?
Bug (defect/fault) — ошибка программиста (или дизайнера или ещё кого, кто принимает участие в разработке), то есть когда в программе, что-то идёт не так как планировалось и программа выходит из-под контроля. Например, когда никак не контроллируется ввод пользователя, в результате неверные данные вызывают краши или иные «радости» в работе программы. Либо внутри программа построена так, что изначально не соответствует тому, что от неё ожидается.
Error — ошибка пользователя, то есть он пытается использовать программу иным способом. Пример — вводит буквы в поля, где требуется вводить цифры (возраст, количество товара и т.п.). В качественной программе предусмотрены такие ситуации и выдаются сообщение об ошибке (error message).
Failure — сбой (причём не обязательно аппаратный) в работе компонента, всей программы или системы. То есть, существуют такие дефекты, которые приводят к сбоям (A defect caused the failure) и существуют такие, которые не приводят. UI-дефекты например. Но аппаратный сбой, никак не связанный с software, тоже является failure.
Какая разница между приоритетом и серьезностью?
Приоритет - как быстро нужно исправить ошибку
Серьезность - насколько серьезно ошибка затрагивает функциональность
Приведите примеры серьезного, но не приоритетного бага
У компании Google на главной странице ошибка в слове “Gogle”.
Высокий приоритет, но низкая серьёзность
Это означает, что дефект нужно исправить как можно скорее, хотя он и не оказывает значительного влияния на функциональность системы. Примеры могут включать:
- Ошибки в ключевых текстах или логотипах на главной странице: Хотя это не влияет на функциональность, такая ошибка может негативно сказаться на репутации компании.
- Незначительные ошибки в функционале, используемом во время демонстраций для важных клиентов: Например, ошибка в отображении логотипа компании-клиента в демо-версии продукта.
Низкий приоритет, но высокая серьёзность
Такие дефекты оказывают значительное влияние на работу системы, но их исправление может быть отложено из-за низкого влияния на текущие бизнес-процессы или из-за малой вероятности возникновения.
Примеры могут включать:
- Критические ошибки в редко используемых функциях: Например, сбой системы при выполнении специфической операции, которую используют единицы пользователей.
- Серьёзные ошибки в функционале, планируемом к скорому удалению или переработке: Если известно, что данный функционал будет скоро заменён, может быть принято решение не тратить ресурсы на исправление серьёзной ошибки.
В чем разница между валидацией и верификацией?
Верификация отвечает на вопрос “Строим ли мы продукт правильно?”, проверяя соответствие продукта требованиям и спецификациям на каждом этапе разработки.
Валидация отвечает на вопрос “Строим ли мы правильный продукт?”, подтверждая, что конечный продукт удовлетворяет потребностям и ожиданиям конечного пользователя.
Зачем требуется тестовая документация?Какие ее виды?
Суть: Помогает планировать, отслеживать процесс и результаты, а также обеспечивать эффективное взаимодействие внутри команды и с другими заинтересованными сторонами.
- Тестовая стратегия (Test Strategy)
- План тестирования (Test Plan)
- Тестовый сценарий (Test Case)
- Тестовый набор (Test Suite)
- Тестовые данные (Test Data)
- Баг (Bug report)
- Отчёт о тестировании (Test Report)
Она включает в себя различные типы документов, каждый из которых выполняет свои задачи на разных этапах тестирования.
Вот основные ее виды:
- Тестовая политика (Test Policy):
Описывает общие принципы и подходы к тестированию на уровне организации. Это стратегический документ, который не вдается в детали исполнения. - Тестовая стратегия (Test Strategy):
Определяет основные стратегические направления тестирования для конкретного проекта или серии проектов. Включает в себя выбор методологий, описание процессов управления рисками, ресурсов, инструментов и прочее. - План тестирования (Test Plan):
Описывает общий план тестирования для конкретного проекта или фазы, включая цели тестирования, объекты тестирования, ресурсы, ответственных и график работ. Он также определяет критерии начала и завершения тестирования, а также методы отслеживания и управления. - Тестовый сценарий (Test Case):
Подробное описание условий и шагов для проверки конкретного аспекта системы или приложения. Тестовый сценарий включает в себя входные данные, условия выполнения, шаги для выполнения и ожидаемый результат. - Тестовый набор (Test Suite):
Коллекция тестовых сценариев, объединённых по определённому признаку, например, функциональности, которую они тестируют, или типу тестирования (регрессионное, приёмочное и т.д.). - Тестовые данные (Test Data):
Данные, используемые для выполнения теста. Могут включать в себя входные файлы, данные для заполнения форм, конфигурационные файлы и так далее. - Протокол тестирования (Test Log):
Журнал, в котором фиксируется информация о процессе выполнения тестов, включая время начала и окончания тестирования, исполнителя, результаты и возникшие проблемы. - Отчёт о дефектах (Defect Report):
Описывает найденные в процессе тестирования ошибки. Включает информацию о способе воспроизведения ошибки, её серьёзности, состоянии и любые дополнительные сведения, которые могут помочь в её исправлении. - Отчёт о тестировании (Test Report):
Итоговый документ, который подводит итоги проведённого тестирования, включая общее качество продукта, обнаруженные дефекты, оценку выполнения тестового плана и рекомендации.
Каждый из этих документов играет важную роль в обеспечении качества и эффективности процесса тестирования, помогая улучшить коммуникацию в команде, обеспечивать прозрачность и отслеживаемость процессов, а также способствуя более глубокому пониманию и анализу тестируемой системы.
Тестовая документация — это набор документов, которые поддерживают и организуют процесс тестирования ПО. Она включает в себя планы, стратегии, сценарии, данные для тестирования, журналы выполнения тестов, отчёты о дефектах и итоговые отчёты, каждый из которых выполняет свою уникальную функцию для обеспечения качества и эффективности тестирования.
Что такое тест-план? Какие элементы у него есть?
Суть: документ для планирования тестирования
- Что надо протестировать
- Что будем действительно тестировать
- Как будем тестировать
- Когда будем тестировать
- Критерии сдачи
- Критерии приёмки
Тест-план — это документ, который описывает объем, подход, ресурсы и план тестирования ПО. Он служит руководством для тестирования продукта, определяя стратегию, задачи, приоритеты, ресурсы, графики и риски, связанные с процессом тестирования. Он помогает всей команде понимать задачи тестирования и ожидаемые результаты, а также обеспечивает структурированный подход к обеспечению качества.
Основные элементы:
- Введение: Краткое описание проекта и целей тестирования.
- Объекты тестирования: Список компонентов или функций программного обеспечения, которые будут тестироваться.
- Задачи тестирования: Четкое определение целей тестирования, включая что должно быть протестировано и что должно быть достигнуто в результате тестирования.
- Область тестирования и исключения: Описание того, что будет тестироваться, а также того, что будет исключено из тестирования.
- Подход к тестированию: Описание методологии и техник тестирования, которые будут использоваться, включая уровни тестирования (например, модульное, интеграционное, системное, приемочное).
- Критерии начала и завершения тестирования: Определение условий, при которых тестирование начнется и завершится.
- Ресурсы: Перечень всех необходимых ресурсов для тестирования, включая персонал, тестовое оборудование, и тестовые данные.
- Ответственные: Распределение ролей и обязанностей в команде тестирования.
- График тестирования: Временная шкала выполнения тестовых задач и этапов.
- Управление рисками: Оценка потенциальных рисков для плана тестирования и стратегии их минимизации.
- План выпуска тестов: Порядок выполнения тестов, включая зависимости между тестами.
- Требования к документированию: Описание того, как будут документироваться найденные дефекты, отчеты о тестировании и итоговые результаты.
Тест-план играет важную роль в успешном тестировании ПО. Он помогает обеспечить, что процесс тестирования является организованным, систематическим и эффективным. Тест-план также способствует обеспечению прозрачности и понимания процесса тестирования для всех участников проекта, а также помогает в управлении ожиданиями заинтересованных сторон относительно объема и глубины тестирования. Создание тест-плана является критическим шагом в обеспечении качества программного продукта и должно предшествовать началу любых тестовых действий.
Какую обязательную информацию должен содержать тест-план?
Как правильно его использовать, поддерживать и вообще он нужен для большинства проектов?
Суть: планирование требуется всегда, тест план нужен не всегда
- Что надо протестировать
- Что будем действительно тестировать
- Как будем тестировать
- Когда будем тестировать
- Критерии сдачи
- Критерии приёмки
В то время как стратегия излагает общие принципы или теорию, план детально описывает практические аспекты того, как проект будет протестирован в реальности.
Даже в Agile необходимо предварительное планирование для структурирования работы, распределения ресурсов и планирования - по крайней мере, на высоком уровне - процесса выпуска на ближайшие месяцы. Но итерация за итерацией, а часто и день за днем, общий план постоянно корректируется с учетом событий и новой информации, которая появляется на свет. Планирование - это непрерывное обучение, а не задача с конечным результатом.
В гибких методологиях всё чаще говорят о концепции одностраничного тест-плана, а в случае необходимости дополнений и уточнений просто создаются ссылки на внешние страницы/документы.
Тест-план призван отвечать на те вопросы, ради которых его создают. Порой весомую часть пользы от данной активности можно получить на этапе самого планирования и составления плана, а не от самого документа. Если команда понимает, что никакой практической “боли” этот документ и его создание не решает, на него нет времени, то можно прекрасно обойтись и без его формализации, т.к. в некоей словесной форме он всё равно будет существовать всегда.
Какая разница между чек-листом и тест-кейсом?
Тест-кейс и чек-лист являются инструментами в области тестирования ПО, но они служат разным целям и используются в различных контекстах.
Тест-кейс
Это документ, который содержит подробные инструкции для проверки конкретного аспекта системы или приложения. Он включает в себя информацию о предварительных условиях, входных данных, действиях, которые нужно выполнить, ожидаемых результатах и фактических результатах. Они разрабатываются для того, чтобы обеспечить систематическую проверку функциональности продукта и гарантировать, что все сценарии использования были тщательно протестированы.
Особенности:
- Подробное описание процедуры тестирования.
- Четко определенные шаги.
- Ожидаемые результаты для каждого шага.
- Предназначен для повторного использования в разных циклах тестирования.
Чек-лист
Это более обобщенный документ, который содержит список элементов или задач, которые нужно проверить, но без подробного описания того, как именно эти проверки должны быть выполнены. Они используются для упрощения процесса тестирования и обеспечения того, чтобы все важные аспекты были учтены. Они могут служить напоминанием для тестировщиков о том, что необходимо проверить, но оставляют за тестировщиком свободу выбора способа проверки.
Особенности:
- Список проверок без подробных инструкций.
- Гибкость в использовании.
- Может не содержать ожидаемых результатов.
- Подходит для общего обзора тестирования и помощи в организации тестов.
Различия
- Детализация: Тест-кейс содержит подробные шаги и ожидаемые результаты, в то время как чек-лист представляет собой простой список элементов для проверки.
- Цель использования: Тест-кейсы разработаны для детального тестирования функциональности и обеспечения полного покрытия тестами. Чек-листы же чаще используются для быстрой проверки или в качестве напоминания о том, что нужно протестировать.
- Гибкость: Чек-листы более гибкие и могут быть легко адаптированы под разные задачи и условия тестирования. Тест-кейсы, с другой стороны, требуют точного следования предписанным шагам.
И тест-кейсы, и чек-листы являются важными инструментами, выбор между которыми зависит от конкретной задачи, целей тестирования и требуемой глубины проверки.
Назовите обязанности QA.
- изучение и уточнение требований к программе у заказчика (в больших проектах этим могут занимаются бизнес аналитики)
- написание и последующая доработка сценариев тестирования
- проведение тестирования функционала ПО
- внесение отчетов по обнаруженным недочетам в трекинговую систему
- анализ результатов и показателей проведенных тестов
- составление ТЗ на устранение найденных после тестирование недочетов
- мониторинг и отслеживание правок
- проведение повторных тестов на отсутствие найденных ошибок
- анализ и оптимизация этапов разработки для устранения причин ошибок и избежания повторного их появления
- работа с тестовой документацией
Что знаете о тестировании нагрузки?
В каком случае следует проводить такое тестирование?
На каком этапе готовности продукта?
Нагрузочное тестирование (load testing) - выполнение программы c повышением нагрузки, вплоть до достижения запланированных характеристик, и далее с отслеживанием поведения на всем протяжении повышения загрузки системы. При этом может происходить:
- измерение времени выполнения выбранных операций при определенных интенсивностях выполнения этих операций
- определение количества пользователей, одновременно работающих с приложением
- определение границ приемлемой производительности при увеличении нагрузки (при увеличении интенсивности выполнения этих операций)
Проводится в следующих случаях:
- новый проект, который ещё не проходил нагрузочного тестирования и настало время аудита производительности
- внедрили крупное изменение, которое существенно влияет на функционал
- планируется участие в крупных маркетинговых акциях, которые привлекут большой трафик
- изменение конфигурации стендов
- оценка возможностей существующей системы
- Обычно проводится заранее перед релизом или ожидаемым увеличеннием нагрузки.
Что такое таблица решений/decision table и как ее можно использовать?
Структура данных для представления комбинаций входных условий и действий, используется для анализа сложных бизнес-правил.
Другое название метода – матрица принятия решений. Эта техника подходит для более сложных систем, например – двухфакторной аутентификации. Предположим, чтобы войти в систему, пользователю нужно ввести сначала логин и пароль, а затем еще подтвердить свою личность присланным в смс кодом.
Какие возможны сценарии:
1. Правильный логин и правильный пароль.
2. Правильный логин, неправильный пароль.
3. Неправильный логин, правильный пароль.
4. Неправильный логин, неправильный пароль.
Первый из этих сценариев сопровождается либо правильным, либо неправильным вводом смс-кода, итого у нас получается 5 тестов. При этом только один из сценариев приведет к положительному результату (пользователь успешно авторизуется), а остальные закончатся неудачей.
Однако, может быть так, что система выдает разные сообщения в зависимости от того, на каком этапе была допущена ошибка, скажем: invalid login, invalid password. Соответственно, групп потребуется больше, а таблица станет обширнее.
Этот метод хорош тем, что он показывает сразу все возможные сценарии в форме, понятной даже неспециалисту.
Что может быть критериями запуска и завершения тестирования?
Критерии входа: Критерии входа содержат обязательные элементы, которые должны быть выполнены перед началом тестирования.
1. Выход билда для тестирования
2. 100% требований и мокапов утверждены и проверены
Критерии выхода: Критерии выхода определяют элементы, которые должны быть выполнены до завершения тестирования.
1. Выполнение более 80 % запланированных на итерацию тест-кейсов
2. Исправлено 100% критических багов
3. Автоматизированно 80% регрессионных тест-кейсов
