пятница, 29 декабря 2017 г.

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

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

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

 

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

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

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

 

Первая

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

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

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

 

Вторая

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

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

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

 

Выводы

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

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

четверг, 23 ноября 2017 г.

Еще про жизнь

Мотивы этой осени.

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

понедельник, 20 ноября 2017 г.

Про жизнь

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

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

В настолки стали играть редко. В первый раз проиграл в цивилизацию.

 Хотя вот эта конкретная - огонь!

У сообщества тестеров все хорошо. Скоро допереводим вторую книгу. В этот раз редактура будет вдумчивой.
В ритейле работа как кипела:

Так и продолжает:
Хотя обстановка не то, чтобы совсем напряженная:
И да. в этом году велосезон закрыл до весны. Чот накатило.

среда, 8 ноября 2017 г.

Задачки об тестирование

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

Вопросы в виде кейсов, с пояснениями. Вот такие кейсы выдал я:


КЕЙС: Сложная задача
На проверку пришла большая задача. Тестировщик заранее тщательно готовился к ней, поэтому за полдня нашел 18 ошибок верстки, три ошибки удобства использования, семь логических и три неверных толкования ТЗ.

Что делать дальше?
  1. завести дефекты юзабилити в трекер и назначить их на проектировщика, чтоб он мог принять решение по их исправлению, логические дефекты назначить на разработчика, чтоб тот мог их исправить, а неверные толкования ТЗ передать аналитику для разрешения неоднозначности.
  2. не заводить дефекты, громко выругаться, прекратить работу и пойти пить кофе.
  3. завести дефекты, собрать совещание, на него позвать проектировщика, аналитика и разработчика, на совещании заняться приоритезацией дефектов.

КЕЙС: Ночью в поле с конем
День разработчика. Восемь вечера, конец рабочего дня. Разработчик сделал завершающий коммит по задаче и с остальными программистами пошел в бар, отмечать. Менеджер, уходя, просит проверить эту задачу, чтоб в 4 часа ночи (пока нагрузка на сервера минимальна) служба дежурных инженеров выкатила задачу в бой. Задача содержит критическую функциональность, в которой не должно быть дефектов, поэтому на проверку задачи уйдет не меньше восьми часов. Времени впритык и менеджер просит протестировать ее прямо сейчас, завтра без этой задачи Контур уже начнет терпеть убытки в десятки миллионов рублей.

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


воскресенье, 29 октября 2017 г.

О качестве ПО

Третьего дня приобрел роутер Asus RT-AC51U, так как мой старый DIR-300 должен был умереть и умер.

Настройка, фигня-война, самба, USB-хранилище и вдруг не стартует закачки Download Master, который на самом деле transmission daemon.

Час плясок с бубном, обновление прошивки роутера, десяток перезагрузок,
установок-переустановок демона, изменение размера кеша, неудачные попытки зайти по ssh, удачная - по telnet.

И наконец решение:
Изменить максимальный размер буфера приема и передачи данных для всех соединений:
net.core.rmem_max
net.core.wmem_max
sysctl на роутере нет, так что идем и пишем:
echo 4048576 > /proc/sys/net/core/rmem_max
Тадам! Не прошло и 4 часов!

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

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

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

суббота, 21 октября 2017 г.

О делегировании

Пишет нам один знакомый:
Что делегировать-то? опыт? гибкость мозга? предприимчивость и шустрость? основательность в подходе? — хер что из этого делегируешь

понедельник, 9 октября 2017 г.

45 татуировок менеджера

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

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


Под катом - краткое содержание книги.

вторник, 3 октября 2017 г.

Мотивация

Какими должны быть сообщения в ленте внутренней социалки:

понедельник, 2 октября 2017 г.

Двустишия


 Честно честно, скоро буду постить всякое тестерское техномясо. А пока еще - на память.


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


Так, значит, я не зверь.

— Ты сам отверг закон людской и Божий!
Зверь, самый лютый, жалости не чужд.
— Я, леди, чужд. Так, значит, я не зверь.
— О, чудо — дьявол истину изрек!
 Ричард III (Уильям Шекспир)

воскресенье, 24 сентября 2017 г.

Пять пороков команды

Ленсиони "Пять пороков команды".

Третьего дня дочитал сабж. Неоднозначное чтиво.

