понедельник, 1 июня 2015 г.

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

Всем привет!

Вот и прошел мой самый любимый месяц в году - май. Позади День Рождения, участие в сессии Weekend testing 05: Тестирование белого ящика, тренинг Рекса Блэка и конференция SQA Days в Минске. О конференции и тренинге я расскажу в июне в блоге, а пока делюсь слайдами моего доклада со второго дня SQA Days  "Как оценить процесс тестирования на проекте":



В мае я сделал обзор Макса Дорофеева "Джедайская техника пустого инбокса", прошедший в апреле в Минске, добавил на книжную полку 3 книги:
В июне добавлю обзор еще двух книг, следите за блогом!

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

Разбиение ссылок традиционное:
QA Quality Assurance. Обеспечение качества, контроль качества, тестирование. Заинтересовавшие меня статьи по профильной теме за месяц.
STU Studying, образование и самообразование, обучение.
GA Gamification. Геймификация тестирования, обучения, управления - составляющих Qastugama.
MA Management and leadership - управление командой, людьми, лидерство. Составляющие Management.
+
Books - обзоры прочитанных и/или рекомендованных книг.
+
Other - "сборный раздел". То, что не относится к предыдущим четырем темам, но то, чем я хотел бы с вами поделиться.
+
Bonus.Fun. - (не)серьезно о тестировании, об IT и не-IT.

Quality Assurance.


Test Automation.

Management.

До встречи в июне, оставайтесь с Qastugama!

вторник, 26 мая 2015 г.

Книжная полка. Фредерик Брукс "Мифический человеко-месяц или как создаются программные системы"

Продолжаю обзор IT-классики, которая попала в мою коллекцию благодаря акции books.ru "Книги по свободной цене". На очереди вторая книга - по управлению проектами. Вслед за Джоэлом Спольски, я расскажу о книге Фредерика Брукса "Мифический человеко-месяц или как создаются программные системы".

Технико-тактические характеристики:
Год издания: 2007 (Символ)
Страниц: 304
Скорость чтения - выше среднего
Время на прочтение:  6-8 часов
Полезность - высокая
Это классическая книга по управлению проектами: первое издание книги вышло в 1975 году, общий тираж - более 250.000 экземпляров.

Книга состоит из 19 глав. Каждая глава - отдельный очерк, как и в книге Джоэла Спольски. Первые 7 глав описывают общие трудности, которые возникают при управлении программными проектами. Главы с 8 по 15 описывают различные аспекты управления проектами: объем работ, размер программы, внутреннюю документацию, первую версию, инструментарий, архитектуру, опоздания в проектах, пользовательскую документацию. В главе 16 Брукс утверждает, что "серебряной пули нет", и приводит доказательства. Эта глава вызвала споров больше, чем остальные главы книги вместе взятые. В книгу 1995 года добавлена глава 17, которая включает ответы Брукса на замеча ния критиков, и также уточняет взгляды к предыдущему изданию книги.

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

Чуть ниже - мой конспект книги. Замечу, что конспект Брукса - в главе 18, которую он добавил в издание 1995 года и в которой Брукс систематизировал взгляды из глав.
  1. Программный продукт (интерфейсы, системная интеграция) или программный комплекс (обобщение, тестирование, сопровождение, документация) стоит в 3 раза дороже автономной программы, а системный программный продукт - в 9 раз дороже.
  2. Программирование доставляет удовольствие, поскольку отвечает глубокой внутренней потребности в творчестве и удовлетворяет чувственные потребности, которые есть у всех нас.
  3. Печали программирования: необходима безошибочная точность действий, полномочия ниже ответственности, периоды однообразного и кропотливого труда, продукт может оказаться устаревшим в момент своего завершения.
  4. Программные проекты чаще проваливаются из- за нехват ки календарного времени, чем по всем остальным причи нам, вместе взятым.
  5. Причины провалов проектов из-за нехватки времени: слабо развиты методы оценок, методы оценки ошибочно путают достигну тый прогресс с затраченными усилиями, менеджеру недостает упрямства из-за неуверенности в оценках, выполнение графика работ слабо контролирует ся.
  6. В основе планирования разработки программ лежит ложное допущение, что все будет хорошо, т. е. каждая задача займет столько времени, сколько «должна» занять.
  7. Использование человеко-месяца как единицы измерения объема работы является опасным заблуждением (не учтены другие зависимости: разделимость задачи, обмен данными, обучение).
  8. Эмпирическое правило Брукса при планировании разработки ПО:
    1/3 — планирование,
    1/6 — написание программ,
    1/4 — тестирование компонентов и предварительное систем
    ное тестирование,
    1/4 — системное тестирование при наличии всех компонентов.
  9. Закон Брукса - Если проект не укладывается в сроки, то добавление рабочей силы задержит его еще больше.
  10. Хорошие и плохие программисты очень сильно различаются между собой по производительности.
  11. Решение Миллза - на каждом участке работы была команда, организо ванная наподобие бригады хирургов, а не мясников: хирург, второй пилот, администратор, редактор, секретарь, делопроизводитель, инструментальщик, отладчик, языковед.
  12. Концептуальная целостность - важнейшая характеристика системного проекта.
  13. Для некоторого заданного уровня функциональности лучшей оказывается та система, в которой можно работать с наи большей простотой и непосредственностью.
  14. Блау: всю программу создания составляют три отдельные стадии: архитектура, разработка и реализация. Ока зывается, что на практике их можно начинать параллельно и продолжать одновременно.
  15. Получение архитектуры извне уси ливает, а не подавляет творческую активность группы исполни телей.
  16. Архитектору, когда он сталкивается с неприемлемо высо кой стоимостью, необходимо:
    • Помнить, что ответственность за изобретательность и творче ство, проявляемые при реализации, несет строитель, поэтомуархитектор предлагает, а не требует.
    • Всегда быть готовым предложить некоторый способ реализа ции своих замыслов и быть готовым согласиться с любым другим способом, позволяющим решить задачу не хуже.
    • Выдвигая такие предложения, действовать без шума и огласки.
    • Не рассчитывать на признательность за сделанные предло жения.
  17. Эффект второй системы архитектора
  18. Лучший друг менеджера проекта — его постоянный противник, независимая организация, тестирующая продукт. Каждой организации, ведущей разработки, нуж на такая независимая группа технического аудита, которая долж на быть неподкупна.
  19. Аудит менеджмента Вавилонского проекта. Было: ясность цели, человеческие ресурсы, материалы, достаточно времени, адекватные технологии. Не было: обмена информацией и вы текающей из него организации. Итог - fail.
  20. Обмен информацией между бригадами: неформально, совещания, рабочая тетрадь.
  21. Способы, позволяющие сократить обмен информацией, — разделение труда и специализация функций.
  22. Характеристики древовидной организации программистов, чтобы быть эффективной:
    1. задание,
    2. продюсер,
    3. технический директор или архитектор,
    4. график работ,
    5. разделение труда,
    6. определение интерфейсов между разными частями.
  23. Не люди должны быть втиснуты в чи сто теоретические организационные формы, а организация долж на строиться вокруг тех людей, которые есть.
  24. Объем работы = (константа) × (количество команд)1,5
  25. Планируйте выбросить первую версию — вам все равно придется это сделать. (Сейчас
    я считаю его ошибочным — не в силу чрезмерного радикализма, но в силу чрезмерной упрощенности.)
  26. Ссистемная отладка займет больше времени, чем предполагается, а ее сложность оправдывает досконально систематичный и плановый подход:
    1. используйте отлаженные компоненты (компонент готов к использованию в системной проверке, когда все его ошибки найдены, но необязательно уже исправлены),
    2. создайте больше окружений,
    3. контролируйте изменения ("фиолетовые провода),
    4. добавляйте компоненты по одной,
    5. квануйте изменения.
  27. Отставание, растущее понемногу изо дня в день, труднее рас познать, труднее предотвратить, труднее исправить.
  28. Верно то, что создание программных систем всегда будет труд ным. Серебряной пули нет по самой природе вещей.
  29. Верификация программ не означает создания программ, ли шенных ошибок. И здесь нет чудес. Математические доказатель ства тоже могут быть ошибочными. Поэтому хотя верификация может облегчить тестирование, она не может отменить его.
  30. за одинаковые сроки команда может нарастить значительно более сложный объект, чем построить.
  31. Практически ни один проект невозможно завершить быстрее, чем за 3/4 расчетного оптимального графика вне завиимости от количества занятых в нем.
Вывод. Книга must-read каждому тестировщику, не только для общей ИТ-грамотности и обращения к "классике".Содержит общие взгляды на управление программными проектами, проверенные временем и на которые ссылаются многие современные авторы и докладчики. Автор уделяет внимание и роли тестирования. Читается достаточно легко, или последовательно, или отдельно по главам. Для повторного обращения к книге используйте конспект идей Брукса в главе 18.

воскресенье, 24 мая 2015 г.

Книжная полка. Девора Зак "Управление для тех, кто не любит управлять"

Сегодня на Книжной полке менеджерская книга - Девора Зак "Управление для тех, кто не любит управлять".
Технико-тактические характеристики:
Год издания: 2013 (Манн-Иванов-Фербер)
Страниц: 224
Скорость чтения - выше среднего
Время на прочтение:  4-5 часов
Полезность - средняя

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

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

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

"Думающие люди руководят головой. Чувствующие - сердцем."

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

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

Книга легко читается. Девора Зак шутит, приводит много примеров из жизни, командных упражнений. Авторские упражнение заинтересуют и менеджера с опытом. Мне понравились упражнения "Не паникуйте" (рассказать о себе перед всеми участниками), "Тренерский мандат" (вспомнить лучшего, на ваш взгляд ,тренера), "Обратная связь" (передать как можно больше воздушных шариков, не зная правил).

Приведу ключевые мысли и идеи из этой книги:
  1. Гибко адаптируйте свой стиль для управления другими
  2. Лидерство, ориентированное на результат, дает командам больше позитива, чем лидерство, орентированное на настрой.
  3. Люди могут усомниться в том, что вы говорите, но они поверят в то, что вы делаете. 
  4. Управляйте диалогом с помощью вопросов. И слушайте ответы собеседника. Если вы считаете, что знаете их заранее, вы уже проиграли.
  5. Мы ответственны за свое сознание, а следовательно, и за свои результаты.
  6. Ваши единственные учаски прямой ответственности - ваши мысли, слова и действия.
Вывод. Книга об управлении, которую можно прочитать за один вечер, легкая в понимании. Полезна начинающему лиду. Более опытные руководители найдут интересные командные упражнения в книге. В книге приводятся интересные истории из жизни менеджера. Не ждите в малом объеме "всю суть управления", но для начала знакомства с менеджментом книга пригодится.

пятница, 15 мая 2015 г.

Книжная полка. Джоэл Спольски "Джоэл о программировании"

Благодаря акции books.ru "Книги по свободной цене" в апреле прошлого года, я пополнил Книжную полку тремя классическими книгами по программированию, управлению и дизайну. Часть первая обзоров Books.ru - книга Джоэла Спольски "Джоэл о программировании и разнообразных и иногда родственных вопросах, которые должны быть интересны разработчикам  программного обеспечения, проектировщикам и менеджерам, а также тем, кому посчастливилось или не повезло в каком- то качестве работать с ними".


Технико-тактические характеристики:
Год издания: 2008 (Символ)
Страниц: 352
Скорость чтения - выше среднего
Время на прочтение:  6-8 часов
Полезность - высокая

Книга представляет собой сборник статей-эссе, опубликованных Джоэлом Спольски на своем сайте в 2000-2003 годах. Статьи разнообразные, от исследований программиста по вопросу оптимизации памяти в С и С++, до размышлений Джоэла на тему стратегии развития компании. Статьи-главы книги имеют взаимосвязь, но можно приступать к чтению с любой части, главы без опасения упустить цепочку рассуждений. Но я рекомендую читать ее от начала до конца любому, даже не техническому специалисту, потому что чистых технических тонкостей и примеров кода немного, в ней нет листингов программ на целые страницы, зато есть куча полезных вещей для любого ИТ-специалиста: программиста, тестировщика, менеджера, бизнес-аналитика.

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

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

Книга разбита на 3 части. Строгого деления между частями нет, они связаны между собой. К каждой из частей я прикрепляю ценные мысли и идеи, высказанные автором, с своими замечаниями с точки зрения тестирования (курсивом):
  1. Биты и байты: практика программирования. Самая техническая часть.
    • по возможности избегайте "Алгоритмов маляра Шлемиля" с нелинейной сложностью (пример со строками в разных языках программирования).
      Для находжения таких "алгоритмов" тестировщики используют граничные значения, очень большие входные данные, нагрузочное тестирование.
    • "Тест Джоэла: 12 приемов написания лучшего кода".
      Актуальные вопросы и с точки зрения тестирования. Проверьте, на какие из вопросов по вашему проекту вы ответили "да". Ответы "нет" - потенциальные области для улучшений.
    • "Отсутствие спецификации – это самый крупный и совершенно ненужный риск, который вы берете на себя, принимаясь за программный проект"
    • 3 правила составления спецификации: Пишите занимательно, Спецификация должна напоминать код, предназначенный для выполнения мозгами; Пишите проще, Исправляйте и перечитывайте текст по нескольку раз, Шаблоны бывают вредны
    • Обязательно составляйте график работы
    • Ежедневная сборка необходима для сокращения цикла REP - «Read, Eval, Print»: для программирования - чем быстрее выполняется цикл, тем выше производительность разработчика, для работы в команде - чтобы сократить цикл между регистрацией ошибки и повторным тестированием.
    • "Исправлять ошибки необходимо только тогда, когда сохранение ошибки обходится дороже, чем ее исправление."
      Звучит как памятка для тестировщика-перфекциониста и взгляд "с другой стороны баррикад". Но при этом автор справедливо говорит, что "в большинстве случаев исправление ошибок экономически оправданно. Но иногда можно получить более высокую прибыль иными способами, не занимаясь тотальным истреблением ошибок."
    • "Существуют разные сферы разработки программ, и в каждой из них действуют свои законы: коробочные продукты, внутрифирменное ПО, встроенное ПО, игры. одноразовые программы".
      Соответственно, стратегии тестирования программ из разных сфер будут различными. Но даже и для двух, например, игр, стратегии тоже будут отличаться, хотя и иметь общего больше, чем с тестированием встроенного ПО.
    • "Не дайте астронавтам от архитектуры запугать себя. Помните, что эти архитекторы решают те проблемы, которые, как им кажется, они могут решить, а не те проблемы, которые было бы полезно решить. Лучше расскажите мне,
      что я теперь смогу сделать нового, чего не мог сделать раньше."
      Памятка тестировщику: не бойтесь сложных архитектурных терминов, а задавайте вопросы, какую именно задачу решает данная архитектура. Это вам позволит понять проблему и лучше вникнуть, какие возможные уязвимости есть у данного решения.
    • Путь к продуктивности - "огонь и движение: Если вы не движетесь, то развитие
      событий станет определять противник, а это нехорошо. Если вы не ведете
      огонь, противник станет вести огонь по вам и уложит вас."
      Ежедневно тестируйте, продвигайтесь вперед, и совершенствуйте ваши "инструменты огня".
    • "Иногда исправление 1 процента неисправностей требует 500 процентов усилий." Иногда и тестирование 1 строки исправлений может потребовать большого объема регрессионного тестирования.
  2. Руководство разработчиками. Менеджерская часть.
    • "Как же определить, что этого человека надо принять? В принципе просто. Искать надо тех, кто: 1. Умен. 2. Доводит дело до конца."
    • Типичный план собеседования с программистом:
      1. Знакомство.
      2. Вопрос о последнем проекте, над которым работал кандидат.
      3. Вопрос, не имеющий ответа.
      4. Вопрос о программировании.
      5. Вы удовлетворены?
      6. У вас есть вопросы?
      Меняем программирование на тестирование, и план тот же.
    • "Советую избегать всеми силами разных оценок продуктивности, поощрительных премий и дурацких конкурсов на лучшего работника месяца."
      Глава про то, почему не работает система "если-то" в творческих коллективах, к которым относится любая проектная команда. Основной посыл книги Дэниела Пинка "Драйв", о которой я уже писал.
    • "То, чего делать нельзя - Они решили переписать весь код заново."
      Относится и к тестированию. Да, есть соблазн выкинуть старые тест-кейсы, чек-листы и написать новые. Но выкидывая старые тесты, мы рискуем потерять знания об ошибках программы, которые мы вносили в тест-кейсы. С точки зрения процесса, тоже легко сказать, что давайте делать теперь вот так, не вникнув, почему именно так раньше был построен процесс тестирования. У коренных изменений больше шансов "прорасти" (и то не факт), если вы сумели доказать неэффективность старого подхода и оценить, что новый подход будет лучше. Не попадайте в ловушку "Читать код труднее, чем писать его."
    •  "Программное обеспечение обычно похоже на айсберг: в нем есть милый интерфейс пользователя, который требует процентов 10%, а 90% программистского труда скрыто от глаз."
      Тестируем не только верхушку айсберга, но и то, что "под кулисами". В частности, пирамида автоматизации поможет с составлением автотестов для нижней части айсберга.
    •  "Если показать непрограммисту экран с интерфейсом пользователя, который на вид готов и красиво выглядит, то он решит, что программа почти готова."
      Вывод для тестировщика: не надейтесь, что одним тестированием интерфейса программа почти протестирована.
    •  "Закон дырявых абстракций означает, к сожалению, что абстракции не так сильно упрощают нашу жизнь. Единственный компетентный способ залатать дыры абстракций - выучить, как работают абстракции, и какие подробности они скрывают. Итак, абстракции экономят наше рабочее время, но не экономят учебное время."
      Способ найти дыры абстракций тот же: разобраться, как работают абстракции и какие у них могут быть проблемы.
  3. "Мысли Джоэла: случайные высказывания по не столь случайным поводам"
    • "Идиома to eat one's dog food (есть корм своей собаки) в компьютерной
      индустрии означает, что разработчик использует собственное ПО."
      Отличный классический способ тестирования.
    • "Как делать дело, если вы всего лишь рядовой. Стратегия:
      1. Просто делай
      2. Воспользуйся силой вирусного маркетинга
      3. Создай оазис качества
      4. Нейтрализуй дураков
      5. Избавься от отвлечений
      6. Стань незаменимым"
    • "1. Чтобы действительно хорошо делать некоторые вещи, нужен талант.
      2. Талант трудно масштабировать.
      3. Один из способов масштабирования таланта – предложить его носителю написать инструкции, которые должны выполнять те, у кого таланта нет.
      4. Качество получаемого продукта очень низкое."
    • "Слабые системы могут казаться вполне безопасными, пока не сломаются
      какие-нибудь смежные системы."
Вывод. Книга must-read всем тестировщикам и не только для общей ИТ-грамотностии обращения к "классике". Читается легко, не перегружена техническими деталями, затрагивает все аспекты разработки ПО. Из-за того, что это "классика" и статьям более 10 лет, некоторые вещи могут показаться слишком очевидными. Но автор аргументированно объясняет, почему он приходит к тем или иным действиям и выводам.

воскресенье, 10 мая 2015 г.

О джедайском тренинге Макса Дорофеева, пустом инбоксе, списке задач и высоких целях

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

Для меня Максим Дорофеев один из лучших докладчиков и тренеров. Почему?
  • Мне близки темы личной эффективности, оценки проектов, которыми он занимается
  • Доклады Макса содержат свои фишки: авторские рисованные слайды, яркие образы (например, "человек-снежинка"), чувство юмора и прямые формулировки
  • Как Макс работает с аудиторией. Вопросы-ответы в зал, практические задания, работа в группах
Доклады Макса со многих конференций есть в свободном доступе - http://cartmendum.livejournal.com/164238.html. Для тестировщиков рекомендую серию докладов  "Обезьянки против роботов" про плюсы и минусы автоматизации.

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

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

Максим Дорофеев очень много пишет о личной эффективности в своем блоге, поэтому мой конспект ниже - это не попытка охватить все, что хотел донести Макс, а недостающие "кирпичики" в мое здание. Рекомендую вам сделать свой конспект по следам тренинга или по статьям в блоге.
  • "Делать дела не сложно. Сложнее решить, что делать"
  • 2 ситуации, когда люди хотят личной эффективности: кончилось время и кончился мозг. В первой помогает тайм-менеджмент, во второй ТМ не поможет, необходимо экономить патронорешения (медленное мышление)
  • "Что не записано, то продолбано"
  • Идеи записывать необходимо, чтобы освободить "помнилку" и чтобы не тратить время на идею каждый раз, когда она "путешествует из неосознанного в осознанное ("Мышление может запуститься само")
  • Полный инбокс - это не список задач. Это может быть список проблем, проектов, заявок на прокрастинацию, узелков на память
  • Первый парадокс личной эффективности: Для того, чтобы выправить баланс между работой и личной жизнью, надо не разделять их, а наоборот смешать на сколько это возможно. Все задачи по работе и для себя должны вестись в едином списке задач.
  •  Если не знаешь, какой сделать первый шаг - реши, что бы ты сделал за 15 минут. Если не знаешь, что делать, - выдели 15 минут на обдумывание только этой задачи, не отвлекаясь на постороннее.
  • 4 шага шаблона естественного планирования: мотиватор (для меня это важно, потому что) + видение результата (визуализация) + организация (например, карта памяти) + самый первый шаг
  • Борьба с прокрастинацией, 2 вопроса: каков самый первый шаг и какой минимально приемлемый результат
  • Соотнесение своих жизненных целей и задач из списка. Очень полезно смотреть в список задач и отмечать, запланированы ли задачи, которые данную цель продвигают. И в обратную сторону: какую цель помогает достичь данная задача? 
Практическая часть (если даже вы не были на тренинге, подумайте над следующими составными частями инструмента вашей эффективности и тем, как их можно улучшить):
  • Единый список задач - done
  • Еженедельная задача на обзор списка задач (он же "гвоздодер") - done. Я пользуюсь "спусковыми крючками" Татьяны Беловой.
  • Сортировка писем во входящих - done в рабочих, todo - в личных 
  • Календарь - done
  • Система для хранения информации - todo (на тренинге не было)
  • Интернет-шабат на сутки - попробовать
Только практика и действия помогут вам стать джедаем. И да прибудет с вами сила! Ставьте высокие цели и их достигайте :)


воскресенье, 3 мая 2015 г.

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

Всем привет!

Май - отличный месяц для отдыха, чему способствуют и праздничные дни, и весеннее потепление. Но и для работы и развития май тоже хорош. 29-30 мая состоится конференция SQA Days в Минске, а днем раньше - тренинги Рекса Блэка и Пола Джеррарда (оба посетить не получится, придется выбирать).

Второй день конференции, секция А, время встречи - 16-15. Жду вас на докладе "Как оценить процесс тестирования на проекте".

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

Разбиение ссылок традиционное:
QA Quality Assurance, обеспечение качества, все, что относится к тестированию. Наиболее заинтересовавшие меня статьи по профильной теме за месяц.
STU Studying, образование и самообразование, обучение.
GA Gamification, или геймификация тестирования, обучения, управления - всех составляющих Qastugama.
MA Management and leadership - управление командой, людьми, лидерство. Составляющие Management.
+
Books - обзоры прочитанных и/или рекомендованных книг.
+
Other - "сборный раздел". То, что не относится к предыдущим четырем темам, но то, чем я хотел бы с вами поделиться.
+
Bonus.Fun. - (не)серьезно о тестировании, об IT и не-IT.

Quality Assurance.


Test Automation.

Management.

Books.

Bonus. Fun.

До встречи в мае, оставайтесь с Qastugama!

пятница, 10 апреля 2015 г.

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

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

2 апреля на белорусском ИТ-портале dev.by вышло мое нетехническое  интервью о жизни, карьере, армии и конечно, семье. Спасибо Наталье Провалинской за интервью и проделанную работу по выбору самого интересного из нашей беседы. Приятного прочтения! Ссылка - http://dev.by/lenta/main/andrey-ladutko-ya-nemnozhko-dzhek-potroshitel-po-nature

В марте прочитал еще 5 книг - скорых кандидатов на пополнение Книжной Полки. А уже через полтора месяца конференция SQA Days, она пройдет 29-30 мая в Минске, так что ехать далеко мне не придется :) Буду рад вас увидеть на ней, планирую выступить с докладом, который активно буду готовить в апреле. А завтра в Минске будет Максим Дорофеев с мастер-классом "Джедайская техника пустого инбокса", который я не могу не пропустить. Отчет будет в течение недели.

Вернемся к рубрике. Разбиение ссылок на группы остается прежним-традиционным:
QA Quality Assurance, обеспечение качества, все, что относится к тестированию. Наиболее заинтересовавшие меня статьи по профильной теме за месяц.
STU Studying, образование и самообразование, обучение.
GA Gamification, или геймификация тестирования, обучения, управления - всех составляющих Qastugama.
MA Management and leadership - управление командой, людьми, лидерство. Составляющие Management.
+
Books - обзоры прочитанных и/или рекомендованных книг.
+
Other - "сборный раздел". То, что не относится к предыдущим четырем темам, но то, чем я хотел бы с вами поделиться.
+
Bonus.Fun. - (не)серьезно о тестировании, об IT и не-IT.

