Будем честными: пропущенный баг – это всегда повод для огорчения. Скажем больше: попадание бага в финальную версию продукта – один из самых страшных снов тестировщика, особенно начинающего.
Страх пропустить дефект подпитывается мифом о том, что тестировщики обязаны найти все баги. И вот вы стараетесь-стараетесь, тестируете-тестируете, а потом пользователь заявляет о критической ошибке в приложении. Как такое могло случиться?
Не торопитесь посыпать голову пеплом. Лучше попытайтесь найти причину и исключить ее.
Наиболее частые причины пропуска дефектов в ПО
#1. «Эффект пестицида» в тестировании: с течением времени написанные тесты теряют эффективность.
Около 20 лет назад американский инженер и автор множества книг по тестированию и разработке ПО Борис Бейцер сформулировал правило, которое позже вошло в историю под названием «Эффект пестицида», которое гласит, что под «эффект пестицида» понимается повторное применение одних и тех же методов со временем перестает быть эффективным, поскольку выжившие вредители приобретают иммунитет.
Говоря языком тестировщиков, если написанные тесты («пестициды») запускаются сотни раз, то они становятся менее эффективными. В результате новые виды дефекты (вредители), которые появились в поздних версиях системы, не попадают под покрытие данными тестами и с легкостью проникают в релизную версию ПО.
Решение
Создавая набор тест-кейсов, не рассчитывайте на то, что с этим набором вы сможете успешно протестировать все версии доверенного вам ПО. Это заблуждение. Для того чтобы успешно обнаруживать баги в каждой последующей версии продукта, необходимо практиковать исследовательское тестирование, следить за обновлениями ПО и регулярно обновляйте набор тестов (ручных и автоматизированных).
#2. Не хватило времени выполнить тесты.
Случается, что тестировщики становятся заложниками форс-мажорных обстоятельств: в самую последнюю минуту в систему вносятся изменения, поставка сборки задерживается и блокирующий дефект не устраняется разработчиком. Несмотря на то, что повлиять на все перечисленные обстоятельства тестировщики не могут, они являются последним звеном в цепочке разработки ПО. И именно они чаще остальных будут отвечать за срыв релиза.
Чтобы предотвратить срыв сроков, тестировщики вынуждены выбирать: работать сверхурочно или пропустить выполнение некоторых тестов. И сложно сказать, что лучше. Ведь даже если тестировщик найдет в себе силы поработать в выходные, он все равно будет спешить. А в спешке, как известно, люди теряют бдительность, внимание рассеивается. Поэтому шансы просмотреть дефекты у тестировщика, который торопится, очень высоки.
Решение
Если вы видите, что есть вероятность не успеть завершить тестирование в установленный срок, обсудите это с вашим руководителем. Наверняка, он инициирует провести анализ рисков и проранжировать функциональность продукта и тесты в зависимости от их важности для заказчика и пользователей. Обсудите, какие тесты вы не успеете выполнить в этой итерации, и то, какие риски с этим сопряжены.
Главное, не пытайтесь скрыть от команды или заказчика факт нехватки времени. Не стоит надеяться, что пропуск дефектов останется незамеченным.
#3. Пропуск наиболее очевидных дефектов.
Вы даже представить себе не можете, насколько часто начинающие тестировщики не замечают дефекты, которые находятся на самом, казалось бы, видном месте. Почему так происходит? Чем чаще специалист открывает один и тот же раздел в приложении, тем увереннее он становится в том, что в этом месте все точно работает правильно.
Существует и другая причина: не все тестировщики справляются с многозадачностью. Иногда в процессе написания тест-кейсов тестировщик теряет бдительность и не замечает того, что в приложении не все работает, как задумано.
Решение
Учитесь работать в режиме многозадачности, развивайте внимание к деталям, чаще становитесь на место пользователя, который видит приложение впервые.
#4. Неполная документация.
Часто причина пропуска дефектов кроется в самом начале проекта, на этапе выяснения требований заказчика к продукту. Не всегда требования задокументированы в полном объеме. Иногда, особенно это применимо к небольшим проектам, задокументированных требований может не быть совсем, они проговариваются голосом. Впоследствии то, что не было записано, забывается, теряется, сценарии не проверяются.
Решение
Важно, чтобы все требования к финальной версии продукта были точно задокументированы. Создать хорошую документацию всегда дешевле, чем устранить дефект на поздней стадии проекта.
Прежде чем приступать к тестированию продукта убедитесь, что вам известны ожидания заказчика касательно его работы. Если требования меняются, обновляйте набор написанных тестов.
#5. Дефект был обнаружен, но не был исправлен.
Тестировщики обязаны своевременно оповещать разработчиков обо всех обнаруженных дефектах, а также готовить регулярные отчеты заказчику по текущему качеству продукта. Однако решение о том, выпускать продукт с дефектами на рынок или отложить релиз, принимает заказчик. И решение это принимается на основе многочисленных факторов, а не только исходя из наличия/отсутствия дефектов.
Именно поэтому иногда на рынок выходят продукты с минорными недоработками, которые исправляются в последующих версиях продукта.
Решение
Сообщайте разработчикам о найденных дефектах. При этом текст сообщения должен быть понятен и не содержать двусмысленностей. Обязательно обозначайте степень критичности дефекта.
При составлении отчета о тестировании для заказчика будьте объективны и наиболее полно расскажите о функциональности, производительности и безопасности тестируемой системы.
#6. Данный пункт мы намеренно оставили пустым.
Мы назвали пять наиболее частых причин, по которым инженеры по тестированию пропускают дефекты. Наверняка, этот список можно продолжать.
Ждем ваших комментариев и дополнений.
Перечень всех
услуг по тестированию представлен на страницах нашего сайта.