пятница, 22 сентября 2017 г.

Вес бортового залпа

Вы знаете сколько я слышал разных идеологий? И все они были прекрасны и убедительны. Коммунизм, толерантность, демократия, равноправие, капитализм, свободный рынок.
А побеждает всегда почему-то информированность, точность прицела и вес бортового залпа.
Вроде бы из книги "Параллельные дневники Виталика Туманова".
https://bash.im/quote/405237

понедельник, 18 сентября 2017 г.

Двойная звезда

 Третьего дня дочитал Двойную звезду Хайнлайна.

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

Я ждал от Хайнлайна серьезного изменения, перерождения персонажа - как раз то, что он описал на последней странице книги.

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

Этого я в книге не нашел.

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

понедельник, 4 сентября 2017 г.

Концептуальное


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

 Чуть позже, уже в институте, я познакомился разом с целым рядом:
  • Юнона и Авось
  • Эльфийская рукопись
  • The Wall
И после института:
  • Орфей и Эвридика
  • Моцарт
Кстати, все перечисленное - к прослушиванию рекомендую.

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

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

А на прощание - цитата из Брига:
Сегодня тебе нравится Гендель. А завтра - ни хуя... Кого за это пиздить - Генделя? Не надо никого за это пиздить. Это, вроде как, отражение внутреннего твоего развития. Прогресс, регресс там или вообще деградация. И оттого перестает тебе нравится виртуоз Гендель. И глыба Толстой. И пронзительный Левитан. А начинает тебе нравится дурь Рахманинова, ехидство Достоевского и еблан Пиросманишвили. Это они в иерархиях своих - на разных полках, в разных купе и разной значимости. Это пидоры культуроведы им рейтинги раздают. А внутри у меня - они так вот и обитают... Либо нравятся. Либо нет. Потому и живут вместе группа "Ленинград" и Бетховен. Шекспир и Веничка Ерофеев. Леонардо Да Винчи и безвестный мудила с Красного проспекта, который нарисовал однажды мою ненаглядную так, что я и сейчас на этот портрет дрочу.

вторник, 8 августа 2017 г.

Mindware, Нисбетт.

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

К прочтению - рекомендую.

понедельник, 7 августа 2017 г.

Антибиблиотека через год

Год назад я писал пост про антибиблиотеку, о том, что я хочу прочесть, но еще не прочел. Итог:

Не прочел:

  • Разработка требований к программному обеспечению, Вигерс
  • More Agile Testing Lisa Crispin
  • The Human interface, Раскин
  • Системоинженерное мышление, Алиев
  • Дизайн привычных вещей Норман
  • Организация как система, Деминг
  • Рождение идеи, Боно
  • Эффективный управляющий Друкер
  • Найти идею, Альтшуллер
Прочел:
  • Джоэл о программировании, Спольски 
  • Психология влияния. Чалдини
  • Человеческий фактор, Демарко
  • Современный методы описания функциональных требований к системам, Коберн
Через пару недель составлю новую.

воскресенье, 30 июля 2017 г.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

четверг, 13 июля 2017 г.

Стенограффия отчет

Итоговый счет - 32 километра, трек.
Задача выполнена практически в полном объеме, пропущено по разным причинам всего пара объектов.

Фотки под катом

понедельник, 3 июля 2017 г.

Стоя на плечах гигантов, Эли М. Голдратт, 2008

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

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

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

А можно избавиться от 85% ерунды.

Стоя на плечах гигантов, Эли Голдратт.

Автор рассказывает о применимости и неприменимости бережливого производства и пути Toyota на примере Hitachi, а также о том, чем  являются и не являются Лин и Канбан.
Ну, мы все это знаем. Это когда мало складов, just in time и доска с карточками. Почему у нас не используется? Мы попробовали, нам не подходит, хотя часть практик мы взяли. Например, у нас есть доска. И нет складов, мы же в IT. И вообще некогда, у нас дедлайн, а это все бесполезные теории.

Что меня впечатлило больше всего

В 1926 году производственный цикл** от добычи железной руды до получения готового автомобиля** (состоящего более чем из 5000 деталей), находящегося на железнодорожной платформе и готового к отправке, достиг **81 часа**!

Нецензурно восхищается

О главном

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

Канбан - это не когда доска и карточки, это когда не больше одной задачи в работе и одной на складе.

