Теория тестирования (начальный уровень) Flashcards

Question

Что такое Regression и Confirmation тестирования, какая между ними разница? | Теория тестирования

Answer 1

**Суть:** Retest - смотрим на изменившейся участок. Регресс - смотрим на не изменившиеся участки. **Регрессионное тестирование (regression testing):** Тестирование уже протестированной программы, проводящееся после модификации для уверенности в том, что процесс модификации не внес или не активизировал ошибки в областях, не подвергавшихся изменениям. Проводится после изменений в коде программного продукта или его окружении. (ISTQB) **Confirmation тестирование (retest)** - тестирование, во время которого исполняются тестовые сценарии, выявившие ошибки во время последнего запуска, для подтверждения успешности исправления этих ошибок. В ходе повторного тестирования (confirmation), происходит поиск мелких деталей в изменившейся зоне функциональности, тогда как регрессионное тестирование охватывает все основные функции, чтобы гарантировать, что нет функции, нарушающейся из-за этого изменения. ## Footnote https://vladislaveremeev.gitbook.io/qa_bible/vidy-metody-urovni-testirovaniya/regressionnye-vidy-testirovaniya-regression-testing https://easyoffer.ru/question/7801 https://vk.com/wall-130102652_218

Answer 2

При каждом изменении в системе.

Answer 3

* Big bang - все компоненты приложения тестируются сразу после того, как они были разработаны, без поэтапного интегрирования. Этот подход обычно используется в небольших проектах. * Инкрементное тестирование - разработка приложения разбивается на отдельные этапы, после завершения каждого из которых происходит интеграция уже готовых компонентов. Этот подход позволяет обнаруживать проблемы на ранних этапах и быстрее реагировать на изменения в требованиях. В свою очередь, инкрементное тестирование можно разделить на: * Нисходящий подход * Восходящий подход * Гибридный подход ## Footnote https://easyoffer.ru/question/8982

Answer 4

**Краткая суть:** Тестирование различных конфигураций системы - железа, драйверов, операционных систем **Конфигурационное тестирование (Configuration testing)** - специальный вид тестирования, направленный на проверку работы ПО при различных аппаратных и программных конфигурациях системы (заявленных платформах, поддерживаемых драйверах, при различных конфигурациях компьютеров и т. д.). **Configuration** = performance + compatibility: * performance аспект: определить оптимальную конфигурацию оборудования, обеспечивающую требуемые характеристики производительности и времени реакции тестируемой системы; * compatibility аспект: проверить объект тестирования на совместимость с объявленным в спецификации оборудованием, операционными системами и программными продуктами третьих фирм; Существует два главных уровня конфигурационного тестирования: серверный и клиентский. **Серверный уровень тестирования конфигурации** Если говорить о первом уровне, то смысл его состоит в проверке взаимодействия между программным обеспечением и внешним окружением, в которое планируется его установка. **Клиентский уровень тестирования конфигурации** На втором уровне тестирование программного обеспечения производится с позиции интересов его непосредственного пользователя, то есть будут исследованы удобство пользования и функциональность программного продукта. В тех случаях, когда число системных требований к работе программного обеспечения велико, рекомендуем автоматизировать весь процесс тестирования с целью экономии и времени, и ресурсов. ## Footnote https://software-testing.org/testing/chto-takoe-konfiguracionnoe-testirovanie-configuration-testing.html

Answer 5

* Material Design * Apple Human Interface Guidelines * Microsoft Design Language * Bootstrap * Materialize Существует множество UI-стандартов, некоторые из которых являются общепризнанными и широко используются в индустрии разработки ПО. Ниже перечислены некоторые из них: 1. Material Design - стандарт дизайна, разработанный компанией Google. Включает в себя рекомендации по использованию цветовой палитры, шрифтов, иконок и анимаций. 2. Apple Human Interface Guidelines - руководство от Apple, в котором описываются стандарты дизайна для приложений под iOS, macOS и watchOS. 3. Microsoft Design Language - стандарт дизайна, используемый в операционных системах и приложениях от Microsoft. Он включает в себя рекомендации по использованию типографики, цвета, анимации и иконок. 4. Bootstrap - фреймворк, который содержит рекомендации по использованию готовых компонентов интерфейса, таких как кнопки, формы, таблицы и другие элементы. 5. Materialize - фреймворк, основанный на Material Design, который содержит готовые компоненты интерфейса, такие как кнопки, навигационные панели, формы и др. Кроме этого, многие компании имеют свои собственные UI-стандарты и руководства для разработки интерфейсов своих продуктов. ## Footnote https://easyoffer.ru/question/8980

