Кто несет ответственность за качество?

 Расставим точки в уже классическом обсуждении.

Постановка вопроса

Итак, кто несет ответственность за качество продукта?

Уже тут к нам бегут душнилы (я первый) и вопят:
 - Нужно определить слова _ответственность_, _качество_ и _продукт_ и только потом продолжать разговор!

Душнилам мы ответим, что для простоты:

• список потенциально ответственных ограничим ролями команды разработки: аналитиком, программистом, тестировщиком фичи и их менеджером
• за продукт мы возьмем те исходники, что во время релиза будем пытаться деплоить в бой
• качество измерим объемом косяков, которые надо срочно исправлять после релиза
• за несение ответственности условно примем ответ на вопрос "кого взгреть?"

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

Итак, кого взгреть, если после релиза навалило косяков и пришлось всё бросить, бежать и чинить? Взгреем аналитика? Программиста? Тестировщика? Менеджера? Всех?

Мнения

Я опросил менеджера, программиста, аналитика и тестировщика.

Один уважаемый менеджер пишет:

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

Не менее уважаемый программист считает иначе:

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

Какой-то неглупый аналитик сказал:

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

Тестировщик может заметить:

Что только он защищает интересы юзеров и вообще он один на пути продукта к хаосу.

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

Правильный ответ

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

И я не подведу. Вот что я сформулировал для себя, во-первых, прочитав немало книг по теории  управления, а во-вторых, получив некоторое количество практического опыта.

За качество продукта не отвечает никто, это результат стечения обстоятельств.

В этот момент к нам врываются бизнес-пацаны, бьют всех ногами и кричат: а мы знали! Вы ни за что не отвечаете! Давно пора прекращать платить вам такие деньги!

Подождите. Есть НО.

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

Этот набор действий не всегда прописан в должностных инструкциях, часто отсутствует регламент и согласованный список. Тем не менее, набор достаточно точно определяется:

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

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

Когда случился факап:

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

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

К чему я веду

Я понимаю:

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

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

Я несу ответственность (во имя луны)!

классно звучат, но на практике приводят к весьма плачевным результатам:

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

Я призываю

Больше смотреть не то, кто за что отвечает, а на то, кто и что:

• обучен делать
• обещал делать
• способен и имеет возможность делать
• уже сделал

А еще призываю учить. особенно тех, кто несет много ответственности.

Двенадцать способов выполнить задачу (в Контуре)

Этот пост я опубликовал во внутренней сети и он применим именно к нашей культуре разработки. 

Предвосхищая возгласы (всем, конечно же, не пофиг) вида: 

- Да у вас бардак и все делают что хотят, ужас, так жить нельзя!

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

Итак, сам текст: 

Итак, мы съездили в Ростов

Мы уже побывали в Ижевске, Казани, Новосибирске, Питере и Перми.
Муза дальних странствий манила нас.

Итак, мы поехали в Пермь

С очередным митапом.

Когда уезжали, падал прошлогодний снег.

Состав практически тот же, что и в прошлый раз:

• Ирина Полунина с докладом "Как развестись, но остаться друзьями или зачем тестировать через API, если есть UI"
• Сергей Махетов с рассказом о том, "Как перехват и анализ трафика помогает в тестировании"
• Я с новым докладом о жизни "Без менеджеров и тимлидов"

Запись этих докладов мы хотим сделать в Ростове.

Об использовании статистических методов для оценки сроков

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

В частности. в докладе звучала фраза:

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

Попробуем применить к моей реальности и культуре разработки. Сегодня я взял на тестирование задачу, аналитику по которой сделали в феврале. Это не уникальная задача, таких много.

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

Итак, пытаемся применить метод из доклада для оценки наших SLA.

Бизнесу мы скажем примерно это:

Мы не знаем, когда мы сделаем эту конкретную фичу, но знаем, что за два с половиной года мы сделаем 27 из 30 фич. Не знаем, каких именно. Не знаем, когда именно. Точнее не выходит =)

Интересно, что скажет в ответ бизнес?

Забавно, но именно эта оценка не будет ложью, а те, что обычно звучат — будут.

К чему я?

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





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

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

Турне в Казань и Ижевск

Суть коротко

Я и несколько коллег из Контура в прошедший четверг выступили на Izh Tech Talks #6, а в субботу на Kzn Tech Talks #2. Добирались поездами.

Дайджест

Вот тут я собрал в кучу важные для меня и просто интересные тексты.

Оценка исполнителем сроков на разработку и тестирование задачи (не нужна)

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

Научиться оценивать сроки на тестирование задач

Уверен, такие же цели ставятся и другим ролям в разработке.

Укладывается в самостоятельно сделанные оценки сроков по задаче

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

Дорофеев, Эффект выпрямления сроков

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

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

Задача начинает «дымиться», и мы приступаем к ней. Если ничего не случилось, то мы успеваем вовремя, а вот если что-то случилось… Резерв мы на это «что-то» уже потратили и в итоге опаздываем.

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

Голосом с 23 минуты.

Демарко, Человеческий фактор

В пятой части первой главы есть ссылки и объяснения исследований.

Коротко: сам факт оценки влияет на сроки в худшую сторону примерно на 40%. Рекомендую прочесть. Все факторы, перечисленные в книге, релевантны до сих пор.

Деминг и Нив, статистика и вариации

За последний год в двух командах слышал следующее:

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

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

Упомянутые в заголовке авторы говорят, что верный способ оценки сроков — статистический. Оценивается пакет типовых задач.

У нас все задачи разные.

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

Что делать, заказчик же требует сроки?

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

Как правило, ответом на вопрос успеем ли мы к заданному сроку? является аналитика и mvp, качественная инфраструктура разработки и размер техдолга: скорость рефакторинга, наличие автоматической регрессии. Ещё раз, оценка сроков мешает исполнителю успеть к дедлайну.

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

• MVP.
• Декомпозиция задачи.
• Раздельный релиз фронта и бекенда.
• Канареечные релизы.
• Фича-флаги.
• Умение тестировщиков отделять важные дефекты от неважных и умение релизить с неважными
• Pull стратегия работы над задачами (я говорю о том, что программисту не должны совать новые задачи, пока не вышли старые, даже если над задачей пока работает не он).
• Много раз слышал о такой стратегии: сперва релиз рефакторинга, который готовит код к появлению новой фичи, затем релиз самой функциональности. По сути, та же декомпозиция.

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

Ты выпадаешь на умняк и учишь жизни, а чего добился сам?

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

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

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

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

В последний раз я задерживался на работе по просьбе менеджера, чтоб выпустить срочную задачу в январе 2017 года. До этого пару раз,  в 2015 и в 2016 году.

P.S. 

Речь идет о продуктовой разработке.

Про экзокортекс (и блокнотики)

История о том, когда мне не нужно компьютеризировать и автоматизировать.

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

Есть такая штука в современном дискурсе, как экзокортекс, о нем много пишет Левенчук. Вики:

Экзоко́ртекс (др.-греч. ἔξω [exō] — вне, снаружи; лат. cortex — кора) — внешняя система обработки информации, которая поможет усилить интеллект или выступить нейропротезом для коры головного мозга. Если термин «экзокортекс» понимать расширенно, то можно сказать, что его функции уже выполняются Интернетом, смартфонами, различными гаджетами и что его история началась с изобретения письменности.

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

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

Что я не использую как хранилище

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

YoungGen (время жизни около недели), Micromiles

Micromiles на телефоне, главная задача: разгрузить оперативную память, ничего не запоминать.

• Любые мысли, которые пришли в голову или в телегу, когда я не у компа. Их потом нужно перенести в остальные хранилища.
• Напоминалки. Тетрадки, мапки и всё остальное не умеет "напомнить в следующую среду".

OldGen (время жизни полгода), темповый блокнот для всего подряд

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

В нем записи на любые темы, от заметок по конференций

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

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

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

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

OldGen (время жизни полгода), блокнот по отделу

Уже третий том, два предыдущих на полке, те, что со стикерами.

На стикерах названия бизнес-направлений, команд.

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

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

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

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

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

PermGen (время жизни не ограничено), файлы в облаке

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

Файлы стараюсь называть осмысленно, выходит не всегда.

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

Храню файло с 2012 года, научил Саша Ликулин в Наумене.

PermGen  (время жизни не ограничено), мапки

В ней информация по каждому тестировщику и по каждой команде.

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

Веду с 2011 года, по одной мапке на компанию, в которой работаю, научила одна из тестировщиц в Наумене.

Личная библиотека в домашнем кабинете

Когда буду совсем старый и у меня будет много денег (_ага_), хочу, чтоб было так:

Вместо выводов

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

Когда и как нужно уходить из команды

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

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

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

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

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

Ряд команд традиционно называют уходящих предателями.

• Он лучше всех выполнял свою работу и её не научился делать никто больше.

• Он выполнял работу без ошибок и вокруг него не был создан или был атрофирован контур контроля.

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

• Он стал лицом команды и люди шли работать не в команду, а с ним. За ним могут уйти и остальные, кроме того, команда разучилась искать людей другим способом.

• Попытки занять место такого человека, захватить его роль немыслимы или пресекаются.

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

Как в мифологии, каждый герой рано или поздно становится драконом.

Неизбежно

Уход любого человека из команды неизбежен.

Два года назад мы в EDI сделали фотографию, ознаменовавшую, что в команде не осталось ни одного человека с другой фотографии команды, шестилетней давности.

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

Решение

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

Я считаю, что у нас должно начать действовать правило.

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

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

А еще мы большие, намного больше, чем одна команда. Нужно этим пользоваться.

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

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

Нашим продуктам нужны качественные интеграции, и что, как не переход сильного разработчика (в широком смысле этого слова), может лучше помочь им?

О том, как появляются лидеры

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

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

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

Срок

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

Кто решает?

Кто решает, что вот конкретно этому человеку пришла пора сказать "я уйду через 2 года"?

• Команда? Слишком абстрактно.
• Менеджер? Это прямо противоречит его тактическим интересам. Не каждый способен.
• Функциональный руководитель? Не всегда он есть.
• Он сам? Самому сказать: "я самый крутой и ваш лидер, поэтому... "? Так себе идея.

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

А если взорвется?

А что если ну вот никак нельзя, всё сломается, взорвется и упадет?

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

О соревнованиях тестеров и навыках

Я занимаюсь тестированием с 2007 года и самоидентификация для меня важна. В том числе она включает в себя ответ на вопрос "Какой я специалист? Что я умею, а что нет?"

Из 8 проектов, в которых я работал дольше месяца, в 4 я был первым тестировщиком в команде. За процессы в 2 из этих 4 команд мне не стыдно.

Я всегда старался узнать ответ на вопрос — насколько хороший я тестировщик?

Ответ на этот вопрос не может не включать проблему сравнения себя с другими тестировщиками.

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

Один из способов — соревнования тестировщиков.

Я принимал участие в 4 соревнованиях по тестированию и каждый раз занимал призовые места:

• 1 место, вне зачета тестили е96
• 1 место, тестили экстрим
• 3 место, тестили мобилки
• 2 место, тестили кроссаут

Еще два соревнования тестировщиков я организовывал и судил.

Себе я доказал всё, что хотел.

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

Да, но...

Некоторые призеры первых тест-сессий, которые приходят на ум:

• Юра Рягин, руководитель отдела тестирования в Экстриме
• Наташа Селиверстова, самый сильный тестер в екбшном Яндексе.
• Саша Ахметов, широко известный в узких кругах Контура

Есть какая-то корреляция...

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

Я заметил, что они очень круто, быстро и умеючи делают самые простые вещи:

• слепая печать
• хоткеи и фишки в инструментах
• быстрый доступ к информации
• умение в календарь
• пустой почтовый ящик
• ...

• Оформить скриншот за 2 секунды.
• Создать дефект из шаблона меньше, чем за минуту.
• Ответить на вопрос "Над какими задачами ты работал в апреле 2016 года?" меньше, чем за минуту.
• Создать встречу на 1,5 часа на этой неделе на 4 человека и 3 менеджера, и чтоб у всех не было занято.
• Написать скриптик на питоне или баше, готовящий данные.

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

Подробно и хорошо об этом механизме пишет Лемов в книге "От знаний к навыкам". Книга есть в библиотеке.

