Техники дест дизайна (Test Design Technics)

Шапка

Короткое описание (Summary) Короткое описание проблемы, явно указывающее на причину и тип ошибочной ситуации.

Проект (Project) Название тестируемого проекта

Компонент приложения (Component) Компонент приложения (Component)

Номер версии (Version) Версия на которой была найдена ошибка

Серьезность (Severity) Наиболее распространена пятиуровневая система градации серьезности дефекта: S1 Блокирующий (Blocker), S2 Критический (Critical), S3 Значительный (Major), S4 Незначительный (Minor), S5 Тривиальный (Trivial) [(подробнее смотрите ниже в разделе Серьезность дефекта)]

Приоритет (Priority) Приоритет дефекта: P1 Высокий (High), P2 Средний (Medium), P3 Низкий (Low) [(подробнее смотрите ниже в разделе Приоритет дефекта)]

Статус (Status) Статус бага. Зависит от используемой процедуры и жизненного цикла бага (bug workflow and life cycle)

Автор (Author) Создатель баг репорта

Назначен на (Assigned To) Имя сотрудника, назначенного на решение проблемы

Окружение

ОС / Сервис Пак и т.д. / Браузера + версия / ... Информация об окружении, на котором был найден баг: операционная система, сервис пак, для WEB тестирования - имя и версия браузера и т.д.

...

Описание

Шаги воспроизведения (Steps to Reproduce) Шаги, по которым можно легко воспроизвести ситуацию, приведшую к ошибке.

Фактический Результат (Result) Результат, полученный после прохождения шагов к воспроизведению

Ожидаемый результат (Expected Result) Ожидаемый правильный результат

Дополнения

Прикрепленный файл (Attachment) Файл с логами, скриншот или любой другой документ, который может помочь прояснить причину ошибки или указать на способ решения проблемы

[Сайт «Про Тестинг»]

16. Приоритет и Серьезность

Серьезность (Severity) - это атрибут, характеризующий влияние дефекта на работоспособность приложения.

Приоритет (Priority) - это атрибут, указывающий на очередность выполнения задачи или устранения дефекта. Можно сказать, что это инструмент менеджера по планированию работ. Чем выше приоритет, тем быстрее нужно исправить дефект.

Градация Серьезности дефекта (Severity)

S1 Блокирующая (Blocker)
Блокирующая ошибка, приводящая приложение в нерабочее состояние, в результате которого дальнейшая работа с тестируемой системой или ее ключевыми функциями становится невозможна. Решение проблемы необходимо для дальнейшего функционирования системы.

S2 Критическая (Critical)
Критическая ошибка, неправильно работающая ключевая бизнес логика, дыра в системе безопасности, проблема, приведшая к временному падению сервера или приводящая в нерабочее состояние некоторую часть системы, без возможности решения проблемы, используя другие входные точки. Решение проблемы необходимо для дальнейшей работы с ключевыми функциями тестируемой системой.

S3 Значительная (Major)
Значительная ошибка, часть основной бизнес логики работает некорректно. Ошибка не критична или есть возможность для работы с тестируемой функцией, используя другие входные точки.

S4 Незначительная (Minor)
Незначительная ошибка, не нарушающая бизнес логику тестируемой части приложения, очевидная проблема пользовательского интерфейса.

S5 Тривиальная (Trivial)
Тривиальная ошибка, не касающаяся бизнес логики приложения, плохо воспроизводимая проблема, малозаметная посредством пользовательского интерфейса, проблема сторонних библиотек или сервисов, проблема, не оказывающая никакого влияния на общее качество продукта.

Градация Приоритета дефекта(Priority)

P1 Высокий (High)
Ошибка должна быть исправлена как можно быстрее, т.к.ее наличие является критической для проекта.

P2 Средний (Medium)
Ошибка должна быть исправлена, ее наличие не является критичной, но требует обязательного решения.

P3 Низкий (Low)
Ошибка должна быть исправлена, ее наличие не является критичной, и не требует срочного решения.

Порядок исправления ошибок по их приоритетам:

High -> Medium -> Low

[Сайт «Про Тестинг»]