Приоритеты

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

Оценка

Факты:
  • Оценка увеличивает время выполнения задачи
  • Оценка отдельной задачи врет

Нам важно знать, когда задача будет закончена и мы будем оценивать.

Ценность - время

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

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

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

К чему это все

Опыт - не образование. Здравый смысл - не знание.

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

Элияху гораздо более убедителен, чем я. Прочтите статью.

среда, 28 июня 2017 г.

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

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

Впечатление

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

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

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

Людвиг пользуется тремя эвристиками, помогающими преодолеть тупняки и совершить прорыв.
  • Контринтуитивное. Решить вопрос противоречащим интуиции способом. снимать носок за пятку. Есть сахар по утрам, чтоб не есть торты вечерами. Часто есть, чтоб похудеть. 
  • Ошибки мышления. Читать о ошибках мышления, находить их в себе и, осознавая, искоренять.
  • Получать системные знания. Когда знаешь, как все работает на самом деле.
После этого еще два этапа.
Первый - отработка техники. Второй - изменение мировоззрения.
IIПрограмма для ведения финансов YNAB.
Принципы:
Не контролировать и ограничивать, а помогать понять свои приоритеты и заранее положить в них деньги
  • тратить деньги из прошлого
  • непредвиденные статьи
  • понять сколько ты можешь не работать
IIIСхема планирования дня.
По большей части о книге: Марк Форстер, Do it tomorrow
Суть: 
  • сегодня делаешь только дела, которые ты запланировал вчера 
  • все новые сегодняшние откладываешь на завтра
  • ограничение на количество дел в день
  • по каждому пункту отвечаешь на вопрос - а почему я хочу это сделать

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

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

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

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

II. Как избавиться от сверхконтроля за подчиненными?
Давать больше возможностей. Дать планировать бюджет.
Давать право на ошибку.
Чаще проводить не финальное, а промежуточные демо.
Заказчикам на входе говорить, что будет плохо. И жить с этим.
Контроль заканчивается там, где человек сумеет поставить ограничение. Поэтому, если человек его не ставит, то начиная контролировать ты неизбежно зайдешь слишком далеко. Пример: позвони, разбуди.

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

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

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

понедельник, 26 июня 2017 г.

Статья Болтона "Проблемы тестирования – это результаты тестирования"

http://software-testing.ru/library/testing/general-testing/2562-testing-problems-are-test-results

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


Оригинал статьи: http://www.developsense.com/blog/2011/09/testing-problems-are-test-results/
Автор: Майкл Болтон (Michael Bolton)
Перевод: Ольга Алифанова

В курсе Rapid Software Testing я даю студентам такое упражнение: я прошу их перечислить все, что, с их точки зрения, усложняет или замедляет тестирование. Их ответы, как правило, однотипны – я регулярно слышу одни и те же вариации (пример таких ответов можно посмотреть, к примеру, в обсуждении на Stack Exchange). Обычно это примерно следующий перечень:
  • Я единственный тестировщик, и работаю с несколькими разработчиками (или один из тестировщиков, и в нашей команде много разработчиков).
  • Я очень сильно ограничен по времени. Постоянно приходят новые билды, и мы релизимся каждую неделю-две.
  • Продукт(ы), который я тестирую, очень сложен сам по себе.
  • Между модулями продукта (или между разными продуктами) множество взаимозависимостей.
  • Я вижу, что ряд проблем возникает именно из-за этих взаимозависимостей – небольшое изменение в одном модуле может повлечь за собой катастрофу в другом.
  • Я считаю, что для отлова подобных багов нужно прогонять полный регресс для каждого нового билда.
  • Я стараюсь справиться с задачей, используя автотесты, но сложность продукта затрудняет автоматизацию тестирования – "якоря" для автотестов минимальны или отсутствуют, а частые изменения продукта усложняют поддержку автоматизации.
  • На поддержку автотестов уходит приличное время, и я не успеваю заняться тестами, которые хотел бы прогнать.
  • Все это сильно выматывает, но я пытаюсь справляться.
И, в плюс к вышеперечисленному,
  • Компания, в которой я работаю, утверждает, что работает по Agile
  • Помимо двухнедельных итераций, на самом деле мы применяем максимум пару практик, относящихся к Agile-подходу – как правило, ежедневные scrum-встречи или канбан-доски.