Answer 6

**Краткая суть:** * Черный ящик: Нет доступа ко внутренней структуре приложения и коду. Тестирование проводится с точки зрения конечного пользователя. * Белый ящик: Основывается на внутренней структуре системы или ее реализации (код, архитектура, принципы работы и\или потоки данных внутри системы) * Серый ящик: доступ к базам данных, архитектурным схемам и документации API. **Белый ящик (White Box Testing)** Также известен как структурное тестирование. В этом подходе тестировщики имеют полное представление о внутренней структуре и коде программы. Тесты разрабатываются с учётом алгоритмов, ветвлений кода, путей выполнения и внутренних интерфейсов. Цель — проверить внутренние операции продукта и убедиться, что все внутренние компоненты функционируют правильно. **Чёрный ящик (Black Box Testing)** В этом методе тестировщики не знают о внутреннем устройстве тестируемой системы. Тесты разрабатываются на основе требований и спецификаций функциональности, без знания о том, как система реализует эти функции. Цель — проверить, соответствует ли система внешним требованиям и ожиданиям пользователя. Тестируется функциональность и поведение системы. **Серый ящик (Grey Box Testing)** Этот метод является комбинацией подходов белого и чёрного ящиков. Тестировщики имеют частичное знание о внутреннем устройстве системы, что позволяет им создавать более целенаправленные тестовые сценарии, основываясь как на внутренней структуре, так и на функциональных требованиях. Это может включать доступ к базам данных, архитектурным схемам и документации API. ## Footnote https://easyoffer.ru/question/7858

Answer 7

**Краткая суть:** проверка поведения системы при рабочей нагрузке: скорость, время отклика, стабильность, надежность, мастштабируемость и использование ресурсов ПО при определенной рабочей нагрузке. **Тестирование производительности** - это нефункциональный вид тестирования программного обеспечения, используемый для проверки скорости, времени отклика, стабильности, надежности, масштабируемости и использования ресурсов программного приложения при определенной рабочей нагрузке, обычно регрессионным образом, когда в приложение ежедневно или еженедельно вносятся небольшие изменения. **Основная цель тестирования производительности** - выявить и устранить узкие места производительности в программном приложении. Это подмножество performance engineering, также известное как «Perf Testing». Само по себе оно не призвано находить дефекты, но оно помогает в обнаружении узких мест в системе. Обычно продолжительность теста производительности составляет 1 час (устойчивое состояние) на средней / ожидаемой нагрузке; это может варьироваться в зависимости от вашего SLA / требований. **Примечание 1:** все подвиды тестирования производительности отличаются, грубо говоря, только параметрами (тип возрастания нагрузки, ее количество, длительность и т.п.) и собираемыми метриками (без которых это тестирование бессмысленно). Точкой отсчета для всех подвидов принято брать результаты Capacity testing. **Примечание 2:** несмотря на необходимость понимания многих математических и статистических концепций, многие тестировщики и менеджеры либо не имеют достаточных знаний в области математики и статистики, либо не пользуются ими. Это приводит к значительным искажениям и неверной интерпретации результатов тестирования производительности (те же перцентили).

Answer 8

Smoke - проверка стабильности билда, что он вообще работает. Sanity - более глубокая проверка важного функционала.

Answer 9