Quality Assurance.

Management.

До встречи в апреле, оставайтесь с Qastugama!


Adme - Япония, апрель 2015, цветут сакуры и выпал снег

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

Рубрика "ПочитайQA". Полезные ссылки за февраль-2015

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

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

Вернемся к рубрике. Разбиение ссылок на группы остается прежним-традиционным:
QA Quality Assurance, обеспечение качества, все, что относится к тестированию. Наиболее заинтересовавшие меня статьи по профильной теме за месяц.
STU Studying, образование и самообразование, обучение.
GA Gamification, или геймификация тестирования, обучения, управления - всех составляющих Qastugama.
MA Management and leadership - управление командой, людьми, лидерство. Составляющие Management.
+
Books - обзоры прочитанных и/или рекомендованных книг.
+
Other - "сборный раздел". То, что не относится к предыдущим четырем темам, но то, чем я хотел бы с вами поделиться.
+
Bonus.Fun. - (не)серьезно о тестировании, об IT и не-IT.

Quality Assurance.

Gamification.

Management.

Books.

Bonus. Fun.

Всех с наступившей весной! До встречи в марте, оставайтесь с Qastugama!
Автор Jan Machata.
Источник - https://500px.com/photo/5225418/may-it-be-by-jan-machata?from=popular



воскресенье, 22 февраля 2015 г.

Заметки на полях. Weekend Testing RU #02. Исследовательское тестирование.

Сегодня поучаствовал в скайп-сессии Weekend Testing по исследовательскому тестированию, и теперь разбавляю февральский месяц Книжной Полки этим обзором.

Weekend Testing - двухчасовая сессия в формате текстового скайп-чата на определенную тему. Для участия необходимо заранее зарегистрироваться и выйти в онлайн за 15 минут до начала сессии, чтобы организатор добавил вас в группу для обсуждения. Участие добровольное, бесплатное, не ограниченное годами опыта, стеком технологий, инструментов :)

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

Тема исследовательского тестирования (сокращенно - ИТ) подробно описана в работах Баха, Болтона, Виттакера, Канера, Хендриксон, статьях в блогах, последние февральские - Романа Шейко и переводы туров Ольги Киселевой. На обсуждении Weekend Testing мы затронули такие темы: определение ИТ и как его выполнять, структура, цели, объем, плюсы и минусы ИТ, когда оно полезно и нет, инструменты ИТ и отчетность.

Главная и самая полезная часть Weekend Testing - практика. На ней мы выполняли ИТ по сайтам (на выбор) и составляли отчеты об ИТ, которыми делились друг с другом и обсуждали идеи и находки каждого:

  1. Совместить отчет в формате карты памяти с отметкой результатов прохождения проверок (Илья Агеев и Илья Комендантов)
  2. Использовать несколько уровней отчетности: первый - в Word с общими выводами и со ссылкой на второй более подробный уровень - чеклист в Excel. Для некоторых пунктов чеклиста делаются комментарии со ссылкой на третий уровень: картинки в скриншотерах или Onenote / Evernote (Алексей Виноградов)
  3. Совместить в отчете ИТ и поиск ошибок (Ольга Артемьева, Константин Коваль, Ольга Христенко, Александр Ковалев)
  4. Формат отчета в Rapid Reporter c картинками (Александр Мужичек)
Для сессии ИТ мы использовали следующие инструменты: Word+Excel или Google Docs, OneNote, редактор карт памяти, скриншотер, Rapid Reporter. Для практики на Weekend Testing можно пользоваться ручкой и тетрадью, но лучше использовать инструменты, тогда не возникнет необходимость думать о переносе результатов в формат для отчета, чтобы поделиться с коллегами. Плюс, если вы работаете над заданием в распределенной группе, - организовать "совместный доступ" к ручке и  тетради не получится.

Большое спасибо участникам из четырех стран (Россия, Украина, Беларусь, Германия), среди которых я встретил знакомые лица - Алексея Виноградова, Илью Комендантова. И отдельно спасибо организаторам Роману Шейко за интересную сессию, рецензии, задания и соблюденный тайминг, и Алексею Федорову за анонс мероприятия, которое и попало в мой to-do лист на февраль! И большое спасибо всем участникам за комментарии, идеи оформления репортов по результатам сессии исследовательского тестирования!

До следующей встречи, оставайтесь с QaStuGaMa!

суббота, 21 февраля 2015 г.

Книжная полка. Пинк "Драйв. Что на самом деле нас мотивирует".

Как и обещал в предыдущем обзоре на  Книжной полке, сегодня я расскажу о книге "Драйв. Что на самом деле нас мотивирует" Дэниэла Пинка.
Дэниэл Пинк "Драйв. Что на самом деле нас мотивирует"
. Книга на oz.by





Технико-тактические характеристики:
Год издания: 2013 (Альпина)
Страниц: 274
Скорость чтения - выше среднего
Время на прочтение:  4 - 6 часов
Полезность - выше среднего

Книга Пинка - продолжатель идей позитивной психологии. Автор исследует вопрос о мотивации работников и убедительно, с использованием примеров и отсылкой к другим авторам, включая Друкера, Минцберга, Дуэка, Макгрегора, Харлоу, доказывает, что существующая система мотивации (названная автором "Мотивация 2.0" или "Метод кнута и пряника") не работает. Это главы 1 и 2 книги.
Далее в третьей главе автор рассказывает о поведении типа Х (которое свойственно "Мотивации 2.0 и ориентировано на внешние награды) и поведении типа I (ориентируется на внутренние награды и ведет, по словам автора, "к более высокой продуктивности, более крепкому здоровью и большему благополучию"). Если работа монотонная, предсказуемая, поощряется поведение типа Х. Для творческого и интеллектуального труда необходимо построить систему мотивации для поведения типа Y. Третьей главой заканчивается первая часть книги.
В последующих трех главах, или второй части книги, автор разбирает основные элементы "Мотивации 3.0" - "нового уровня" (не апгрейда действующей версий с 2.0. до 2.1) - автономию, мастерство и целеустремленность и дает общие рекомендации по достижению элементов в организации.
Наиболее сильная третья часть книги - практикум, который Дэниэл Пинк дает после самой книги. Практикум включает в себя стратегии для внутренней мотиваций для индивидуальных, организационных целей, правила вознаграждения в Мотивации 3.0., список литературы для дальнейшего изучениия, 3 варианта конспекта книги: твиттер-формат, одностраничный и отдельно по каждой главе, глоссарий и список вопросов для обсуждения. Я рекомендую стратегии для мотивации - для претворения нового знания в действия, конспекты - чтобы "освежить" идеи книги, и список вопросов для обсуждения - для обдумывания возможных "проблемных мест" при применении нового знания. 

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