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

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

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

Вообще, встретив какую-то странность в поведении приложения, тестировщик должен прежде всего понять, баг это или нет; а если баг — в чем он заключается. Возможно, просто так хитро звезды, в смысле — настройки приложения, совпали, что поведение немного изменилось. Или может проблема в чужом продукте, с которым работает наше приложение. А может приложение все сделало верно, просто в пользовательском интерфейсе сообщило об этом не самым адекватным способом. Все это не исключает наличия проблем в нашем продукте, просто проблемы уже немного другие: нигде не сказано, что при таком сочетании настроек приложение станет себя вести иначе; нам надо учитывать, что чужое приложение ломается на определенных входных данных; нам нужно улучшить отчеты приложения о выполненых действиях.

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

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

Если есть ощущение, что с проблемой не все понятно, но нет идей, что и где проверить, то в таком случае полезно поговорить с разработчиками. Они неплохо знают неявные зависимости в поведении программы; у них нередко больше возможностей для исследования проблемы. В крайнем случае они могут хотя бы указать направление, куда стоит копать, чтоб понять, с чем мы столкнулись. Подойти с вопросом — это гораздо лучше, чем регистрировать баг с невнятным описанием. В разговоре можно объяснить, какие есть сомнения, что конкретно уже было проверено, а что нет, быстро узнать, какие дополнительные вопросы возникают у разработчика по данной проблеме.

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

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

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

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

Авралы как производная от качества планирования

Долгое время я считал авралы/переработки делом обычным — как в IT без этого? Но со временем я стал задумываться и понял, что все не так просто. В целом, понятно, что аврал — производная от планирования. Если мы что-то хотим сделать, но не успеваем, то приходится работать дополнительно по вечерам и/или в выходные. Нюанс в том, почему сложилась такая ситуация. Я выделил для себя три причины авралов со следующими условными названиями: ошибка планирования, тенденция планирования и отсутствие планирования.

Подробнее о каждом из типов.

Ошибка планирования

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

  • тестирование фич(и) занимает больше времени, чем планировалось
  • нужно срочно выполнить дополнительное тестирование какого-то модуля
  • половина команды слегла с гриппом
  • и т.п.

Я считаю этот вариант сравнительно безобидным, потому что известно, что надо сделать, чтобы аврал закончился (или даже не начинался, если удастся достичь цели в рамках рабочего времени). Конечно, плохо, что такая ситуация стала возможной, но есть шанс, что в будущем при планировании подобные риски будут учтены. Безусловно, если качество планирования не меняется, если похожие «неожиданные» проблемы возникают регулярно, то стоит задуматься: а способны ли участники проекта адекватно планировать? Или проблема вовсе не в неожиданности проблем?

Тенденция планирования

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

Отсутствие планирования

Ну тут все просто. Мы смутно представляем, какой объем работ должны выполнить («нужно полностью протестировать продукт»). Мы не оцениваем, сколько времени это займет. Возможно, мы даже не выделяем более или менее приоритетные вещи — просто тестируем «подряд». Не исключено, что мы даже толком не фиксируем, что мы уже протестировали и когда. Это, конечно, пример клинический, но идея, я думаю, понятна. В итоге две трети имеющегося времени мы работаем спокойно, а потом вдруг выясняем, что мы не успеваем протестировать значительную часть продукта. Начинается аврал и продолжается до самого релиза (если тот наступает). При этом зачастую сам аврал довольно бессмысленнен, поскольку мы по-прежнему не знаем, что нужно делать в первую очередь, а что может подождать.

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

Другое дело — как отличить один вариант от другого? На мой взгляд, полезно задать руководителю простой вопрос: «Вот у нас на субботу запланирован аврал. Сегодня среда. Какой объем работ должна выполнить команда, чтобы аврал стал не нужен? Чего мы хотим достичь этим авралом?» Если руководитель может дать внятный ответ на этот вопрос, указать достижимую цель, то все не так плохо. Во-первых, он знает (а теперь и мы), к чему мы стремимся. Во-вторых, есть шанс соптимизировать работу и успеть все сделать до конца пятницы. Или — до середины субботы, и сидеть на работе не весь выходной, а только половину. И, кстати, не сидеть в выходной на работе, а работать.

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

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

Четкого вам планирования и безавральной работы!

Аттестация в жизни технического человека