**Краткая суть:** Таблица для отслеживания взаимосвязей между требованиями проекта и выполненной по ним работе. (Учёт реализации требований) **Матрица трассируемости (Traceability Matrix)** — это документ или таблица, используемая в управлении проектами и разработке программного обеспечения для отслеживания и демонстрации взаимосвязей между требованиями проекта и работой, выполненной для их удовлетворения. Этот инструмент позволяет убедиться, что все требования к проекту или системе были учтены и реализованы на различных этапах разработки, включая дизайн, разработку и тестирование. **Основные цели:** * Подтверждение полноты: Гарантировать, что каждое требование отражено в конечном продукте и что все элементы продукта обоснованы требованиями. * Упрощение валидации и верификации: Помочь в проверке соответствия продукта требованиям, обеспечивая легкую отслеживаемость от требований к тестовым случаям и обратно. * Управление изменениями: Облегчить оценку влияния изменений требований на проект, позволяя быстро определить, какие компоненты системы будут затронуты. * Улучшение коммуникации: Служить средством общения между всеми заинтересованными сторонами проекта, предоставляя прозрачный вид на статус требований и их реализацию. **Типы**: * Вертикальная трассируемость: Отслеживает взаимосвязь между требованиями на разных уровнях (например, от бизнес-требований к пользовательским историям и далее к функциональным и нефункциональным требованиям). * Горизонтальная трассируемость: Связывает требования с соответствующими артефактами разработки, такими как техническая документация, исходный код, тестовые сценарии и результаты тестирования. **Структура:** Матрица может быть структурирована различными способами в зависимости от потребностей проекта, но обычно она содержит: * ID требований: Уникальные идентификаторы для каждого требования. * Описание требований: Краткое описание требований для удобства отслеживания. * Ссылки на артефакты: Ссылки на дизайн, исходный код, тестовые случаи и другие документы, связанные с каждым требованием. Статус: Текущее состояние реализации требования (например, “Не начато”, “В процессе”, “Завершено”). Матрица трассируемости является мощным инструментом управления качеством и рисками в проектах разработки, позволяя эффективно контролировать выполнение требований и обеспечивать высокое качество конечного продукта. ## Footnote https://easyoffer.ru/question/7931

Answer 10

Sanity - подвид регрессионного тестирования, используется на более стабильных билдах для определения работоспособности определенной части приложения после внесения изменений. Тест работоспособности (sanity test): См. тест “на дым”. (ISTQB) Другие источники: Sanity testing также является подмножеством регрессионного тестирования и выполняется до или вместо полной регрессии, но после smoke. Эти два подвида похожи, но в целом Sanity используется на более стабильных билдах для определения работоспособности определенной части приложения после внесения изменений. Примечание. Санитарным это тестирование в русскоязычной среде назвалось по совершенно непонятным причинам, но гуглится только так. На самом же деле дословно переводится как тестирование на вменяемость / разумность / работоспособность / согласованность или по версии ISTQB “Тест работоспособности”. Sanity тестирование (от англ. “sanity” — “здравомыслие”) — это вид тестирования, который проводится для подтверждения того, что после внесения небольших изменений или исправлений в программный продукт основные функции по-прежнему работают корректно. Этот тип тестирования обычно выполняется в конце тестового цикла и перед выпуском продукта для убеждения в том, что внесенные изменения не привели к возникновению новых критических ошибок в уже проверенных и работающих частях программы. Данное тестирование часто путают с Smoke тестированием, но между ними есть различия. Smoke тестирование выполняется для проверки стабильности и работоспособности всего программного продукта или его ключевых компонентов и обычно проводится в начале тестового цикла. В то время как Sanity фокусируется на конкретных функциях или изменениях, которые были внесены в программный продукт, и проводится для подтверждения того, что эти последние изменения не нарушили основную функциональность. **Пример:** Допустим, команда разработки вносит изменения в модуль регистрации пользователей в веб-приложении. После внесения изменений QA инженер проводит Sanity тестирование этого модуля, чтобы убедиться, что регистрация по-прежнему работает корректно: пользователь может зарегистрироваться, получить подтверждение регистрации и войти в систему используя новые учетные данные. **Цели:** * Быстрая проверка: Убедиться, что после небольших изменений или исправлений в программном продукте не возникло критических проблем. * Сосредоточение на изменениях: Проверка только тех аспектов программного продукта, которые подверглись изменениям, без проведения глубокого и всеобъемлющего тестирования. * Экономия времени и ресурсов: Позволяет быстро оценить влияние внесенных изменений, не тратя время на полный цикл тестирования. * Такое тестирование является важной частью процесса обеспечения качества программного продукта, так как оно позволяет быстро и эффективно подтвердить, что внесенные изменения не повлияли негативно на уже проверенную и работающую функциональность. Этот тип тестирования особенно полезен в условиях ограниченного времени и ресурсов, когда необходимо сделать быструю проверку перед выпуском продукта или передачей его на дальнейшие этапы тестирования. Sanity тестирование — это быстрая проверка того, что после внесения небольших изменений в программное обеспечение основные функции продолжают работать корректно. Этот тип тестирования помогает подтвердить здравомыслие программного продукта перед его дальнейшим тестированием или выпуском. ## Footnote https://easyoffer.ru/question/7810 https://vladislaveremeev.gitbook.io/qa_bible/vidy-metody-urovni-testirovaniya/regressionnye-vidy-testirovaniya-regression-testing

