Гейзенбаг 2019

Было интересно.

Ирина Рубченко, Тинькофф — автоматизация отдела автоматизации

Инструмент для записи тест-кейсов на естественном языке с кликов тестировщика, генерация из этих тест-кейсов кода тестов. Начало — 20 тестов, цель — 1000. Отдел автоматизации не общается с тестерами и разрабами. Код тестов не хранят, генерят на лету с тестов. WAT. TestRail, и убивается версионирование.

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

Александр Воробей, Тинькофф — тестирование микрофронтенда

В начале дал неправильное определение микросервисам (микросервис = отдельный репозиторий, ага. конечно). Затем хорошо и по делу, полезно для инфраструктуры фронтенда, нужно послушать. Говорил слова JEST, Puppeteer, Storybook.

Артём Ерошенко, Qameta Software — визуализация покрытия

• 15 000 тестов — на 50% больше, чем в команде, с которой я буду сравнивать дальше.
• 97% стабильность — в 30-300 раз хуже
• 15 минут на прогон — в 10 раз лучше
• 800 потоков — в 100 раз лучше
• Тесты пишут все — аналогично

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

Дальше Артём рассказывал про покрытие API.

С помощью EMMA и Cobertura, или что там нынче актуально. API требует 100% покрытия. Затем патчат Swagger цветовой маркировкой: зелёный — метод покрыт, красный — не покрыт. Посчитали покрытие для каждого теста и в Swagger добавили ссылки на тест (вот этот метод покрыт вот этими тестами).

Норм, но:

• Для апи отлично.
• Для остального кода нет, так как лямбды.

Доклад — ок, дождаться библиотек и использовать.

Барух Садогурский — DevOps

К просмотру обязательно. Ценное: список практик, список литературы.

• Джин Ким — "Проект Феникс", "Руководство по DevOps", "Unicorn project" и "Accelerate"
• Марк Шварц — "War and Peace and IT"
• Дэвид Брэдфорд — "Influence without authority"

Этими четырьмя метриками можно померить любую команду:

• Time to market
• Частота релизов
• Частота факапов
• Время восстановления

Михаил Самарин — Полная прозрачность в компании

В очередной раз про самоуправление и бирюзовость.

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

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

Новогодние обещания

Читаю сейчас "Теорию игр" Диксита, раскрасил фото одной странички оттуда:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Неизбежно

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

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

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

Решение

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

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

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

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

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

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

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

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

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

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

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

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

Срок

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

Кто решает?

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

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

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

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

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

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

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

Позволю себе высказать мнение, как составлять резюме в дальнейшем.

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

А искать работу ты будешь по-другому.

За пять лет до начала поиска начинаешь искренне любить свою профессию, и ненавидеть выходные. И начинаешь ебошить как проклятый.

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

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

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

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

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

Жванецкий

Под катом полный текст от Рушаны, читайте.

Отчет по встрече сообщества, про ДАМП и перевод книги

Выложен. Там есть анкета, её можно заполнить.

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

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

Так победим.

Будущего пост

Около года назад группа тестеров контура встретились и создали некоторый текст на предмет "А какими будут тестирование и тестировщики компании через 3 года, в 2020?"

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

Если есть желание - присоединяйтесь в комментариях.

Итак,  тестирование в Екатеринбурге, 2021

Игроки

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

Не знаю, выживет ли Абак, но если да, то там человек до 25.

Компании, бизнес которых не разработка. МТС, ITM и всё такое.  В сумме много, но живущих очень по отдельности тестеров.
В них отдельной когортой банки - Тинькоф, Сбертех, Альфа, СКБ Лабс, кто там еще - от 10 до 30 тестировщиков в каждом, растут медленно. От предыдущей группы отличаются удвоенной зарплатой и наличиев автотестеров.

Разработка на иностранный аутсорс небольшими группами и общей мощностью от полусотни до сотни.

Обучение

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

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

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

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

Компании с меньшим, чем 20, количеством тестеров успешно наставничают и не понимают сути проблем больших братьев.

 

Стеки

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

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

Ява заменяется на котлин, но принципиально картину это не меняет.

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