И вишенка на торте:
  • Приходящие на тестирование билды очень нестабильны. Система падает при самых базовых smoke-тестах, и мне приходится ждать и/или пересобирать билд вместо того, чтобы заниматься своим прямым делом.
Как можно проанализировать эти наблюдения?
Мы можем расценивать их, как проблемы тестирования, но мы также можем взглянуть на них иначе – как на результаты тестирования.
Результаты тестирования не говорят нам, что что-то пошло хорошо или плохо. Они поставляют информацию для принятия решений, оценки, и тому подобных вещей. Люди, получающие результаты тестирования, решают, есть ли в продукте проблемы и в чем они заключаются, что еще надо выяснить, и какие решения принять. Это требует участия живых людей, оценки множества факторов, и нескольких возможных интерпретаций.
Так же, как и в случае с автотестами и другими результатами тестирования, очень важно принимать во внимание  весь спектр возможных причин и интерпретаций мета-результатов тестирования – наблюдений, касающихся тестирования. Если мы этого не делаем, то рискуем упустить важные проблемы, угрожающие качеству как тестирования, так и продукта как такового.
Джерри Вайнберг в своей книге "Perfect Software and other illusions about testing" отмечает, что то, что мы получаем в качестве результата – это прежде всего информация. Если тестирование, по словам Джерри – это сбор информации с целью ее передачи лицам, принимающим решения, то нельзя оставлять за бортом потенциально значимые наблюдения.
Тестируя, мы часто сталкиваемся с теми или иными проблемами. Однако вместо того, чтобы относиться к ним как к проблемам для тестирования, мы можем также думать о них, как о симптомах проблем продукта или проекта – проблем, которые тестирование может решить.
К примеру, если тестировщик страдает из-за большого количества разработчиков, или если тестировщику не хватает времени на тестирование – это результат теста. Зачастую это ощущение вызывается тем, что программисты генерируют столько сложных задач, что тестировщик просто не может справиться с ними в одиночку. Сложность, как и качество – это взаимоотношение между человеком и чем-либо еще. Сама по себе сложность необязательно будет проблемой, в отличие от реакции людей на нее. Наблюдая за тем, как люди реагируют на субъективную сложность и риски, мы можем узнать много полезного.
  • Помогаем ли мы, как тестировщики, коллегам иметь представление о рисках – особенно о "Черных лебедях" – которые обычно ассоциируются со сложностью?
  • Если люди представляют себе риски, обращают ли они на них внимание? Паникуют ли они, или просто игнорируют в надежде, что все образуется? Или что-то другое?
  • Реагируют ли люди спокойно и прагматично? Признают ли они сложность продукта, пытаются ли с ней справляться?
  • Если сложность продукта или процесса нельзя снизить, предпринимается ли что-то для того, чтобы сделать продукт/процесс проще для понимания?
  • Случается ли, что программисты пишут или изменяют код так быстро, что у них просто нет времени разобраться, что же там на самом деле происходит?
  • Если кто-то полагает, что команде нужно больше тестировщиков, почему он так думает? (Я обсуждал этот вопрос несколько лет назад)
Как же найти ответы на эти вопросы? Один из способов – внимательно посмотреть на результаты и мета-результаты тестирования:
  • Считает ли кто-то в команде, что тестирование затруднено или занимает много времени? Кто?
  • Почему он так думает, какие предположения привели его к этой мысли?
  • Не ухудшается ли тестовое покрытие от того, что тестировщики тратят много времени на исследование, локализацию и оформление багов? (Я писал об этой проблеме ранее).
  • Выявляет ли тестирование единообразные паттерны отказов?
  • Систематически ли эти отказы и их паттерны удивляют программистов?
  • Вызывают ли небольшие изменения кода большие или трудноуловимые проблемы?
  • Хорошо ли программисты понимают внутренние взаимосвязи продукта? Необходимы ли продукту эти взаимосвязи, или их можно избежать?
  • Предпринимают ли разработчики какие-то шаги для предотвращения или предупреждения проблем, связанных с интерфейсами и взаимодействиями?
  • Если автоматические проверки трудно разработать и поддерживать, говорит ли эта ситуация об уровне профессиональных навыков тестировщиков, качестве интерфейсов автоматизации, или масштабе проверок? Или она сигнализирует о чем-то еще?
  • Мешают ли нестабильные билды глубокому тестированию?
  • Можно ли интерпретировать нестабильные билды как знак того, что в продукте настолько много серьезных проблем, что их можно найти даже при поверхностном тестировании?
  • Если после череды нестабильных билдов наконец-то появился стабильный – насколько он на самом деле стабилен?