Answer 11

Сквозное тестирование - Сквозное тестирование (End-to-end, E2E, Chain testing) — используется для проверки ПО от начала до конца, а также его интеграцию с внешними интерфейсами. Цель сквозного тестирования состоит в проверке всего программного обеспечения на предмет зависимостей, целостности данных и связи с другими системами, интерфейсами и базами данных для проверки успешного выполнения полного производственного сценария. **Пример:** На примере интернет магазина, это одна объемная проверка, которая включает в себя все шаги пользователя, начиная от регистрации в системе и заканчивая покупкой товара в магазине. ## Footnote https://habr.com/ru/companies/otus/articles/681066/

Answer 12

**Суть:** выявляет уязвимости, угрозы и риски. Целью тестов безопасности является выявление всех возможных лазеек и слабых мест в ПО, которые могут привести к потере информации, доходов, репутации компании, сотрудников или клиентов. Общая стратегия безопасности основывается на трех основных принципах: * Конфиденциальность - сокрытие определенных ресурсов или информации; * Целостность - ресурс может быть изменен только в соответствии с полномочиями пользователя; * Доступность - ресурсы должны быть доступны только авторизованному пользователю, внутреннему объекту или устройству; Тестирование безопасности обычно выполняет отдельный специалист по безопасности. В ходе тестирования безопасности испытатель играет роль взломщика. Ему разрешено все: * попытки узнать пароль с помощью внешних средств; * атака системы с помощью специальных утилит, анализирующих защиты; * перегрузка системы (в надежде, что она откажется обслуживать других клиентов); * целенаправленное введение ошибок в надежде проникнуть в систему в ходе восстановления; * просмотр несекретных данных в надежде найти ключ для входа в систему; При неограниченном времени и ресурсах хорошее тестирование безопасности взломает любую систему. Задача проектировщика системы - сделать цену проникновения более высокой, чем цена получаемой в результате информации. ## Footnote https://vladislaveremeev.gitbook.io/qa_bible/vidy-metody-urovni-testirovaniya/testirovanie-bezopasnosti-security-and-access-control-testing

Answer 13

**Краткая суть:** приоритеты в тестировании устанавливаются на основе оценки рисков. Акцент на частях системы с наибольшим риском возникновения серьёзных проблем, влияющих на работоспособность продукта и удовлетворённость пользователя. Подход позволяет оптимизировать процесс тестирования, обеспечивая наибольшую эффективность при ограниченных ресурсах. **Тестирование рисков (Risk-Based Testing)** — это подход к тестированию ПО, при котором приоритеты в тестировании устанавливаются на основе оценки рисков. Это означает, что внимание и ресурсы сосредотачиваются прежде всего на тех частях системы, которые несут наибольший риск возникновения серьёзных проблем или ошибок, влияющих на работоспособность продукта и удовлетворённость пользователя. Подход позволяет оптимизировать процесс тестирования, обеспечивая наибольшую эффективность при ограниченных ресурсах. **Основные этапы:** 1. Идентификация рисков: Определение потенциальных угроз для проекта, которые могут включать технические аспекты (например, сложность реализации определённой функции), а также факторы, связанные с бизнес-целями (например, важность функции для клиента). 2. Анализ и оценка рисков: Оценка вероятности возникновения каждого риска и степени его воздействия на проект. Это помогает определить приоритеты для тестирования. 3. Планирование тестирования: Разработка стратегии и плана тестирования, в котором тест-кейсы распределяются с учётом установленных приоритетов риска. 4. Выполнение тестирования: Тестирование программного обеспечения с акцентом на области, представляющие наибольший риск. 5. Мониторинг и контроль: Отслеживание процесса тестирования и внесение корректировок в план в соответствии с изменениями в проекте и повторной оценкой рисков. 6. Анализ результатов: Оценка результатов тестирования и определение, как риски были снижены до приемлемого уровня. **Преимущества:** * Фокус на критически важных аспектах: Тестирование сосредотачивается на наиболее важных с точки зрения бизнеса и технической сложности функциях. * Эффективное использование ресурсов: Ресурсы для тестирования распределяются таким образом, чтобы максимизировать покрытие наиболее рискованных областей при ограниченных времени и бюджете. * Улучшение качества продукта: Снижение рисков, связанных с программным обеспечением, ведёт к повышению общего качества продукта. * Повышение удовлетворённости клиентов: Защита от потенциальных проблем, которые могли бы наиболее негативно сказаться на пользовательском опыте. Тестирование рисков требует тщательной подготовки и глубокого понимания как бизнес-целей проекта, так и технических аспектов программного обеспечения. Это позволяет оптимизировать процесс тестирования и обеспечивает создание качественного продукта, соответствующего ожиданиям клиентов. ## Footnote https://easyoffer.ru/question/7932