17. Назовите баг с высшим приоритетом и низкой серьезностью и наоборот

Например, если на главной странице вместо "Сделать Яндекс стартовой страницей" была бы надпись с орфографической ошибкой: "Сделать Япдекс стартовой страницей" (высший приоритет - низкая серьёзность)

Например, ошибка на уровне архитектуры, исправление которой на текущий момент дороже, чем существование с ней (низкий приоритет - высокая серьезность)

18. Use case отличие от test case

Сценарий использования системы (use case): Последовательность операций во взаимодействии актера и компонента или системы со значимым результатом, при которой актером может быть как пользователь, так и все, что может обмениваться информацией с системой.

Тестовый сценарий(test case): Набор входных значений, предусловий выполнения, ожидаемых результатов и постусловий выполнения, разработанный для определенной цели или тестового условия, таких как выполнения определенного пути программы или же для проверки соответствия определенному требованию.

[IEEE 610 - Стандартный глоссарий терминов, используемых в тестировании программного обеспечения (Версия 2.2)]

Важное Дополнение: Читать (документ ppt), желательно всё, кому лень вам стр.24-25.

19. Верификация и валидация.

Верификация (verification): Подтверждение посредством представления объективных свидетельств того, что установленные требования были выполнены.

Примечания

1. Термин “верифицирован” используют для обозначения соответствующего статуса.

2. Деятельность по подтверждения требования может включать в себя:

· Осуществления альтернативных расчетов;

· Сравнение спецификации на новый проект с аналогичной документацией н апробированный проект;

· Проведение испытаний и демонстраций;

· Анализ документов до их выпуска.

Валидация (validation): Подтверждение посредством представления объективных свидетельств того, что требования, предназначенные для конкретного использования или применения, выполнены.

Примечания

1. Термин “валидация” используют для обозначения соответствующего статуса.

2. Условия применения могут быть реальными или смоделированными.

[ГОСТ ISO 9000-2011.

Объективное свидетельство(objective evidence): Данные, подтверждающие наличие или истинность чего-либо.

Требование (requirement): Потребность или ожидание, которое установлено, обычно предполагается или является обязательным

Спецификация (specification): Документ, устанавливающий требования.

Испытание (test): Определение одной или нескольких характеристик согласно установленной процедуре.]

20. Граничные условия, классы эквивалентности.

Граничное значение(boundary value): Входное значение или выходные данные, которое находится на грани эквивалентной области или на наименьшем расстоянии от обеих сторон грани, например, минимальное или максимальное значение области.

Эквивалентная область(equivalence partition): Часть области входных или выходных данных, для которой поведение компонента или системы, основываясь на спецификации, считается одинаковым.

[Стандартный глоссарий терминов, используемых в тестировании программного обеспечения (Версия 2.2)]

21. Различие между тестированием desktop and web.

Одно из мнений:

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

...

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

[Отсюда]

Комментарий BadMF: "да глупости это всё, высосанные из пальца, c учётом развития интернет технологий никакой разницы нет."

22. Поддержка пользователей (Support).

Автор: Рина Уживко. Читать.

23. Отличие Sanity от Smoke.

Тест работоспособности (sanity test): См. тест "на дым".

Тест "на дым" (smoke test): Выборка из общего числа запланированных тестовых сценариев, покрывающая основную функциональность компонента или системы. Проводится с целью удостовериться, что базовые функции программы в целом работают корректно, без углубления в детали. Ежедневная сборка и тест "на дым" являются передовыми практическими методами. См.

входной тест.

Входной тест (intake test): Специальный тип теста "на дым" для принятия решения, готов ли компонент или система готова для дальнейшего детального тестирования. Обычно начинается в начале фазы тестирования. См. также тест "на дым".

[Стандартный глоссарий терминов, используемых в тестировании программного обеспечения (Версия 2.2)]

Другое мнение:

Отличие санитарного тестирования от дымового (Sanity vs Smoke testing)

