Найти в Дзене
Жизнь массовщика

Пятая часть курса по тестированию ПО. Терминалогия.

QA (aнгл. Quality assurance — обеспечение качества) — это процесс или результат формирования требуемых свойств и характеристик продукции по мере её создания.

Баг (англ. Bug — насекомое) — ошибка в ПО из-за которой программа не выдает пользователю ожидаемый конечный результат.

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

Система отслеживания ошибок (англ. bug tracking system) — программа учета и/или контроля багов:

•Atlassian JIRA

•HP ALM (HP Application Lifecycle Management)

•Bugzilla

•YouTrack

•Redmine

Приоритет багов (англ. Bug priority) — важность той или иной ошибки в ПО:

•Trivial — косметическая малозаметная проблема

•Minor — очевидная, незначительная проблема

•Major — значительная проблема

•Critical — проблема, нарушающая работу c ключевыми функциями ПО

•Blocker — проблема, нарушающая функционирование ПО

Очень часто тривиальные ошибки относятся к минорным и поэтому тривиальные не так часто используются.

Error — ошибка пользователя, то есть он пытается использовать программу иным способом.

Failure — сбой (причём не обязательно аппаратный) в работе компонента, всей программы или системы.

UX (англ. User eXperience — опыт пользователя) — ощущение, испытываемое пользователем во время использования цифрового продукта

UI (англ. User Interface — пользовательский интерфейс) — это инструмент, позволяющий осуществлять взаимодействие «пользователь — приложение».

Анализ Граничных Значений (англ. Boundary Value Analysis — BVA). Анализ граничных значений может быть применен к полям, записям, файлам, или к любого рода сущностям имеющим ограничения.

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

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

Верификация (англ. verification — подтверждение) — это процесс оценки системы или её компонентов с целью определения удовлетворяют ли результаты текущего этапа разработки условиям, сформированным в начале этого этапа.

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

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

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

Матрица соответствия требований (англ. Traceability matrix) — это двумерная таблица, содержащая соответсвие функциональных требований (functional requirements) продукта и подготовленных тестовых сценариев (test cases).

Матрица соответствий требуется в основном только самим тестировщикам. Ее мало кто требует, но ведение матрицы полезно для того, чтобы знать на сколько покрыты тестами требования, чтобы что-то не пропустить.

Предугадывание ошибки (англ. Error Guessing — EG). Это когда тест аналитик использует свои знания системы и способность к интерпретации спецификации на предмет того, чтобы «предугадать» при каких входных условиях система может выдать ошибку.

Причина / Следствие (англ. Cause/Effect — CE). Это, как правило, ввод комбинаций условий (причин), для получения ответа от системы (Следствие). Из этого состоят тест-кейсы.

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

Альфа-тестирование (англ. Alpha testing) — имитация реальной работы с системой штатными разработчиками, либо реальная работа с системой потенциальными пользователями/заказчиком на ранней стадии разработки продукта, но в некоторых случаях может применяться для законченного продукта в качестве внутреннего приёмочного тестирования.

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

Релиз-кандидат или RC (англ. Release candidate), Пре-релиз или Pre, иногда «гамма-версия» — стадия-кандидат на то, чтобы стать стабильной.

Релиз или RTM (англ. Release to manufacturing — промышленное издание) — издание продукта, готового к тиражированию.

Пост-релиз или Post-RTM (англ. post-release to manufacturing), издание продукта, у которого есть несколько отличий от RTM и помечается как самая первая стадия разработки следующего продукта.

Тест дизайн (англ. Test design) — это этап процесса тестирования ПО, на котором проектируются и создаются тестовые случаи (тест кейсы).

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

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

Тестовый случай (англ. Test Case) — это артефакт, описывающий совокупность шагов, конкретных условий и параметров, необходимых для проверки реализации тестируемой функции или её части.

Чек-лист (англ. Check list) — это документ, описывающий что должно быть протестировано. Обычно составляется на те или иные требования. И очень часто по чек-листу составляется тест план. С чек-листа начинается наша работа. Мы составляем список того, чем мы собираемся заниматься и отдаем его, обычно, менеджеру для подтверждения и далее на его основе начинаем делать тестовый план.

Буду рад Вашим комментариям и Вашей поддержке моего канала. Подписывайтесь, ставьте лайки! Всем удачи!