Возможно, получив ответы на эти вопросы, мы можем задать еще больше вопросов.
  • Как эти проблемы угрожают успеху продукта в краткосрочном и долгосрочном периодах?
  • Если тестирование систематически выявляет паттерны отказов и сопутствующих рисков, что делает команда с этой информацией?
  • Обязаны ли программисты только и исключительно предоставить код, или они обязаны предоставить код с гарантией, что этот код делает то, что должен (и не делает того, что не должен), насколько им известно? Насколько искренне программистам предпочтителен второй вариант?
  • Заставляет ли кто-то программистов выдерживать сроки/объемы работ, в которые они на самом деле не могут уложиться?
  • Могут ли программисты и тестировщики противостоять навязанным им срокам и объемам работы, если эти сроки повышают продуктовые или проектные риски?
  • Прислушивается ли бизнес к опасениям команды? Знают ли они о рисках, найденных тестировщиками и разработчиками? Когда команда разработки указывает на существующие риски, предпринимает ли менеджмент/бизнес адекватные шаги в ответ на это?
  • Работает ли команда в комфортном режиме, или продукт/проект серьезно задавлен сложностью, внутренними взаимосвязями, хрупкостью и трудностями, находящимися за пределами возможностей разработки/тестирования справиться с ними?
  • Действительно ли команда работает по Agile, соблюдая манифест Agile? Может, "гибкость" используется как карго-культ – практики и артефакты только маскируют бестолковость проекта?
Тестировщики зачастую считают, что их задача – искать, исследовать и сообщать о багах в тестируемом ПО. Обычно это так и есть, но такой взгляд на тестирование крайне ограничен. Продукт – это все, что кем-то произведено: программа, требования, диаграмма, спецификация, график, прототип, процесс, идея… Тестирование может искать информацию о любых продуктах, если им уделяется достаточное внимание.
С одной стороны, проблемы, перечисленные в начале этой статьи, выглядят серьезными проблемами тестирования. Возможно, это так, но это не все, что за ними стоит. Если вспомнить определение Джерри Вайнберга – "тестирование – это сбор информации для передачи ее людям, принимающим решения", окажется, что абсолютно все, что мы обнаруживаем и замечаем в процессе тестирования – это результат тестирования.

пятница, 23 июня 2017 г.

О проектах

- Не знал, что вы умеете жонглировать, сэр, - прошептал, обращаясь к лорду Витинари, Колон.
- А ты разве этого не умеешь, сержант?
- Никак нет, сэр!
- Странно. Вряд ли это можно назвать умением. Известно, где объекты находятся. Куда они направляются, тоже известно. Остается лишь позволить им занять правильное положение во времени и пространстве.
- У вас чертовски хорошо это получается, сэр. Часто тренируетесь?
- Сегодня первый раз попробовал. - Лорд Витинари спокойно взглянул на Колона, чье лицо выражало удивление и недоверие. - После Анк-Морпорка, сержант, летающие дыни - это цветочки, можешь мне поверить.
Пратчетт, "Патриот" 

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

Кстати, определение:
  • Проект – это временное предприятие, предназначенное для создания уникальных продуктов, услуг или результатов (PMBoK)
  • Проект — предприятие (предпринятие) с определёнными датами начала и завершения, предпринятое для создания продукта или услуги (сервиса) в соответствии с заданными ресурсами и требованиями (ISO/IEC/IEEE 15288:2008).
  • Проект — предприятие с предопределёнными целями, масштабом и длительностью (ISO/IEC 2382-20:1990).
  • Проект – это последовательность взаимосвязанных событий, которые происходят в течение установленного ограниченного периода времени и направлены на достижение неповторимого, но в то же время определенного результата (Фил Бэгьюли).
Есть мнение, особенно ценны люди, умеющие превращать проекты в процессы, это, кстати, определение таланта, или гения, не помню.

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

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

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


Стихи

Оксана Мельникова:
Забывают лица, слова и даты,
Но живёт веками один сюжет:
Не забыть того, кто тебя когда-то
Так и не сумел полюбить в ответ.


Олег Ладыженский
Разбиты стекла в нашем витраже
И не помогут жалобные речи.
Пора учиться тверже быть и резче,
Пора учиться говорить: -- До встречи!
И знать, что мы не встретимся уже.



четверг, 22 июня 2017 г.

Imagine Dragons Evolve

Черт возьми, офигенно.


Особенно:
Whatever It Takes
Believer
Yesterday
Thunder

вторник, 13 июня 2017 г.

Встреча сообщества, новые проекты и всякое

2 июня прошла встреча UTC - про подведение итогов, раздачу слонов и новые горизонты.

О самой встрече
Самая многочисленная.
Неудавшаяся, но все же состоявшаяся экскурсия по яндексу.
Раздача книг
Миллионы стикеров и позитив.
Лично для меня встреча закончилась на плотинке в 5 часов утра следующего дня.

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

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

А ведь у нас уже есть заготовки пары тест-сессий, ролевой игры и выезд.
Будет интересно.


DUMP-2107
Доклад на дампе, который я делал с Леной и Иларией:

вторник, 6 июня 2017 г.

Гейзенбаг

Третьего дня просмотрел трансляцию конференции Гейзенбаг.

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

Особенно хотелось бы отметить доклад Николая Алименкова Паттерны проектирования в автоматизации тестирования.

В докладе Николай пройдётся по всем известным паттернам и подробно опишет их с несколькими практическими примерами.
Рекомендую просмотреть.
Основную и самую ценную мысль Николай сказал в самом начале. Своими словами:
Вы не сможете купить и внедрить инструмент автоматизации, фреймворк, CI, автотествы. Вы обязаны купить и внедрить принципиально иной подход и отношение к разработке.

пятница, 2 июня 2017 г.

Нет времени

- Почему ты не читаешь книги?
- Я очень хочу, но не хватает времени.

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

- Почему ты закроешь этот техдолг?
- Менеджер не выделяет времени.

- Эта полугодовая цель не сдвинулась с места, отчего?
- У нас были срочные задачи.

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

вторник, 30 мая 2017 г.

Майская прогулка 2017



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

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

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

Те, кто привык к прогулкам - были нимало удивлены. Остальные отдохнули так, как любят.
Фото.
1.
2.
3.
3.
4.
5.
6.


Больше фото.

вторник, 2 мая 2017 г.

GTD, прокрастинация, личная эффективность и книги

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

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

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

Прочтите обе. Хуже не будет. А вдруг - поможет?

понедельник, 17 апреля 2017 г.

DUMP 2017

Дамп 2017 - особенная для меня конференция.

Лучшая и последняя (в которой я был организатором секции тестирования).

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

Почему последняя?

  •  Дамп перестает быть городской конференцией. Уже меньше четверти докладов от местных рассказчиков. Это неизбежное развитие, но в качестве СНГшной конференции для тестеров лучше SQA Days.
  • Не могу сформулировать точно, но есть ощущение, что из Дампа ушла разработка. Мобилки, тестирование, дизайн остались. И менеджмент. И девопс. А разработки нет.
  • Я выбираю определенные доклады, даю конкретные советы. И сделаю секцию именно такой. Не лучше, не хуже. А секции нужно меняться. Теперь ваша очередь делать тестирование на Дампе.
  • Не стало бесплатного бухла.

P.S. Доклады хороши. Но сильно зацепил один -  "Профессиональное выгорание" от Орлова Александра.

воскресенье, 16 апреля 2017 г.

30


Поздравление от сообщества:

И Наумен передает привет:
Шикарно.

Отчет по дампу, рефлексия о подготовке и всякое такое с фотками - позже.

четверг, 6 апреля 2017 г.

Язык шаблонов. Города. Здания. Строительство

Авторы книги:
Кристофер Александер, Сара Исикава, Мюррей Силверстайн.

Как выглядит:
Хорошее описание есть на сайте Артемия Лебедева.
Небольшая цитата оттуда:
«Язык шаблонов» — одна из самых значимых книг XX века, которая до сих пор не издавалась на русском, хотя оказала сильнейшее влияние на развитие дизайна, проектирования, архитектуры и компьютерных наук, в том числе объектно-ориентированного программирования.

