Шпаргалка по тестированию ПО

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

Дефект (bug) — отклонение фактического результата от ожидаемого.

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

Принципы тестирования:

Тестирование демонстрирует наличие дефектов (Testing shows presence of defects).
Исчерпывающее тестирование невозможно (Exhaustive testing is impossible).
Раннее тестирование сохраняет время и деньги (Early testing).
Скопление (кластеризация) дефектов (Defects clustering).
Парадокс пестицида (Pesticide paradox).
Тестирование зависит от контекста (Testing is context depending).
Заблуждение об отсутствии ошибок (Absence-of-errors fallacy).

Верификация и валидация - сравнение поведения продукта с документами и с ожиданиями клиента.

Этапы тестирования (STLC): общее планирование (тест-план) и анализ требований, уточнение критериев приёмки, уточнение стратегии тестирования, разработка тест-кейсов, выполнение тест-кейсов, фиксация найденных дефектов, анализ тестирования, отчетность.

Стадии разработки ПО (SDLC): идея, требования к проекту; проектирование или дизайн; разработка; тестирование продукта; внедрение, поддержка и закрытие (опционально).

Атрибуты требований:

Корректность — точное описание разрабатываемого функционала.
Проверяемость — формулировка требований таким образом, чтобы можно было выставить однозначный вердикт, выполнено все в соответствии с требованиями или нет.
Полнота — в требовании должна содержаться вся необходимая для реализации функциональности информация.
Недвусмысленность — требование должно содержать однозначные формулировки.
Непротиворечивость — требование не должно содержать внутренних противоречий и противоречий другим требованиям и документам.
Приоритетность — у каждого требования должен быть приоритет(количественная оценка степени значимости требования). Этот атрибут позволит грамотно управлять ресурсами на проекте.
Атомарность — требование нельзя разбить на отдельные части без потери деталей.
Модифицируемость — в каждое требование можно внести изменение.
Прослеживаемость — каждое требование должно иметь уникальный идентификатор, по которому на него можно сослаться.

Градация Серьезности дефекта (Severity), устанавливается тестировщиком:

Блокирующий (S1 – Blocker) - полное падение приложения, дальнейшее тестирование не возможно;
Критический (S2 – Critical) - частичная неисправность в приложении, часть приложения становится недоступная, тестировать можно обходными путями;
Значительный (S3 – Major) - не работает часть функции логики (важная логика), но приложение работоспособное, дальнейшее тестирование возможно;
Незначительный (S4 – Minor) - ошибки не влияющие на функциональность приложения, либо влияющие на функционально, но воспроизводятся на каком-то одном определенном устройстве;
Тривиальный (S5 – Trivial) - ошибки не влияющие на функциональность - дефекты GUI, опечатки в подписях элементов. Либо, плохо воспроизводимая ошибка. Не оказывает влияния на качество продукта.

Срочность (priority) - как быстро исправить дефект, устанавливается менеджером, тим-лидом, заказчиком:

P1 Высокий (High) - исправить как можно быстрее;
P2 Средний (Medium) - исправить надо, но не срочно;
P3 Низкий (Low) - не срочно, исправить, когда (если) появится время.

Основные фазы тестирования

Pre-Alpha: для ознакомления с будущими возможностями программ, функциональность не полная, баги есть;
Alpha: ранняя версия демонстрирующая полную версию продукта и готовая для полноценного тестирования (внутреннее тестирование). Часть функциональности может быть на заглушках, баги в наличии;
Beta: практически готовый продукт, который разработан в первую очередь для тестирования конечными пользователями;
Release Candidate (RC): полный функционал, продукт готов для регрессионного тестирования;
Release: финальная версия программы, готова к использованию.

Вид тестирования — это совокупность действий, направленных на тестирование заданных характеристик системы или её части.

Многообразие видов

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

Тестирование на основе классов эквивалентности (equivalence partitioning) — это техника, основанная на методе чёрного ящика, при которой мы разделяем функционал (часто диапазон возможных вводимых значений) на группы эквивалентных по своему влиянию на систему значений.
Техника анализа граничных значений (boundary value testing) — это техника проверки поведения продукта на крайних (граничных) значениях входных данных.
Попарное тестирование (pairwise testing) — это техника формирования наборов тестовых данных из полного набора входных данных в системе, которая позволяет существенно сократить количество тест-кейсов.
Тестирование на основе состояний и переходов (State-Transition Testing) — применяется для фиксирования требований и описания дизайна приложения.
Таблицы принятия решений (Decision Table Testing) — техника тестирования, основанная на методе чёрного ящика, которая применяется для систем со сложной логикой.
Доменный анализ (Domain Analysis Testing) — это техника основана на разбиении диапазона возможных значений переменной на поддиапазоны, с последующим выбором одного или нескольких значений из каждого домена для тестирования.
Сценарий использования (Use Case Testing) — Use Case описывает сценарий взаимодействия двух и более участников (как правило — пользователя и системы).

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

Вопросы, на которые отвечает тест план: Что необходимо протестировать? Как будет проводиться тестирование? Когда будет проводиться тестирование? Критерии начала тестирования. Критерии окончания тестирования.

Тест-план состоит из:

Идентификатор тест плана (Test plan identifier);
Введение (Introduction);
Объект тестирования (Test items);
Функции, которые будут протестированы (Features to be tested;)
Функции, которые не будут протестированы (Features not to be tested);
Тестовые подходы (Approach);
Критерии прохождения тестирования (Item pass/fail criteria);
Критерии приостановления и возобновления тестирования (Suspension criteria and resumption requirements);
Результаты тестирования (Test deliverables);
Задачи тестирования (Testing tasks);
Ресурсы системы (Environmental needs);
Обязанности (Responsibilities);
Роли и ответственность (Staffing and training needs);
Расписание (Schedule);
Оценка рисков (Risks and contingencies);
Согласования (Approvals).

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

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

Атрибуты: Предусловия (PreConditions); Шаги (Steps); Ожидаемый результат (Expected result).

#testing #quality_control #quality_assurance #qa_engineer