Answer 14

**Краткая суть:** через выполнение кода (через запуск программы. **Динамическое тестирование** — это процесс проверки ПО путём выполнения его кода с целью обнаружения ошибок. В отличие от статического тестирования, которое анализирует код без его выполнения, динамическое требует запуска программы в реальной или эмулированной среде выполнения. Этот подход позволяет проверить поведение программы в различных ситуациях, включая обработку данных, взаимодействие с другими системами, реакцию на ввод пользователя и выполнение предназначенных функций. **Основные аспекты динамического тестирования:** * Виды тестирования: Включают функциональное (проверка соответствия функциональным требованиям), нефункциональное (проверка производительности, безопасности, удобства использования и т. д.), а также регрессионное (проверка, что новые изменения не привели к появлению ошибок в уже протестированных частях программы). * Уровни: Различают несколько уровней, включая модульное (тестирование отдельных компонентов или модулей), интеграционное (проверка взаимодействия между модулями или системами) и системное (проверка всей системы в целом). * Автоматизация: Динамическое тестирование может быть как ручным, так и автоматизированным. Автоматизация включает использование специального ПО для создания и выполнения тестов, что позволяет повысить эффективность тестирования и ускорить процесс разработки. * Тестовые сценарии и данные: Разработка тестовых сценариев и подготовка тестовых данных являются ключевыми аспектами динамического тестирования. Они описывают условия и шаги для проверки конкретных функций или сценариев использования, а тестовые данные предоставляют необходимую информацию для выполнения этих тестов. **Преимущества:** * Практическая проверка: Динамическое тестирование демонстрирует реальное поведение программы, позволяя обнаружить ошибки, которые могут не быть очевидны при статическом анализе. * Валидация функциональности: Помогает убедиться, что программное обеспечение выполняет все требуемые функции и соответствует спецификациям. * Повышение качества продукта: Помогает улучшить надёжность, производительность и безопасность программного продукта, повышая тем самым удовлетворённость пользователя. ## Footnote https://easyoffer.ru/question/7826

Answer 15

**Суть:** Повторное использование одних и тех же тестовых сценариев со временем становится всё менее эффективным в обнаружении новых дефектов. Аналогия с пестицидами в сельском хозяйстве подразумевает, что так же, как вредители могут со временем развить устойчивость к определённым химическим веществам, программное обеспечение может “привыкнуть” к постоянно повторяемым тестам, и эти тесты перестанут быть эффективными для нахождения новых ошибок. **Причины:** * Ограниченное покрытие: Повторяющиеся тесты часто проверяют одни и те же аспекты программного обеспечения, оставляя другие части кода мало исследованными. * Привыкание к дефектам: Со временем разработчики и тестировщики могут начать игнорировать известные проблемы, считая их “нормой”. * Неадаптивность к изменениям: В процессе разработки ПО постоянно вносятся изменения, но если тесты не адаптируются под эти изменения, их эффективность уменьшается. **Как преодолеть эффект:** * Регулярное обновление тестов: Необходимо периодически пересматривать и обновлять тестовые сценарии для адаптации к изменениям в программном обеспечении и среде. * Использование разнообразных методов тестирования: Применение различных подходов и техник тестирования помогает обеспечить более полное покрытие тестами и увеличивает шансы на обнаружение дефектов. * Исследовательское тестирование: Помимо автоматизированных и ручных тестов по сценариям, полезно включать исследовательское тестирование, которое предполагает исследовательский подход к поиску ошибок. * Перемешивание тестов: Изменение порядка тестов и данных может помочь выявить новые ошибки, которые не обнаруживаются при стандартном выполнении тестов. Эффект пестицида подчёркивает важность постоянного обновления и улучшения процессов тестирования в динамичной среде разработки программного обеспечения. Постоянное стремление к улучшению тестов и методов тестирования помогает поддерживать высокое качество продукта и эффективность процесса обнаружения дефектов. ## Footnote https://easyoffer.ru/question/7872

Answer 16

**Суть:** Некорректная работа программы, вызванная ошибкой в программном коде или дизайне продукта. **Баг** — это ошибка, дефект или недочёт в коде, из-за которого ПО ведёт себя непредсказуемо, некорректно или не соответствует спецификациям и требованиям. Это может проявляться в виде сбоев, неправильной обработки данных, отклонений от заданных функциональных требований или других нежелательных поведений программы. **Причины возникновения могут включать:** * Ошибки в логике программы или алгоритмах. * Неправильное использование типов данных или структур. * Ошибки в коде, связанные с неучтёнными условиями или краевыми случаями. * Непредвиденное взаимодействие между различными частями программы или с внешними системами. * Ошибки в документации, приводящие к неправильной реализации функционала. **Обработка и исправление включает в себя несколько этапов:** 1. Идентификация и регистрация: Сначала он должен быть обнаружен, что может произойти в процессе разработки, тестирования или уже после релиза продукта пользователями. Затем ошибка регистрируется в системе учёта задач или баг-трекере с подробным описанием проблемы, условий, при которых она возникает, и, по возможности, шагов для её воспроизведения. 2. Анализ и приоритизация: Команда разработки анализирует зарегистрированные баги, определяет их причины и приоритеты для исправления на основе важности функционала и влияния ошибки на пользователей. 3. Исправление: Разработчики вносят необходимые изменения в код для устранения ошибки. 4. Тестирование: После исправления бага проводится повторное тестирование соответствующего функционала, а также регрессионное тестирование для убедительности в том, что исправления не привели к новым проблемам в программе. 5. Деплоймент: Исправленный код включается в следующую версию программного продукта, которая после прохождения всех тестов и проверок выкладывается для пользователей. Управление багами является важной частью процесса разработки программного обеспечения, поскольку позволяет систематически улучшать качество продукта, устраняя обнаруженные недостатки и повышая удовлетворённость пользователей.

Answer 17

**Software Testing Life Cycle:** 1. Анализ требований 2. Планирование тестирования 3. Разработка тест-кейсов 4. Настройка тестовой среды 5. Выполнение тестов 6. Завершение цикла испытаний **Критерии входа:** обязательные элементы, которые должны быть выполнены перед началом тестирования. **Критерии выхода:** определяют элементы, которые должны быть выполнены до завершения тестирования. 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% регрессионных тест-кейсов ## Footnote https://stepik.org/lesson/1036729/step/4?auth=login&unit=1045214 https://vladislaveremeev.gitbook.io/qa_bible/sdlc-i-stlc/zhiznennyi-cikl-testirovaniya-po-stlc-software-testing-lifecycle

Answer 18

**Суть:** Некорректная работа программы, вызванная ошибкой в программном коде или дизайне продукта. **Баг** — это ошибка, дефект или недочёт в коде, из-за которого ПО ведёт себя непредсказуемо, некорректно или не соответствует спецификациям и требованиям. Это может проявляться в виде сбоев, неправильной обработки данных, отклонений от заданных функциональных требований или других нежелательных поведений программы. **Причины возникновения могут включать:** * Ошибки в логике программы или алгоритмах. * Неправильное использование типов данных или структур. * Ошибки в коде, связанные с неучтёнными условиями или краевыми случаями. * Непредвиденное взаимодействие между различными частями программы или с внешними системами. * Ошибки в документации, приводящие к неправильной реализации функционала. **Обработка и исправление включает в себя несколько этапов:** * Идентификация и регистрация: Сначала он должен быть обнаружен, что может произойти в процессе разработки, тестирования или уже после релиза продукта пользователями. Затем ошибка регистрируется в системе учёта задач или баг-трекере с подробным описанием проблемы, условий, при которых она возникает, и, по возможности, шагов для её воспроизведения. * Анализ и приоритизация: Команда разработки анализирует зарегистрированные баги, определяет их причины и приоритеты для исправления на основе важности функционала и влияния ошибки на пользователей. * Исправление: Разработчики вносят необходимые изменения в код для устранения ошибки. * Тестирование: После исправления бага проводится повторное тестирование соответствующего функционала, а также регрессионное тестирование для убедительности в том, что исправления не привели к новым проблемам в программе. * Деплоймент: Исправленный код включается в следующую версию программного продукта, которая после прохождения всех тестов и проверок выкладывается для пользователей. Управление багами является важной частью процесса разработки программного обеспечения, поскольку позволяет систематически улучшать качество продукта, устраняя обнаруженные недостатки и повышая удовлетворённость пользователей. ## Footnote Надо дополнить: https://testengineer.ru/error-defect-fault-bug-failure/ https://testbase.ru/235

Answer 19

**Приоритет** - как быстро нужно исправить ошибку **Серьезность** - насколько серьезно ошибка затрагивает функциональность

Answer 20

У компании Google на главной странице ошибка в слове “Gogle”. **Высокий приоритет, но низкая серьёзность** Это означает, что дефект нужно исправить как можно скорее, хотя он и не оказывает значительного влияния на функциональность системы. Примеры могут включать: * Ошибки в ключевых текстах или логотипах на главной странице: Хотя это не влияет на функциональность, такая ошибка может негативно сказаться на репутации компании. * Незначительные ошибки в функционале, используемом во время демонстраций для важных клиентов: Например, ошибка в отображении логотипа компании-клиента в демо-версии продукта. **Низкий приоритет, но высокая серьёзность** Такие дефекты оказывают значительное влияние на работу системы, но их исправление может быть отложено из-за низкого влияния на текущие бизнес-процессы или из-за малой вероятности возникновения. **Примеры могут включать:** * Критические ошибки в редко используемых функциях: Например, сбой системы при выполнении специфической операции, которую используют единицы пользователей. * Серьёзные ошибки в функционале, планируемом к скорому удалению или переработке: Если известно, что данный функционал будет скоро заменён, может быть принято решение не тратить ресурсы на исправление серьёзной ошибки. ## Footnote https://easyoffer.ru/question/7895

Answer 21

**Верификация** отвечает на вопрос **“Строим ли мы продукт правильно?”**, проверяя соответствие продукта требованиям и спецификациям на каждом этапе разработки. **Валидация** отвечает на вопрос **“Строим ли мы правильный продукт?”**, подтверждая, что конечный продукт удовлетворяет потребностям и ожиданиям конечного пользователя. ## Footnote https://easyoffer.ru/question/7811

Answer 22

**Суть:** документ для планирования тестирования 1. Что надо протестировать 2. Что будем действительно тестировать 3. Как будем тестировать 4. Когда будем тестировать 5. Критерии сдачи 6. Критерии приёмки **Тест-план** — это документ, который описывает объем, подход, ресурсы и план тестирования ПО. Он служит руководством для тестирования продукта, определяя стратегию, задачи, приоритеты, ресурсы, графики и риски, связанные с процессом тестирования. Он помогает всей команде понимать задачи тестирования и ожидаемые результаты, а также обеспечивает структурированный подход к обеспечению качества. **Основные элементы:** 1. Введение: Краткое описание проекта и целей тестирования. 2. Объекты тестирования: Список компонентов или функций программного обеспечения, которые будут тестироваться. 3. Задачи тестирования: Четкое определение целей тестирования, включая что должно быть протестировано и что должно быть достигнуто в результате тестирования. 4. Область тестирования и исключения: Описание того, что будет тестироваться, а также того, что будет исключено из тестирования. 5. Подход к тестированию: Описание методологии и техник тестирования, которые будут использоваться, включая уровни тестирования (например, модульное, интеграционное, системное, приемочное). 6. Критерии начала и завершения тестирования: Определение условий, при которых тестирование начнется и завершится. 7. Ресурсы: Перечень всех необходимых ресурсов для тестирования, включая персонал, тестовое оборудование, и тестовые данные. 8. Ответственные: Распределение ролей и обязанностей в команде тестирования. 9. График тестирования: Временная шкала выполнения тестовых задач и этапов. 10. Управление рисками: Оценка потенциальных рисков для плана тестирования и стратегии их минимизации. 11. План выпуска тестов: Порядок выполнения тестов, включая зависимости между тестами. 12. Требования к документированию: Описание того, как будут документироваться найденные дефекты, отчеты о тестировании и итоговые результаты. Тест-план играет важную роль в успешном тестировании ПО. Он помогает обеспечить, что процесс тестирования является организованным, систематическим и эффективным. Тест-план также способствует обеспечению прозрачности и понимания процесса тестирования для всех участников проекта, а также помогает в управлении ожиданиями заинтересованных сторон относительно объема и глубины тестирования. Создание тест-плана является критическим шагом в обеспечении качества программного продукта и должно предшествовать началу любых тестовых действий. ## Footnote https://easyoffer.ru/question/7846

Answer 23

**Суть:** планирование требуется всегда, тест план нужен не всегда 1. Что надо протестировать 2. Что будем действительно тестировать 3. Как будем тестировать 4. Когда будем тестировать 5. Критерии сдачи 6. Критерии приёмки В то время как стратегия излагает общие принципы или теорию, план детально описывает практические аспекты того, как проект будет протестирован в реальности. Даже в Agile необходимо предварительное планирование для структурирования работы, распределения ресурсов и планирования - по крайней мере, на высоком уровне - процесса выпуска на ближайшие месяцы. Но итерация за итерацией, а часто и день за днем, общий план постоянно корректируется с учетом событий и новой информации, которая появляется на свет. Планирование - это непрерывное обучение, а не задача с конечным результатом. В гибких методологиях всё чаще говорят о концепции одностраничного тест-плана, а в случае необходимости дополнений и уточнений просто создаются ссылки на внешние страницы/документы. **Тест-план призван отвечать на те вопросы, ради которых его создают.** Порой весомую часть пользы от данной активности можно получить на этапе самого планирования и составления плана, а не от самого документа. Если команда понимает, что никакой практической “боли” этот документ и его создание не решает, на него нет времени, то можно прекрасно обойтись и без его формализации, т.к. в некоей словесной форме он всё равно будет существовать всегда.

Answer 24

Тест-кейс и чек-лист являются инструментами в области тестирования ПО, но они служат разным целям и используются в различных контекстах. **Тест-кейс** Это документ, который содержит подробные инструкции для проверки конкретного аспекта системы или приложения. Он включает в себя информацию о предварительных условиях, входных данных, действиях, которые нужно выполнить, ожидаемых результатах и фактических результатах. Они разрабатываются для того, чтобы обеспечить систематическую проверку функциональности продукта и гарантировать, что все сценарии использования были тщательно протестированы. **Особенности:** * Подробное описание процедуры тестирования. * Четко определенные шаги. * Ожидаемые результаты для каждого шага. * Предназначен для повторного использования в разных циклах тестирования. **Чек-лист** Это более обобщенный документ, который содержит список элементов или задач, которые нужно проверить, но без подробного описания того, как именно эти проверки должны быть выполнены. Они используются для упрощения процесса тестирования и обеспечения того, чтобы все важные аспекты были учтены. Они могут служить напоминанием для тестировщиков о том, что необходимо проверить, но оставляют за тестировщиком свободу выбора способа проверки. **Особенности:** * Список проверок без подробных инструкций. * Гибкость в использовании. * Может не содержать ожидаемых результатов. * Подходит для общего обзора тестирования и помощи в организации тестов. **Различия:** * Детализация: Тест-кейс содержит подробные шаги и ожидаемые результаты, в то время как чек-лист представляет собой простой список элементов для проверки. * Цель использования: Тест-кейсы разработаны для детального тестирования функциональности и обеспечения полного покрытия тестами. Чек-листы же чаще используются для быстрой проверки или в качестве напоминания о том, что нужно протестировать. * Гибкость: Чек-листы более гибкие и могут быть легко адаптированы под разные задачи и условия тестирования. Тест-кейсы, с другой стороны, требуют точного следования предписанным шагам. И тест-кейсы, и чек-листы являются важными инструментами, выбор между которыми зависит от конкретной задачи, целей тестирования и требуемой глубины проверки.

Теория тестирования (начальный уровень) Flashcards

(49 cards)