Баг для лога

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

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

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

Лог для бага

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

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

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

40 и 90

Как и многие до меня, однажды я задумался о звучании чисел 40 и 90 в русском языке. Почему они - "сорок" и "девяносто", а не "четыредесять" и "девятьдесять"? В том же английском языке все честно: forty и ninety. И у нас вроде бы должно быть так же, если сравнивать с другими числами: "пятьдесят", "семьдесят". Что не так с этими двумя?

Наверняка я не знаю, конечно; разные есть версии на этот счет. Приведу те, что мне самому кажутся интересными и правдоподобными.

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

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

Впрочем, речь не о числах, интересно другое. Замеченная "странность мира" (нелогичные названия чисел) позволила по-новому взглянуть на числа и связь их названий с историей страны. То есть, заметив странное и покопав в этом направлении, я узнал что-то новое.

Странности мира - отличный источник знаний о мире. 

Дефекты продукта - отличный источник знаний о продукте. 

Правильный багрепорт 2: точность описания и исследование проблем

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

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

Статистика дефектов. Спросите "Почему?"

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

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

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

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

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

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

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

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

Почему их так много?

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

Вот что получилось.

Никто не любит "инвалиды". А зря?

Нередкая претензия к  тестировщикам со стороны разработчиков:
- Сколько можно плодить "инвалиды"? Достали уже. Вы б хоть немного думали перед забиванием багов!
Ситуация неприятная для всех. Тестировщики чувствуют себя идиотами, разработчики плачут о времени потерянном на такие баги, все это ухудшает отношения между разработчиками и тестировщиками (и без того не безоблачные). Завести все это далеко может, но сейчас не об этом.
Что делать, если число багов с резолюцией (resolution) INVALID зашкаливает? Очевидно, что такого быть не должно, но как бороться? Для начала - понять, в чем причина такого положения и бороться уже с причинами. А они могут быть разными, "тестировщики идиоты" - не единственная.

Небольшой список возможных причин: