Тестирование 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% регрессионных тест-кейсов
Расскажите о вариантах интегрирования тестовой документации в проект, инструментах для работы с ней.
Тестовую документацию можно интегрировать с помощью:
- систем управления тестовой документацией (например, TestRail),
- инструментов управления проектами (например, Jira),
- систем контроля версий (например, Git).
Как организовать сквозное тестирование (e2e)?
Сквозное тестирование (e2e) организуется путем создания тестовых сценариев, которые моделируют полное взаимодействие пользователя с системой от начала до конца. Эти сценарии затем автоматизируются с использованием инструментов для тестирования интерфейсов.
Какие тест-кейсы можно сделать для тестирования баз данных?
- Проверку CRUD (создание, чтение, обновление, удаление) операций,
- Восстановление после сбоев,
- Проверку интеграции с другими компонентами системы.
Приведите примеры подходов для тестирования локализации.
- Проверку локализованных строк и текста,
- Проверку форматирования дат и чисел в соответствии с языком,
- Проверку поддержки локальных символов
- Проверку корректности расположения элементов интерфейса на разных языках.
Что такое A/B тестирование?
A/B тестирование это метод тестирования, при котором два или более варианта интерфейса или функциональности сравниваются, чтобы определить, какой из них более эффективен в достижении целей, таких как увеличение конверсии или улучшение пользовательского опыта.
Что такое mock/stub?Какие знаете инструменты для работы с ними?
Моки помогают имитировать и изучать исходящие (outcoming) взаимодействия. То есть вызовы, совершаемые тестируемой системой (SUT) к ее зависимостям для изменения их состояния.
Стабы помогают имитировать входящие (incoming) взаимодействия. То есть вызовы, совершаемые SUT к ее зависимостям для получения входных данных.
Python: pyDoubles, Mox, Mockito-python
Когда необходимо использовать технику Pairwise?
Технику Pairwise используют, когда есть множество вариантов комбинирования параметров тестирования, и нужно уменьшить количество тестов, сохраняя при этом покрытие различных комбинаций.
Что такое fuzz-тестирование и где его используют?
FUZZ testing (fuzzing) - это тип тестирования безопасности, который обнаруживает ошибки кодирования и лазейки в программном обеспечении, операционных системах или сетях. Фаззинг включает в себя ввод огромного количества случайных данных, называемых fuzz, в тестируемое программное обеспечение, чтобы заставить его дать сбой или прорвать его защиту. Фаззинг часто выявляет уязвимости, которые могут быть использованы с помощью SQL-инъекции, переполнения буфера, отказа в обслуживании (DOS) и XSS. Fuzz-тестирование выполняется с помощью фаззера - программы, которая автоматически вводит полуслучайные данные в программу и обнаруживает ошибки. Fuzz-тестирование обычно выполняется автоматически.
Обычно fuzzing обнаруживает наиболее серьезные ошибки или дефекты безопасности. Это очень экономически эффективный метод тестирования. Fuzzing - один из самых распространенных методов хакеров, используемых для обнаружения уязвимости системы (сюда относятся популярные SQL- или скриптовые инъекции). Примеры фаззеров:
Mutation-Based Fuzzers: Этот тип фаззера проще всего создать, поскольку он изменяет существующие образцы данных для создания новых тестовых данных. Это относится к тупому фаззеру, но его можно использовать с более интеллектуальными фаззерами. Мы можем сделать это, выполнив некоторый уровень анализа образцов, чтобы гарантировать, что он изменяет только определенные части или не нарушает общую структуру ввода;
Generation-Based Fuzzers: Этот тип фаззера требует большего интеллекта для создания тестовых данных с нуля, т.е. новые тестовые данные создаются на основе входной модели. Обычно он разбивает протокол или формат файла на фрагменты, которые затем выстраиваются в допустимом порядке, и эти фрагменты случайным образом распределяются независимо друг от друга;
PROTOCOL-BASED-fuzzer: самый успешный фаззер - это детальное знание тестируемого формата протокола. Понимание зависит от спецификации. Это включает в себя запись массива спецификации в инструмент, а затем с помощью метода генерации тестов на основе модели проходится спецификация и добавляется неравномерность в содержимое данных, последовательность и т. д. Это также известно как синтаксическое тестирование, грамматическое тестирование, тестирование надежности, и т. д. Fuzzer может генерировать Test case из существующего или использовать допустимые или недействительные входные данные;
Типы ошибок, обнаруживаемых Fuzz testing:
Сбои ассертов и утечки памяти (Assertion failures and memory leaks). Эта методология широко используется для больших приложений, где ошибки влияют на безопасность памяти, что является серьезной уязвимостью;
Некорректный ввод (Invalid input). Фаззеры используются для генерирования неверного ввода, который используется для тестирования процедур обработки ошибок, и это важно для программного обеспечения, которое не контролирует его ввод. Простой фаззинг может быть способом автоматизации отрицательного тестирования;
Исправление ошибок (Correctness bugs). Fuzzing также может использоваться для обнаружения некоторых типов ошибок «правильности». Например, поврежденная база данных, плохие результаты поиска и т. д.;
Что такое Regexp?
REgexp (Regular Expression) это последовательность символов, которая определяет шаблон поиска в тексте. Он используется для выполнения текстового поиска и сопоставления в строках.
Как меняется стоимость дефекта при тестировании программного обеспечения?
Стоимость дефекта увеличивается с увеличением стадии проекта, на которой его обнаружили. На ранних стадиях обнаружение и исправление дефектов дешевле, чем на поздних этапах разработки или после выпуска продукта.
Каковы пути анализа бизнеса клиента?Как определить целесообразность того или иного функционала?
- Анализ бизнес-процессов клиента, общение с заказчиком и конечными пользователями.
- Сбор требований и их приоритизация.
- Оценка бизнес-целей и бюджета проекта для определения приоритетных функций.
Назовите последовательность выполнения CI/CD процесса на проекте.
- Continuous Integration (CI) — Непрерывная интеграция
- Continuous Delivery (CD) — Непрерывная доставка
- Continuous Deployment (CD) — Непрерывное развертывание
Continuous Integration (CI) — Непрерывная интеграция
- Commit-изменение в коде (GitHub):
- Сборка
- Unit-tests
- Staging (deploy to stage)
- Приёмочное тестирование (acceptance tests)
Continuous Delivery = CI+CD
- Развёртывание в промышленной среде происходит по кнопке
Continuous Deployment
- Развёртывание в промышленную среду происходит автоматически
Какое должно быть процентное соотношение между положительным и отрицательным тестированием на проекте?
Все требования должны быть покрыты позитивными сценариями, плюс стоит делать минимум хотя бы один-два негативных сценария на каждое требование.
Положительное: 70-80%
Отрицательное: 20-30%
Есть ли разница между bug leakage и bug release?
Bug release — баги, которые были выпущены в релиз и команда разработки о них знает.
Bug leakage — неизвестные команде разработки, баги, которые находят пользователи после релиза.
Может ли быть ситуация, когда критерии завершения (exit criteria) не выполнены?Что должно происходить в этом случае?
Да, может возникнуть ситуация, когда критерии завершения не выполнены, например, из-за выявленных серьезных дефектов.
В этом случае проект не должен переходить к следующему этапу, и должны быть предприняты меры для устранения проблем.
Что мы должны покрывать тест-кейсами, а что считается избыточными затратами времени и денег?Когда нецелесообразно писать тест-кейсы?
Тест-кейсы следует писать для критически важных сценариев и функциональности, которые могут повлиять на качество продукта или безопасность. Писать тест-кейсы для очень редко используемых и малозначимых функций может считаться избыточным.
Для какого функционала труднее всего написать тест-кейсы?
Труднее всего писать тест-кейсы для функционала с сложными бизнес-правилами и множеством вариаций.
Как посчитать Cyclomatic complexity?
Цикломатическая сложность программы (Cyclomatic Complexity of a Program) — структурная/топологическая мера сложности компьютерной программы. Разработана Томасом Дж.Маккейбом в 1976 году.
При вычислении цикломатической сложности используется граф потока управления программы. Узлы графа соответствуют неделимым группам команд программы, они соединены ориентированными рёбрами, если группа команд, соответствующая второму узлу, может быть выполнена непосредственно после группы команд первого узла. Цикломатическая сложность может быть также вычислена для отдельных функций, модулей, методов или классов в пределах программы.
Ей на замену пришла Cognitive Complexity разработанная в 2017 году компанией Sonar Source.
В чем основная разница между defect detection percentage и defect removal efficiency?
Сколько устранили дефектов до выхода в прод относительно всех обнаруженных дефектов в проде vs обнаруженные дефекты в тесте относительно обнаруженных дефектов в проде
- Defect detection percentage измеряет процент дефектов, обнаруженных на данной стадии разработки.
- Defect removal efficiency измеряет способность команды обнаруживать и устранять дефекты до их выпуска в конечный продукт.
Какие модели risk-based testing вы знаете?
FMEA(Failure Mode and Effect Analysis) - является наиболее популярным подходом к тестированию основанному на рисках. Это модель анализа причин и последствий отказов системы, которая определяет потенциальные дефекты и причины их возникновения. Работа по такой модели подразумевает, что команда проекта пробует определить все компоненты, процессы, модули, в которых может произойти сбой. Этот сбой с различной долей вероятности может привести к ухудшению качества ПО.
Для измерения таких сбоев используются 3 показателя:
1. серьезность
2. приоритет
3. вероятность
Каждому риску назначается Risk Priority Number (RPN) и в зависимости от показателей закладывается глубина тестирования.
- Модель основанную на приоритетах,
- Модель основанную на статистике
- Модель основанную на критичности функций.
Что такое тестирование API?Какими инструментами пользуются для его выполнения?
API (программный интерфейс приложения) – набор процедур, протоколов и инструментов для создания программных приложений. API определяет, как приложение должно взаимодействовать с другими программами.
Тестирование API предполагает проверку правильности этих взаимодействий.
Инструменты: Swagger, SoapUI, Postman, Requests
Какая разница между Scrum и Kanban?
- Scrum имеет фиксированные спринты и роли (Product Owner, Scrum Master).
- Kanban ориентирован на непрерывное потоковое выполнение задач без спринтов.
Scrum - это как команда зайца, которая делает шаги и выигрывает одну игру за раз. Команда работает в коротких циклах, называемых спринтами, обычно от 1 до 4 недель. Каждый спринт начинается с планирования, затем команда делает работу, и в конце спринта есть обзор, на котором команда показывает, что они сделали. Скрам имеет жесткую структуру с ролями, событиями и артефактами.
Kanban - это как поток цветных кубиков, который идет с одного конца комнаты в другой. Работа команды в Канбане не разбивается на спринты, а продолжается непрерывно. Команда визуализирует свою работу на доске Канбан и перемещает задачи от одной колонки к другой по мере выполнения работы. Канбан позволяет гибче реагировать на изменения в работе и акцентирует внимание на потоке работы.
Таким образом, Скрам - это игра с шагами, где команда работает в спринтах, а Канбан - это поток работы без спринтов и более гибкий подход к организации работы.
Что такое performance testing?Какими инструментами пользуются для его выполнения?
Оценка производительности ПО. Инструменты: JMeter, LoadRunner, Apache Benchmark.
Что такое load и stress testing?Какими инструментами пользуются для их выполнения?
- Нагрузочное тестирование (load testing) - выполнение программы c повышением нагрузки, вплоть до достижения запланированных характеристик, и далее с отслеживанием поведения на всем протяжении повышения загрузки системы.
- Стрессовое тестирование (stress testing) - тестирование, оценивающее систему на граничных значениях рабочих нагрузок или за их пределами, или же в состоянии ограниченных ресурсов, таких как память или доступ к серверу.
- Тестирование стабильности (stability testing) - проверка работоспособности приложения при длительном (многочасовом) тестировании со средним уровнем нагрузки. Времена выполнения операций могут играть в данном виде тестирования второстепенную роль. При этом на первое место выходит отсутствие утечек памяти, перезапусков серверов под нагрузкой и т.д.
Инструменты: LoadRunner, Apache JMeter, Gatling
Что такое contract testing?
Тестирование соблюдения контрактов между компонентами программного обеспечения, чтобы убедиться в их корректном взаимодействии.
Расскажите о ритуалах, ценностях и ролях в Scrum.
Ритуалы: Sprint Planning, Daily Scrum, Sprint Review, Sprint Retrospective.
Ценности: прозрачность, инспекция, адаптация.
Роли: Product Owner, Scrum Master, Development Team.
Как выбор методологии может отразиться на качестве разработки?
- Agile методологии (например, Scrum) способствуют гибкости и быстрой адаптации к изменениям, что может повысить качество.
- Waterfall может обеспечить строгий контроль, но менее гибок.
Какой вид тестирования целесообразнее проводить до релиза?
Перед релизом целесообразно провести регрессионное тестирование, чтобы убедиться в том, что новые изменения не повредили существующую функциональность.
Какие препятствия могут возникнуть в обеспечении качества для Agile Tester?
В Agile разработке, тестировщику приходится адаптироваться к частым изменениям и коротким срокам. Препятствия могут включать в себя:
- Нехватка времени на тестирование.
- Отсутствие полной документации.
- Неопределенные требования.
- Сложности в автоматизации тестов из-за частых изменений.
Что такое ROI и как его считать?
ROI (Return on Investment) — это показатель, который измеряет возврат инвестиций. В контексте тестирования, ROI оценивает, сколько ценности приносят тесты по сравнению с затратами на их создание и выполнение. ROI рассчитывается по формуле:
ROI = ((Прибыль − Затраты) \ Затраты) × 100%
- Зарплаты ручных тестировщиков * время на тестирование
- Зарплаты автоматизаторов * время на тестирование
- Стоимость инфраструктуры автоматизации
Как можно посчитать покрытие тестами функционала?
Для оценки покрытия тестами функционала, можно использовать метрику «Code Coverage» (покрытие кода), которая измеряет, сколько строк кода или ветвей выполнено тестами. Другой способ — анализ тестовых кейсов и их соответствие функциональным требованиям.
Когда следует делать стресс-тестирование на проектах? От чего отталкиваться, когда строите сценарий для такого тестирования? Что учесть при выборе инструмента?
Стресс-тестирование следует проводить, когда необходимо оценить производительность системы в условиях максимальной нагрузки. Сценарий стресс-тестирования должен имитировать реальные нагрузочные условия, например, максимальное количество пользователей или запросов. При выборе инструмента, учтите характеристики системы, которую тестируете, и желательно использовать инструменты, подходящие под специфику проекта.
Как можно быстро сделать выборку необходимых проверок для смоук-тестирования?
Для быстрой выборки проверок smoke-тестирования, начнем с определения ключевых функций или сценариев, которые являются критическими для базовой функциональности продукта. Например, если у нас есть веб-приложение для электронной почты, критические проверки могут включать в себя:
- Вход в учетную запись.
- Отправка и получение электронных писем.
- Открытие важных писем и вложений.
- Затем мы выбираем тест-кейсы, которые покрывают эти функции.
Например, тест-кейс для входа в учетную запись может включать следующие шаги:
- Открыть браузер.
- Перейти на страницу входа.
- Ввести имя пользователя и пароль.
- Нажать кнопку «Войти».
Используя подобные тест-кейсы для ключевых функций, мы можем быстро собрать набор проверок для смоук-тестирования.
Расскажите о метриках качества, которые вы применяли. Зачем они нужны?
- Code Coverage (Покрытие кода): Эта метрика измеряет, сколько строк кода или ветвей выполнено тестами. Чем выше покрытие, тем больше уверенность в стабильности кода.
- Defect Density (Плотность дефектов): Эта метрика показывает, сколько дефектов обнаружено на определенный объем кода. Это позволяет оценить, насколько «загрязнен» код.
- Customer Satisfaction (Удовлетворенность клиентов): Эта метрика позволяет измерить, насколько довольны клиенты продуктом. Она может быть собрана через обратную связь клиентов или опросы.
Как избежать появления регрессивных дефектов?
Авто-тесты
Как вы преодолеете трудности из-за отсутствия надлежащей документации для тестирования?
- Пообщаться с разработчиками, аналитиками, product owner - для определения требований и ожидаемого поведения системы
Отсутствие документации — распространенная проблема. Для преодоления ее, начните с общения с разработчиками, аналитиками и продуктовым владельцем, чтобы понять функциональные требования и ожидаемое поведение системы. Создайте собственные тест-кейсы и документацию, если это необходимо. Важно также активно вовлекать команду в процесс тестирования, чтобы обеспечить лучшее понимание продукта.
Что такое тестирование со смещением влево (Shift Left Testing)?
- Тестирование на раннем этапе. Основная часть тестирования приходится на этапы:
- анализ требований
- проектирование
- разработка
Это практика включения тестирования на более ранних этапах SDLC. Конечная цель состоит в том, чтобы тестировщики работали вместе с командой разработчиков на ранних этапах разработки, чтобы те могли работать над предотвращением проблем до их возникновения, а не выявлять их в конце проекта. Тестируя на раннем этапе, тестировщики могут сократить время, необходимое для проведения тестовых спринтов, могут помочь повысить качество программного обеспечения и помочь устранить фатальные проблемы, которые обычно обнаруживаются в конце.ие со смещением влево — это подход, при котором тестирование внедряется на ранние этапы разработки, такие как анализ требований и проектирование. Это позволяет выявлять и устранять дефекты на ранних этапах, что экономит время и ресурсы в будущем. Пример: тестирование безопасности проводится на этапе проектирования системы, чтобы избежать уязвимостей в коде.
Какой подход является наилучшим для старта QA в проекте?
- Начать с понимания бизнес-целей и требований проекта.
- Разработать стратегию тестирования включая:
- выбор методологии (например, Agile, Waterfall),
- определение тестовых целей и плана,
- выбор необходимых инструментов.
- Важно также интегрировать QA в процесс разработки с самого начала.
Как часто следует ревьюировать тестовую документацию?
Частота ревьюирования тестовой документации зависит от контекста проекта. В общем случае, ревьюирование тестовых документов может проводиться при каждом изменении функционала или требований. Это обеспечит актуальность и надежность документации.
Какой подход вы используете для Test Cases Review?
- Peer review
- Pair testing
Для ревью тест-кейсов можно использовать стандартные методы, такие как «Peer Review» или «Pair Testing». Это позволяет не только выявить ошибки в тестовых сценариях, но и обеспечивает обмен знаний и лучших практик между членами команды.
Какие виды рисков существуют? Что такое Mitigation Plan?
- Технические риски (связанные с инфраструктурой или инструментами),
- Бизнес-риски (связанные с целями проекта),
- Процессуальные риски (связанные с организацией процесса тестирования).
Mitigation Plan — это план по смягчению рисков, который включает в себя действия для предотвращения или уменьшения воздействия рисков на проект.
Что такое Definition of Done?
Набор критериев, которые определяют, когда задача или функционал считаются завершенными и готовыми к выпуску. DoD помогает устанавливать общее понимание завершенности работы в команде и предотвращать неоднозначности.
Как можно подкорректировать флоу разработки, чтобы получать более чистые результаты на выходе и уменьшить количество багов на проде?
- Тестирование требований аналитиками
- Пирамида тестирования
- Code review
- Рабочие ретроспективы как у морских котиков
- Меньше итерации
Какую ценность несет анализ результатов тестирования команде и проекту в целом?
- Можно понять слабые места
- Можно понять - что нужно улучшить для избежания таких проблем в будущем
Анализ результатов тестирования позволяет выявить дефекты, оценить качество продукта, повысить надежность и безопасность системы, а также улучшить процессы разработки. Это дает команде и заказчику информацию для принятия обоснованных решений и улучшения проекта.
Какие минусы полной автоматизации тестирования?
- Высокие затраты на разработку и поддержку автотестов.
- Ограничения в тестировании UI-интерфейсов и некоторых видов тестирования.
- Необходимость постоянной актуализации автотестов при изменениях в приложении.
- Невозможность тестирования некоторых аспектов, требующих человеческого вмешательства и интуиции.
Что вы думаете по поводу BDD? Когда следует использовать, а когда будет только хуже? Если все же следует использовать, то для UI или API автоматизированного тестирования?
Behavior Driven Development - может работать только когда требования и тесты пишутся первыми, затем пишется код. В первую очередь относится именно к разработчикам и аналитикам. Т.к. требования описывают изначально аналитики.
Без outside in - это bullshit driven development.
Какое оптимальное количество шагов в тестовом сценарии?
Оптимальное количество шагов в тестовом сценарии зависит от конкретной задачи и сложности тестирования. Важно стремиться к простоте и четкости сценариев. Обычно 5-15 шагов считаются оптимальным количеством, так как слишком длинные сценарии могут быть трудно управляемыми и поддерживаемыми.
Как будете тестировать программу, если для продукта нет документации?
Если для продукта нет документации, вам придется выполнять тестирование на основе здравого смысла и интуиции. Важно будет провести исследование продукта, изучить его функциональность и взаимодействие с приложением, идентифицировать ключевые сценарии использования.
Также можно проводить эксплораторское тестирование, где тестировщики исследуют приложение, пытаясь выявить дефекты и противоречия. При таком подходе, важно систематически фиксировать найденные дефекты и создавать тест-кейсы на основе их исправлений.
Что такое RCA в тестировании? Нужно ли его проводить?
RCA (Root Cause Analysis) в тестировании — это процесс выявления и анализа корневых причин дефектов или проблем, возникших во время тестирования. Это позволяет определить и устранить причины дефектов, а не только их симптомы.
RCA важен, так как помогает предотвратить повторное возникновение аналогичных дефектов и повысить качество продукта. Он также позволяет улучшить процессы тестирования. Проведение RCA — важный этап в управлении качеством.
Что такое качество?
Quality is extremely hard to define, and it is simply stated: “Fit for use or purpose.” It is all about meeting the needs and expectations of customers concerning the functionality, design, reliability, durability, & price of the product.
Это определение потребителя, а не определение инженера, не определение маркетинга и не общее определение менеджмента.
Оно основано на фактическом опыте клиента в отношении продукта или услуги, измеряется в соответствии с его требованиями — заявленными или неустановленными, осознанными или просто ощущаемыми, технически действующими или полностью субъективными.
Качество всегда представляет собой движущуюся цель на конкурентном рынке.
В процессе тестирования какие артефакты возникают?
- Тест-план
- Тест-стратегия
- Тест-кейс
- Чек-лист
- Баг-репорт
- Отчёт о тестировании
Как составить минимальный набор браузеров для кросс-браузерного тестирования?
Есть основные движки, на которых все построено:
1. Blink - Chrome
2. Gecko - firefox
3. WebKit - Safari
Если найден критический баг - стоит остановить тестирование или продолжить?
Логично продолжить, т.к. можно найти еще другие ошибки, которые разработчики сразу могут пофиксить.
Горизознтальное масштабирование
Поднять дополнительные сервисы
Вертикальное масштабирование
Добавить ресурсов (cpu например)
Какую тестовую модель вы бы использовали?
- Уточнить - что подразумевают под тестовой моделью
- Какая ТМС система
- Пишем ли тесткейсы
- Какие у нас сьюты (смоки, регрессы)
- Пишем ли чеклисты
- Инструменты (postman, grafana, dbveawer и т.д.)
- Как часто выходят релизы
- Кто является релиз инженером
- Кто дежурит на выходных или по ночам
Топ активностей
- Тестирование верстки
- Кросс-браузерное тестирование