Источник: https://www.artlebedev.ru/izdal/yazyk-shablonov/
«Язык шаблонов» — одна из самых значимых книг XX века, которая до сих пор не издавалась на русском, хотя оказала сильнейшее влияние на развитие дизайна, проектирования, архитектуры и компьютерных наук.
 Пересказывать содержимое не не буду, хоть и хотелось бы, лучше купите книгу. опишу эмоции.

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

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

Дальше - картинки.

суббота, 1 апреля 2017 г.

Вторая часть эксперимента Да́ннинга — Крю́гера

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


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

понедельник, 27 марта 2017 г.

Лекция Сергея Мартыненко

Спасибо Насте Ронжиной и проекту Контура "Гуру на Урале".

Тервер на службе менеджера:

ROI от автоматизации тестирования:


Следующий тренер - через год.

воскресенье, 26 марта 2017 г.

Бремя белого человека

 Оставлю здесь себе на память.

пятница, 17 марта 2017 г.

Вслух

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

- Квентин, а вам не кажется, что вы так и не сняли ничего лучше "Криминального чтива"?
- А кто снял?

воскресенье, 26 февраля 2017 г.

Прекрасное, из Вайнберга

Книга - огонь. Из 14 главы.
 Несмотря на то, что не существует «природы программного обеспечения», существует природа некоторых плохо управляемых проектов разработки – с характеристиками как в следующей последовательности, которые приводят к спешке в конце:
  1. Менеджеры не видят разницы между тестированием, локализацией и отладкой.
  2. Из-за того, что они не видят разницы, они верят, что тестирование было причиной большей части неприятностей, которые они испытали в проектах.
  3. Из-за того, что они верили, что тестирование было причиной проблем, они имели склонность откладывать все формы тестирования настолько, насколько могли.
  4. Из-за того, что они выбрали процессы, откладывающие тестирование, тестируя в первый раз они не могли притворяться, что все идет хорошо.
  5. Или, может быть, если проект плохо управляем...
  6. Из-за того, что они выбрали процессы, откладывающие тестирование, они страдают от информационного иммунитета и могут делать вид, что дела идут хорошо, даже после того, как они провели некоторые тесты.
  7. Из-за того, что они страдают от информационного иммунитета, на ранних стадиях проекта кажется, что все будет идти "гладко" до завершения.
  8. Из-за того, что менеджеры зашли в тупик, баги, многие из которых уже дремали в продукте со времен самых ранних требований, обнаруживаются при позднем тестировании.
  9. Поскольку вся система теперь собрана воедино, многие из этих ошибок трудно локализовать, тем более, что разработчики не могут помочь, так как в настоящее время они бегают, как обезглавленные куры, пытающиеся справиться с внезапным избытком багов.
  10. Так как разработчики, работающие под давлением дедлайнов, делают новые ошибки при попытке исправить недавно найденные, страсти накаляются, разум немеет,  крепнут прогулы, встречи размножаются и стратегия ведет к неприятным последствиям.
  11. Поэтому участники заключают, что «у нас не было никаких проблем, пока мы не приступили к тестированию. Мы шли точно по графику. Тестирование испортило все."
Обремененные этим выводом, менеджеры начинают планировать следующий проект - очередную паническую катастрофу.

И да. Перевод - идет.

среда, 15 февраля 2017 г.

События этой весны в тестировании Екатеринбурга

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

вторник, 14 февраля 2017 г.

среда, 1 февраля 2017 г.

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

Ты "свет фар" своего проекта. (с)
Сэм Канер.
Про то, откуда иду, я уже писал. Теперь про то, куда.

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

 

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

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

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

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

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

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


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

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


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

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


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

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

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


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

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

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

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

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

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

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



четверг, 19 января 2017 г.

Одержимость

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

Финальная сцена, если лень, смотрите с 8:35
https://youtu.be/Tkh5I9w4ySY?t=8m35s

Видео полностью:

О ком этот фильм? О учителе или ученике?
Чья победа ярче в финальной сцене? Победа учителя или ученика?

Я уже больше сопереживаю учителю.
И да. Методы обучения - на отлично. Только так.

пятница, 6 января 2017 г.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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