🗊Презентация Topic 3. Fundamentals of testing. Тестирование ПО

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

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

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

Требования к количеству открытых багов Требования к количеству открытых багов Наличие открытых дефектов P1, P2 и S1, S2, считается неприемлемым для проекта. Все подобные ситуации требуют срочного решения и идут под контроль к менеджерам проекта. Наличие строго ограниченного количества открытых ошибок P3 и S3, S4, S5 не является критичным для проекта и допускается в приложении. Количество же открытых ошибок зависит от размера проекта и установленных критериев качества. Все требования к открытым ошибкам оговариваются и документируются на этапе принятия решения о качестве разрабатываемого продукта.

STATUS STATUS New Approved Needs more info Working Solution Completed Failed QA Passed QA Tested Deployed Closed

Критерии начала тестирования Критерии начала тестирования готовность тестовой платформы (тестового стенда) законченность разработки требуемого функционала наличие всей необходимой документации ... Критерии окончания тестирования результаты тестирования удовлетворяют критериям качества продукта: требования к количеству открытых багов выполнены выдержка определенного периода без изменения исходного кода приложения Code Freeze (CF) выдержка определенного периода без открытия новых багов Zero Bug Bounce (ZBB) ...

Процесс написания тест-кейса (test case generation). Процесс написания тест-кейса (test case generation). Процесс исполнением тест-кейса (test case execution). Каждый тест-кейс, исполнение которого завершено, дает нам одно из двух: 1. Положительный исход (PASS), если ФР равен ОР, 2. Отрицательный исход (FAIL), если ФР не равен ОР: найден баг!

Сколько ожидаемых результатов может быть в одном тест-кейсе? Сколько ожидаемых результатов может быть в одном тест-кейсе? Плохой стиль: 1. Зависимость тест-кейсов друг от друга. 2. Нечеткая формулировка шагов. 3. Нечеткая формулировка идеи и/или ожидаемого результата.

1. По знанию внутренностей системы: 1. По знанию внутренностей системы: • черный ящик (black box testing); • серый ящик (grey box testing); • белый ящик (white box testing). 2. По объекту тестирования: • функциональное тестирование (functional testing); • тестирование интерфейса пользователя (UI testing); • тестирование локализации (localization testing); • тестирование скорости и надежности (load/stress/perfor- mance testing); • тестирование безопасности (security testing); • тестирование опыта пользователя (usability testing); • тестирование установки (Installation testing); • тестирование документации (documentation testing); • тестирование взаимодействия (interoperability Testing); • тестирование на отказ и восстановление (Failover and Recovery Testing); • конфигурационное тестирование (Configuration Testing).

3. По субъекту тестирования: 3. По субъекту тестирования: • альфа-тестировщик (alpha tester); • бета-тестировщик (beta tester). 4. По времени проведения тестирования: до передачи пользователю — альфа-тестирование (alpha-testing); тест приемки (smoke test, sanity test или confidence test); тестирование новых функциональностей (new feature testing); регрессивное тестирование (regression testing); тест сдачи (acceptance or certification test); после передачи пользователю — бета-тестирование (beta testing). 5. По критерию "позитивности" сценариев: • позитивное тестирование (positive testing); • негативное тестирование (negative testing).

6. По степени изолированности компонентов: 6. По степени изолированности компонентов: • компонентное тестирование (component testing); • интеграционное тестирование (integration testing); • системное тестирование (system). 7. По степени автоматизированности тестирования: • ручное тестирование (manual testing); • автоматизированное тестирование (automated testing); • смешанное/полуавтоматизированное тестирование (semi automated testing). 8. По степени подготовки к тестированию: • тестирование по документации (formal/documented testing); • эд хок-тестирование (ad hoc testing).