Критерии завершения тестирования

 
Критерии завершения тестирования - это один из часто задаваемых нам вопросов. В этой статье мы расскажем какие основные факторы влияют на принятие решения о завершении тестирования тестировщиком.

Часто новички в тестировании говорят так: "Буду тестировать пока не найду все баги" :)
А возможно ли это? Нет конечно, никто не может гарантировать отсутствие багов, даже если это приложение было протестировано несколькими опытными тестировщиками. Исчерпывающие тестирование невозможно и об этом гласит один из принципов тестирования

Следует выделить 3 основных критерия для остановки, завершения тестирования:
  • Время
  • Бюджет
  • Все тест-кейсы пройдены, найденные баги исправлены и перепроверены


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

2) Бюджет — очень популярно на биржах фриланса, когда оплачиваются найденные баги в зависимости от количества и серьезности. Либо работа оплачивается по количеству пройденных тест-кейсов, также выделяется бюджет на написание самих тест-кейсов. И когда бюджет опустошен, то все работы по тестированию прекращаются. Как и на фриланс-бирже, заказчик иногда просто оплачивает время работы аутсорсного тестировщика, и иногда не вписываясь в бюджет, просматривает написанные тест-кейсы и какие-то выкидывает в силу не влезания в бюджет.

3) Все тест-кейсы пройдены, найденные баги исправлены и перепроверены — для того, чтобы протестировать приложение, тестировщик для начала должен ознакомиться с требованиями, функциональными спецификациями к приложению, если они конечно есть, или узнать со слов заказчика, какое поведение должно быть при разных сценариях использования приложения или фичи. Затем он должен заняться составлением тестовой документации — написанием тест-кейсов, тест-плана (если нужно), покрывая весь функционал и требования к приложению. Также следует командно или самостоятельно обсудить и решить, не требуется ли проводить нефункциональное тестирование, такое как нагрузочное тестирование (Performance and Load Testing), тестирование удобства пользования (Usability Testing) и т.д., так как у каждого приложения есть «узкие места», на которые следует обратить внимание при тестировании. Далее необходимо начать выполнять, проходить тест-кейсы, и в момент, когда все тест кейсы пройдены, и найденные баги исправлены и перепроверены, можно завершать тестирование.

 

GetGear © 2019