Зашёл я тут как-то случайно на сайт zazzle.com, и пока я там бродил, меня постоянно (на каждой странице!) сопровождало вот такое сообщение (проявляется только в браузере FireFox):



При этом всё на самом деле всё работало (во всяком случае не смог найти чего-нибудь по настоящему unusable). Но этот неизбывный пессимизм программы, с которым она меня предупреждала, что всё плохо и может стать ещё хуже… С этим я не смог справиться… Ведь если нажать refresh — это сообщение, как нетрудно догадаться, появлялось снова...

Мораль: если в программе ещё не случилось ничего критичного, не стоит беспокоить пользователя заранее, у него и своих проблем хватает.

Продолжу рассуждения о том, какие решения мы формулируем в отчётах о тестировании, какие предположения лежат в их основе, и как убедить читателя отчёта в том, что мы приняли правильные решения (если, конечно, мы сами в этом уверены :)).

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

Вот что написано в отчёте:

• «Мы протестировали продукт на операционной системе Windows XP SP2»

А вот то, что там не написано:
( Читать дальше )

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

Осенью я покупал новый ноутбук, и в это время действовала программа бесплатного обмена Windows Vista на Windows 7. Я конечно же пошёл апгрейдиться, а когда я указал, куда должен быть доставлен диск с новой операционкой, я увидел вот это:



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

Недавно послушал подкаст Джеймса Баха и Джона Баха "Testers say the darndest things", в котором они рассуждали о том, как научить тестировщиков точно, технично и правдиво объяснять, что они делают и чего они сделать не могут.

Они достаточно долго говорили о том, как следует реагировать на слова тестировщика, утверждающего, что он занимается «обеспечением качества», и как научить тестировщика, тяготеющего к таким заявлениям общего характера, объяснять, что конкретно он делает.

Но лично мне показалась более интересной мысль, которая вскользь прозвучала ближе к концу подкаста – о предположениях и основанных на них решениях. Я не буду приводить полную расшифровку беседы Джеймса и Джона, сделаю собственный укороченный пересказ. ( Читать дальше )

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

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



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

Мораль для тестировщиков.

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

[Утащено с Хабра]

Разработчики Google Chrome решили последовать примеру Mozilla и запустили экспериментальную программу поощрения исследователей уязвимостей. Они считают, что чем больше людей ищет критические ошибки в браузере, тем легче сделать его ещё более безопасным, и с ними сложно не согласиться.

Гарантированная награда за сотрудничество составляет 500$, за серьёзные же уязвимости обещается вознаграждение в 1337$. Рассматриваться будут абсолютно все сообщения, касающиеся Google Chrome, Chromium и плагинов, которые поставляются вместе с официальной сборкой. Ошибки в «инородных» расширениях и плагинах команду не волнуют. Баги принимаются не только в Stable-релизах, но и в Beta-/Dev-версиях браузера.

Сообщения об ошибках следует отправлять в Chromium Bug Tracker

Issues (bug tracker)
Chromium blog

Коллеги, благодарю всех, кто принимал участие в коллективном переводе серии заметок Джеймса Виттейкера о будущем тестирования — Феликс, Алекс, Андрей, Роман — спасибо!

После объединения всей серии воедино и некотрой редакторской правки я опубликовал статью в библиотеке портала.

Теперь нашего перевода ждут новые интересные статьи :)

Я хочу развить высказанную Алексом Сергеевым тему «осмысленности» заметок с описанием багов.

Как я писал в самой первой заметке, посвящённой созданию Панбагона, я не хотел сделать ни публичный баг-трекер, ни доску позора. Мне хотелось создать некий инкубатор, где из мусора могли бы формироваться идеи, которые могли бы оказаться полезны для поиска багов, аналогичным описанным в Панбагоне. Поэтому я призывал не только описывать сам баг, но и излагать мысли, которые возникли у вас по этому поводу. Может быть я слишком опрометчиво называл это дополнение словом «мораль для тестировщиков», получилось, что я призываю писать заметки с поучениями. Но это не так.

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

Сверну немного в сторону с линейки багов в сообщениях об ошибках, сегодня будет баг в обычном диалоговом окне. Утащил с хабра.

А вот мораль:

По рзелульттам илссеовдний одонго анлигйсгоко унвиертисета не иеемт занчеиня в кокам пряокде рсапожолены бкувы в солве. Галвоне, чотбы превая и псолденяя бкувы блыи на мсете.Отсалньые бкувы мгоут селдовать в плоонм бсепордяке, все рвано тескт чтаиистя без плорбем Пирчионий эгото ялвятсея то, что мы не чиатем кдаужю бкуву по отдльнотси, а все солво цликеом.

UPDATE:

После обсуждения в комментариях я решил расшифровать мораль. Видимо я действительно слишком загадочно выразил свою мысль :)

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

Помните диалог Аркадия Райкина про пошив костюма? «Кто шил костюм?» — «Мы» — «Кто конкретно?» — «Я пуговицы пришивал.  К пуговицам претензии есть?» — «Нет. Пришиты — не оторвёшь. Я спрашиваю, кто костюм шил?» С пуговицами всё в порядке. А с костюмом в целом проблемы. Но понять это, рассматривая отдельно пуговицы, невозможно.

Так и здесь — каждая кнопка в отдельности называется правильно. Но если посмотреть на форму целиком — сразу обнаруживается проблема, связанная с тем, что в одном контексте используется две кнопки с похожими именами.

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

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

Продолжим тему загадочных сообщений об ошибках.

Сижу я как-то раз, работаю, и вдруг из области уведомлений (которая system tray) выползает вот такое сообщение об ошибке:



Что случилось? Где? Если бы я не знал, что Fine Objects используются в Abbyy Lingvo — ни за что бы не догадался (я уже раньше встречался с похожими сообщениями об ошибках в этой программе в другом контексте, поэтому и запомнил эти Прекрасные Объекты).

Мораль для тестировщиков

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