Проекты

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

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

У людей из продуктовой будут перспективы роста выше "рабочий", качество на выходе и интерес к их мнению.

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

Квалификация

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

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

Переходы между компаниями

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

Собеседования

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

Команды

Вслед за продуктами, которые делятся на микросервисы, фронт и бэк, команды делятся так же. И тестеры вслед за ними. Максимальное количество тестеров в команде - 4, после - делятся.

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

Книги

Как и сейчас, те, кто читают, имеют +30% к зарплате, но помалкивают об этом.

Задачи

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

Тестировать их можно либо кодом, либо контрактами, останется и то и другое.

Фронт и бэк

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

Нефункциональное тестирование

Технари - отдельные статистически незначимые глыбы за космический прайс. 

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

Релизный цикл

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

Конференции

Мы так и не привезем SQA в екб.

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

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

Специфические навыки

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

Стартапы

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

Саентологи

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

Конец 

Я попытался описать близкое будущее, но получилась какая-то текущая реальность с украшениями. Ну, что есть.

О качестве ПО

Третьего дня приобрел роутер 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 часов!

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

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

Оказалось, он умеет не только включаться через блютус, но еще:

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

Хочу другой роутер.

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

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

Впечатление

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Мастхэв:

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

Остальное:

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

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

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

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

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

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

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


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

DUMP 2017

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

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

Почему лучшая?

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

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

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

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

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

• Тест-сессия для студентов
• Секция тестирования на Дампе
• Курсы по тестированию от Кати
• Курсы по тестированию от Ильи
• Гуру на Урале: Сергей Мартыненко, лекция для студентов (в разработке)
• Гуру на Урале: Сергей Мартыненко, лекция для сообщества тестировщиков (в разработке)
• Пятая городская сессия тестирования от Targem (в разработке)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Дамп 2016

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

- Все, это в последний раз, дальше максимум докладчиком.

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

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

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

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

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


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

И да, благодарности:
Лена Воронина. Летала, решала проблемы, искала вместо нас докладчиков, задавала правильные вопросы и давала мудрые советы. Все это с улыбкой. Где-то здесь несформулированные слова про искреннее внимание и соучастие.

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

Докладчики. Те, кто, собственно, и приближал перформанс к смыслу:
Андрей Малых
Евгений Сабиров
Андрей Усов
Кирилл Раткин
Анастасия Ронжина
Артём Аксёнов
Василий Никишин

Фотки. Раз:

Два:

Три:

Четыре:

Пять:

Шесть:

Сообщество тестировщиков в Екатеринбурге

Мы - Максим Захаров, Илья Вахрушев и Настя Ронжина - собираем сообщество тестировщиков.
Про это даже будет доклад на Дампе:http://dump-conf.ru/section/14/

Мы подняли сайт и уже собираем информацию по тестированию на урале: http://uraltester.ru/

Там же - будут события и анонсы оффлайн мероприятий.

Нам нужна твоя помощь. Ответь, пожалуйста, на несколько вопросов
http://goo.gl/forms/YIZw12eBn5

Если можешь - попроси знакомых тестировщиков тоже ответить.

Третья городская сессия тестирования

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

В этот раз я уже не был организатором, но довольствовался ролью консультанта.

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


Что запомнилось?

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

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

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

Что еще запомнилось? Диссонанс между ощущением времени организаторов и участников. К 15 часам (а стартовали мы в 11) нам уже стало казаться, что команды начинают скучать, да и багов регистрируется все меньше. Однако  сами участники говорили, что им мало и они готовы фигачить до поздней ночи.

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

Серьезней надо работать как с рекламой, так и с пост-пиаром. Но тут я не специалист.

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

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

И да, с гордостью назову имена победителей. Ими стали Ельцов Андрей и Рягин Юрий из команды Фивы, Ушакова Наталья и Рыбасова Ангелина из команды Спарта, Комиссарова Анастасия и Исаков Владислав из команды Микены.

Кстати, принимаются идеи на тематику названий команд.

Что будет потом?

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

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


Вот тут вконтактик, если что.

