Отличия тестирования от багхантинга

Многие считают, что работа тестировщика заключается в поиске ошибок. Вполне логично. Но считать – это одно, а ждать, что по завершении тестирования будут выявлены все ошибки, – совсем другое. Ведь такое попросту невозможно! Хотя бы потому, что количество комбинаций действий пользователя, переменных окружения и входных данных практически бесконечно.

Учимся отличать тестирование от багхантинга

Итак, заявление о том, что тестирование призвано выявить все ошибки, является ложным. С этим определились. Хуже то, что оно порождает у тестировщиков ошибочные цели. Которые начинают сводиться к одному: чем больше будет найдено багов, тем лучше. И специалисты по тестированию превращаются в охотников за багами: они лихорадочно пытаются найти дефекты при самых невероятных условиях использования приложения с такими же данными. И не принимают во внимание тот факт, что любой пользователь в состоянии завалить приложение, если сильно постарается.

И пользователям это нужно в последнюю очередь

Ведь при обычных условиях их интересует то, что работает в приложении, нежели то, что не работает. А ведь поиск подобных ошибок отнимает время, ресурсы и серьезно отдаляет от главной цели – удостовериться в том, что приложение выполняет все функции, которые нужны пользователю. Ради функциональности пользователь пожертвует таким «качеством» (посмотрите хотя бы на количество известных ошибок у таких популярных продуктов, как ОС, браузер и офисный пакет).

Чтобы культура тестирования не пострадала

Если в компании культура тестирования находится на достаточно низком уровне, и от разработчиков или менеджеров проектов то и дело можно услышать:

«Сколько багов сегодня было найдено? Что значит, ни одного? А ведь вчера нашел 16»

– специалисты рискуют упроститься до уровня детектора сообщений об ошибке. Точнее управленец рискует, сама компания, а тестировщики просто стремились соответствовать заданной системе.

Хороший тестировщик должен понимать цели продукта, видеть его целиком, осознавать ценность всех участников процесса (заказчика, менеджера проекта, разработчика), а также грамотно расставлять приоритеты и оценивать сроки.

Наглядный пример отсутствия такого понимания: тестировщик первые 4 дня из 5 отведенных на проект репортит баги с невысоким приоритетом, касающиеся валидации полей или Gui. А в пятый день заводит в баг-трекинговой системе критикал о том, что не работает система заказов в интернет-магазине. Это неприемлемо. Тестировщик обязан в первую очередь выявить и внести критикал, касающийся самой важной функциональности, а также проинформировать всех участников проекта, чтобы дефект был своевременно исправлен и работы по тестированию продолжились.

Чем опасен багхантинг?

Прежде всего тем, что препятствует контролю основной функциональности. Потому как вероятность обнаружения ошибки в ней достаточно мала, и тестировщики теряют к ней всякий интерес. Да и в целом отсутствие понимания целей и глубоких знаний о продукте ведет к росту процента пропущенных дефектов. А ведь даже одна небольшая ошибка в самой важной функциональности будет стоить очень дорого, несмотря на внушительный список известных ошибок, найденных при самых невероятных условиях. Кстати, этот список вряд ли утешит пользователя или заказчика, если основной функционал неисправен.

Еще одно отклонение от нормы, которое обусловлено самим понятием «тестирование» – занесение в качестве дефекта его следствия, например, какой-либо интерфейсной ошибки. Тестировщик должен понимать суть ошибки, прослеживать логику, отслеживать статусы запросов в браузере и, по итогу, доносить до разработчика суть проблемы. Например, 500 ошибка при запросе к БД, судя по логу из консоли Firebug. А не только ее интерфейсное следствие – неработающий фильтр.

В идеале, тестировщик должен понимать платформу, на которой написан тестируемый продукт, указывать в баг-репорте возвращаемый сервером код ошибки, просматривать подробности с помощью Firebug, предоставлять подробную информацию и экономить таким образом массу времени разработке.

Таких проблем в современном тестинге достаточно много. Наша компания не может себе этого позволить. Чтобы помогать нашим разработчикам и командам клиента делать качественные продукты и сервисы, мы развенчиваем мифы и стереотипы о monkey job тестерах.