Перейти к содержимому

lurk

Регистрация: 11 мая 2014
Offline Активность: 08 апр 2016 17:55
*****

#131076 Вопросы на собеседовании для QA. Собеседование для тестировщиков. Собе

Написано lurk 09 июня 2014 - 14:51

Еще один вопрос появился:
Инструменты для управления тест-кейсами, чек-листами (TestLinkZephyrSitechcoJite) это важно знать? Или можно обойтись без этих программ и писать тест-кейсы к примеру excel, word or by hand?

Можно. Всё зависит от конкретных потребностей.
  • 1


#130535 Вопросы на собеседовании для QA. Собеседование для тестировщиков. Собе

Написано lurk 19 мая 2014 - 10:45

Доделываю pdf. Некоторые вопросы переосмыслены, добавлены новые источники (например: Ключевые процессы тестирования, Блэк). Отошёл от части ненадёжных источников в виде сайтов. Добавил градацию вопросов по уровням отвечающего. Если вопрос для Juniorа - то будет добавлен отдельный приемлемый для Junior ответ на данный вопрос. Добавил новые вопросы. SALar прав все таки это больше иследование на текущий момент. 


  • 1


#130237 Вопросы на собеседовании для QA. Собеседование для тестировщиков. Собе

Написано lurk 11 мая 2014 - 18:53

Версия: 0.9 (Жду ваших отзывов и комментариев)

Вопросы взяты отсюда.

Выложены ответы на все 27 вопросов. 

Просьба отредактировать название темы на: "Вопросы на собеседовании для QA. Собеседование для тестировщиков."

Поскольку в данной ветке форума тема не совсем корректна (много вопросов более высокого уровня) - у меня вопрос - можно ли эту тему будет перенести в другую ветку форума, а эту закрыть?

Если да, то в какую ветку форума лучше перенести и кому по этому поводу лучше обратиться? 

Планирую оформить теоретические вопросы в формате pdf , дополнив некоторые из-них (в частности п.24), и выложить сюда.

Также думаю добавить новые ответы на вопросы отсюда. Автор вопросов: Александр Селяев.

 

Теоретические вопросы на собеседовании по тестированию:

1.      Что такое тестирование?

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

[IEEE Guide to Software Engineering Body of Knowledge, SWEBOK, 2004]

2.      Цели тестирования.

·        Обнаружение дефектов

·        Повышение уверенности в уровне качества

·        Предоставление информации для принятия решений

·        Предотвращение дефектов

[Сертифицированный тестировщик. Программа обучения Базового уровня. Версия 2011]

3.      QA, QC, Testing.

Обеспечение качества (quality assurance) - часть менеджмента качества, направленная на создание уверенности, что требования к качеству будут выполнены.

Управление качеством (quality control) - часть менеджмента качества, направленная на выполнение требований к качеству.

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

[ГОСТ ISO 9000-2011; Стандартный глоссарий терминов, используемых в тестировании программного обеспечения (Версия 2.2).

Менеджмент качества (quality management) - скоординированная деятельность по руководству и управлению организацией, применительно к качеству.

Примечание - Руководство и управление применительно к качеству обычно включает в себя разработку политики в области качества и целей в области качества, планирование качества, управление качеством, обеспечения качества и улучшение качества. ]

4.      Основные виды тестирования.

·        Функциональное тестирование

·        Нефункциональное тестирование

·        Тестирование структуры/архитектуры программного обеспечения (Структурное тестирование)

·        Тестирование изменений: подтверждающее и регрессионное тестирование.

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

Классификация видов Тестирования: по знанию внутренностей системы, по объекту тестирования, по субъекту тестирования, по времени проведения тестирования, по критерию "позитивности" сценариев, по степени изолированности тестируемых компонентов, по степени автоматизированности тестирования и по степени подготовки к тестированию.

[Тестирование Дот Ком, Савин] 

Важное Дополнение: По каким атрибутам характеристик качества мы тестируем? (благодарю SALar за формулировку данного дополнения)

[В соответствии с ГОСТ Р ИСО/МЭК 9126-93 у ПО есть 6 характеристик качества: Функциональные возможности (Functionality), Надёжность (Reliability), Практичность (Usability), Эффективность (Efficiencies), Сопровождаемость (Maintainability) и Мобильность (Portability). У каждой характеристики есть атрибуты.]

5.      Load and performance testing различия.

Нагрузочное тестирование (load testing) - вид тестирования производительности, проводимый с целью оценить поведение компонента или системы под увеличивающейся нагрузкой (число одновременно работающих пользователей и/или число транзакций) для определения максимального уровня нагрузки компонента или системы.)

Тестирование производительности (performance testing): Процесс тестирования с целью определить производительность программного продукта.  

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

