пятница, 31 мая 2013 г.

Рубрика "ПочитайQA". Полезные ссылки за май-2013

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

QA - Quality Assurance, обеспечение качества  во всей красе со всего мира. Наиболее заинтересовавшие меня статьи по профильной теме за месяц. Самая многоссылочная часть.
STU - Studying, образование и самообразование, обучение.
GA - Gamification, или геймификация тестирования, обучения, управления - всех составляющих Qastugama.
MA - MAke your life, MAnagement and leadership, MAny other - "сборный раздел". То, что не относится к предыдущим трем темам, но то, чем я хотел бы с вами поделиться.

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

Quality Assurance.


Studying.


Gamification.


Many other.



Бонус. Books.



Приятного чтения! И с наступающим летом!

пятница, 24 мая 2013 г.

Обзор 2. Игорь Любин "Тестирование по жесткой схеме или 27 + 2 фишки в построении процесса тестирования"

Продолжить серию постов-обзоров я хочу конспектом доклада Игоря Любина "Тестирование по жесткой схеме или 27 + 2 фишки в построении процесса тестирования", прошедшего в Минске на SQA Days-12. Рекомендую к просмотру.

Почему я выбрал именно его? Есть несколько причин.

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

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

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

Видео доклада:


Презентация доклада:



Все 29 фишек от автора:
  1. Тестирование начинается с прихода в компанию. Вопросы на интервью. Определяем, что мы хотим, как будем измерять, как будем достигать, какой результат мы получим и к какому времени.
  2. Горячие точки. Поговорить с ключевыми участниками, составить список горячих точек. 3 цели на месяц. Далее – 3 цели на след месяц.
  3. Фишкинг - процесс сбора всех полезных практик, идей, мыслей, «фишек», которые использовали с успехом для себя другие команды по тестированию, и которые могли бы применяться и у вас. Пообщаться с командой, собирать идеи.
  4. SMART-анализ целей (горячие точки, фишки). Выписать цели, выбрать цели на месяц.
  5. Добиться прозрачности. TOP-5 задач на неделю. Таблица: Задача, исполнитель, срок, комментарий. Тестирования. Выписать в понедельник 5 топ-задач, вычеркивать их по мере выполнения, отслеживать прогресс.
  6. Устроить День Золотого Духа. Влиться в проект и стать джуниором на 1 день и увидеть те проблемы, которые существуют у вас на проекте.
  7. Собрать Feedback. Взять обработку отзывов от пользователей в свои руки. Получить от пользователей, что им действительно важно.
  8. Разделение обязанностей. Мотивация: выявить, кто на проекте чем интересуется, и предложить тестировщикам задачи по специализации.
  9. Методика «Функциональные карты». Сделать тест-анализ по модели Объект-Действие-Параметр-Значение (ОДПЗ). Выявить основной функционал, приоритезировать, оценить покрытие.
  10. Особенности платформы. Усилить покрытие. Провести анализ особенностей платформы.
  11. Чит-листы (не чек-листы)- набор готовых проверок, их масса в сети, не надо придумывать самим.
  12. http://sitechko.ru - много готовых чит-листов. 
  13. Понятие критического бага. Необходимо составить критерии, согласовать. Желательно разобраться с критикал-багом за день.
  14. Критерии выпуска версии. Получить критерии от всех участников: разработчиков, тестировщиков, дизайнеров и т.д. Согласовать с директорами. Процесс тестирования на выпуске.
  15. Build Verification Test. Составляем, прогоняем регулярно, проверяем только Critical.
  16. Волны тестирования. Соорганизоваться, продумать итерации тестирования.
  17. Стратегия тестирования. Сделать маленький компактный документ на одну страницу.
  18. Шаблон баг-репорта. Взять в свои руки и сделать. Обучить всех пользоваться.
  19. Анти “Протестируйте”. Организовать процесс передачи версии в тестирование. Антипаттерн: разработчик собирает билд, пишет "протестируйте" - тестировщик день нечто делал, пишет “протестировано” - получается "выпущено", пользователь собирает баги. Нужны новости версии и понимание, что трогали.
  20. Ежедневные статус-репорты о тестировании. А еженедельно - сообщать о наших успехах.
  21. Post-mortem. Ретроспектива после выпуска версии - провести анализ, выявить сильные и слабые стороны.
  22. Минутки встреч. Записывать ключевые моменты на каждой встрече, разослать всем участникам и другим заинтересованным.
  23. Полчаса на автоматизацию. Выделять каждый день. Пусть одному человеку из команды. В день получаем один тест, за месяц  - уже 20.
  24. Все в Teamcity (Jenkins или другой аналог). Организовать запуск всех автотестов на регулярной основе.
  25. Инженерные практики. Быть QA. Поговорить с разработчиками о качестве, об используемых практиках.
  26. Roadmap тестирования. Выписать даты выпуска версий, нарисовать большую карту, отмечать с помощью стикеров, где мы сейчас находимся.
  27. Трындеть. Никогда не кушать в одиночку. Ежедневно общаться с разными коллегами.
  28. Сплотить команду. Поддерживать ритуалы в команде.
  29. Начинаем рабочий день. Никогда с утра не открывайте почту! Первый час - для разумного планирования и общения.

вторник, 21 мая 2013 г.

Chief Confet&QA - 2013. Spring.

C 13 по 15 мая прошла онлайн-конференция для тестировщиков - ConfeT&QA. Каждый день было представлено три доклада по 20 минут + 15 минут на вопросы. Секция Chief - для тест-менеджеров и тест-лидов.
Несмотря на кажущуюся простоту и легкость формата, у Конфетки, как и любой девушки, есть свои изюминки. Формат блиц - докладов не даст заскучать, и не все настолько очевидно, как может сразу показаться. 

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

Во-вторых, попробуйте сами выступить: чем меньше времени у вас на выступление, тем сложнее выбрать самое главное и подобрать нужные слова.

Вильсона как-то спросили, сколько времени ему требуется, чтобы подготовить слова. Он ответил: «Это зависит от многого. Если я буду говорить 10 минут, мне нужна неделя для подготовки. Если 15 минут, 3 дня. Если полчаса, то два дня. Если час, то я готов прямо сейчас.

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

А теперь о выступлениях.

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

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

Кстати, бонус от Тани - тест на выявление у себя стадии СПВ. Но, опять, и это не главное в докладе :) Ищите именно ту активность, которая вас "зажигает" и мотивирует. 

Продолжил Павел Новик, "Ретроспектива в QA". Превью к докладу замечательное, сам доклад, мое мнение, немного не структурированный, для конспектирования тяжеловат: тема-то очень конкретная, поэтому ожидаешь последовательности. Но ответил на вопросы Павел хорошо, практический опыт чувствуется. И за книжку отдельное спасибо, бесплатный бонус к докладу - "Agile Retrospectives: Making good teams great" - http://bit.ly/agileretro . В общем, читаем книжку, а если будет нужен совет - обращайтесь к Павлу.

Завершила первый день Елена Саламаха из Luxoft, "Концепция построения процесса тестирования в Agile проектах: 3+1". Великолепный доклад! Опыт Елены чувствуется, профессиональный спикер, авторские слайды, все по полочкам, без излишних пауз и затягиваний. Мой фаворит конференции и видео, которое must see.
В начале - очень кратко про 4 принципа Agile и про его влияние на процесс QA.
3 концепции тестирования в Agile:

  • предотвращение (тестировщики принимают участие во всех митингах, приемочные критерии и тесты разрабатываются в сотрудничестве с BA и заказчиком). Инструменты: статический анализ кода, парное программирование, код-ревью.
  • автоматизация (разработчики - модульное тестирование, TDD, интеграционное тестирование; тестировщики - функциональное (авто)тестирование, приемочное тестирование). Все тесты запускаются на сервере непрерывной интеграции.
  • гибкость (пересматриваем, тестируем и меняем подходы; применяем внедрения поэтапно, в соответствии с приоритетами);
  • BONUS-концепт - здравый смысл (начните пользоваться сейчас)


Второй день. Беспроигрышный вариант: первый докладчик - энерджайзер-мотиватор Андрей Мясников "Что нам стоит дом построить". Андрей очень доступно разложил процесс построения команды по 11-12 тезисам. Что-то покажется знакомым и известным, но респект докладчику за то, что собрал все пункты вместе и в довольно простой и доступной форме изложил. Интересно было сопоставить чек-лист Андрея со своим выступлением на SQA Days о росте команд.

  • Узнайте, что от вас хотят (пример, "представьте карандаш")
  • Уточните тайминг (due date)
  • В каком состоянии находится проект?
  • Какими ресурсами вы располагаете (треугольник качества и его деформации)
  • Узнайте, сколько ресурсов вы можете стянуть на себя "на пике"
  • подружитесь с HR
  • планируйте и не грузитесь (ненужными мелочами)
  • предоставьте планы руководству
  • оборудуйте рабочее место + использование инструментов
  • поднимайте багтрекер и хранилище тестов
  • WORK!
За Андреем - Игорь Шаринский, "Подбор и адаптация тестировщиков". Информация по подбору и адаптации именно с позиции QA, не HRа. Что-то спорно (например, непрофильные специальности как минус-фактор негодуют), но в целом, есть очень полезные полезные замечания и идеи от докладчика:

  • QA - "бесполое" (= важен склад ума) существо. Вспомнил про гендер от Сергея Атрощенкова
  • 3 этапа отбора: представление требований HR'у (никаких прямых контактов на первом этапе), отбор по резюме, очное собеседование (не ходить одному - субъективно, не с кем обсудить. Желательно берем куратора. Нужен план собеседования)
  • Испытательный срок и адаптация:
  • "синдром первой недели"
  • сажать рядом с куратором, новичками
  • задачи на +1 день вперед (у новичка должны быть всегда)
  • окончание испытательного срока: слово новичку, цели на полгода, клятва QA.

Следом - Галина Ковтонюк, "Виды Review. Их роль в работе тестировщика". Хороший доклад про:

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

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

За Натальей - Анастасия Мусина, "«Тестировщики не винтики!» или «Не закручивайте гайки!»". Практический доклад с отличными слайдами йоги. Понравилось то, что тема структурирована, у автора хороший менеджерский опыт и success stories. Возможно, некоторые кейсы показались несложными и решения тривиальными, но, мне кажется, это потому что так рассказал докладчик :) Не склонен думать, что ошибок не было, и обычно "налет идеальности" доклада и автора следует разбавлять рассказом о собственных промахах и неудачах. Но заслуги очевидны, проекту пять лет, и он развивается. Поэтому, у Анастасии - только о том, что сработало.
Описанные проблемы и предложенных решений:

  • тест-менеджера не хватает на все задачи. Решение - "1 задача - 1 гуру"
  • распределение задач. Решения - выбираем задачи сами, доска, чаты на проектах (удобно включать-выключать систему оповещений)
  • выпускаются бажные обновления. Решение - вики-статус "Тестирование завершено".
  • вглубь или вширь изучать продукт. Решение - выделяем гуру, количество гуру - в зависимости от объема и текущей активности проекта.
  • "Море работы, горы работы". Решение - исследование месяца, тестерские посиделки
  • Личная жизнь VS работа. Решение - отмечаем планы. "дежурный по палате".
  • Распределение отпусков, чтобы работа не встала ("Народ поуходил в отпуска, а тут еще больничные" - в яблочко). Решение - календарь отпусков.

И завершила третий день и весеннюю менеджерскую конфетку Юлия Абрамова, "Учимся тест-менеджменту у шахматистов". Серьезный блиц-доклад с дебютом-миттельшпилем-эндшпилем. О параллелях игры в шахматы и тестирования. Без углубления в детали и излишних мелочей (можно привязывать шахматные термины к тестированию, но ... 20 минут, надо выделить самое главное). Достаточно ровный, идея интересная: вспомнился доклад Ивана Селиховкина "Чему хороший ПМ может научиться у врача".

Много сладкого вредно, но это не про Конфетку :) Поэтому, если есть возможность - подключайтесь и смотрите. Скоро уже и авто-конфетка. Есть время уже попробовать применить то, что прозвучало на Chief ConfeT&QA.

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

SQA Days-13 в Санкт-Петербурге. День второй.

Продолжение. Начало - SQA Days-13 в Санкт-Петербурге. День первый.

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

Самое "тяжелое" время для доклада - начало второго дня. Первым докладчиком в секции А был Роман Шейко"Как можно построить идеальную команду". Доклад хорошо структурирован, все логично, последовательно, но ... слишком правильно и положительно. Само название "идеальная команда" провоцировала на острые вопросы. Субъективно, Роман очень волновался и часто использовал фразу "мне кажется". Доклад получился методологической инструкцией. Правда, отмечу идею с выходом на одну минуту за слайд презентации, чтобы позволить слушателям поразмыслить над заданным аудитории вопросом. Плюс, в конце инструкции были реальные кейсы, но, на мой взгляд, довольные стандартные и очевидные.

Снова секция А, доклад Сергея Вербенко "Каждый тест-менеджер должен посадить дерево или как искать баги в процессе". Сергей уже не первый раз выступал на конференции, мне запомнился его доклад в записи SQA Days 11 про регрессионное тестирование методом свободного поиска.
Итак, наша задача - найти баги (кто-то сомневался?). Инструментарий:
пять "почему" - выявляем корень проблемы, задавая 5 раз один и тот же вопрос, на 5й ответ обычно получаем суть проблемы
рыбья кость Исикавы - диаграмма корневых причин
дерево текущей реальности - диаграмма, где наглядно показаны причинно-следственные взаимосвязи, существующие между корневой (ключевой) проблемой и большинством нежелательных явлений.
ДТР связано с теорией ограничений и с парадоксом, что если сделать работу каждого подразделения максимально эффективной, то это приведет ... к банкротству. Поэтому путь к непрерывному улучшению лежит через ограничения.
Ограничения могут быть физические и организационные. Согласно теории ограничений:
- QA - ограничение
- ограничение - уникальный (и/или) дорогой ресурс
- если ресурс не ограничение, то должен быть резерв в мощности.
Пять шагов теории ограничений:
В докладе Сергей рассматривал только ДТР, которые отвечают на 1-й вопрос "Что менять?".
На второй вопрос "На что менять?" отвечает диаграмма разрешения конфликтов и дерево будущей реальности, а на третий вопрос "Как изменить?" - дерево переходов.
Далее, применительно к IT-отрасли, Сергей показал, как можно построить ДТР: для поиска конфликтов ("грозовых туч) и через последствия приходим к нежелательным явлениям, или наоборот, от нежелательных явлений - к конфликтам. Программно построить дерево у автора не получилось (Visio, плагин для вики, софт для деревьев). Успешное построение - на доске с листочками (опыт докладчика) и софт Flying Logic (опыт коллег докладчика).  И плюс примеры деревьев от докладчика в презентации.
Доклад из категории тех, что на практике сам сразу не применишь, окончательно сформулированной идеи для тестирования нет, сам докладчик еще, имхо, в процессе улучшения построения деревьев. Но идея есть, сформулирована, и есть первые результаты, которые можно попробовать получить и слушателям данного доклада.

За Сергеем Вербенко в секции А выступал Александр Яковлев с докладом-демонстрацией возможностей Microsoft Test Manager 2012 и ее интеграции с TFS 2012 - "Инструментарий ручного и автоматического тестирования интерфейсов". Доклад в первую очередь, интересен дотнетчикам и тем, кто работает с линейкой Microsoft Visual Studio и отслеживает прогресс продукта. Александр показал возможности TM2012: работа с требованиями, тест-кейсами, багами, запись видео для багов, генерация тест-кейсов из багов при исследовательском тестировании, генерация и хранение автотестов - и все это в рамках одной TM2012. Для тех, кто работает с продуктами Microsoft, - рекомендуется в качестве user guide'а по продукту.

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

Продолжаем в С, Павел Смирнов "Простые инструменты для сохранения внимания на тестировании". Как меньше концентрироваться на второстепенных задачах и разгрузить мозг для главных - Павел предложил довольно простые инструменты с позиции Middle QA Engineer в небольшом проекте. Доклад очень логичный и последовательный, дебют получился. Почин есть, желаю Павлу совершенствоваться и развиваться в тестировании. Этот доклад можно рекомендовать новичкам, добавляю его в список рекомендуемых докладов для Junior'ов.
  • Как же бороться с отвлеканиями: либо экономить внимание, либо его запасать. 
  • Делегируем часть внимания скриптам (базы, тестовое окружение)
  • Поддержка и настройка окружения - автоматизируем активность
  • Пример запасания внимания - шаблонизация. В частности, шаблон баг-репорта
После обеда был мой доклад в секции С. Жаль, конечно, что мой доклад совпал с выступлением Никиты Налютина "Математика для тестировщиков", на который я очень хотел попасть еще до того, как была сформирована окончательная сетка. Но не судьба, буду ждать записи. Впоследствии доклад Никиты получил много положительных отзывов в твиттере и занял первое место на голосовании. Но что поделаешь, у докладчиков на конференции есть свои минусы :)

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


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


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

После доклада я остался в секции С, но "собирал" мысли после своего доклада, поэтому некоторые выступления прошли мимо. Оживил меня доклад Максима Кузьмича из Гомеля про JIRA с добавками для тестировщиков. Максим выступает уже 3-й раз на конференции, и каждый раз находит что-то интересное, новое и полезное в функционале этой багтрекинговой системы. Если вы работаете с Джира, советую найти все записи докладов по ней с прошлых конференций. 
В этот раз список улучшений довольно прост (или просто тех, кто уже давно работает с Джирой, сложно удивить чем-то новым), но актуален:
- настройка Workflow и задач для тестирования
- создание новых полей (например, Тестировщик, Шаги воспроизведения, ожидаемый результат и т.д.)
- настройка и апгрейд системы уведомлений
- валидация и сохранение (required fields)
- фильтры и подписка на них
- интеграция
- плагины (Atlassian Bonfire, BugDigger, Zephyr, Misc Workflow Extensions, User Pickers)

Идем в секцию B, еще один доклад Алексея Яковлева про "Возможности модульного тестирования в среде Visual Studio 2012". В твиттере для тех, кто не был на докладе, Юрий Солдаткин скинул ссылку на msdn'овскую статью - http://msdn.microsoft.com/ru-ru/library/hh549175.aspx (можете поискать по хэштегу #sqadays за 27 апреля).

И закрывала докладную программу конференции гуру тестирования Наталья Руколь с рассказом про Тестирование Юзабилити. Отличный доклад про математические законы в юзабилити, которые реально работают, хоть мы об этом не знаем :)
К сожалению, я успел только на числовые подходы (законы GOMS'а, Фиттса, Хика) - поезд ждал меня на вокзале. Было очень сложно заставить себя уйти с середины очень интересного доклада. Но что же, буду ждать и его в записи. А пока - можно почитать конспект Максима Цепкова именно про выступление Натальи, и не только - http://softwarepeople.ru/blog/2013/04/30/sqadays-13/


Вот и сказке конец, а кто был там - молодец :) Большое, просто огромное, спасибо организаторам конференции, программному комитету и докладчикам! Так держать, и до новых встреч на SQA Days!

четверг, 16 мая 2013 г.

SQA Days-13 в Санкт-Петербурге. День первый.

Вот и очередная SQA Days-13, на этот раз в Санкт-Петербурге, завершилась. Как-то быстро привыкаешь к хорошему, а что может быть лучше двух дней непрерывного обучения, общения с коллегами, множества творческих идей и мыслей? Уже второй раз я был на этом празднике QA, и снова с докладом. Вопрос, ехать или не ехать в третий - закрыт, ищем возможности. И еще, такое ощущение, что после конференции легче написать еще один доклад, чем снова задумываться об этом непосредственно перед подачей заявок - столько новых идей, точек зрения, обсуждений, не соберешь ни на одном форуме. А для реализации некоторых идей нужно время, равное времени до следующей конференции :)

Обо всем по порядку. По организации, на мой взгляд, эта конференция лучшая из тех, которые я видел сам или в записях докладов, роликов, обзорах блогов. Огромная гостиница "Прибалтийская" с тремя отлично оснащенными залами. Люстра в аудитории А - объект съемок №1 всех посетителей :)
На этот раз было всего 2 потока секционных (по 40 или 80 минут) вместо 3х в предыдущие годы, и один поток блиц-докладов по 20 минут (на этот раз блицу отвели полноценную аудиторию, и, надо сказать, много блиц-докладов собирали сопоставимую с секционными аудиториями, так что ставка себя оправдала). Блиц - вообще интересная идея. Кто-то идет с докладом, чтобы "выжать" самое главное, кто-то - потому что тема небольшая и на доклад секционный "не тянет". Но главное - динамика, за 20 минут, без лишней раскачки нужно заинтересовать и изложить тему. Субъективно, после 20-минутки как докладчик устал не меньше, чем после 40-минутного секционного выступления на прошлой конференции. И еще: сколько ни дай места для зрителей на блице, все равно будет мало :)

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

Сравнивать, были ли доклады лучше чем на прошлой конференции, на мой взгляд, не имеет смысла. Потока 3, можно не угадать с выбором, да и по интересующей тебя тематике могут быть доклады лучше, а по другим, на которых ты не был, - хуже. Или наоборот. Это все равно, что сравнивать Пеле и Марадону - гениев футбола разных эпох. Можно лишь говорить о трендах.
Кстати, отличный обзор о трендах тринадцатой SQA Days (и не только) можно почитать у Максима Цепкова - http://softwarepeople.ru/blog/2013/04/30/sqadays-13/

Начинаем с секции А, доклад Ильи Кацова про Jagger. Проблема - протестировать высоконагруженный портал. Традиционная схема "Отчет <- Программа для тестирования производительности -> Система под нагрузкой" не работает. Определяемся, как НЕ нужно делать (антипаттерны):
- приемочное тестирование производительности (проблемы обнаруживаются слишком поздно);
- независимость функционального и тестирования производительности
- мало информации о результатах тестирования
- недостаточная интроспекция тестируемой системы;
- отказоустойчивость тестируется на продакшн-сервере
Далее Илья рассказал про построенную в компании систему, которая затем выросла в отдельный проект. Используем квадрат окружений: продакшн, разработка, нагрузка, тестирование. Определяем ответственностей ролей на этом квадрате. Схему самого Jagger'a можно посмотреть здесь - https://jagger.griddynamics.net/resources/jagger-2013-business_v_1.1.3.pptx, слайд 12. В целом, интересная схема, тул бесплатный, каждый может попробовать Jagger у себя  на проекте - https://jagger.griddynamics.net

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

Вы - менеджер, надо поставить задачу. Группа разношерстная, "человек - личность многогранная". Из всего многообразия Сергей выбирает для доклада один аспект, гендер - социальный пол, определяющий поведение человека в обществе (социальный не всегда эквивалентно реальному):
  • мужская (маскулиная) культура. Престижная должность, высокий статус, видение в "крупном масштабе"...
  • женская (феминная). важен личный рост и самосовершенствование, открытые отношения внутри, внимание к деталям и мелочам…
Если мы берем критерий постановки задачи SMART, то в соответствии с гендером, надо по-разному ставить задачи гендерам. Например, по Specific - пример от автора:
маскулиная - написать тесты для функционального тестирования модуля А
феминная - покрыть функциональными тестами модуль А.
Остальные примеры для МАРТ - на домашнее задание, лучшие ученики будут премированы. Сергей лишь поделился общими идеями. Отличный инструмент, довольно простой и понятный, из категории "можно сразу применять".

Продолжаем в секции С. Андрей Мясников, зажигавший на предыдущей SQA - 12 докладом про принципы юзабилити (слайд с Боярским и Моисеевыми - в избранное), на этот раз "зажигал" буквально, работая с огоньком. И снова Андрей в призах на конференции, 2-е место. Если поступательное движение сохранится, победитель следующей конференции SQA Days - 14 известен заранее :)

Рабочий день, работать лень.... Отпросился сегодня, не пошел на работу и завтра, нашел причину. И начал анализировать.
- Задачи бывают 4 типов - одноразовые, итерационные, внезапные и "волшебные". У каждого свой избранный тип задач - нужно определить свой тип, который вам подходит.
- Добавьте элемент игры (о, да, геймификация рулит, давно уже пора написать пост об этом...)
- на работе - работа, 8 часов отдыха от личных дел.
- пока кто-то ищет работу мечты всю жизнь, можно назначить работу любимой.
Профилактика:
- выгуляйте лень
- найдите общие хобби с коллегами
- раскрутите начальство на билет на SQA Days
Отдельный респект Андрею за ответы на вопросы. Вспоминаю SQA Days-12 в Минске, последний доклад первого дня Мясников+Руколь и "шестой последний вопрос". Думаете, это было все? Еще человек 10 после доклада в кулуарах спрашивали и спрашивали, а Андрей и Наташа терпеливо и обстоятельно на вопросы отвечали.

Следом - секция А, мастер-класс Алексея Кривицкого Перестаньте спрашивать «КОГДА?». Но не все то мастер-класс, что заявлено в программе :) Очень живые слайды, много задач, настоящий аджайл в действии. Если вы не были на скрам-аджайл докладах - рекомендую, минимум один раз сходить стоит. Если у вас есть конкретные вопросы или если вы хотите поучиться у опытных спикеров - тоже. В остальном - у вас всегда есть выбор из трех потоков :)
- стандартные примеры ошибки в оценках (аэропорт в Денвере, Оперный театр в Сиднее)
- порочный круг нереалистичных оценок и IT-рабство
- ошибки в восприятии, задачи "с подвохом"
- "заяц и черепаха" в восприятии: интуиция и логика. Заяц хорош в быстрых вычислениях, черепаха - в сложных.
- задержки накапливаются, ранние завершения - теряются
- намного проще опоздать, чем успеть
- выход: создать срочность, никогда не оценивать в одиночку, оценивать размерами, замерять скорость, вычислять оставшееся время.

Вторая часть дня прошла в кулуарах, общении с коллегами, обмене опытом, я пожертвовал докладами реальному общению. Полностью удалось посетить лишь большой доклад Евгения Чигиринского "Методология и практический опыт тестирования быстродействия приложений, сервисов и сайтов с высокой нагрузкой с помощью Visual Studio 2012"
Очень хороший доклад на реальных практических примерах. Мне запомнились два: добавили фичу - получили 100% загрузки CPU. Начали искать - раскрутка стека, Garbage Collector. Второе - метрики оценки производительности на клиенте (TTFB, TTFR, TAFR, TTO, TTLB).  Если вам интересна тема производительности - к докладу много полезных ссылок, поставил себе в ToRead лист.

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

Продолжение - SQA Days-13 в Санкт-Петербурге. День второй

фотографии:
- Сергей Ревко
- Интернациональный клуб тестировщиков: группа в ФБ http://www.facebook.com/media/set/?set=oa.462769597135875&type=1


четверг, 11 апреля 2013 г.

Образование будущего - как учиться, чтобы научиться

В 2007-м году я получил 2 образования (математик-программист БГУ ФПМИ и математик-экономист ИБМТ БГУ) почти одновременно. Больше всего мне тогда не хотелось - это вновь садиться за учебники, конспекты... Наверное, как и многие из вас я задумался, что действующая система обучения мне не нравится, а своей системы на тот момент я предложить себе не мог.

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

Сейчас давайте поговорим именно об инструментах образования: вы уже решили, что ВАМ нужно что-то менять, теперь давайте подумаем, ЧТО вам нужно поменять.

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

Юрий выделил 8 пунктов своей системы образования будущего и предложил посчитать, сколько твердых "да" вы наберете. Ответ "нет" или "немного есть такое" - напоминание вам, в чем вам следует развиваться.
Много "нет" - ничего страшного, Apple'у и Co. уборщики тоже нужны:)
У меня получилось 4 твердых "да", а у вас?

1. Соревновательные системы - участвуете ли вы в такой системе (желательно зарубежной), входите ли в ТОП-100 специалистов в своей области.

2. Опубликованное портфолио, сервисы

3. "Быстрые проекты" - бывало ли такое, что к вам пришла идея, и вы за сутки реализовали идею, или за первые 7 дней с момента идеи получили первую прибыль?

4. Менторы (практики, лучшие в мире) - должен быть человек-лидер, который вам доступен минимум 1 раз в месяц для беседы.  Ментор занимается не преподаванием, а именно зарабатывает практикой.

5. Пример для подражания (Юрий назвал Элона Маска как пример для бизнесмена) - таких людей нужно знать, если вы стремитесь к совершенству в этой области, и учиться у них.

6. Видеолекции. Тест - смотрели ли вы видео длительностью более 15 минут (промо-ролики и отрывки из бесед не считаются) с лидером (из пункта 5). Второй тест - смотрели ли вы в последний месяц минимум 3 образовательных видео на английском).
Примеры - http://www.charlierose.com - вдумчивые и глубокие интервью с известными людьми.
Образовательные порталы для онлайн-образования - http://www.coursera.orghttp://www.udacity.com

7. Путешествия - для расширения сознания это необходимо. Европа не считается :) Контрольный вопрос: вы были в Нью-Йорке, в Шанхае (в Китае)?

8. Спорт - влияет на креативные идеи.

суббота, 30 марта 2013 г.

Встреча минского QA Club. Риск-менеджмент, или кто не пьет шампанского.

23го марта состоялась очередная встреча минского QA Club'а. За 2 недели до встречи участники получили анкеты, в которых могли оставить все волнующие их вопросы касательно темы - "Управление рисками" от Елены Асташкевич.

Так как я был первый раз на встрече клуба, поэтому сразу расскажу про специфику и плюсы клубных встреч.
  •  выбирается одна тема на 2-3 часа, разбирается довольно подробно и обстоятельно. Это не обзорный доклад на конференции на 20-40 минут, где ты ухватываешь идею + пару тезисов. Подходит и для тех, кто "не в теме", и для более опытных и готовых поделиться.
  • каждый желающий может во время доклада задавать вопросы по теме и комментировать. Таким образом, доклад обогащается взглядом и опытом другого участника. Так как тема большая, это еще и возможность "передышки" докладчику - довольно сложно рассказывать непрерывно 2 часа :)
  • докладчик имеет большой практический опыт в теме, которую он рассказывает. Не все спикеры на конференциях именно практики.
  • после доклада все участники могут принять участие в обсуждении темы. Так называемый "круглый стол", обмен мнениями. Имхо. В отличие от конференций, более ровный состав "клубовцев", и дискуссия получается довольно интересной.
Встреча получилась интересной и продуктивной, за что большое спасибо организатору и руководителю QA Club'a в Минске Наташе Савастюк, Лене Асташкевич - как докладчику, за интересный, подробный доклад и за практические советы из собственного опыта, а также остальным участникам за живую дискуссию, и особенно наиболее активным - Сергею, Антону, Екатерине. Очень рекомендую встречи клуба, обязательно по возможности и сам постараюсь бывать.

А чуть ниже - конспект встречи.

Риски неизбежны (c), и особенно следует отметить риски на fixed-price проектах.

"Основная проблема разработки ПО - это риск." Кент Бэк

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

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

Риск - неопределенное событие, которое при наступлении влияет минимум на 1 цель проекта: содержание, сроки, стоимость, качество.

Затем Лена рассказала про основные фазы управления рисками и специфику УР в Agile-проектах.

1. Планирование - начинается на старте проекта (на стадии Pre-sale - стоимость проекта за счет дополнительного анализа увеличивается, но со временем можно использовать наработки предыдущих проектов).

Категории рисков - см. PMBOK

Как оценивать риски:
- Перемножение трех атрибутов:
Случай * Вероятность * Воздействие = Важность
- Шкала оценки рисков (от 0 до 100 процентов, можно разделить на интервалы, каждому интервалу дать название: например, от "крайне маловероятно" до "очень вероятно")
- Оценка последствий, измерять в том, что важно: деньги, сроки, качество
- Матрица учета последствий риска - например:
Может использоваться и более точная матрица 3x3 (в Скраме) до много * много :) (PMBOK) - пример
- Матрица "угрозы - возможности"

2. Идентификация рисков.

Для идентификации рисков можно использовать следующие мероприятия:
- Мозговой штурм
- Метод Дельфи
- SWOT-анализ
- выявление рисков через катастрофы
Отличный результат может давать ретроспектива.

3. Качественный анализ рисков.

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

Величина затрат = Вероятность риска * оценка стоимости риска
 Для учета рисков при оценке проектов, используем 4 стоимости, которые нам позволяют предположить ту, которая нас ждет:
- оптимистичная стоимость проекта
- стоимость проекта, ожидаемая управлением
- наиболее вероятная стоимость
- наихудший вариант  

4. Планирование реагирования на риски.

Стратегии реагирования:
- Уклонение
- Передача
- Снижение
- Принятие
- Использование
- Улучшение

5. Мониторинг и управление рисками.

Рекомендуемая литература от автора доклада:
- Тони Демарко "Вальсируя с медведями"
- PMI
- PMBOK
- ISTQB Advanced Level Syllabus, Chapter "Risk Management"

Update от 1.06.2013 - презентация от Елены:


пятница, 22 марта 2013 г.

IT Spring в Минске 16-17 марта. День второй

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

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

А теперь к самим докладам. Первыми на сцене А ожидаемо отжигали Орлов и Панкратов с докладом про стартап Стратоплан. Слов и времени ребята не жалели, благо времени у них было полтора часа. И на идеи, и на рекламу хватило :)

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

- У кого на картинке есть деньги?
- У кого видно, откуда они приходят?
- У кого видно, за что они приходят?

Затем докладчики рассказали про свой бизнес: за 2011-2012 год было организовано 24 различных клуба: фриланс, переговоры, лидерство, agile, проектное управление, практическое программирование, практическое тестирование, проектирование....  Но не все клубы были одинаково успешны. На данный момент, О&П сфокусировались на восьми наиболее успешных клубах.

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

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

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

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

Вторым выступал Джон Эйсон (John Ason), компания "Angel Investor". Как несложно догадаться, Джон занимается инвестированием в стартапы, и в своем докладе он рассказал как про свои работающие проекты, так и про требования к потенциальным кандидатам-стартапам.

Что основное можно рассказать по докладу:
- Компания Джона не занимается покупкой существующего бизнеса. Только инвестиции (funding)
- Управление командой - не прямое или совмещенное, а консультации по менеджменту (mentoring)
- Angels оставляет за собой право выйти из бизнеса в любой момент

Что Angels требуют от стартапа:
- короткий сфокусированный бизнес-план на 1 страницу
- управление качеством
- разумные оценки (разброс не более 20-30%)
- оценку рынка
- графическая презентация ценится больше, чем слова

Культурные ценности Angels (напишу на английском, дабы не исказить смысл) :
- speed, speed, speed
- outsorce everything
- leverage / margins
- compete / cooperate
- open non-secretive

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

Вобщем, если у вас есть хороший бизнес-план, и вы готовы с головой взяться за его реализацию - можете попробовать обратиться в Angels Investors. Более подробную информацию вы найдете на сайте - http://www.johnason.com

Следом за Джоном выступал Алексей Минкевич c докладом про трансформацию разработчик -> руководитель. За неполный час Алексей рассказал очень многое в простой ненавязчивой форме, только успевай конспектировать :) При этом, доклад получился очень живым и увлекательным, а ответы на вопросы только усилили и без того очень хорошее впечатление о докладе. С нетерпением буду ждать записи выступления.

А пока нет записи, поделюсь своим конспектом :)

Чем занимается руководитель:
- 90% рабочего времени - решение проблем других людей
- совещания: их много, нужна максимальная эффективность от них, не нужно ходить на те, которые не нужны
- нет больше технологий (как было у девелопера)
- растаскивание по мелочам
- ненормированный рабочий день
- много проектов (всего в подчинении порядка 20 человек)
- завоевать уважение на новом месте или в новом проекте
- одиночество
- кабинет, чтобы "уединиться и поплакать, когда никто не видит"

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

Чему нужно будет научиться при работе ПМом:
- мыслить стратегически
- делегировать
- уметь говорить "нет"
- не бояться давать людям расти

Как научиться быть руководителем:
- найти себе наставника
- общение с тусовкой
- тренинги
- бизнес-книги (личная рекомендация Алексея - "Deadline" Тони Демарко)
- конференции
- сертификация

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

После Алексея был часовой перерыв на обед, во время которого можно было не только отведать масленичные блины от IBA, но и пообщаться в неформальной обстановке с коллегами и докладчиками.

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

Стив разделил эволюцию покупателя на 7 этапов (первые три относятся к маркетингу, другие 4 - непосредственно к продаже). Опять же, дам их перечисление на английском, не искажая авторский оригинал:
1. Status Quo
2. Priority Shift
3. Research
4. Identify options
5. Step back
6. Validation & Beliefs
7. Choice & Commitment

Соответственно как аутсорсер, на различных этапах эволюции покупателя вы должны использовать различные приемы и стратегии, о которых вкратце, в рамках выделенного ему времени, и рассказал Стив. Также докладчик представил свою книгу, посвяшенную этой теме, -  "Software without Borders". Два экземпляра книги были разыграны, награда вместе с автографом Стива Мезака нашла своих героев. Тем, кому не так повезло, можно посетить сайт www.accelerance.com и бесплатно скачать электронный вариант книги.

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

Затем я переместился в секцию Б на доклад Тима Евграшина (мне нравится его подача и доклады на www.tim.com.ua) о "Продукте: вам нарезать или целым куском?" Лектор поговорил в целом про аджайл и про то, как решаются проблемы в нем. Доклад был обзорный, без углубления в детали. Что мне нравится у Тима - это яркие и умело подобранные слайды, которые очень "в тему" и к месту. После доклада было как-то маловато вопросов, но кто хотел - мог задать вопросы и после :) Тим очень внимательно слушал и обстоятельно отвечал, несмотря на то, что доклад был последний в этой секции, и лекционное время уже истекло :)

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

вторник, 5 февраля 2013 г.

Ищете учителя? Задайте ему всего один вопрос....

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

На тренингах очень модно стало рассказывать, как много какой тренер сколько на себя денег потратил, инвестировал на свое обучение. Но когда вы спросите их, так куда же ты на самом деле столько потратил, мало кто из них в состоянии сформулировать, куда он потратил 50 тысяч или 100 тысяч, или 200 тысяч, или 500 тысяч... Я вам рекомендую, в следующий раз, когда вам какой-либо учитель говорит, какую сумму он потратил, спросите у него, ты можешь перечислить, куда именно ты эти деньги потратил.... И здесь не может быть тайн, здесь не может быть никакой приватной информации.

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

Итак:

1. Стратоплан, "Курс практического тестирования". 550$
2. Экзамен ISTQB Advanced Level Test Analyst, готовился самостоятельно, сдал со 2-го раза. 2 * 150 евро = 300 евро или  почти 400 долларов
3. Дистанционное обучение Mini-MBA + годовая подписка на онлайн-семинары MBA. 450$ по скидке. 
4. Тренинг Стратоплана "Продуктивные коммуникации в команде" - 100 долларов
5. Confet&QA - выиграл бесплатное участие в конкурсе - 100 долларов за осеннюю программу
6. SQA Days-12 - бесплатное участие как докладчик конференции - 350 долларов за участие в конференции.

Итого 1950 долларов за год. Из них - 300 долларов оплатила компания, 450 долларов я выиграл в конкурсе или как участник конференции. Получается 1200 долларов только за тренинги я заплатил самостоятельно. Или 100 долларов в месяц.

Кроме того:
- приобретение наиболее ценных для меня бумажных книг в интернет-магазине. Приблизительно 2 книги или около 20-25 долларов ежемесячно.
- чтение литературы и блогов по тестированию - это бесплатно
- просмотр видео, участие в бесплатных видеоконференциях по тестированию (Рекс Блэк, Михаил Поляруш, Майкл Болтон, Джеймс Бах, SQA Days 11, Selenium Camp...)

В марте мой друг посоветовал меня в УЦ "Белхард", и с мая я преподаю курсы "Тестирование ПО" и "Тестирование веб-ориентированных приложений". Продолжительность курса  - 56 академических часов. С мая по декабрь я выпустил 4 группы (в сумме 40 человек). Подробнее про занятия буду освещать в этом блоге.

Но 2012 год уже история, а впереди очень много интересных событий: Стратосфера Grand Conference, сертификат ISTQB AL TM, SQA Days-13, новая Confet&QA, окончание Mini MBA, запланированные тренинги, продолжение преподавания в УЦ... Отличный должен получиться год! Обо всем этом я буду рассказывать в своем блоге.

До связи!

пятница, 1 февраля 2013 г.

Курсы по тестированию ПО. 7 советов по улучшению.

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

1. Помните, что обучение - это передача не только знаний, но и энергии. 

Никаких "сухих" лекций. Люди к вам пришли не за буквами, а за знаниями и вашей энергией. Почему они должны заниматься тем, о чем вы неохотно рассказываете, будто делая одолжение? Литературы по тестированию много, а если студент еще владеет английским на уровне Intermediate, плюс умеет искать и находить в интернете, то он может и сам научиться, сразу освоит необходимые материалы и с успехом пройдет собеседование на Junior QA Engineer.

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

2. Организуйте себя и учите личным примером.

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

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

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

Для себя решил - берись за группу, если уверен на 99.99%, что будешь вести ее до конца. Иначе пострадают студенты, сложно привыкать к новому преподавателю. Если не уверены, что сможете, - предупредите заранее. И, конечно, никаких перерывов в занятиях, регулярность - залог успешного обучения. Лучше заниматься 3 раза в неделю по 2 часа, чем один раз в неделю 6 часов.

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

3. Делайте ритмичные перерывы, не перегружайте.

Универсального, всем подходящего, графика нет, тут важен ваш пример. Работаете, например по Pomodoro: 25 минут работы + 5 минут отдыха, - отлично, научите свою группу так работать и понаблюдайте, чтобы группа "приняла" ваш режим.

Мой режим: 55 минут работы + 5 минут перерыва. Стараюсь планировать свои тематические блоки именно таким образом. И да, эти 55 минут тоже не монотонные - см. кривую внимания.

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

4. Создайте и поддерживайте в актуальном состоянии дополнительные материалы.

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

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

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

5. Внедряйте больше практики!

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

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

Практики мало не бывает: скриншоты с ошибками, командные игры по нахождению багов, рецензирование и оценка коллег (peer review)... И геймификация вам тоже в помощь. Testing could be fun!

6. Используйте все каналы связи со студентами: онлайн-связь и онлайн-сообщества.

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

7. Признавайте свои ошибки и учитесь, не "бронзовейте".

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

Если допустили ошибку - поправьтесь и продолжайте дальше. Только один человек был совершенен, он жил более 2 тысяч лет тому назад. " А мы не ангелы, парень" (c)

8. "Будьте собой, все остальные места уже заняты".

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