Рост — вести всё более сложные и масштабные проекты, расширять ответственность. Но обеспечит его именно повторение простых гамм, отточенное умение реализовывать базис.

Кстати, мне нравится, что в управлении разработки Контура

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

Все они — действующие специалисты, которые пилят задачи, рисуют макеты, коммитят тесты, выпускают релизы.

Что делать?

Сравнивать.

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

Справа от тебя аналитик. Почему он всё помнит, а ты нет? Записывает? Как? В вики, в мапку, в тетрадку? Почему ты так не умеешь? Подсмотри. Приучи себя вести свои записи так же.

Напротив — программист ... Ну ты понял.

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

P.S. А еще следи за новостями, одна тест-сессия будет 1 декабря, другая в начале февраля.

Roadmap тестировщика в контуре

У нас в контуре есть гайд о том, каким мы видим проектировщика.

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

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

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

Итак:

Тестировщик в Контуре

Per aspera ad astra

О чем речь?

Текст поможет ответить на вопросы **Кто я и как мне стать круче?** и понять, кем хочешь быть в профессии и что сделать, чтоб стать лучше.

Стажер, младший тестировщик (0)

Чтоб стать

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

• Высшее техническое образование
• Серьезный объем подготовки
• Опыт работы в профессии

Совсем не о фехтовании

Недавно услышал фразу, которая позабавила, и поэтому зацепилась в голове.

Фехтование - гражданское искусство.

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

Что даст метафора на мою профессию?

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

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

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

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

А что является умением держать строй?
Управление техдолгом, умение не наращивать его безмерно.

Тыкать копьем?
Простые проверки под команды, которые диктуют нам риски.

Как это переложить в требования к кандидату?
Последовательность, умение после А говорить Б.
Способность отделить важное от неважного: вопросы "Зачем?", "Для кого?"

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

Почему я все равно считаю тест дизайн важным?

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

Все равно, фраза шикарная, нужно что-то еще из нее вытащить.
И да, пора в отпуск.

Разбери бэклог

Написал статью для календаря тестировщиков, первый выпуск.
Лежит вот тут, ниже ее текст.

Не новогодняя история вместо итогов года

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

Брат рассказал историю, которую я перескажу вам. Байка или нет, не знаю. Где наврал не помню. А в конце будут мои выводы и пожелания всем нам на следующий год.

 

Итак, с его слов, по памяти

Не так давно случилось ЧП: отлетела лопасть у винтового самолета малой авиации. Самолет приземлился. Инцидент не замолчали, началось расследование по всей форме.

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

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

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

• Тех, кто заменял лопасти. Вовремя ли списывал?
• Тех, кто вез до места сборки. Не повредил ли в дороге?
• Тех, кто покрывал составами, прессовал и вплоть до тех, кто отливал заготовку — нет ли в ней каверн?

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

 

Первая

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

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

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

 

Вторая

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

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

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

 

Выводы

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

Въедливый читатель возразит:

• Мы же не рискуем жизнями!

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

Так что еще пара пунктов:

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

О квалификации

ТОП-5 докладов TED о HR.

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

Но меня всю дорогу не покидало чувство, что что-то не так.  Какие-то они слишком софт скиллс. Ну или "пиздеть - не мешки ворочать".

Вам знаком тест?

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

2) Происходят выборы мирового лидера и Ваш голос - решающий.
Краткие характеристики кандидатов:
а) Связян с политиками, уличенными в мошенничестве, постоянно консультируется с астрологом, имеет двух любовниц, курит трубку и выпивает каждый день 8-10 мартини.
б) Дважды вышибали со службы, имеет привычку спать до полудня, в институте был уличен в употреблении опиума, каждый вечер выпивает бутылку виски.
в) Герой войны, вегетарианец, изредка пьет пиво, не курит, ни в каких матримониальных связях не замечен.

Кого же Вы выбираете? Ответили?
Тогда еще два слова о кандидатах.

а) Уинстон Черчилль
б) Фрэнкли Д. Рузвельт
в) Адольф Гитлер

Вот теперь Вы готовы ответить на самый первый вопрос. Если Вы посоветовали сделать аборт - Вы только что убили Людвига ван Бетховена.

Пример подобной манипуляции из речи одного эйчара на TED.

Дама задает вопрос - а стали бы вы брать на работу или сотрудничать с больным дислексией (проблемы с чтением и письмом)? И тут же добавляет. что  в США 35% успешных предпренимателей больны дислексией, как бы намекая, что зря вы отказались в предыдущем вопросе.

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

Корреляция отличается от причины.

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

/me продолжает читать Нисбетта, главу про эксперименты.

Рассказ Людвига Быстроновского «Как я выхожу из тупиков»

Намедни посетил двухдневную лекцию.
Остался доволен. Далее - впечатления, выводы и пополнившийся список литературы на будущее.

Впечатление

Как всегда - очевидное о жизни. Как обычно - лектор уложил интуитивное и очевидное в структуру. Ощущение - "именно эти слова я искал" и "я такой же".
Почему нет? Мне понравилось.

Конспект первого дня.

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

Людвиг пользуется тремя эвристиками, помогающими преодолеть тупняки и совершить прорыв.

• Контринтуитивное. Решить вопрос противоречащим интуиции способом. снимать носок за пятку. Есть сахар по утрам, чтоб не есть торты вечерами. Часто есть, чтоб похудеть. 
• Ошибки мышления. Читать о ошибках мышления, находить их в себе и, осознавая, искоренять.
• Получать системные знания. Когда знаешь, как все работает на самом деле.

После этого еще два этапа.
Первый - отработка техники. Второй - изменение мировоззрения.

II.  Программа для ведения финансов YNAB.
Принципы:
Не контролировать и ограничивать, а помогать понять свои приоритеты и заранее положить в них деньги

• тратить деньги из прошлого
• непредвиденные статьи
• понять сколько ты можешь не работать

III.  Схема планирования дня.
По большей части о книге: Марк Форстер, Do it tomorrow
Суть: 

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

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

IV. Мелкие советы: 

• дубликаты вещей
• программа альфред
• postnauka.ru
• оценивать работу по когнитивной нагрузке
• научиться медитировать

Конспект второго дня.

I. Что делать с ощущением неуспеха?

Найти человека, с которым можно поговорить

Читать литературу о когнитивных искажениях и психологии. Зачем - чтоб получить право на нормальность.

Примеры головняков, которые вешают родители: "шапка", "мы не смогли, но ты".

II. Как избавиться от сверхконтроля за подчиненными?

Давать больше возможностей. Дать планировать бюджет.

Давать право на ошибку.

Чаще проводить не финальное, а промежуточные демо.

Заказчикам на входе говорить, что будет плохо. И жить с этим.

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

Не брать долги. Совсем.

• Денежные
• Технические
• Управленческие

Не обещать, что все будет хорошо. Все будет плохо и поменяется.

В случае смертельного марша - спасать людей, а не проект.

 Список литературы

Мастхэв:

• Марк Форстер, Do it tomorrow
• Ричард Нисбетт, Мозгоускорители

Остальное:

• АРИЗ Интеллектуальное айкидо
• Правила игры без правил
• Щедровицкий , Оргуправленческое мышление
• Фрит, Мозг и душа
• Кэтмелл, Корпорация гениев
• Хоровиц, Легко не будет
• Лич, Вовремя и в рамках бюджета
• Бек, Когнитивная терапия
• Арнхейм, Искусство визуального восприятия
• Байстер, Искусство видеть паттерны
• Румельт, Хорошая стратегия, плохая стратегия
• Люттвак, стратегия. Логика войны и мира

Про то, куда иду

Ты "свет фар" своего проекта. (с)

Сэм Канер.

Про то, откуда иду, я уже писал. Теперь про то, куда.

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

 

Ты не программист

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

Но приложения создают именно программисты. И отчасти ты - программист.

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

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

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

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

Если ты пишешь тесты, то код тестов соответствует стандартам кода продукта. Тесты - часть продукта и их качество - качество продукта. Ты пишешь код системы тестов на нужном уровне. И проходишь стандартное ревью программистов.

Ты не проектировщик

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

Но твоим продуктом будут пользоваться люди. И отчасти ты - проектировщик.

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

Ты не аналитик

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

Но аналитики определяют, что мы должны создать. И отчасти ты - аналитик.

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

Ты не менеджер

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