Ссылка на отчет по предыдущей.

Фотки. Раз:

 Два:

Три:

Четыре:

Пять:

Шесть:

Семь:

Ответов на вопросы пост

Ответ на вопросы, которые мне задают при встрече знакомые и не очень люди, рано или поздно, так или иначе.

Почему ты уволился из яндекса?

Обстоятельства сложились так, что я больше не смог работать на проекте Яндекс Мастер - проекте, с командой которого я работал с самого начала.
И я не смог придумать, как я могу помочь другим проектам в других городах.
А еще я не хочу переезжать в Питер.
А не работать - это вообще плохо. Хуже только - плохо работать.

Куда ты ушел?

Сейчас я работаю в СКБ-Контуре, проект EDI
Работаю тестировщиком, надеюсь, что у меня получится нанести проекту пользу.
И я уже вижу, что у местных тестеров есть чему поучиться.

Ты дурак?

Ага

Один день из будущего

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

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

Давайте посмотрим, сбылось ли? Я не все сюда выложил, но большую часть. Итак:


Подъем в 7.30
[Да.]
В 9:00 выезжаю на велике
[Да.]
В 9:30 на работе, почта, новости, чай.
Затем полчаса читаю внигу.
[Да, перевод]
С 10-11 - смотрю текущие задачи на день. Сегодня у меня 2 совещания, не больше, чем на два часа. Одно собеседование - сотрудника мы ищем вяло, на будущее.
[Вот с собеседованиями я погорячился, хех]
Я работаю на 2-3 проекта - из за неравномерности нагрузки. Со мной еще 3-4 тестировщика. Они неофициально считаются моей группой. Как вариант - моего влияния достаточно для организации. Мы своими силами сменяем друг друга на время отпусков. Может быть, ротируемся между проектами.
[Понтов то! У меня действительно несколько проектов, но помогала мне только Настя, сугубо по доброй воле и из-за своей замечательности]

У нас есть собственный, но согласованный проект сопутствующей автоматизации, не тупо регрессия, а что-нибудь интересное.
[Нету =(]

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

Как следствие утром я проверяю - как прошли тесты, чинят ли их программисты. Программисты самостоятельно умеют пользоваться тестами.
[Утром я смотрю на magic tester]

У меня есть экспериментальный подпроект - изучение и использование magic tester. Или что-нибудь из ручного тестирования. На час-другой в день.
[Дааааа!]

Соседние отделы знают, что есть тестировщики и  тоже хотят себе таких. Уже задумываются о приглашении нас к качестве экспертов. Но это еще не процесс, а мои мысли.
[Как то не особо рьяно. Даже скорее никак.]

Часам к 12 у нас короткий полумитинг - тестировищков.
[А ведь было, но забросили...]

До часу я или занимаюсь срочной работой или страдаю херней. В час тридцать мы идем обедать.
[Обед по расписанию, это да]

После обеда я сажусь за боевые задачи - таски на тестирование. Срочных особо нет, делаю по порядку.
[дык]

Часов до четырех. Там -совещание.
Потом - письма - прочесть, ответить, дополнить карту памяти.
[Ага]

Полчаса - час в день трачу на редактирование вики.
[Меньше, но вообще не забываю]

Ухожу в 7-8, не хотелось бы задерживаться допоздна.
[Выполнено]

Когда нибудь через пару недель у меня какой нибудь докладик и еще полчаса я трачу на его подготовку.
[Подготовка к дампу считается?]

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

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

Управление максимально визуализировано. Коммуникация голосом и прочими скайпами. Отсутствие необходимости в бюрократии объясняется высоким качеством кода.
[Ха. Ха. Ха. Все совсем по другому.]

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

Конец.

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

А сейчас - я буду стараться и через три месяца напишу еще одно письмо в будущее "мой день в edi через год"

Сегодняшнего дня пост

Лейтмотив:

Наступающего будущего пост

Я один слоупок, а вы все наверняка уже слышали о функциональности Хрома "Окей, гугл".

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

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

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

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

Ну и  еще одно замечание, гугл.
Сука - не мат.