Во многих крупных компаниях существует, в том или ином виде, процедура периодической аттестации сотрудников. Раз в год или в полгода работу сотрудников за прошедший период оценивают по нескольким параметрам. Число и набор параметров может разниться, но сейчас не об этом. Зачастую процедура предполагает, что каждый сотрудник заполняет некую форму, помогающую произвести оценку. Проблема в том, что многие «технические» люди — программисты, тестировщики — воспринимают эту деятельность, как ненужную потерю времени и придурь начальства, которому нечем заняться. Даже зная, что на основе этого документа будут приниматься решения о карьерных и зарплатных изменениях, технари обычно не видят смысла его заполнять, и вообще тратить время на процедуру аттестации: работаем же, все в порядке, и так ясно, кто хорош, а кто нет.

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

Итак, момент аттестации наступил.От тестировщика требуют, чтоб он написал/рассказал, что и как он работал за последний период; чего достиг, как проявил себя в той или иной сфере. Тестировщик сидит, пытается вспомнить, что такого интересного было полгода назад и ругается. И правда — придумали же ерунду какую-то. Есть же непосредственный начальник. Нужно решить, повышать ли зарплату, — ну так спросите у него, он же знает, кто чем занимается. И писанину разводить не пришлось бы, время тратить.

Проблема в том, что начальник вовсе не обязательно так уж хорошо все знает. Вообще, многие технические люди, особенно по молодости, считают начальника таким странным существом, которое ничего полезного не делает, зато при этом знает, что и почему делал каждый сотрудник в отделе. Это заблуждение приводит к недопониманию и обидам. На деле начальник, очевидно, не может знать, чем занимается каждый из его сотрудников в каждый момент времени, особенно если подчиненных больше трех. Он может не помнить, а то и не знать, что Вася написал скрипт, который облегчил работу трем сотрудникам. А к Пете часто приходят посоветоваться по разным заковыристым вопросам. И если Вася и Петя сами не скажут ему об этом, то он может никогда и не узнать. Я не призываю хвастаться каждым своим действием. Но если тестировщик знает, что он сделал что-то полезное для отдела, то аттестация — удобный момент об этом напомнить. Никто это как хвастовство не воспримет. Аттестация и создана для того, чтоб узнать, кто и что делал. И как, что немаловажно. С другой стороны, если каких-то особых достижений нет, а вы просто «хорошо делали свою работу», то непонятно за что вас поощрять. Вас и нанимали, чтоб вы хорошо делали свою работу, не так ли? Подумайте, что вам позволило достигать хороших результатов.

Ну, хорошо. Сообщил Вася, что он написал скрипт — и ничего не произошло. Никто его не похвалил, вообще не оценил принесенной пользы. Тут тоже стоит подумать, почему так произошло — просто потому, что «да наверху только козлы и идиоты» или дело в чем-то еще. Нередко проблема в том, как описано достижение. Если Вася написал только про сам факт создания скрипта, то это никаких данных не дает. Ну написал, и что? Непосредственный начальник может подойти и уточнить детали, конечно. Но зачастую решение принимает не он, а вышестоящий менеджер, а тот опрашивать каждого точно не пойдет. Так может стоит сразу написать так, чтоб было понятно? Вообще, стоит помнить, что тот, кто будет читать заполненную аттестационную форму не в контексте вашей работы. Он вовсе не обязательно идиот. Он, может, даже в тестировании/программировании понимает. Но из пары строчек понять, чем был полезен скрипт, зачастую трудно. Не надо, опять же, расписывать технические детали — за редким исключением, они мало кому из читающих интересны. Обязательно нужно написать, какую проблему решает скрипт. Не просто так же вы его создали — хотели что-то упростить наверное или автоматизировать, или еще что. Вот об этом и напишите. Если есть какие-то количественные показатели — обязательно надо их упомянуть. «Скрипт позволяет сэкономить половину человеко-дня в неделю» — отличный результат, который скорее всего будет по достоинству оценен руководством. Возможно, подобный измеримый результат представить трудно, зато были созданы некие артефакты — на них тоже полезно сослаться. «Заметив, что вопросы возникают снова и снова у разных людей, организовал базу знаний, куда занес сведения и отсылаю людей к этой базе. База знаний находится вот тут» — тоже прекрасно. Гораздо лучше, чем «я часто, много и охотно помогаю коллегам а решении проблем».

Кто-то может сказать: «Здорово, конечно. Скрипт там, база знаний. А я программировать не умею, и железа чтоб какие-то базы размещать у нас нет. И вообще, у меня компьютер тормозит, когда я приложение запускаю, чтоб протестировать. Какие уж тут достижения!»