Но ты работаешь в команде. Будь менеджером.

Чтоб стать хорошим работником ты поработал руководителем.
Ты не мудак.
На выходе ты даешь качество.
Ты сообщаешь о проблемах.
Ты выполняешь приказы.
И все записываешь.

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

Ты тестировщик

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

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

Ты профессионал

Ты качественно и быстро выполняешь свою работу и у тебя нет конфликтов с коллективом.
Ты качественно и быстро выполняешь свою работу и команда не работает за тебя.

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

Самый ценный ресурс тестировщика - доверие. Тебе доверяют.

Про то, откуда иду

Главпроектировщик, Сергей, с коллегами создал манифест о хорошем, правильном проектировщике. А про тестеров у нас в компании такого нет.
Короче, я тоже захотел. Но не осилил.

Кто такой - отличный тестировщик?

Кого я называю отличным?
В чью группу хочу попасть?
Кто работает лучше меня?
На кого равняюсь?
У кого хочу учиться?

В мире? Виттакер, Канер, Бах, Болтон. Почему? Они профессора, программисты, авторы книг, евангелисты. Я читал их книги и статьи.
В стране? Руколь, Назина, Баранцев, Александров, Мартыненко, Мериин, Нечаева, Высоцкий. Почему? Они известные тренеры и докладчики. Я был на тренингах и слушал доклады.
В Екатеринбурге? Юра Р., Женя А., Илья В., Ната С.. Почему? Они умеют работать, у нас были совместные проекты.

- Можно ли стать отличным, не интересуясь, как работают другие?
- Нет.

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

Так и записал. Что еще?
Не знаю.

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

Куда и откуда?
Прежде всего это история людей, с которыми работал.

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

Второй шаг - в Наумене удалось вместе работать с руководителем разработки SD, программистом А.Л..

Он тратил свое время на обучение и воспитание сотрудников.
Вместе с ним за пару лет прошли от "программисты пишут какой-то код без CI" до "релизим ежедневно с постоянно зеленых тестов". Первые в компании использовали скрам (по канону), перешли на git, ввели системное автоматизированное тестирование на всех уровнях, системное нагрузочное тестирование в CI.
Он садился и делал задачи вместе со мной.
Примером показывал, как использовать блокнот и хоткеи в IDE.
Показывал, как считает время и как складывает текстовые файлы у себя на компе.
Вникал в детали моих задач. После получаса совместной работы обычно оставалось ощущение "а почему я все это не сделал сам?".
Учил начинать с проблем, а не с решений.
Учил писать требования, контракты и письма.
Учил отличать полезную работу от бесполезной и признаваться, что делал бесполезную.

Третий шаг. В тот период я занялся переводом "lessons learned in software testing", книги, которая не столько о стандартах, техниках и методологиях, сколько о о ситуациях, в которые попал автор. Читая ее я чувствовал, что веду диалог с автором о том как жить и работать.
В ней есть понемногу обо всей жизни тестировщика. Попасть на работу, работать руками, что и зачем автоматизировать, на какие конференции ходить, какие подходы срабротали, какие нет. Как нанимать и как увольняться.
Иногда даже удавалось успешно применить какой-нибудь из 293 уроков.Рассылка о состоянии тестирования, посещение конференций, маркетинг своей деятельности и многое другое вышло со страниц этой книги.
Канеру в деле воспитания меня помогали Блэк, Виттакер, Криспин, Адизес и многие другие.

Следующий шаг и следующий человек - Ю.З., аналитик, менеджер разработки.

Она - все больше про то, как выражать свои мысли и отсекать все лишнее. Кстати, ни один спор с ней я не выиграл, как бы ни готовился и насколько бы ни был прав (а иногда был!).
А значит, надо готовиться лучше, формулировать четче и соображать быстрее.
Она говорила, что у специалиста должно быть основное умение. У аналитика - писать текст. Программист - писать код. Тестировщик - решай сам. Наверное, придумывать кейсы. Остальное можно отсечь и сосредоточиться на том, что действительно нужно.

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

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

- Что дальше?
- Не знаю. Наверное, опять ищу человека.

- Пост точно про тестирование?
- Нет. Про жизнь.

Творчество

Коллективное бессознательное коллег: