пятница, 26 декабря 2014 г.

Итоги 2014

У меня сегодня последний рабочий день в 2014 году.

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

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

Семья - это главное.
1. Ура, мы переехали в новую квартиру. Теперь всем хватает места, тихо, тепло и уютно. Спасибо моему главному мотиватору-толкателю-пинателю-любителю - жене :)

2. Я добил отделку дома на даче. Растянулось на 3 сезона. Внутри еще есть чем заниматься, но глаз снаружи радуется :)
Это первая сторона. 2012 год. Начало.Теперь он весь такой
3. Старший сын поймал первого "шнурка"

4. Я поймал первую "съедобную" щуку (вся рыба была поцелована в лобик и отпущена)

5. После переезда младший пошел в новую школу. Аклиматизировался и радует успехами. Старший пока еще учится в ФМЛ 239. Тоже достижение (кто не в курсе, что это за школа - просто поверьте :) )

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

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

Собственно я
А я во всем выше описанном активно поучаствовал :)
Немного статистики: 
1 выступление на конференции. Мало.
45 постов в блоге. Спасибо тем, кто читает и оставляет свои комментарии. 
Аналитика Гугла говорит, что 18 тыс. просмотров.
10 прочитанных книг. Мало. Надо читать больше. Зато ревью стараюсь писать.

Всех с наступающим Новым 2015 Годом. 
Он наверняка будет непростым, но ведь трудности закаляют :)



пятница, 19 декабря 2014 г.

Новогодний IT talk#26. Питер

18 декабря прошел заключительный в этом году IT talk.
Тема была неожиданная, но мне показалась интересной и я не пожалел. DataArt переводит свою деятельность на новый уровень и, кроме традиционной для него заказной разработки, теперь предоставляет услуги IT-консалтинга. О новой для себя области Андрей и рассказывал.

Одним из самых интересных моментов был небольшой инсайд с некоторыми деталями реального кейза в виде бонуса. Для видеолюбителей (зрителей YouTube) эта часть была недоступна, поэтому личное присутствие оправдалось :)

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

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



Вообще DataArt-Питер молодцы. Встречи IT talk проводятся достаточно регулярно, тематика разносторонняя. Спасибо вам. Насколько мне известно, это единственное IT-мероприятие, которое в Питере проводится таким образом.

Хотя нет, есть еще встречи сообществ Piter United, которые сейчас тоже стали проводится гораздо чаще.

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

Всем удачи :)

PS Вчера на IT talk новогодняя лотерея выбрала меня и теперь у меня на столе вот такой вот IT-"букет" :)


PS2 Интересующимся темой консалтинга хочу порекомендовать книгу "Закон малинового варенья". В интернете можно найти много рецензий. Скоро и у меня будет обзор этой книги.

четверг, 18 декабря 2014 г.

Technology Radar - январь 2015

Прошло полгода с прошлого выпуска радара.

Что нового на этот раз?

Из того, что мне показалось интересным или затронуло:

Методы (Techniques), элементы процесса разработки ПО
Воздержаться от применения:
  • long lived branches (долго ведущиеся ветки кода без мержа)
  • Avoid microservice envy (тема популярная, но не стоит ее внедрять только ради этого)
  • programming in the CI/CD tool (все максимально должно быть в репозитории. У нас с этим, на мой взгляд, есть над чем поработать - увлекаемся PowerShell-ом в Jenkins-работах)
  • testing as a separate organization (о-ооо, это моя боль :))
  • velocity as productivity (попытка использовать скорость работы команды как оценку ее производительности, усугубляющаяся желанием делать из этой скорости цели)
Инструменты (Tools) разработки
Готово к использованию, но аккуратно:
  • Docker
  • Gitlab
Оба мы уже используем. Что радует.

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


пятница, 12 декабря 2014 г.

Бережливое производство в промышленности или Lean в реале

Попал тут по блату, Миша - спасибо, на забавное мероприятие: "II Российская научно-LeanProm»".
практическая конференция по промышленности и производству «

Хорошее такое расширение кругозора получилось. Многие аспекты того, как ложится эта теория на нашу работу (разработку ПО), прояснились.

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

Тут "напочитать" себе ссылок:

"Бережливое производство. Как избавиться от потерь и добиться процветания вашей компании"

Понятие OEE (забавная была дискуссия)

Концепция "социальной инженерии" А.К.Гастева (1924 год - русский lean?)

Самым интересным был доклад Анатолия Филипишина. Тут нашел интересный отзыв об одном из его семинаров.

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




понедельник, 8 декабря 2014 г.

Нужны ли тестировщики, если разработчики пишут тесты?

Ура, вопрос из зала после статьи о разработчиках и тестах:

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

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

Действительно, зачем нам нужен такой Петя? Такой Петя нам не нужен, потому что см.картинку.

Но нам очень нужны правильные тестировщики, хорошие . Мне такие попадались :)

Где их взять? Хороший вопрос, но пока похоже риторический...
Кроме капитанского "учить, искать" ничего на ум и не приходит.

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

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

Вопрос скорее надо ставить как "зачем нам нужны тестировщики?", чем их наличие может помочь в достижении поставленной цели и что они должны делать.


четверг, 4 декабря 2014 г.

Почему разработчики не тестируют свой код?

На недавно прошедшем IT Global Meetup Леша Федоров спросил (а может трольнул) меня: "А почему разработчики не тестируют свой код?".

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

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

"Мнение редакции" может не совпадать с мнением "ведущих" экспертов в области разработки ПО.

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

Причин на самом деле немного и все они тесно связаны:

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

2. Разработчик знает про тестирование, но ему не дают их писать - "много времени занимает"
Кому то может показаться это странным - но это тоже бывает. Такие товарищи подходят ко мне на конференциях, пишут вопросы в комментариях - "Я хочу делать все правильно, но мне не дают. Когда я пытаюсь что-то предлагать,  отвечают - Зачем тебе это надо? Нам некогда писать тесты." и тд. Я даже знаю, тссс, тестировщиков, которые такое говорят разработчику. Наверно за свой хлеб переживают? Часто, в этом случае, разработчики пишут тесты втихаря, но, по опыту, пользы от них (тестов) в этом случае немного.
Регулярно слышу мнение: "время разработчика стоит дороже времени тестировщика". БРЕД! (извинения за upper case) Понятно, что если говорить о квалификации большого количества тестировщиков, то стоимость их действительно ниже (на первый взгляд). Но если мы говорим о продукте, который надо поддерживать от 3 лет и выше, то итоговая стоимость неквалифицированной и продолжительной проверки каждого релиза + стоимости затраченного времени (а время деньги) будет многократно превышать стоимость правильно разработанных тестов (даже с учетом их поддержки). Кстати, тут неважно, как обзывается тот, кто эти тесты писал.

3. Разработчик знает про тестирование, но лично считает это потерей времени
"Я могу писать тесты, но тогда фича займет в 2 раза больше времени. Поэтому не буду писать" - говорит тот, кто никогда не писал и не пишет тесты. Знаете почему он неправ? Потому что на самом деле, очень часто, "с тестами" получается в 4 и больше раз времени! Особенно в начале. Но вопрос - какого времени? Что для этого разработчика (и его менеджера) понятие "Сделано"? Когда фича считается готовой к релизу? А вот тут как раз и надо посчитать это самое время и не забыть про тех.поддержку.
Вы спросите - а как же его менеджер? А никак. 
Иногда он считает разработчиков "голубой кровью" - пусть тестировщики смотрят. Тут солидарность с пунктом 2. 
Иногда он боится надавить и заставить писать с тестами - мой мегакодер (ключевое слово "кодер") обидится и уйдет. 
Иногда у него нет возможности (нет знаний) объяснить людям, зачем эти самые тесты нужны, что их "быстро без тестов" никому не нужно.

Итого: кто виноват? Правильно - менеджер!
Все описанное выше целиком и полностью лежит на совести руководителей (тех.лидов, менеджеров проекта и тп).

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

Что делать? Решать вопросы выше.

И да, на всякий случай, рекомендации:


Читать дальше: а если разработчики все же пишут тесты, нужны ли тестировщики?

вторник, 2 декабря 2014 г.

Как прошел 3й IT Global Meetup (Питер)

"To be or not to be" - Ты все еще одинок? Приходи в IT-сообщество.

28 ноября в Питере прошел 3-й IT Global Meetup
Черт возьми, у них это получилось! Это я про организаторов. Я был более пессимистичен, но они это сделали. За что им большое спасибо.

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

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

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

Можно было найти сообщество по интересу, настроению или просто пообщаться с друзьями в кулуарах. Места хватало всем (ну может некоторым было чуть тесновато). И все это с 17 до 22.45 - еще один рабочий день, да еще и в пятницу! Я этого не осилил, но фанаты были :)




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

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

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

Официальный отчет о мероприятии можно найти здесь.

Еще фото с мероприятия - можно оценить масштаб мероприятия.


(слева-направо) Владимир Лапардин, Миша Рыжиков, я


воскресенье, 23 ноября 2014 г.

Отзыв "Магия чисел" Артур Бенджамин и Майкл Шермер

Недавно в руки попала загадочная книга с привлекательным названием "Магия чисел. Моментальные вычисления в уме и другие математические фокусы".
Как оказалось по прочтению, чудес все же не бывает :) Все объясняется математическими формулами - просто не все их знают и быстрое вычисление начинает казаться магией.

Господа-товарищи, особенно те, у кого есть детишки - очень рекомендую эту книжку :)

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

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

Другое дело, что необходимость быстро считать в уме надо еще как то обосновать, при наличии в карманах различных гаджетов, делающих это быстро и не напрягаясь. Это сродни теме недавнего мини-сочинения в школе (уже у старшего) "Зачем нужно знать правила русского языка, если сейчас все проверки делаются компьютером". Я думаю, каждый должен ответить на эти вопросы сам.
А мы с мелким пока начинаем изучать способы быстрого сложения и вычитания.

Из маленьких недочетов книги могу вспомнить только ошибку в предисловии, где автор оного обозвал "10" цифрой и забыл про 0. Немного отлегло, когда увидел, что предисловие писал не автор книги. Но редакторам надо быть аккуратней.

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

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

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

среда, 12 ноября 2014 г.

Новости с Microsoft Visual Studio Connect. Visual Studio 2015. Visual Studio 2013 Update 4.

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



Питер, 3-й IT Global Meetup


Через 15 дней в Питере запланировано проведение интересного мероприятия: IT Global Meetup. Update: как все прошло.

Что это такое и для чего?

Говоря официальным языком:

"IT Global Meetup — это уникальное событие для опытных профессионалов и начинающих ИТ-специалистов, на котором собираются вместе участники ИТ-сообществ Санкт-Петербурга, знакомятся друг с другом, обмениваются знаниями и опытом.

IT Global Meetup проводится в рамках некоммерческой инициативы Piter United, целью которой является формирование благоприятной экосистемы для развития ИТ-сообществ Санкт-Петербурга."

А что будет на самом деле?

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

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

Будут программеры, тестировщики, UX-спецы, аналитики, технические писатели. Ну и куда уж без менеджеров :)

Предварительные программы сообществ (считай inside)

Тестировщики
"Основание отдела тестирования" Екатерина Гайнутдинова, Trans-IT
"Правила написания хороших тест-кейсов" Наташа Узенцова, Total Objects
"Как дружить с разработчиками" Юля Атлыгина, ALM Works
"VIQA - тестирование UI с помощью VI" Роман Иовлев

UX-спецы
"Техническое и дизайн-мышление: почувствуйте разницу", Захар Кириллов, Ольга Павлова, КБ "Собака Павлова"
"UX-тестирование в Яндексе", Ксения Артеменко, Яндекс
"Карты эмпатии", Никита Ефимов, IT Mine


Писатели
"Word: великий и ужасный", Алексей Агибалов, Рамакс Интернейшнл
"Промышленная разработка в DITA на основе единого источника"
"Инструменты создания Help"
"ГОСТ, ISO - пишем по стадартам"

Lisp
"Костыли и грабли. Метапрограммирование в мейнстримных языках(и лиспе)", Дмитрий Игнатьев, Artec
"Литературное программирование и Common Lisp", Михаил Глухов

IT Talk
"Нелёгкий путь культуры свободного кода", Кирилл Тимофеев, DataArt
"Ошибки молодого PM. 10 вещей, которые я сделал не так, получив свой первый проект", Евгений Ефимов, DataArt
"Sick Systems. Как работа уничтожает нас", Евгений Ефимов, DataArt

Agile Piter
"Предания старины глубокой или когда жесткие планы и нормы - это хорошо", Сергей Котлов, Happy Melly

Аналитики
"Неочевидные аспекты работы с user stories в agile", Дмитрий Петрашев, Dell
"Анализ документа: эвристический и с помощью разметки", Абрамова Анна, мастер-класс

Менеджеры
"Использование мотивационных факторов в работе с командой на основе работ С.Рисса", Евгений Крапивко, EPAM Systems
"Почему легко построить продажи в IT", Владимир Лапардин, А25
"Как выбирать проектные методологии и как от них отказываться" (кейсы, обсуждение), Иван Селиховкин, НИПК "Электрон"


Мероприятие бесплатное.

Регистрация обязательна и доступна на сайте проекта.

Присоединяйтесь.

Если есть желание помочь с организацией - you're welcome. Благодаря издательству "Манн, Иванов и Фербер" у нас есть полезные подарки волонтерам.


вторник, 28 октября 2014 г.

Отзыв "Первые 90 дней" Майкл Уоткинс

Эта книга долго пребывала в "хотелках". Ее рекомендовала Инна Кузнецова в своей книге "Вверх!".
Осилил (по-другому, к сожалению, не скажешь).

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

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

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

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

Напоследок небольшой, очень показательный отрывок:

"Проводя исследования для этой книги, я столкнулся с непостижимой загадкой. Почему так мало компаний готовят своих менеджеров к переходу на новые должности? Другими
словами, почему компании не видят преимуществ в ускорении процесса адаптации для всех? В среднестатистической компании примерно 25% менеджеров ежегодно вступают
в новые должности. Адаптационный период каждого из них оказывает влияние на многих других. Удивительно, что компании так мало заботятся об ускорении этого процесса. Некоторые компании (GE, например) специально занимаются обучением и подготовкой своих менеджеров к переходам на новые должности. Более распространенными являются программы «ассимиляции», которые знакомят пришедших «со стороны» со стратегией, бизнесом и культурой компании. Хотя такие программы полезны, они редко являются практическим руководством к управлению процессом успешного перехода. Большинство же компаний вообще не предоставляют никакой поддержки. Почему?

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

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

Собрание выступлений Макса Дорофеева (ссылка - чтобы потом не искать)

Макс любезно выложил ссылки на все свои слайдкасты.

И я вас уверяю, там есть что посмотреть.

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

IT-конференции в 2015, на которые я бы съездил

А зачем на конференции ездите вы?
Не хотел в этом году писать про конференции. Уже вроде как приелось, основные ежегодные конференции +/- не меняются, локальные заранее планировать не нужно, и тд, и тп.

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

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

1 квартал

PGCONF.RUSSIA 2015
6-7 февраля, Москва, Российская конференция разработчиков и пользователей PostgreSQL

SPM Conf-4 (отменена)
20-21 Февраля 2015, Москва

Конференция C++ Russia 
27-28 февраля 2015, Москва. По состоянию на 15 января 2015 - все билеты проданы :)

AgileDays 2015 
20–21 марта 2015, Москва
Отзыв Максима Цепкова
Стас Фомин начал выкладывать видео и писать их обзоры

Piter Py
20 марта, Санкт-Петербург, вторая Python-конференция на Неве.
Мой отчет после участия в конференции

2 квартал

ПрофсоUX
25 апреля, Санкт-Петербург. Конференция для UX-профи, а также менеджеров проектов и продуктов, аналитиков, тестировщиков, программистов.

Microsoft Ignite
May 4–8, 2015 Chicago, IL
Новая конференция Microsoft призванная заменить (или объединить) конференции типа TechEd и профильные тематические конференции (SharePoint Conference, Project Conference, Microsoft Exchange Conference, Lync Conference and Microsoft Management Summit)

DevCon 2015
20-21 мая, Москва (снова в Яхонтах)
Ежегодная конференция DevСon, посвященная разработке под платформу Microsoft, пройдет 20-21 мая 2015 года. Конференция ориентирована на профессионалов в области разработки ПО, специалистов по тестированию, архитекторов и руководителей групп разработки

Международная IT HR конференция «нАйТи ответ!»
29-30 мая, Санкт-Петербург

SQA Days #17
29-30 мая, Минск. Конференция по вопросам качества программного обеспечения.

3 квартал

PG Day'15 Russia
15-17 июля, Санкт-Петербург. Вторая официальная российская конференция, посвященная вопросам разработки и эксплуатации PostgreSQL, лучшей в мире реляционной базы данных с открытым исходным кодом.

Конференция C++ Siberia, 2015 
28 августа, Новосибирск. Вторая часть конференции C++ Russia


4 квартал

XP Days - 5 (юбилейный)
осень 2015, Киев (к сожалению визит туда маловероятен...). Интервью Коли Алименкова об этой конфе.


Регулярные и бесплатные мероприятия в Питере:
Новый проект от DataArt: IT NONSTOP. Проводится в разных городах с февраля по ноябрь 2015. Подробности здесь.

Интересный пост (не мой) про то как правильно слушать доклады :)

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

среда, 22 октября 2014 г.

Демо использования FitNesse+PowerSlim в CI системе на базе Jenkins

Сделал небольшое демо того, как у нас используется FitNesse+PowerSlim в CI на базе Jenkins.

Первые 20 мин рассказ про Fitnesse (в основном все есть в моих постах на эту тему)
Дальше описание нашего общего workflow: commit - build - unit tests - acceptance tests

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

четверг, 2 октября 2014 г.

Анонс Windows Server Preview (Windows Server 2016?) и подробности про изменения в Hyper-V

Появились некоторые детали об изменениях в новой версии Windows Server, касающиеся Hyper-V.

Upgrade
  • Виртуалки работавшие ранее на Windows Server 2012 R2 могут продолжать работать и на Windows Server Technical Preview (Windows Server 2016). При этом новые фичи (о которых ниже) не будут работать на виртуалках до их принудительного апгрейда. До апгрейда виртуалки можно вернуть обратно на Windows Server 2012 R2 и они там снова будут работать. Для обновления версии конфигурации машины используется Update-VmConfigurationVersion cmdlet. После апгрейда запустить эту машину на Windows Server 2012 R2 нельзя. Если сервера в кластере, то обновление возможно только после обновления конфигурации кластера (см. след. пункт).
  • Возможна совместная работа новой версии сервера и R2 в одном кластере. При этом новый функционал не будет работать до апгрейда конфигурации кластера и виртуальных машин. Для обновления конфигурации кластера используется Update-ClusterFunctionalLevel cmdlet. После этого в кластер нельзя добавить новые Windows Server 2012 R2 сервера.
Storage quality of service (QoS)
Теперь функционал службы QoS, который раньше использовался для контроля за качеством сетевых соединений можно использовать и контроля за нагрузкой на виртуальные диски лежащие на внешних хранилищах (Scale-Out File Server).

Конфигурация виртуальной машины
Формат хранения параметров конфигурации ВМ изменился. Теперь это бинарные файлы с расширением *.VMCX для конфигурации и *.VMRS для хранения параметров запущенной машины. Сделано это для повышения скорости чтения и записи, а также уменьшения рисков повреждения файла-хранилища. Прямое изменение этих файлов (мимо API) не поддерживается. Статья про то, как можно добраться до содержимого файла скриптом "Reading Windows Server 2016 Hyper-V Configuration Files".

Production checkpoints
Новая возможность сохранить состояние машины с использованием backup-технологий изнутри гостевой ОС. Считается, что это больше подходит для production-систем.
На Windows машинах для таких снимков используется Volume Snapshot Service. Linux машина делает снимок состояния своей файловой системы.
По умолчанию используется  production checkpoints, но при необходимости можно воспользоваться старой технологией сохранения checkpoints (снаружи машины).

Улучшения Hyper-V Manager
  • Возможность указать и сохранить для дальнейшего использования специфичных пользователя и пароля для каждого подключаемого сервера Hyper-V
  • Поддержка предыдущих версий Hyper-V: Windows Server 2012, Windows Server 2012 R2 и Windows 8.1
  • Измененный протокол управления - теперь используется WS-MAN протокол, который допускает использование CredSSP, Kerberos и NTLM аутентификации. Что это дало: возможность управления Live Migration без настроек делегации в Active Directory и упрощенная настройка межсетевых экранов, потому что WSMAN использует 80 порт (по умолчанию)
Integration Services (вспомогательные службы запускаемые на гостевых машинах) могут быть обновлены через систему Windows Update для Windows машин. vmguest.iso файл больше не используется для установки Integration Services.

"Горячее" добавление и удаление сетевых адаптеров, и памяти
Появилась возможность изменения памяти запущенной виртуальной машины без прерывания ее работы и добавления/удаления сетевых адаптеров. Работает только для ВМ созданным как generation 2.

Update: Чуть более подробно и с картинками :)
Update: Еще новости про Windows Server 2016
Update: Возможно чуть более подробное описание новых фичей
И еще про what's new
Видеокурс от Microsoft

Why are there two Hyper-V PowerShell modules in Windows 10?

Хорошо описана разница между Hyper-V контейнерами и Hyper-V ВМ

пятница, 26 сентября 2014 г.

Обзор-неконспект "Идеальная IT-компания. Как из гиков создать команду программистов"

По наводке Леши Пименова прочитал эту книжку.

Общее резюме (сразу в начале): книга ОБЯЗАТЕЛЬНА к прочтению менеджерами-новичками и теми, кто хочет ими стать.
Разработчикам-технарям тоже будет полезна (разработка - это командная работа) - надо выйти за рамки IDE и посмотреть на свою работу с другой стороны.

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

Мои заметки на полях (возможно сумбурно).

Разработка - командная работа. 
Строится на 3-х китах: Скромность, Уважение, Доверие.
Работа в команде без общения - нонсенс. Надо уметь правильно коммуницировать. Сихнронные vs Асинхронные коммуникации.

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

Про мотивацию
Описывается модель Пинка ("Драйв" - ждите моего отзыва, а пока вот обзор Леши и видео)

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

Про позиционирование команды в компании (искусство корпоративной манипуляции)
Тут замечены новые термины: "наступательная" и "оборонительная" работа команды.
"Наступательная" - работа по производству нового функционала
"Оборонительная" - работа по возврату технического долга и вспомогательные вещи.
Отличные метафоры - буду использовать.
Рекомендуемое соотношение: 1/3 от всего времени можно отводить на "оборону". Если больше - польза приносимая командой будет неочевидна.
Вспомнился этот твит:

(с) оригинал


Письмо начальнику: правило "3 пункта и призыв к действию". Отлично.

Ну и про отношение к пользователям вашего продукта. 
Не забывать про них! Важны эмоции. Паттерн "первая минута пользования"

Паттерны автоматизации тестирования

"Test Automation Patterns Wiki"

Просто ссылка.

Просто полезно. 

вторник, 23 сентября 2014 г.

Тестируем с помощью Fitnesse+PowerSlim. Часть 3. Advanced


Часть 1. Введение 
Часть 2. База 
Часть 3. Интересные возможности (эта статья)
Часть 4. Демо FitNesse + Jenkins
Часть 5. Пример трансформации PowerShell скрипта в тест

Прошло уже достаточно много времени с момента опубликования первых двух частей (часть 1, часть 2) про использование связки FitNesse+PowerSlim. Не скажу, чтобы статьи пользовались большой популярностью. Команда время от времени меня тролила и накручивала статистику блогу. Я вас обожаю :)

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

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


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

Давайте попробуем прикинуть набор тестов для проверки функционала нашего продукта, который контролирует возможность запуска виртуальной машины пользователем. Для старта машины пользователь должен выполнить несколько действий:
  • Аутентифицироваться на сервере авторизации и установить уровень сессии "Для служебного пользования"
  • Выполнить запуск виртуальной машины
С точки зрения теста мы должны: 
  • аутентифицировать пользователя, 
  • установить уровень сессии, 
  • попробовать запустить машину,
  • проверить - машина запустилась или нет (в зависимости от теста)
  • проверить, что факт попытки запуска и принятое решение (о разрешении или запрете) записаны в системе аудита
  • отключить пользователя от сервера авторизации
И этот набор действий надо выполнить во всех сочетаниях входных данных и результатов. Если к этому добавить еще и то, что кроме запуска мы должны контролировать все операции пользователя с виртуальной машиной (и не только с машиной, а вообще всей виртуальной инфраструктурой), то очевидно, что "аутентификация", "установка уровня сессии", "проверка аудита", "отключение пользователя" - хорошие кандидаты на превращение их в кубики, которые будут использованы во всех тестах.
Используя Scenario libraries в сюите можно добиться доступности сценариев во всех тестах сюиты без дополнительных действий.  
Наша иерархия "кубиков"
Есть другой способ переиспользования кода тестов: подключение страниц (include page). Это можно использовать например для возможности использования PowerShell функции написанной прямо внутри страницы (хотя тут же можно использовать и сценарий). PowerShell код по вызову Win32 API функции из kernel32.dll (страшная штука сама по себе) - отличный кандидат на такой "кубик".
Вообще PowerShell функции поддерживаются в PowerSlim и это еще один способ переиспользования кода в тестах.


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


Неочевидные преимущества PowerSlim:
1. Можно запустить несколько PowerSlim серверов на разных портах на одной машине. Зачем?
  • Надо иметь возможность обращаться и к 64, и к 32-битному PowerShell из теста.
  • Можно запустить несколько PowerSlim под разными Windows-пользователями на одной машине. При этом все действия на удаленной машине будут идти от "первого" лица - без наложенных преобразований, которые неизбежно возникают при использовании, например, PowerShell Remoting.
2. Так как это PowerShell и соответственно .Net, то у нас есть возможность, при желании, проверять функционирование UI с помощью уже готовых библиотек, например WhiteUI Automation PowerShell Extensions.

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

пример есть в PowerSlim сюите тестов ExampleS

4. Возможность запуска теста на нужном по сценарию количестве машин становится еще удобнее с фичей Symbols Sharing. Мы это используем в том случае, если прямо в тесте нам нужно создать виртуальную машину локально на сервере виртуализации, получить ее ID-идентификатор и использовать его при при проверке аудита на другом сервере.
пример есть в PowerSlim сюите тестов ExampleS
5. Правильно написанные тесты на FitNesse+PowerSlim дают возможность абстрагироваться от способа реализации фичи: тесту все равно какой способ аутентификации используется системой, какой транспорт используется для передачи служебной информации между компонентами тестируемой системы, какая база используется для хранения настроек, какой язык используется для написания продукт и так далее. В итоге автор тестов, большей частью, сконцентрирован на реализации проверки пользовательских сценариев. Тесты можно писать параллельно самому функционалу. Например, здесь все равно каким образом система контролирует свои файлы, тест просто удаляет файл настроек и проверяет реакцию


6. Это в свою очередь дает возможность писать тесты любому человеку знакомому с PowerShell. Это могут быть тестировщики, или сами разработчики (как у нас). Весь наш продукт написан на C++, иногда сложно переключаться между языками, но мозг тренирует. (Гусары, молчать :)

7. FitNesse+PowerSlim хорошо встраивается в Continuous Integration системы (TeamCity и Jenkins). Мы долгое время использовали готовый плагин к Jenkins (я пожалуй расскажу как-нибудь про нашу CI-систему). Но растущее количество запускаемых тестов, а также ряд проблем с этим плагином заставили нас написать свой "почти"-плагин, который закладывает результаты тестов и артефакты (логи) в базу и дает возможность быстро смотреть часть логов привязанную к конкретному тесту. Очень удобно.

Небольшое итого
на мой взгляд количество и качество существующих фреймворков, с помощью которых можно автоматически проверять функционал продуктов работающих на Windows-платформах, оставляет желать лучшего. Из бесплатных это, пожалуй, только Robot Framework (недавно появился неплохой guideline), FitNesse . Из известных мне платных: Visual Studio Test Professional.

К достоинству Robot Framework можно отнести его используемый язык программирования (Python, хотя есть расширения для IronPython и Jython) и, возможно, большая популярность, в сравнении с Fitnesse. Во всяком случае информации в интернете побольше будет.

Fitnesse+PowerSlim дает возможность использовать все, что есть в PowerShell - мощный инструментарий для настройки Windows, и так же сервисов Microsoft (Exchange, SharePoint, Hyper-V и тп). Для использования всего этого в Robot'e пришлось бы писать прослойки.
К недостаткам Fitnesse+PowerSlim можно отнести некоторую сложность внедрения (например, прекрасно автономно работающие PowerShell скрипты могут не работать внутри PowerSlim), неочевидность его преимуществ. Именно поэтому я решил написать эти статьи и добавить более жизненные примеры в сюиту примеров PowerSlim. Надеюсь, это поможет.

Visual Studio в редакции для тестировщиков я не рассматривал. Во-первых она платная и в нашу подписку не входит. Во-вторых, на момент внедрения автоматизации тестирования, функционал студии был достаточно слабый и в качестве платформы виртуализации использовался Hyper-V, что нам не подходит. Допускаю, что сейчас положение дел улучшилось. Но у open-source движков есть важное преимущество - их можно подтачивать под себя в случае необходимости. При этом базовые вещи уже реализованы.

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

Update: Записал screencast своей презентации на работе с демо того, что у нас получилось с Fitnesse и как он интегрируется в Jenkins

вторник, 16 сентября 2014 г.

Тест-сертификации команд разработчиков в Google

Краткое описание уровней Тест-сертификации команд разработчиков (из книги "Как тестируют в Google")

Уровень 1
  • Создать пакеты тестового покрытия.
  • Установить систему непрерывной сборки.
  • Ранжировать тесты на малые, средние и большие.
  • Определить недетерминированные тесты.
  • Создать набор смоук-тестов.

Уровень 2
  • Не выпускать, пока не пройдут все тесты.
  • Обязательно выполнять смоук-тесты до отправки кода.
  • Инкрементальное покрытие всеми тестами не меньше 50%.
  • Инкрементальное покрытие малыми тестами не меньше 10%.
  • Хотя бы одна фича покрыта интеграционным тестом.

Уровень 3
  • Создавать тесты для всех нетривиальных изменений
  • Общее покрытие малыми тестами не меньше 50%.
  • Важные новые фичи покрыты интеграционными тестами.

Уровень 4
  • Смоук-тесты запускаются автоматически перед отправкой нового кода.
  • Смоук-тесты проходят за время меньше 30 минут.
  • Нет недетерминированных тестов.
  • Общее тестовое покрытие не меньше 40%.
  • Тестовое покрытие только малыми тестами не меньше 25%.
  • Все важные фичи покрыты интеграционными тестами.

Уровень 5
  • Добавить тест к исправлению всех нетривиальных багов.
  • Активно использовать доступные средства анализа.
  • Общее тестовое покрытие не меньше 60%.
  • Тестовое покрытие только малыми тестами не меньше 40%.
Странно, что покрытие малыми тестами на уровне 4 уменьшается, а потом опять растет. У нас получается нечто среднее между 3, 4 и 5. На самом деле малых тестов у нас мало. А с остальным похоже все получше, что радует :)

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

Обзор-конспект "Как тестируют в Google"

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

Как тестируют в Google


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

Ниже будет много букв, кому побыстрее - могу рекомендовать глянуть этот пост, от Никиты Макарова (тезисы отдельно здесь).

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

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

Да, пока не забыл, огромное спасибо Алене Васюхиной, Юлии Нечаевой, которые перевели книгу.

Итак, поехали.

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

Тезисы:
"Качество ≠ Тестирование: перестаньте рассматривать разработку и тестирование по отдельности. Тестирование и разработка идут рука об руку...Тестирование не отдельная практика, это часть самого процесса разработки."

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

Виды тестов
  • В Google тесты различают по размеру того, что тестируется. И условно делятся три группы: малые (это, например, юнит-тесты), средние (например, тесты для проверки взаимодействия компонентов) , большие (это когда проверяются реальные пользовательские сценарии). 
  • Малые тесты направлены на проверку качества кода, а средние и большие - на проверку качества всего продукта.
  • На каждый вид тестов действует ограничение по времени выполнения и то, с чем они могут взаимодействовать. Тип теста должны быть обозначен в свойствах теста. От этого зависит поведение системы автоматического запуска тестов: максимальное время выполнение каждого типа отличается и система просто рубанет якобы "зависший" тест.
  • Рекомендуемое соотношение количества тестов разных типов: 70 - 20 -10% (малые-средние-большие). Малые всегда автоматизируются, средние и большие - it depends.

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

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

Еще интересно: "Часто забывается, что тестирование — это по сути проверка. Делает ли приложение то, что должно делать? Большая часть работы по тестированию сводится к планированию и выполнению проверок. Да, приложение может падать в процессе, но добиться сбоя — не цель тестировщика. Давить на программу, пока она не сломается, интересно, но куда интереснее давить на нее понемногу, снова и снова, имитируя ее реальную эксплуатацию пользователем. А как приятно убедиться в том, что она не сломается при таких условиях! Мы ищем именно такой позитивный взгляд на тестирование, когда проводим собеседование"

Интересно про оценку и повышение:
"Решения о повышении основываются на том, какое влияние специалист оказал на свой проект. Во время ежегодных отчетов менеджеров просят описать ценность вклада своих подчиненных и перечислить, на что это повлияло. Мы ожидаем, что при движении по карьерной лестнице сотрудник влияет на все большее количество вещей".
Используются ежеквартальные и годовые OKR (Objectives and Key Results) - список целей и оценка успеха в достижении этих целей. "Google уделяет большое внимание количественно измеряемым метрикам успеха. То есть достижение 70-процентного успеха означает, что вы поставили достаточно высокие цели и усердно работали для их достижения, а 100-процентный успех говорит о том, что вы были недостаточно амбициозны".

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

Есть в книге и про тест-план, как его делать, что он из себя должен представлять. В основе лежит ACC-анализ
Основные принципы ACC-анализа (Attribute Component Capability)
  • Избегайте повествования, пишите списки. 
  • Оставьте продажи в покое. Тест-план — это не маркетинговый документ.
  • Не лейте воду. 
  • Если какой-то пункт не важен и не требует действий, не включайте его в план.
  • Пишите «от общего к частному». Каждый раздел плана должен расширять предыдущий, чтобы у читателя оставалась общая картина проекта в голове, даже если он прекратил читать. 
  • Направляйте процесс мышления. Хороший процесс планирования помогает участнику тщательно продумать функциональность и потребности тестирования.
  • Итогом должны стать тест-кейсы. 

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

Про автоматизацию
  • Создавайте инфраструктуру, в которой писать тесты будет легко. Тесты должно быть проще написать, чем пропустить.
  • Примерно 20% всех сценариев использования отражают 80% самого использования. Автоматизируйте эти 20% и не беспокойтесь об остальных. Оставьте их для ручного тестирования.
Про метрики качества кода (например покрытие кода)
"Измеряйте все, что плохо лежит, но доверяйте людям. При этом все равно будьте реалистом: можно сколь угодно тщательно тестировать продукт внутри компании, но он все равно окажется в руках пользователя. Во внешней среде работают другие законы, вы не можете их ни предсказать, ни воспроизвести".

Про умирание кода
"При переводе проекта в режим сопровождения качества важно снизить зависимость от участия людей в поддержании качества. У кода есть интересное свойство: если оставить его без внимания, он черствеет и ломается сам по себе. Это верно и для кода продукта, и для кода тестов".

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

Кстати, неожиданный инсайт из другого источника, все что описано  работает в таких вот условиях: "one monolithic C++ codebase, 4000+ engineers working on it, 30,000 commits a day"- по материалам конференции CppCon 2014. Для меня это действительно показатель.

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

О книге "Когда я говорил... Об образовании, ИТ и не только"

(с) из статьи о книге
Очередная книжка популярного в последнее время у меня формата "сборник блог-статей":  "Когда я говорил... Об образовании, ИТ и не только" (дубликат на хабре)
Александр Краковецкий

Если смотреть по выставленным мною тегам к этому посту, то в книге рассмотрен широкий спектр вопросов. Да это и по оглавлению видно:
  • Нужно ли учиться в университете?
  • Кто хочет, тот ищет возможности, кто не хочет — ищет причины
  • Эффект бабочки
  • Дилеммы молодого преподавателя
  • Пишем кандидатскую работу
  • Немного слов об интеллектуальной собственности и здравом смысле
  • Возможности для студентов, о которых вы, возможно, не знали
  • О проблеме продвижения научных работ и исследований
  • Возвращаясь к теме высшего образования
  • Нужна ли аспирантура?
  • Философия науки, или Почему мы доверяем науке?
  • Как я учил английский
  • А ваши сотрудники продуктивные?
  • Правильно ли использовать сотрудников только по назначению?
  • Главные причины перехода в другую компанию
  • Когда я говорил…
  • Тренды, возведенные в культ
  • Как отпугнуть высококлассных специалистов. Руководство для компаний
  • Что нужно делать начинающему специалисту
  • Действительно ли нужны головоломки на собеседованиях?
  • Про вред молчания
  • Об идеальном коде и суровой реальности
  • Несколько слов о продуктивности
  • И еще немного мыслей на тему методологий управления проектами
  • Книги для тимлидов и руководителей проектов
  • О мотивации в ИТ
  • О конкурентных преимуществах, или Не заставляйте заказчика чувствовать себя идиотом
  • О журналистах, социальных сетях и здравом смысле
  • Собеседуем IT-специалистов: 8 рекомендаций работодателям
  • Где можно получить знания, которые пригодятся при устройстве на работу в IT-компанию
  • Где лучше работать: в сервисной или продуктовой компании?
  • Что мешает отечественным программистам повторить успех Цукерберга
  • Как организовать мероприятие
  • О бесплатных и платных конференциях
  • Я устал, я ухожу…
  • Почему ДОУ уже не тот…
  • ИТ-цирк уехал, клоуны остались

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

Читается легко и быстро. Рекомендуется большинству, начиная со студентов (must read) и заканчивая бодрыми динозавриками.

Update: но есть и другой, я бы так сказал, более критичный взгляд на эту книгу. Можно глянуть и его, чтобы не разочароваться :)