Качественный субъективизм

Один из серьёзных нюансов с качеством ПО с точки зрения разработки: уровень этого самого качества в изрядной степени субъективен.

При желании каждый участник процесса разработки легко найдёт оправдания и объяснит, почему налажал не он. Бизнес-аналитик честно подумал, но не смог учесть все нюансы многолетней архитектуры. Разработчик честно реализовал требования, а тестировщик честно их проверил. Оба — как поняли. Ну а что, если требования не полны — вопросы к аналитику. Он ещё и менял их постоянно, чего удивляться. Техлид недоучёл энтузиазм джуниора, а джуниор не в курсе, чем отзывается взмах крылом в этом конкретном компоненте системы.

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

И да, отмечу, фраза «каждый легко найдёт оправдания и объяснит, почему налажал не он» не должна вводить в заблуждение. Злобные мудаки встречаются всё же не очень часто (ну или я избалован работой в продуктовой компании). Никто не стремится саботировать. Просто каждый работает так, как видит возможным. Через голову не перепрыгнешь. Если есть из критериев качества только и прежде всего соответствие требованиям, то от них и будет каждый отталкиваться. В меру своего формализма, бодрости, семейных радостей и физического здоровья.

Я как аналитик сделал всё возможное: проанализировал ожидания и возможности, проконсультировался с инженерами. Несколько раз скорректировал требования по мере проявления нюансов.

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

Я как тестировщик, проверил фичу, пришёл в ужас, зарепортил баги, бился за них, но треть багов умерли вонтфиксами. Часть потом переоткроется, как показывает опыт, но это потом. Ответственные лица решили, что баги не фатальные. С формальной точки зрения блокирующих проблем нет, тестирование — done.

Я как… Ой, а всё, никого ж не осталось. Релиз.

Я как руководитель RnD недоволен, что мне на совете директоров рассказывают про баги в продукте. Каждый из инженеров видел проблему, и никто её не починил (а то и не заметил).

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

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

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

Полагаю, привносить эту субъективность можно по-разному, и разным командам/компаниям подойдут разные способы. Я лично знаком с системой Quality rating’ов, и сам видел, как она помогала. Если тестировщик поставил фиче оценку 2 из 5, вероятно с фичей что-то не так. Возможны и другие способы, но «техническая» реализация не суть важна. Важно дополнить формальные показатели живым ощущением сотрудника — тогда чуть больше шансов узнать реальное состояние продукта.

Всяко это лучше и полезней, чем пытаться понять, что таск-трекер может сказать о качестве продукта (QA квартирник Codefest’а, привет). Таки таск-трекер для задач, а качество для людей. Давайте у людей и спрашивать о качестве.

Привет, Аноним в поисках вопросов

Внезапно мне пришёл комментарий:

Анонимный прокомментировал(а) ваше сообщение:

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

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

Добрый день, Аноним.

Краткость – сестра таланта, поэтому я никогда не умел излагать коротко (и с годами – всё хуже). Так что я даже и ответов дам несколько.

Сферический ответ в вакууме (все же у меня математическое образование): Чтоб не было скучно, нужно делать то, что тебе интересно. А для этого надо сперва понять, что же тебе интересно и почему. Твой Кэп.

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

Пространный ответ.

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

1.

Итак, ты прочел Савина и пошёл устраиваться в тестировщики. Опыта, как я понимаю, пока нету. Знание техник тестирования – на уровне книги Савина.

Тут есть нюанс. Если я верно помню, Савин описывает скорее некий общий процесс разработки ПО и примерное место тестирования в этом процессе. Да, он уделяет больше внимания тестированию, чем разработке, и рассказывает, как работать с багтрекером. Но на самом деле это – про процесс тестирования, а не про его техники. Ну просто чтоб юный тестировщик понимал контекст своей работы – откуда появляется предмет тестирования, кто обрабатывает багрепорты и т. п. Естественно, Роман старался описать общий подход. Естественно, в реальной жизни процесс отличается от книжного (где-то больше, где-то совсем).

2.

Ну ладно, так или иначе – ты устроился на работу и начал свой путь тестировщика. Чорный ящик + свободный поиск. Не очень понятно, в чём тут скука. Ты же не ожидал, что тебя сразу посадят работать с Самой Главной Фичей или анализировать архитектуру проекта. Или – что ящик сразу будет белый/прозрачный: это требует умения читать и анализировать код и еще некоторых специфических знаний, которые трудно ожидать от новичка с Савиным в рюкзаке.

