Home

Автор: Эрик Хан (Erik Hun)

Оригинал статьи: https://promptest.wordpress.com/2016/07/27/ever-noticed-what-do-you-do-between-finding-and-reporting-a-bug/

Перевод: Ольга Алифанова

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

Мы проводили рефакторинг одной из частей нашего приложения. Там использовался Javascript, и присутствовала корзина интернет-магазина. Я решил проверить, как она среагирует на максимально большие числа, и нашел баг. Перемножение очень больших чисел приводило, судя по всему, к фризу всей корзины. Я нажал F12, чтобы проверить, что происходит конкретно. Виноваты оказались не большие числа как таковые. Виновно было переполнение, возникающее из-за ошибки точности в Javascript (я быстро выяснил все про эту ошибку: http://www.w3schools.com/js/tryit.asp?filename=tryjs_inaccurate2). Ага, вот в чем дело! Как еще можно вызвать эту проблему? Я попробовал ввести совершенно обычные числа, которые спровоцируют ту же самую ошибку – и фриз повторился. Призванный на помощь разработчик даже не нуждался в подробных разъяснениях.

Почему бы не сообщить о баге сразу? Потому что баг, возникающий при перемножении 999999999999.99 на 99 вызовет реакцию "Какой нормальный человек так сделает", или "Ну засунь ее в бэклог, где-нибудь в 2038 году мы разберемся" – и такая реакция может быть вполне оправданной. Но демонстрация, что баг воспроизводится и на вполне обычных числах, вроде умножения 25,89 на 3, приведет к мгновенному исправлению проблемы.

Я использую мнемонический прием, придуманный Кемом Кейнером (http://kaner.com/?page_id=11): RIMGEA, позже переделанный в RIMGEN тестировщиками. Вот в чем он заключается:

R: Replicate (воспроизведите). Найдите условия, при которых баг воспроизводится. В баг-репорте плохо смотрятся слова вроде "иногда" или "похоже на то". Вначале я убеждаюсь, что баг есть, это не галлюцинация, и корзина действительно замирает при вводе наибольших возможных чисел в поля цены и количества.

I: Isolate (локализуйте). Сократите количество шагов воспроизведения до минимума. Вам нужно точно знать, что вызывает баг. Именно так я узнал, что виноваты не большие числа, а ошибка точности Javascript. После этого продемонстрировать баг было легче легкого.

M: Maximize (максимизируйте). Продемонстрируйте, какой вред может причинить такой баг. Я обосновал свой баг тем, что люди будут сконфужены и раздражены, столкнувшись с фризом корзины.

G: Generalize (генерализуйте). Выясните, где еще и как еще этот баг может вызвать проблему. Не очень люблю понятие "частный случай" – если вы его используете, то при генерализации вы переходите от частного случая к общему.

E: Externalize (сделайте видимым). Сделайте так, чтобы о баге услышали все заинтереосванные лица. Возможно, для внутренних команд тестирования это не столь важно, хотя мои баги, бывает, умирали, когда мне не удавалось определить весь список значимых лиц, или я не смог толком их проинформировать из-за выбранного способа коммуникации.

A или N: And use Neutral tone (будьте нейтральны). Будьте беспристрастны, держите свое личное мнение (как это могли допустить???) при себе – не надо искать виноватых. Баг-репорт – это информация, лишенная эмоциональной окраски и осуждений. Ваши мысли и ожидания по поводу поведения приложения – это не самая значимая часть разработки ПО. Просто примите это как данность.

На картинках – открытки, сделанные Леви (https://twitter.com/leventebalint) в Altom (https://altom.ro/).

Оригинальная информация о RIMGEA: http://www.testingeducation.org/BBST/bugadvocacy, другая информация о применении мнемоники: https://www.google.com/search?q=rimgea

Если Вы хотите попрактиковаться в использовании техники RIMGEA, приходите на наш курс «НЛО: Найти, локализовать и оформить ошибку».

Обсудить в форуме