В некоторых источниках ошибочно полагают, что санитарное и дымовое тестирование - это одно и тоже. Мы же полагаем, что эти виды тестирования имеют "вектора движения", направления в разные стороны. В отличии от дымового (Smoke testing), санитарное тестирование (Sanity testing) направлено вглубь проверяемой функции, в то время как дымовое направлено вширь, для покрытия тестами как можно большего функционала в кратчайшие сроки.

[Сайт «Про Тестинг»]

24. Разработка Agile and Waterfall

Гибкая методология разработки [wiki]

Каскадная модель [wiki]

25. Какая система разработки используется на проекте сейчас.

Итеративая разработка. Какая система разработки используется у вас - вам лучше знать.

26. Какие роли на проекте занимает Junior,Middle,Senior.

Автор: Сергей Марков. Читать.

27. Различие между error, bug, failure.

Ошибка(error): Действие человека, которое приводит к неправильному результату. [IEEE 610]

Помеха(bug): См. дефект.

Дефект (defect): Изъян в компоненте или системе, который может привести компонент или систему к невозможности выполнить требуемую функцию, например неверный оператор или определение данных. Дефект, обнаруженный во время выполнения, может привести к отказам компонента или системы.

Отказ(failure): Отклонение компонента или системы от ожидаемого выполнения, эксплуатации или результата. [Fenton]

[Стандартный глоссарий терминов, используемых в тестировании программного обеспечения (Версия 2.2)]

Различия вытекают из определений.

 

Приоритет литературы: Стандарты (ГОСТ ISO 9000-2011 (аналог ISO 9000:2005) и IEEE Guide to Software Engineering Body of Knowledge, SWEBOK, 2004) > ISTQB (Стандартный глоссарий терминов, используемых в тестировании программного обеспечения (Версия 2.2) и Сертифицированный тестировщик. Программа обучения Базового уровня. Версия 2011.) > книги по тестированию (Искусство тестирования программ, Тестирование программного обеспечения, Тестирование Дот Ком) > ссылки (в случае ссылки указан источник).

 

Техники дест дизайна (Test Design Technics)

Многие люди тестируют и пишут тестовые случаи (test cases), но не многие пользуются специальнымитехниками тест дизайна. Постепенно, набираясь опыта они осознают, что постоянно делают одну и ту же работу, поддающуюся конкретным правилам. И тогда они находят, что все эти правила уже описаны.

Предлагаю вам ознакомиться с кратким описанием наиболее распространенных техник тест дизайна:

• Эквивалентное Разделение (Equivalence Partitioning - EP). Как пример, у вас есть диапазон допустимых значений от 1 до 10, вы должны выбрать одно верное значение внутри интервала, скажем, 5, и одно неверное значение вне интервала - 0.
• Анализ Граничных Значений (Boundary Value Analysis - BVA). Если взять пример выше, в качестве значений для позитивного тестирования выберем минимальную и максимальную границы (1 и 10), и значения больше и меньше границ (0 и 11). Анализ Граничный значений может быть применен к полям, записям, файлам, или к любого рода сущностям имеющим ограничения.
• Причина / Следствие (Cause/Effect - CE). Это, как правило, ввод комбинаций условий (причин), для получения ответа от системы (Следствие). Например, вы проверяете возможность добавлять клиента, используя определенную экранную форму. Для этого вам необходимо будет ввести несколько полей, таких как "Имя", "Адрес", "Номер Телефона" а затем, нажать кнопку "Добавить" - эта "Причина". После нажатия кнопки "Добавить", система добавляет клиента в базу данных и показывает его номер на экране - это "Следствие".
• Предугадывание ошибки (Error Guessing - EG). Это когда тест аналитик использует свои знания системы и способность к интерпретации спецификации на предмет того, чтобы "предугадать" при каких входных условиях система может выдать ошибку. Например, спецификация говорит: "пользователь должен ввести код". Тест аналитик, будет думать: "Что, если я не введу код?", "Что, если я введу неправильный код? ", и так далее. Это и есть предугадывание ошибки.
• Исчерпывающее тестирование (Exhaustive Testing - ET) - это крайний случай. В пределах этой техники вы должны проверить все возможные комбинации входных значений, и в принципе, это должно найти все проблемы. На практике применение этого метода не представляется возможным, из-за огромного количества входных значений.