Home

Автор: Майкл Болтон (Michael Bolton)
Оригинал статьи
Перевод: Ольга Алифанова

Почти десять лет назад я написал серию статей об оценке проекта и черных лебедях.

И почти что спустя десять лет Крис НеДжейм сообщил о своем наблюдении об абзаце ближе к концу четвертой части:

Как часто говорил Джерри (Вайнберг), множество компаний становятся жертвами неужач, но в основном всему виной не неудачи, а то, как они реагируют на неудачи.

Заметили проблему? Крис заметил. Он вежливо сообщил – "возможно, что в части 4 опечатка: "неужач"?" После чего я исправил баг.

Какие уроки можно из этого извлечь?

• Баги могут жить и здравствовать, а автор их не замечает. Как и каждый раз, когда я пишу статью, я вычитывал и эту, когда писал ее (не поверите, как долго я пишу статьи). Я читал и перечитывал ее; я нашел кучу ошибок и исправил их. И я все равно не заметил ошибку с "неужачами". Все, все склонны не замечать проблемы в своей собственной работе до какой-то степени. Когда мы долго смотрим на что-то, наша способность замечать определенные баги снижается.
• Баги могут существовать, а пользователь их не замечает. Люди чинят проблемы в коммуникации, зачастую не прикладывая к этому сознательных усилий. Когда глаза некоторых людей падают на строку текста "становятся жертвами не_ач", то часть мозга, отвечающая за извлечение смысла, может починить проблему, и вы ее не осознаете. Другие люди могут на мгновение выпасть из потока чтения. Они поймут "неужачи", прочитав следующие два эпизода с "неудачами", и продолжат читать.
• Свежие глаза находят проблемы. Это одна из самых четких и запоминающихся строк из книги Lessons Learned in Software Testing. Крис читал статью впервые. У него был незамыленный взгляд и критическая дистанция от авторской перспективы – ему было проще, чем мне, заметить проблему.
• В тестировании помогает смотреть на вещи в разное время. В течение нескольких минут строка "одна из самых четких" выглядела как "оно из самых четких". Обычно я пишу статью, одновременно форматируя ее, и тэги маркированного списка влияют на мое восприятие, поэтому проблема какое-то время прожила.
• В тестировании помогает смотреть на вещи разными способами. Составляя эту статью, я концентрировался, как всегда, на словах текста. Я не особенно задумывался о презентации, в лучшем случае я ее воображал. Переключившись в режим предпросмотра, я понял, что полужирная фраза в начале каждого урока поможет им визуально выделиться. Это было неочевидным, когда я писал и форматировал текст. Одно из противоядий – взглянуть на статью в режиме предварительного просмотра, в нем такие ошибки заметнее.
• Опыт разработчика сильно отличается от опыта пользователя. Когда я что-то пишу, мои идеи о том, как это будет читаться, воображаемы и расплывчаты. Ничто не заменит работы с продуктом и взаимодействия с ним так, как это делали бы пользователи. Вот почему тестирование через опыт – это так важно (пожалуйста, не называйте это ручным тестированием).
• Баги могут жить долго-долго, и о них никто не сообщит. Крис не одинок – как-то раз я нашел похожую проблему в книге Джерри Вайнберга. Когда я сообщил ему об этом, он ответил, что эта проблема сидит в книге уже лет тридцать.
• Идея, что "о багах сообщат пользователи" – это чушь. Люди, отмахивающиеся от ценности тестирования или тестировщиков, часто используют этот аргумент. Множество пользователей не заметят баг. Множество пользователей заметят его, и не сообщат об этом. Множество пользователей заметят его, не сообщат о нем, и просто не будут использовать (или покупать) ваш продукт, и вы ничего от них не услышите. Некоторые пользователи заметят его и сообщат о нем, но иногда ваша изрядно занятая служба поддержки не сообщит об этом вам. Обратное, конечно, возможно, но я почти уверен, что Крис – не первый, кто заметил проблему. Но он был первым, кто потрудился сообщить о ней!
• Неважный для ваших пользователей баг может быть важен для вас, и наоборот. Мои читатели не замечали проблему, или она их недостаточно тревожила, чтобы сообщать о ней – возможно, они думали, что это неважно. Я прилагаю много сил, чтобы статьи не выглядели неряшливо, поэтому это важно для меня.
• Отчет о баге занимает время и силы. Следовательно, хорошая идея – устранить все препятствия для отчетности о багах как для пользователей, так и для тестировщиков.
• Инструменты проверок могут помочь найти проверяемые проблемы. Проверка орфографии может помочь найти ошибки. Проверка грамматики может помочь с грамматическими ошибками (хотя, по моему опыту, большая часть из этих инструментов ни о чем). Встроенная в браузер проверка орфографии пометила несколько опечаток, и я заметил и исправил их, пока писал эту статью. Ура.
• Инструменты проверок могут быть ненадежными. Пока я писал, я заметил, что после того, как WordPress обновляет редактируемую страницу, встроенная в браузер проверка орфографии не отмечает все ошибки в окне редактирования текста. Она отмечает ошибки только в том параграфе, где находится курсор. Из-за этого я чуть не упустил пачку ошибок. В то же самое время она подчеркивает слово "проверяемые" в предыдущем абзаце, хотя это именно то слово, которое мне нужно, даже если оно не включено в словарь браузера. И суть тут в том, что…
• Чтобы находить проблемы, машины полезны, но ничто не заменит человеческой наблюдательности и мнения. Инструменты не понимают наших намерений. В случае с "неужачами" (в оригинале back luck – прим. переводчика) все было в порядке и с орфографией и с синтаксисом. Проблема была в значении предложения, в его семантике. В "проверяемом" случае я использую неологизм, который люди отлично интерпретируют. Проверка орфографии не предупредит меня о пропущенном слове, и ни один инструмент не подтвердит, что статья, которую я пишу – это та статья, которую я хочу написать.
• Критики очень важны. Некоторые люди (вроде меня или Криса) имеют способность и предрасположенность к обнаружению проблем в чужой работе. У нас мышление критиков, хоть мы и можем упускать некоторые проблемы в своей собственной работе. Это очень хороший склад ума для тестировщика. Но…
• Быть критиком социально опасно. На длинной дистанции знать о проблемах полезно, но немногие любят, когда их тыкают в проблемы носом. Тестировщикам стоит об этом не забывать. Поэтому…
• Хорошие тестировщики управляют социальными рисками. Хоть он и сказал "возможно, там опечатка", я убежден, что Крис был уверен, что нашел баг, и что я с этим соглашусь. Однако, выразившись "возможно", он передал мне принятие решения, баг это или не баг. Это важный ход для тестировщика. Всегда полезно признавать, что авторы (программисты, дизайнеры, менеджеры) решают, получился ли у них тот продукт, который они хотели, и что они ответственны за качество работы. Это может помочь смягчить удар от столкновения с очередной чертовой проблемой.
• Мы можем многому научиться на мелкой проблеме. Вот случай, когда проблема в том, что вместо одной буквы (bad luck) букв стало две (back luck), и из этих двух одна неверна. Для статьи в блоге это не так страшно, но в ПО два байта могут сделать из работающего продукта катастрофу. Эти проблемы могут годами оставаться невидимыми, пока в один прекрасный день не вылезут на свет. И хоть это и относительно тривиальная проблема, смотрите, сколько мы можем из нее извлечь, если захотим! И смотрите, как размышление о проблеме ведет к еще более поучительному опыту!

Спасибо, Крис, за сообщение о баге, а также за возможность извлечь эти уроки.

Какие уроки бы вы добавили?

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