Ковыляющий по прямой дороге
опередит бегущего, который
сбился с пути

Фрэнсис Бэкон

Сегодня речь пойдет о багхантинге — поиске ошибок в ПО как методе тестирования.

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

Статья будет полезна самим тестировщикам. Вы узнаете о стратегии багхантинга, плюсах и минусах такого подхода. А также причины, по которым работодатель предлагает подобный вариант организации тестирования.

Багхантинг глазами работодателя

Представим на мгновение, что вы хотите нанять тестировщика на подряд. Когда речь идет о сдельной работе, предметом сделки является услуга. Бухгалтеры вас заставят, чтобы она была измеряема и подробно задокументирована. Так они прикрывают себя на случаи проверки. Да и вообще неплохо было бы понимать: за что мы отдаем деньги.  У нас остается несколько вариантов:

1. Регулярный оклад

Это как минимум противозаконно. Если вы регулярно платите по договору подряда одну и ту же сумму одному и тому же лицу, вы обязаны заключить с ним трудовой договор (привет ЕСН и прочие сборы).

1. Сдельная почасовая оплата

Такой договор пройдет юристов. Но как быть уверенным, что человек отработал заявленное время?

2.  Оплата за тест кейсы

Это что вообще такое? Какие-то кейсы… может у нас будет миллион бездумных тест кейсов? Зачем они?

3. Оплата за количество найденных ошибок

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

Из всех предложенных вариантов, объективно самый удобный – оплата за найденные ошибки. Но насколько такой вариант удобен другой стороне – тестировщику?

Багхантинг глазами тестировщика

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

Но у нас багхантинг, извините. Нам не до use cases. Наша задача – выявить самое «вкусное», т.е. «слабое» место в приложении. Нам не важно, что этим модулем пользуется 0,01% клиентов. Мы охотники за багами.

Багхантинг глазами менеджера

Теперь встанем на место менджера. Перед вами график найденных багов инженера Петрова.

 

О чем можно сказать, глядя на график? Единственное наиболее верное заключение: в августе Петров ходил в отпуск. Количество ошибок сперва росло, но с течением года наблюдается отрицательный тренд. Наблюдения показывают, что в долгосрочных проектах багхантинг превращается в формальность, мотивация сотрудников стабильно падает.  Зато в краткосрочных проектах, либо при высокой текучке исполнителей багхантинг оправдывает себя.

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

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

Решая все эти проблемы, вам будет не до клиента и стратегического развития.

Что получает конечный пользователь

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

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

Как эффективно использовать багхантинг

Рассмотрим некоторый аналог facebook и его модули с точки зрения важности для пользователя и подверженности к ошибкам.

	Авторизация	Мои аудиозаписи	Мои видеозаписи	Мои приложения	О сайте
Важность	20	12	12	11	1
Бажность	1	5	6	9	15

Модуль авторизации получает 20 баллов за важность. Если он не будет работать, мы не сможем воспользоваться остальными функциями сервиса. Вспомните, как давно вы заходили в «О сайте»? Вероятно, вы только что узнали о подобной возможности – модуль «О сайте» получает 1 балл. Остальные модули получают примерно равно число очков.

Ошибки распределяется по другой логике. Программисты тоже догадываются о важности модуля авторизации и отлаживают его в очень жесткой манере – всего лишь один балл за ошибки. Но до модуля «О сайте» никак не доходят руки. Там кишмя кишат баги разной модификации – 15 баллов – это максимальная забагованность. Остальные модули в рабочем порядке.

Разные пользователи видят приложение по-разному. Конечный клиент видит его так:

	Авторизация	Мои аудиозаписи	Мои видеозаписи	Мои приложения	О программе
Важность	20	12	12	11	1

 

Охотник за багами видит так:

	Авторизация	Мои аудиозаписи	Мои видеозаписи	Мои программы	О программе
Бажность	1	5	6	9	15

 

Менеджер проекта так:

	Авторизация	Мои аудиозаписи	Мои видеозаписи	Мои приложения	О программе
Важность +бажность	21	17	18	20	16

 

В такой ситуации у каждого свой приоритет, и при использовании багхантинга конфликты неизбежны.

Когда полезен багхантинг?

Если в вашем приложении важные участки являются максимально подверженным ошибкам (важность~бажность), можно смело использовать багхантинг. Обычно такие ситуации бывают на начальных этапах разработки прототипов и приложений. С обратной стороны багхантинг полезен на поздний стадиях развития приложения — когда число успешно пройденных сценариев приближается к 100%.

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

P.S. Вы можете почувствовать себя багхантером прямо сейчас. В статье разбросано несколько ошибок. Первые нашедшие получат призы! Пишите на krukovskiy.ignat@gmail.com. Удачи в поисках!