Lesson 101

Разработчик: «Приложение поднимается, а то, что оно работает я не проверил»
Норм, чо.


Слово Канеру:

Если ты решил бороться, ты решил выиграть!

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

Чтоб подготовиться к апелляции, ты можешь:

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


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

Lesson 100

Сотая лекция Канера. Надо разбить об меня 40% бутылки шампанского.
Слово Канеру:

Обжалуйте отсроченные баги немедленно.


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

Lesson 99

Слово Канеру:

Инерция тестирования никогда не должна быть причиной откладывания исправления дефекта.

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

Lesson 98

Слово Канеру:

Не позволяй отложенным багам исчезать.

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

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

Продукты, которые проходят через большое количество релизов, накапливают большой набор раздражающих багрепортов, которыен никогда не приведут к изменению кода или документации. Некоторые группы вместе с руководителями проектов делают ревью таких багов и постоянно закрывают их с причиной INWTSTA ("I never want to see this again").

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

Lesson 97

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

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

Слово Канеру:

Не настаивай, чтоб каждый баг был исправлен. Выбери свою битву.



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

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

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

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

Lesson 96

А вы знали, что падежей в русском языке прям 13?

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

Слово Канеру:

Проверяйте исправления быстро.

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

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

Ни одна ошибка не может быть закрыта никем, кроме тестировщика.

Lesson 95

У меня масса вопросов.
1. Нужна ли в jira русификация?
2. Что вы думаете о плагине Зефир? ну у нас реально нет кейсов вне АТ, значит и зефир не нужен, правильно?

Нашел примерно такой отзыв о Зефире:
[...] И при этом окружать профессионала будут очень приятные и адекватные люди (медленно сжимая кольцо), с которыми он будет говорить на одном языке – на языке жестов и междометий в адрес проклятых создателей гребанного Zephyr… [...]

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

Слово Канеру:

Если фикс фейлится (ну подскажите, как еще перевести fixes fail), поговорите с пограммистом

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

Твой тон и отношение должны быть дружелюбными и нацеленными на пользу. Ты не должен говорить программисту: «Плохой! Плохой программист!». Вы должны принести пользу программисту, предоставив ему информацию и быть доступным для устранения неясностей, демонстрации ошибки, если нужно.

Lesson 94

Сегодня в гости с целью грабежа опыта заходили программисты и руководители разработки из соседних отделов.
Мы с падаваном рассказывали что и как мы наворотили за полгода.
Подошел наш руководитель, три минуты послушал и тоже толкнул речугу.
Возник интересный диспут. Суть вкратце: понятно и очевидно, что нужно делать с тестами, когда их у тебя 21 штука. Когда у тебя 1000+ тестов - появляется масса опыта, но ясность и понятность того, что со всем этим делать - как то пропадает. Все больше проблем и вопросов...

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

Слово Канеру:

Проверяйте исправления быстро.


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

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

Lesson 93

Слово Канеру:

Когда программист что-то починил, убедитесь, что оно все еще не сломано.

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

Lesson 92

Слово Канеру:

Лучшим способом может быть демонстрация бага программисту

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

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

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

Lesson 91

Слово Канеру:

Познакомьтесь с программистами, которые будут читать ваши отчеты


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

Lesson 90

Кто негугля знает что такое пик Балмера?
http://xkcd.com/323/

Слово Канеру:

Просматривайте каждый чужой багрепорт

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

Этот тестировщик может также просмотреть:
- Все дефекты
- Все дефекты в своей области
- Все дефекты коллеги

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

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

Lesson 89

Я бы просклонял дефект по падежам так:

Именительный: Баг.
Родительный: Бага.
Дательный: Баге.
Винительный: Багу.
Творительный: Багом.
Предложный: Баге.

У вас есть свои версии?
UPD: Путаю мужской и женский род дефекта, но некоторые баги те еще суки, не так ли?

Слово Канеру:

Используйте рекламную информацию или данные техподдержки для разъяснения.

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

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

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

Lesson 88

Из тестировщика получится саппорт лучше чем из саппорта тестировщик? Или нет?

Слово Канеру:

Улучшайте навыки багрепортинга

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

Lesson 87

Никто так и не ответил. Давайте попробуем еще раз, а?

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

Куплю сегодня яблок.

Альбом: randompics4lj

Слово Канеру:

Сделайте ваш репорт читаемым даже для уставших и раздраженных людей.

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

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

Lesson 86

Слово Канеру:

Будь осторожен со своим тоном. Каждый, кого вы критикуете, увидит ваш багрепорт.

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

Например, репорт, ПОЛНОСТЬЮ НАПИСАННЫЙ КАПСОМ читается как крик. Если вы не уверены в том, как будуть читать ваше репорт, попросите прочитать доклад кого-нибудь и ВНИМАТЕЛЬНО ПОСЛУШАЙТЕ его комментарии.

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

Lesson 85

Слово Канеру:

Сообщайте о проблеме, не пытайтесь ее решить.

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

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

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

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

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

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

Lesson 84

Слово Канеру:

Никогда не преувеличивайте серьезность бага.

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

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

Lesson 83

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

Мой итог:
Всего слов - 104
Выкинул слов - 41

(А в рабочей почте еще хрен найдешь письмо даже из 15 слов...)

Слово Канеру:

Заголовок бага— самое важное поле багрепорта.


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

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

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

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

Lesson 82

В кинотеатре "Буревестник",
После той, большой войны
За полпачки "Беломора"
проходили пацаны.



Спасибо estel-oscora за историю этой песни.

Автор – поэт-песенник Александр Вратарев, и композитор – Владимир Быстряков

Оказывается, песня целиком и полностью основана, как это принято говорить, «на реальных событиях».

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

Слово Канеру:

Каждый баг заслуживает репорта

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

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

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