Критерии выхода, завершения тестирования (Exit criteria). Когда остановиться тестировать?
Критерии завершения тестирования это один из часто задаваемых вопросов на собеседованиях на должность тестровщика ПО. Давайте разберем какие же основные факторы влияют на принятие решения о завершении тестирования тестировщиком.
Часто новички в тестировании отвечают на данный вопрос — буду тестировать пока не найду все баги :)
А возможно ли это? Нет конечно, никто не может гарантировать отсутствие багов, даже если это приложение было протестировано несколькими опытными тестировщиками. Исчерпывающие тестирование невозможно и об этом гласит один из принципов тестирования
Следует выделить 3 основных критерия для остановки, завершения тестирования:
1) Время — В ходе тестирования могут находиться баги с разным приоритетом серьезности, попадаются баги блокеры, которые блокируют дальнейшее прохождение по тест кейсам, время на исправление и перепроверку багов может затянуться. Так как продукт или новую фитчу обещали к определенной дате то проджект менеджер вместе с тим лидом или тестировщиком принимает решение какие баги все таки стоить исправить, а какие можно отложить до следующего релиза в порядке приоритета и серьезности багов. Таким образом тестирование завершается по истечении времени.
2) Бюджет — очень популярно на биржах фриланса, когда оплачиваются найденные баги в зависимости от количества и серьезности или оплачивается по количеству пройденных тест кейсов, также выделяется бюджет на написание самих тесткейсов. И когда бюджет опустошен, то все работы по тестированию прекращаються. Как и на фриланс бирже заказчик иногда просто оплачивает время работы аутсорсного тестировщика и иногда не вписываясь в бюджет, просматривает написанные тест кейсы и какие-то выкидывает в силу не влезания в бюджет.
3) Все тест кейсы пройдены, найденные баги исправлены и перепроверены — Для того чтобы протестировать приложение, тестировщик для начала должен ознакомиться с требованиями, функциональными спецификациями к приложению, если они конечно есть, или узнать со слов заказчика какое поведение должно быть при разных сценариях использования приложения или фитчи. Затем заняться составлением тестовой документации — написанием тест кейсов, написать тест план если нужно, покрывая весь функционал и требования к приложению. Также обсудить и решить в команде или самостоятельно не требуется ли проводить нефункциональное тестирование, такое как нагрузочное тестирование (Performance and Load Testing), тестирование удобства пользовавия (Usability Testing) и т.д. Так как у каждого приложения есть «узкие места», на которые следует обратить внимание при тестировании. Далее начать выполнять, проходить тест кейсы и в момент, когда все тест кейсы пройдены и найденные баги исправлены и перепроверены, можно завершать тестирование.
Часто новички в тестировании отвечают на данный вопрос — буду тестировать пока не найду все баги :)
А возможно ли это? Нет конечно, никто не может гарантировать отсутствие багов, даже если это приложение было протестировано несколькими опытными тестировщиками. Исчерпывающие тестирование невозможно и об этом гласит один из принципов тестирования
Следует выделить 3 основных критерия для остановки, завершения тестирования:
- Время
- Бюджет
- Все тест кейсы пройдены, найденные баги исправлены и перепроверены
1) Время — В ходе тестирования могут находиться баги с разным приоритетом серьезности, попадаются баги блокеры, которые блокируют дальнейшее прохождение по тест кейсам, время на исправление и перепроверку багов может затянуться. Так как продукт или новую фитчу обещали к определенной дате то проджект менеджер вместе с тим лидом или тестировщиком принимает решение какие баги все таки стоить исправить, а какие можно отложить до следующего релиза в порядке приоритета и серьезности багов. Таким образом тестирование завершается по истечении времени.
2) Бюджет — очень популярно на биржах фриланса, когда оплачиваются найденные баги в зависимости от количества и серьезности или оплачивается по количеству пройденных тест кейсов, также выделяется бюджет на написание самих тесткейсов. И когда бюджет опустошен, то все работы по тестированию прекращаються. Как и на фриланс бирже заказчик иногда просто оплачивает время работы аутсорсного тестировщика и иногда не вписываясь в бюджет, просматривает написанные тест кейсы и какие-то выкидывает в силу не влезания в бюджет.
3) Все тест кейсы пройдены, найденные баги исправлены и перепроверены — Для того чтобы протестировать приложение, тестировщик для начала должен ознакомиться с требованиями, функциональными спецификациями к приложению, если они конечно есть, или узнать со слов заказчика какое поведение должно быть при разных сценариях использования приложения или фитчи. Затем заняться составлением тестовой документации — написанием тест кейсов, написать тест план если нужно, покрывая весь функционал и требования к приложению. Также обсудить и решить в команде или самостоятельно не требуется ли проводить нефункциональное тестирование, такое как нагрузочное тестирование (Performance and Load Testing), тестирование удобства пользовавия (Usability Testing) и т.д. Так как у каждого приложения есть «узкие места», на которые следует обратить внимание при тестировании. Далее начать выполнять, проходить тест кейсы и в момент, когда все тест кейсы пройдены и найденные баги исправлены и перепроверены, можно завершать тестирование.
2 комментария
На этапе Test Planing? И кто их утверждает?