Load vs Performance Testing
Нам показалось, что Load и Performance 
Testing преследуют все же одну и ту же цель: проверка производительности (времени отклика) на разных нагрузках. Собственно поэтому мы и не стали разделять их. В то же время кто то может разделить. Главное все таки понимать цели того или иного вида тестирования и постараться их достигнуть.

(Автор: Андрей Широбоков. Ответ взят отсюда.) 

Интересная статья о цели нагрузочного тестирования: Читать. Благодарю, SALar за ссылку.

6.      Не функциональные виды тестирования.

·       Нефункциональное тестирование - включает, но не ограничивается, нагрузочное тестирование, тестирование производительности, стресс-тестирование, тестирование удобства использования, тестирование восстановления, тестирование надежности и тестирование переносимости. Это тестирование того, как система работает.

·       Тестирование структуры/архитектуры программного обеспечения (Структурное тестирование)

·       Тестирование изменений: подтверждающее и регрессионное тестирование.

[Примечание: Регрессионное тестирование может выполняться на всех уровнях тестирования и включает функциональное, нефункциональное и структурное тестирование.

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

7.      Тестирование инсталляции.

Тестирование установки (installation testing) - Проверяет работоспособность методов установки программы на всех поддерживаемых платформах.

[Искусство тестирования программ, Гленфорд Майерс, 3 издание]

8.      Тестирование документации основные принципы.

Проверка точности пользовательской документации (documentation testing) - Проверяет точность всей пользовательской документации.

Системное тестирование включает проверку точности пользовательской документации. Для этого с помощью документации проверяют способ представления описанных ранее системных тестов. Например, если запланирован некий нагрузочный тест, то следует использовать документацию для подбора конкретных вариантов. Кроме того, путем непосредственной инспекции (в духе инспекции кода) необходимо проверить точность и ясность изложения пользовательской документации. Любые процедуры, фигурирующие в документации, должны кодироваться и пропускаться через программу.

[Искусство тестирования программ, Гленфорд Майерс, 3 издание]

Читая и анализируя документацию, следует прежде всего уделить внимание её точности, полноте, ясности, простоте использования и тому, насколько она соответствует духу программного продукта.

[Тестирование программного обеспечения, Канер, Фолк, Нгуен, 2 издание]

9.    Основные принципы Usability testing.

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

Важную роль играет сбор и анализ подробных, точных данных. Реальным началом процесса сбора данных является разработка детальных пользовательских инструкций и списка задач. Заканчивается же этот процесс сведением в воедино результатов наблюдений, сделанных пользователями, или ответов пользователей на анкеты после проведения тестов.

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

[Искусство тестирования программ, Гленфорд Майерс, 3 издание]

10.   Артефакты тестирования.

Основными понятиями RUP являются артефакт (artifact) и прецедент (precedent). Артефакты — это некоторые продукты проекта, порождаемые или используемые в нем при работе над окончательным продуктом. Прецеденты — это последовательности действий, выполняемых системой для получения наблюдаемого результата.

(Автор: Сергей Трофимов. Ответ взят отсюда.)

2 вариант ответа на вопрос: 

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

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

Набор тест кейсов и тестов (Test Case & Test suite) - это последовательность действий, по которой можно проверить соответствует ли тестируемая функция установленным требованиям.

Дефекты / Баг Репорты (Bug Reports / Defects) - это документы, описывающие ситуацию или последовательность действий приведшую к некорректной работе объекта тестирования, с указанием причин и ожидаемого результата.

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

Интересный факт: На Сайт «Про Тестинг» ссылается и "Учебно-методический комплекс по дисциплине «Тестирование программного обеспечения»" для студентов специальности «ПРИКЛАДНАЯ ИНФОРМАТИКА (В УПРАВЛЕНИИ)» - ИНСТИТУТ УПРАВЛЕНИЯ, БИЗНЕСА И ПРАВА.

11. Тест план и check-list.

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

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

Чек-лист - это документ, описывающий что должно быть протестировано. При этом чек-лист может быть абсолютно разного уровня детализации. На сколько детальным будет чек-лист зависит от требований к отчётности, уровня знания продукта сотрудниками и сложности продукта.

Чек-лист нужен для 

·     Не забыть требуемые тесты

·     Для деления задач по уровню квалификации

·     Для сохранения отчётности и результатов тестирования

Что должно быть в Чек-Листе:

·     Список проверок (с требуемой степенью детализации)

·     Статус проверок:

сборка, на которой проводилось тестирование 

тестовое окружение (если применимо) 

тестировщик

·     Результат проверки

[Тестопедия]

12.    Tracebility matrix, а нарисуйте

Матрица соответствия требований - это двумерная таблица, содержащая соответствие функциональных требований (functional requirements) продукта и подготовленных тестовых сценариев (test cases). В заголовках колонок таблицы расположены требования, а в заголовках строк - тестовые сценарии. На пересечении - отметка, означающая, что требование текущей колонки покрыто тестовым сценарием текущей строки.
Матрица соответствия требований используется QA-инженерами для валидации покрытия продукта тестами. МСТ является неотъемлемой частью тест-плана.
Sample%20Traceability%20Matrix_thumb%5B5
[WIKI] - о Traceability matrix (на английском).
13.    Основные поля test case.
Тестовый сценарий (test case) - Набор входных значений, предусловий выполнения, ожидаемых результатов и постусловий выполнения, разработанный для определенной цели или тестового условия, таких как выполнения определенного пути программы или же для проверки соответствия определенному требованию. 
[IEEE 610 - Стандартный глоссарий терминов, используемых в тестировании программного обеспечения (Версия 2.2)]
Основные поля тестового сценария: Набор входных значений, предусловий выполнения, ожидаемых результатов и постусловий выполнения.
14.    Жизненный цикл бага

Блок-схема, показывающая основные статусы и возможные переходы от статуса к статусу в процессе его существования:
bug-lifecycle_ru.png

Описание данной схемы.
Допустим вы нашли баг и зарегистрировали его в баг трекинг системе. Согласно нашей блок-схеме он получит статус “Новый”. Тестировщик, ответственный за валидацию новых баг репортов, или координатор проекта (в зависимости от распределения ролей в вашей команде) может перевести его в один из следующих статусов:
·     “Отклонен”, если данный баг невалидный или повторный, или же его просто не смогли воспроизвести
·     “Отсрочен”, если данный баг не нужно исправлять в данной итерации
·     “Открыт”, если исправление бага необходимо
Рассмотрим теперь по порядку каждый из вариантов.

1.    Отклонен. В этом случае вы можете либо поспорить о судьбе вашего багрепорта, изменив статус на “Переоткрыт” либо закрыть его - статус “Закрыт”

2.    Отсрочен. Баг репорт в статусе “Отсрочен” можно перевести в статус “Открыт”, когда потребуется исправление либо в статус “Закрыт”, если уже не потребуется.

3.    Открыт. Именно в таком состоянии разработчик получает баг репорт для исправления. Он может отклонить (дальнейшие действия смотрите в пункте 1) или исправить баг. Баг репорт в статусе “Исправлен” переводится на тестировщика для проверки. В случае если проблема все еще воспроизводится, выставляется статус “Переоткрыт” и баг репорт направляется назад на доработку к разработчику. Если же исправление было успешным, то баг репорт переводится в статус “Закрыт”.

* * *
Хотим отметить, что данная схема сильно упрощена. Для большей наглядности и, возможно, удобства работы на проекте, вы можете добавить дополнительные статусы и переходы, тем более, что современные баг трекинговые системы позволяют это делать. Правда имейте ввиду, что излишне запутанные схемы переходов и лишние статусы могут значительно усложнить жизнь.

Примечание 1: в некоторых системах баг трекинга созданный баг репорт сразу получает статус “Открыт” без дополнительной валидации
Примечание 2: многие баг трекинговые системы позволяют переоткрывать закрытые баги, однако лично я против такой практики, поэтому и не описывал подобный переход в выше представленном жизненном цикле
Примечание 3: Рассмотренный выше жизненный цикл основан на том, что в команде есть кто-то, ответственный за назначение баг репортов. В случае, если такой роли на проекте нет, то баги назначаются разработчиками самостоятельно, и тогда во избежании путанницы, есть смысл ввести еще один промежуточный статус “В разработке” (In progress), показывающий, что данный баг репорт уже назначен и находится на стадии исправления.

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

15.    Bug report, Основные поля bug report.

Отчет о помехе (bug report): См. отчет о дефекте.
Отчет о дефекте (defect report): Документ, содержащий отчет о любом недостатке в компоненте или системе, который может привести компонент или систему к невозможности выполнить требуемую функцию.
[IEEE 829 - Стандартный глоссарий терминов, используемых в тестировании программного обеспечения (Версия 2.2)]
Разные системы менеджмента дефектами, предлагают нам разные поля для заполнения и разные структуры описания дефектов. Нижеприведенная таблица - это попытка показать то, что на основании полученного нами опыта, мы рекомендуем вам использовать в виде шаблона баг репорта.
Шапка
Короткое описание (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
25.    Какая система разработки используется на проекте сейчас.
Итеративая разработка. :smile:  Какая система разработки используется у вас - вам лучше знать.
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.) > книги по тестированию (Искусство тестирования программ, Тестирование программного обеспечения, Тестирование Дот Ком) > ссылки (в случае ссылки указан источник).


  • 4