Автор: Джеймс Бах (James Bach)
Оригинал статьи
Перевод: Ольга Алифанова

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

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

Предположим, что мы разговариваем с разработчиком: логика этого процесса примерно такова.

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

Звучит довольно мудрено, не так ли? Наберитесь терпения. Так как это одновременно решето и цепочка, назовем их как-нибудь так, чтобы объединить эти образы: трубопровод баг-репорта. Давайте посмотрим на него поближе и разберемся, что в нем может пойти не так.

Трубопровод баг-репорта

Баг…

1. Существует
2. Воспроизводим
3. Воспроизвелся
4. Видим
5. Виден
6. Осмыслен
7. Подтвержден
8. Опубликован
9. Принят
10. Значим.

Для отчета о баге он должен существовать

Для отчета о реальном баге баг должен для начала реально существовать. Под "багом" я понимаю что-то в продукте, что угрожает его ценности по мнению значимого лица. Это значит, что слово "баг" – широкий термин, включающий ошибки, отказы, поводы для раздражения, и даже возможности для улучшений.

Что это значит – сказать, что баг существует, даже если пользователи еще его не видели или никогда не увидят? Начните с первого принципа: баг – всегда взаимоотношение между продуктом, людьми и контекстом. Когда люди узнают о продукте больше, это взаимоотношение становится еще яснее, и они или счастливы пользоваться продуктом, или не удовлетворены. Теперь представьте, что все значимые люди имеют владеют превосходным знанием о продукте уровня "Бог". Теперь все плохое в продукте, насчет чего они согласны, будет "существующим багом" на этот момент. Вот о чем я говорю. Конечно, вы не можете знать наверняка, существует ли баг, пока не встретитесь с ним, но существование бага не зависит от вашего знания или вашего поля зрения – это зависит от самого продукта, значимых лиц, и контекста, в котором они существуют.

Работа тестирования заключается в исследовании состояния всего этого.

Для того, чтобы баг на кого-то повлиял, он должен быть воспроизводим.

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

Разработчики и менеджеры могут довольно нервно относиться к воспроизводимости багов. Они могут запретить вам писать баг-репорты на то, что вы не сможете воспроизвести при необходимости. Боритесь с таким положением дел! Попробуйте сказать им вот что:

Безусловно, в любой нетривиальной ситуации я буду пытаться предоставить шаги для воспроизведения, но что, если я попробую так и эдак, и все равно не найду способ воспроизвести этот баг? А что, если это окажется очень важным багом? А что, если, будь у вас возможность знать о том случае, когда я его поймал – вы бы поняли, в чем проблема, вообще не воспроизводя ее?

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

Что, если вместо этого мы договоримся, что воспроизводимость бага желательна, но не обязательна? Я предлагаю сделать нашей политикой подход, при котором тот, кто добросовестно сообщил о какой-либо проблеме, будет услышан, а не атакован. Отчитывающиеся о багах должны прилагать разумные усилия, чтобы отчет был ясным, точным, уважительным, и достаточно детальным, чтобы приносить пользу разработчикам и менеджерам. Нашей политикой должно стать приветствие любых подобных репортов, неважно, воспроизводимы они или нет (и баги ли это вообще). Лучше время от времени получать плохие репорты, чем создать враждебную атмосферу, которая может отторгнуть даже один хороший репорт.

(Я осознаю, что это слишком долгая речь для разговора у кофемашины, но помните, что такие разговоры в основном ведутся с теми, кому на вас наплевать).

Может ли баг существовать, но быть невоспроизводимым?

Да. Изъян, имеющийся в коде, может быть недостижим. Это может иметь значение в том случае, когда дальнейшая разработка этого продукта активирует этот код. Единственный способ найти баги в недостижимом коде – это статический анализ (то есть методы, не основанные на запуске кода).

Может ли "баг" воспроизводиться, но не существовать?

Да. Вы можете посчитать определенное поведение багом, а позже осознать, что оно все же было корректным.

Чтобы баг попал в ваше поле зрения в ходе тестирования, он должен быть вызван.

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

Может ли баг быть легко вызываемым, но не обнаружиться в ходе тестирования?

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

Может "баг" быть вызван, но быть невоспроизводимым?

Да. Вы можете вызвать баг, используя тип ввода или системную конфигурацию, которая никогда не будет доступна при реальном использовании. Или же вы можете тестировать не ту версию продукта.

Чтобы баг попал в ваше поле зрения в ходе тестирования, он должен быть видимым.

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

Можно ли вызвать баг, который невидим?

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

Может ли "баг" быть видимым, но не вызываться?

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

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

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

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

Может ли баг быть видимым, но не быть увиденным в ходе тестирования?

Запросто! Одна из причин снижения шансов встретить баг – это вера, что в продукте, возможно, багов нет. Тестировщику очень важно убедить себя, что баги с большим шансом найдутся.

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

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

Может ли "баг" быть увиденным, но не видимым?

Возможно. По причинам, указанным выше: ваши глаза и память ненадежны. К тому же то самое ментальное состояние, которое необходимо нам для ловли багов – вера в то, что они есть – может заставить наш разум увидеть что-то, чего там нет. Как арахнофоб, я с таким сталкивался – краем глаза я видел пауков, которые оказывались пятнами на стене или комком шерсти на полу. Однако мой мозг решил, что я лучше буду чересчур чувствителен к паукам, чем недостаточно, и я с ним согласен.

Чтобы создать убедительный репорт, вы должны понимать баг.

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

Может ли баг быть увиденным, но не понятым в ходе тестирования?

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

Может ли "баг" быть понятым, но не увиденным?

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

Чтобы знать, что это поведение – баг, его нужно подтвердить через хороший оракул.

У вас может быть причина верить, что поведение или атрибут, на который вы смотрите, на самом деле неверны. Некоторые вещи могут поначалу выглядеть неверными, и оказаться правильными при дальнейшем разбирательстве. Некоторые вещи могут казаться вам неверными, и быть верными в глазах значимых лиц. Это называется "проблемой оракула". Как я узнаю, что это баг?

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

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

Может ли баг быть понят, но не подтвержден?

Да. Чаще всего это может произойти, если процесс понимания бага "научил" вас, что это было верным  поведением. Однако нужно беречься от пропуска реальных багов, вызванного слабыми или ложными оракулами.

Может ли "баг" быть подтвержден, но не понят?

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

Чтобы клиент узнал о баге, вы должны отчитаться о нем.

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

Может ли баг быть подтвержденным, но остаться без отчета?

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

Можно ли отчитаться о "баге", который не был подтвержден?

Да. Это может произойти, если существует несогласие по поводу оракулов, но вы все равно пишете репорт на случай, если это важно. Или же это может произойти, если люди, не являющиеся профессиональными тестировщиками, смотрят на сырые результаты автотестов. В последнем случае менеджмент часто пожимает плечами и говорит, что "это, возможно, глюки автоматизации" (ни один проект, в котором я работал, не разрешает машинам "отчитываться о багах" без вмешательства человека, кроме ситуаций, когда это что-то убийственно очевидного, вроде падения или нарушения безопасности. Хоть это и не настоящий баг-репорт, это сигнал о проблеме, которая еще не изучена. Ценность человеческого подтверждения, если оно правильно проведено, в том, что вы убеждены, что отчет, написанный не вами, действительно заслуживает чтения).

Чтобы клиенты оценили баг, они должны получить отчет.

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

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

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

Может ли отчет о баге не дойти до адресата?

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

Может ли "баг" быть получен при отсутствии отчета?

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

Чтобы клиент предпринял что-то с багом, он должен считать его значимым.

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

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

Может ли полученный баг ничего не значить?

Да. Множество вещей технически – баги, но на самом деле на пользователя не влияют. Они могут варьировать от косметических проблем и минорных проблем производительности до поведения, которое просто незначительно отличается от оригинального техзадания.

Может ли значимый баг не дойти до клиента?

Да. Иными словами, баг может нанести урон вашей компании или клиентам, но вы об этом не узнаете.

К сожалению в нашей области баги часто попадают в это поле. DevOps стремится выкатить продукт как можно быстрее и считает, что тестирование их замедляет – возможно, полагая, что ни одна проблема не может быть такой уж ужасной. Поклонники Agile читают мантру "все должны тестировать" (что в лучшем случае означает, что все тестируют плохо, и никто не несет за это реальной ответственности). Фанаты технологии молятся на "полностью автоматизированное" тестирование, что означает, что тестирование не автоматизируется вообще (потому что это не то, чем могут заниматься машины) – автоматизируется горсточка узких проверок результатов, которые выглядят как тестирование в глазах людей, не имеющих о тестировании понятия. Значимы ли эти баги – вопрос, специфический для вашей области, ваших заказчиков ,и вашего уровня принятия рисков.

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

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