Нет, задачи первого времени: познакомить тебя с продуктом, посмотреть, как ты работаешь (на собеседовании же этого не увидишь особо), как общаешься с коллективом и т.д. Понятно, решать их можно по-разному, смотря сколько ресурсов в наличии и какие люди нужны.

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

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

Домашнее задание: Вспомни, что ты делал, когда становилось непонятно и скучно. Как ты знакомился с продуктом. Сколько вопросов задавал, как и кому. Разобрался ли с главной идеей продукта. Какой там основной сценарий использования. Можешь ответить внятно – хорошо. Нет – а может, ты не очень и интересовался? А работодатель-то больше любит активных ребят. Да и не могут окружающие понять без твоей помощи, что тебе понятно, а что нет.

3.

Так о чём же спрашивать работодателя, когда принимают на работу?

Ну, вообще – о чём угодно, точнее – обо всём, что интересно (и имеет отношение к работе, конечно). Сколько лет другим тестировщикам? На скольки проектах нужно будет работать? Сколько лет проекту? Каковы его перспективы? Что будет, когда он закончится? Есть ли в здании столовая? Давно ли образована команда тестирования? Во сколько люди приходят на работу? Какая ОС используется на рабочих машинах? Как уменьшить испытательный срок? В какой комнате я буду сидеть? Можно ли совмещать работу с учёбой? Что самое главное в моей работе? Какая методология разработки используется? А свою кружку можно принести на работу?

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

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

Не, ну с вопросами-то понятно. А что спрашивать, чтобы потом не было так скучно?

Ну что тебе сказать, я не знаю. Почему скучно-то было?

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

Важный момент: вопросами «когда принимают на работу» всё не заканчивается. Когда уже приняли, их всё еще можно задавать. И нужно. Чем больше спросишь – тем больше тебе расскажут, тем больше будешь понимать, тем больше интересного узнаешь.

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

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

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

Сумбурно получилось, извини – давно я не брал в руки шашек. Надеюсь, хоть частично я тебе ответил.

Пойду работать, у меня там сегодня столько вкусного запланировано…

Калибан с зеркалом

Перетолмачил предисловие к «Портрету Дориана Грея» в терминах тестирования. Получился своеобразный манифест :)

Тут исходный текст, ниже — мои вариации на тему.

Итак.

Тестировщик — тот, кто предоставляет информацию [о качестве].

Раскрыть окружающим положение дел и скрыть [роль] тестировщика — вот к чему стремится тестирование.

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

Высшая, как и низшая, форма руководства — один из видов воспитания.

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

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

Но избранник — тот, кто в результатах тестирования видит лишь одно: Информацию.

Нет продуктов изобилующих дефектами или избавленных от оных. Есть продукты хорошо протестированные или протестированные плохо. Вот и все.

Ненависть индустрии разработки ПО к Дефектам — это ярость Калибана, увидевшего себя в зеркале.

Ненависть индустрии разработки ПО к Требованиям — это ярость Калибана, не находящего в зеркале своего отражения.

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

Тестировщик не стремится что-то доказывать. Доказать можно даже даже неоспоримые истины.

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

Не приписывайте тестировщику нездоровых тенденций: ему дозволено сомневаться во всем.

Идеи и Навыки для тестировщика — средства тестирования.

Дефекты и Ценности — материал для его работы.

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

Во всяком виде тестирования есть то, что описано в книгах, и суть.

Кто пытается постичь больше, чем описано, тот идет на риск.

И кто раскрывает суть, идет на риск.

В сущности, Тестирование — зеркало, отражающее того, кто в него смотрится, а вовсе не продукт.

Если результаты тестирования вызывают споры — значит, в них есть нечто важное, сложное и значительное.

Пусть руководители расходятся во мнениях — тестировщик остаётся верен себе.

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