Это еще один важный момент. Не стоит воспринимать аттестацию как «ерунду, нужную только для менеджеров». Даже если форма не содержит подходящего поля, все равно аттестация — очень удобный момент, чтоб рассказать про накопившиеся проблемы самого разного плана. Устаревшее железо, сломанный стул, неактуальное ПО, необходимый тренинг, невкусный кофе — обо всем, что мешает эффективной работе, стоит написать или хотя бы поговорить со своим начальником. Может, он и не в курсе проблемы — стул у него хороший, с железом напрямую не работает, пьет чай, а не кофе. А узнав, он может или сам проблему решить или [попытаться] продавить решение по иерархии. Но сначала он должен узнать, что проблема есть. Не обязательно ждать аттестации, чтоб о ней сообщить, но если проблема еще не решилась — то хорошо про нее напомнить.

Еще ситуация: что-то сделано, красиво подано, но реакция на достижение все равно не вдохновляет. К сожалению, возможно, что вы рыли не в том направлении. Вы в курсе, чего от вас и вашей работы ждет начальник? Вы в курсе, какие направления деятельности отдела начальник считает более важными? Вы в курсе, как начальник оценивает вашу работу и почему; куда по его мнению вам стоит развиваться? Если нет — то стоит его спросить. И аттестация, опять же, удобный момент это сделать. В первый раз подобные вопросы задавать многим страшновато, но на самом деле ничего страшного в этом нет — такие обсуждения обычно проходят гораздо проще, чем может представиться. А польза — огромная.

Вообще, аттестация сотрудников это такой момент, когда даже плохонький начальник (а таких, я верю, в IT все же не так много) вынужден вспомнить, что он управляет людьми и высказать какое-то обоснованное мнение на их счет. Он может не все знать про достижения своих людей, он может забыть про что-то. Ему может не хватать какой-то еще информации. И если вы как подчиненный облегчите начальнику его работу, предоставив ему эту информацию — он скорее всего оценит. А если вдруг нет, то все равно остаются два плюса: вы для себя проанализировали собственную деятельность — достижения и слабые места. Всегда полезно знать о себе больше. Если вы пришли к выводу, что начальство ваши усилия не ценит — может, стоит подумать об изменениях? Смена места работы — тоже вариант, если на текущем месте вы уперлись в стену или потолок.

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

  • сообщить о успехах
  • сообщить о проблемах
  • рассказывать о достижениях, а не про то что работал работу. есть количественные показатели? круто!
  • помнить, что менеджер не знает о вас все
  • помнить, что вы не все знаете о менеджере
  • прояснить ожидания руководителя о вас и вашей работы
  • выяснить мнение руководителя о текущем уровне работы
  • выяснить мнение руководителя о возможных/приоритетных направлениях развития
  • рассказать свое мнение руководителю на этот счет
  • высказать свои идеи

Успехов и адекватных оценок вам во время аттестации!

Статистика дефектов.

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

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

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

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

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

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

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

Но ведь бывает так, что какой-то один программист действительно небрежен, и его код просто кишит дефектами. Или — тестировщик настолько невнимательно работает, что его описания дефектов зачастую бесполезны. Как отловить такие проблемы, если не анализировать распределение багов по людям? На самом деле — просто. Если человек действительно так уж выделяется на общем фоне, то скорее всего вы и так уже об этом знаете, без всякого анализа. А если не знаете — то весьма вероятно, что кто-то из участников постмортема (а чаще — сразу несколько) укажет на эту проблему.

Ок, людей не анализируем. Что же тогда можно извлечь?

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

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

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

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

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

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

Аномалии в статистике — это повод задать вопрос: «Почему так?» И постараться на него правильно ответить.

[HDI] Увеличение своп-файла Linux без изменения разделов диска

Если вдруг потребовалось увеличить swap раздел на Linux’овой машинке, а править текущее разбиение диска на разделы не хочется, то можно поступить так:

# dd if=/dev/zero of=/var/swap bs=1M count=1048
# chmod 0 /var/swap
# mkswap /var/swap
# echo "/var/swap none swap defaults 0 0" >> /etc/fstab
# swapon -a

Собственно, тут создается файл, который в дальнейшем используется как swap-раздел.

Ключевой момент тут count=1048 — этот параметр определяет, какого размера файл будет создан.

P.S. честно своровано отсюда