Всякое тестирование [само по себе] совершенно бесполезно.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Рунглиш. Новояз. Жаргон.

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

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

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

  1. Нет общения с посторонними. Чаще всего айтишники общаются с себе подобными. К ним не приходят люди с улицы заполнять бланки. Для общения с заказчиками зачастую есть специальный человек, и программисты, тестировщики и т.д. могут позволить себе речь отличающуюся от повседневной средней нормы чуть менее чем полностью.
  2. Высокий уровень абстракции. Айтишники работают с тем, что невозможно потрогать руками; в лучшем случае можно посмотреть на строчки кода или нарисовать диаграмму, записать последовательность действий или сделать скриншот. Поэтому в разговоре приходится либо оперировать длинными и сложнопроизносимыми понятиями, либо заменять их одинм словом, понятным далеко не всем. Обычно выбирается второе — так быстрее. Кстати, я тоже пишу «айтишники» вместо «люди, работающие в сфере информационных технологий» — по той же причине.
  3. Заимствование терминов. Многие термины и жаргонные слова, используемые айтишниками, заимствованы либо скалькированы из английского языка. Это понятный и естественный процесс: поскольку вся документация доступна прежде всего на английском языке, то зачастую проще использовать английский термин, чем придумывать или вспоминать адекватный перевод, причем еще неизвестно — поймет ли собеседник этот перевод. Так, в предыдущем абзаце я написал «скриншот», хотя мог бы написать «снимок экрана». Многие айтишники даже отказываются от использования русифицированных версий программ, ибо «мало ли, как они там в меню Options перевели».

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

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

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

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

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

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

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

P.S. Конечно, жаргон порой используется и для других целей — подавления собеседника неизвестными терминами, демонстрации своей учености/крутости, укрывания сути проблемы за непонятным набором слов, и т.п. Я не хочу здесь останавливаться на этих моментах подробно, поскольку меня сейчас интересует конструктивное использование жаргона, а не борьба с его темными сторонами.

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

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

Сегодня я задумался, о чем говорит большое количество багов с другими резолюциями.

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

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

Если много дубликатов, то возможно, что

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

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

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

Что делать: объяснять нюансы работы приложения, улучшать архитектуру системы, внедрять/расширять тестирование методом белого ящика (white/glass box testing)

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

Что делать: отслеживать срок жизни багов, искать пути его сокращения

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

что делать: объяснять архитектуру приложения; при написании багрепорта думать, насколько общая функциональность затронута; слушать, по какому поводу матерят продукт коллеги.

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

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

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

Что делать: тщательней смотреть, к какому продукту относится проблема; если проблема описана для продукта А, а на самом деле беда в продукте К, то не переносить багрепорт в базу продукта К, а создавать там клон этого багрепорта.

Большое число невоспроизводимых багов говорит о

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

Что делать: максимально точно устанавливать и описывать сценарий повторения проблемы. Обычно это требует хорошего понимания работы продукта.

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

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

— том, что часть из них инвалиды. Просто по каким-то причинам их не сочли таковыми.

 

Если много описанных проблем закрывается как Wontfix, то вероятно

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

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

Что делать: улучшать продукт; уточнять приоритеты тестирования.

 

Кроме того, для любой из этих резолюций (Invalid, Worksforme, Duplicate, Wontfix) ненормально большое количество таких багов может указывать на то, что резолюции по каким-то причинам используются неверно.

Что делать: объяснять значение каждой резолюции, каким багам они должны присваиваться.

Кроме резолюций, можно обратить внимание и на статусы багов.

Много новых (New) багов:

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

Что делать: аккуратней работать, чтобы багов в целом было меньше. Включать в планы починку багов.

Много починеных, но не проверенных багов:

— похоже, тестировщики не успевают проверять баги. Это плохо, особенно если известно, что баги часто переоткрываются после проверки.

Что делать: тщательней планировать работу тестировщиков.

Высокий уровень Reopen’ов может указывать на то, что

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

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

Что делать: всем быть внимательней. Дьявол в деталях.

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

P.S.

Определения:

Возможные резолюции багов:

Инвалид (Invalid) — багрепорт, описывающий ситуацию, не являющуюся багом, система работает правильно.

Дубликат (Duplicate) — багрепорт описыват проблему уже описанную ранее в другом багрепорте

Невоспроизводим (Worksforme) — при попытке воспроизвести проблему по описанию из багрепорта проблема не воспроизводится. С другой стороны нет и уверенности/доказательств, что это инвалид.

Оставлен (Wontfix) — багрепорт описывающий реальную проблему, которую решено не чинить.

Починен (Fixed) — багрепорт, описывающий реальную проблему, которая была починена в продукте.

Возможные статусы багов:

Новый (New) — решение по багу еще не принято (возможные решения: Invalid, Duplicate, Worksforme, Wontfix, Fixed)

Закрыт (Resolved) — багрепорт, по которому принято то или иное решение (возможные решения: Invalid, Duplicate, Worksforme, Wontfix, Fixed).

Проверен (Verified) — багрепорт, решение которого было проверено соответствующим подразделением, в процессе проверки не было найдено несоответствий.

Переоткрыт (Reopened) — багрепорт, решение которого было проверено соответствующим подразделением, в процессе проверки обнаружилось, что принятое решение неверно.