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

Книжная полка. В. Ким Чан, Рене Моборн "Стратегия голубого океана"

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


Технико-тактические характеристики:
Год издания: 2013
Страниц: 304
Переплет: Твердый переплет
Формат: 170х240 мм, увеличенный
ISBN: 978-5-91657-634-4
Скорость чтения - выше среднего
Ориентировочное время на прочтение: 5 - 7 часов

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

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


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

Отличный практический пример применения стратегии голубого океана можно почитать здесь - http://habrahabr.ru/company/intel/blog/89286/ 

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

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

вторник, 18 июня 2013 г.

Книжная полка. Гленфорд Майерс "Искусство тестирования программ"

Прочитал книгу Гленфорда Майерса "Искусство тестирования программ", третье издание. Книга отличная, рекомендую.


Технико-тактические характеристики:
Год издания: 2012
Страниц: 272
Переплет: Твердый переплет
Формат: 170х240 мм, увеличенный
ISBN: 978-5-8459-1796-6
Скорость чтения - средняя
Ориентировочное время на прочтение: 8 - 10 часов

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

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

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

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

Глава 1. Тест для самопроверки. Короткое, на пару страниц, введение и вышеупомянутая задача про треугольники.

Глава 2. Психологические и экономические аспекты тестирования. Психология, связанная с определением тестирования; невозможность полного тестирования и использование стратегий "белого" и "черного" ящика; десять принципов тестирования ПО. Это базовые вещи, с которых надо начинать знакомство с тестированием.

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

Глава 4. Проектирование тестов. Самая объемная глава, целых 45 (!) страниц :) Наиболее общие техники белого ящика (покрытие операторов, покрытие решений и покрытие логики) и черного ящика (эквивалентное разбиение, граничные значения, причинно-следственные диаграммы). Для новичков можно посоветовать читать целиком, затем, по необходимости, "добивать" эти темы Канером и уже упомянутым ISTQB с примерами вопросов по тест-дизайну. Для более продвинутых тестировщиков я бы рекомендовал обратить внимание на причинно-следственные диаграммы: великолепный пример построения диаграммы с использованием базовых знаний математической логики, не сильно усложненный, как у Бейзера, но и не слишком упрощенный, где диаграмма "притягивается за уши" к тривиальному примеру.

Глава 5. Модульное тестирование. Пожалуй, лучшая практическая и "уникальная" глава в книге: чаще всего объяснения про МТ сводятся к простым примерам, например, как в Википедии: пишем тесты для функции сложения, используем предикат Assert. И да, модульные тесты должны писать программисты - гуглим. Майерс предлагает использовать методики белого ящика для проектирования тестов, а затем дополнить набор тестов тестами "черного ящика". В дополнение к проектированию, очень важно, как мы объединяем модули в работающую программу - для этого используем неинкрементное или инкрементное тестирование (автор показывает преимущества и недостатки обоих методов и предлагает использовать инкрементное тестирование,  на следующем шаге мы выбираем одну из возможных стратегий инкрементного тестирования - восходящее или нисходящее тестирование).
Хорошая новость для тех, кто хочет ознакомиться с этой главой - в бесплатном доступе есть возможность пролистать ее - http://oz.by/books/more10264179.html

Глава 6. Высокоуровневое тестирование. Рассматривается процесс разработки ПО как Получение требований -> Постановка целей -> Внешняя спецификация -> Проект системы -> Проект структуры программы -> Спецификация интерфейсов модулей -> Код. Затем мы используем три взаимодополняющий подхода, которые позволяют предотвращать и (или) обнаруживать ошибки:
  • повышение точности разработки
  • в конце каждого этапа вводим стадию верификации
  • ориентируем конкретные процессы тестирования на конкретные процессы разработки
Третьему подходу и посвящена эта глава: рассматривается функциональное, системное, приемочное тестирование. Отдельно рассматривается инсталляционное тестирование и планирование и контроль тестирования. Модель Майерса напоминает V-модель тестирования ПО c небольшими отличиями.

Глава 7. Тестирование удобства использования. Общие рекомендации по тестированию юзабилити БЕЗ привязки к особенностям интерфейса различных ОС, user interface guide'ам и моделям GOMS в сочетании с законами Фитса и Хика. В книге рассматриваются только основы и процесс тестирования удобства использования с использование анкет.

Глава 8. Отладка. Глава скорее для программистов. Неэффективность метода "грубой силы" и принципы эффективной отладки, разбитые на 2 этапа: локализацию ошибок и их устранение.

Глава 9. Тестирование в среде гибкой разработки. Общие принципы Agile-методологий. Экстремальное программирование и тестирование. И все. Не рассматривается тестирование в скрам-командах, автоматизированное тестирование.

Глава 10. Тестирование интернет-приложений. Рассматривается архитектура e-commerce приложений, проблемы тестирования в веб, стратегия тестирования веб-приложений на трех уровнях: слой представления, бизнес-логика, слой данных.

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

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

четверг, 13 июня 2013 г.

Обзор 3. Гойко Аджич "Изобретаем качество"

Продолжаем традиционную серию постов-обзоров. На этот раз я взял панорамный доклад в формате "рассказ историй" (story telling).

Итак, Гойко Аджич "Изобретаем качество" (Gojko Adjic - Reinventing Software Quality). В интернете есть несколько видеоверсий доклада (а общее число выступлений Гойко с этой темой - более двухсот), в каждой новой версии автор что-то изменяет, дополняет. Но общая канва остается. Как и формат - отличные живые истории с долей юмора, которые показывают неразрывную взаимосвязь тестирования и реальной жизни и их взаимное влияние друг на друга.

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

Рекомендую этот доклад тем, кто смотрит вперед, кому небезразлично, как и зачем он тестирует (а не просто "что-то проверил и написал отчет").

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

Конспект:

  • В 2004-м году потери на проектах ПО составили 1,4 млрд $
  • качество ПО означает абсолютно разные вещи для разных людей.
  • Пример: Англия, банкомат Deutsche Bank'а, вначале заблокировавший карточку, затем он выдал деньги, без транзакции на счету
  • Итерация цикла качества - измерять, обеспечивать, улучшать - за последние 10 лет сократилась с одного года до двух недель в agile. Вопрос, что тестировать и не тестировать в цейтноте времени.
  • Пример одного проекта, в котором автотесты были написаны ровно до того момента, на котором они все вернули passed, затем они были выключены.
  • Пример: GPS -  "нет нужды в GPS, когда он отключился и я заблудился, мне нужен GPS для того, чтобы он не допускал, что я заблудился".
  • Качество ПО - это информационное искусство, зеркало команды.
  • Пример: друг, который подбирал туфли (аналогия - улучшал часть процесса), хотя сам был похож на тролля (аналогия - весь процесс уродлив, нужно изменять его целиком).
  • ART (искусство) как акроним аккуратности (accurate), релевантности (relevant), своевременности (timely). 
  • Мы научились быстро и аккуратно считать (A + T done), но у нас остались проблемы с релевантностью (R). 
  • "Ценность метрики - это в своей основе, ценность информации, которую эта метрика приносит." Даг Хаббард
    Пример: инфомационное табло аэропорта в Хитроу (Англия). Какие выводы мы можем сделать из полученных метрик?
  • В переводе с языка QA на язык бизнеса, качество = стоимость (QA = cost)
  • Пример: книга самого докладчика, ошибки в переводе: Гойко потратил немало времени на внимательное перечитывание своей книги и нашел 27 опечаток наивысшего приоритета (например, заглавная буква в середине слова и т.п.), а всего 159 опечаток. Затем посмотрел отзывы о книге - все 21 отзыва - "пять звезд". Nobody cares about such mistakes. Вывод - инвестируем время в качество более продуктивно.
  • Пример, когда пробный выпуск продукта может стоить дешевле, чем прогон всех регрессионных тестов. "больше не значит лучше"
  • Пирамида Маслоу и ее проекция на пирамиду качества от Гойко Аджича:
  1. развертываемая функциональность исправна (deployable functionality OK)
  2. производительность, безопасность (performant and secure)
  3. удобство использования (usable)
  4. полезность (useful)
  5. успешность - бизнес-ценность (successful)
Подумайте над тем:
  • Как эта пирамида будет выглядеть для вашего ПО?
  • Что вам следует измерять?
  • В какие области обеспечения качества вы можете инвестировать (свое время)?

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

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

четверг, 6 июня 2013 г.

Встреча QA Club Minsk. Как тестировать, когда нет времени и людей?

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

Вечером в среду после обеда сон для усталых Игорь Бондаренко нам рассказывал "Как тестировать, когда нет времени и людей". Я хорошо знаю Игоря, мы оба работаем в Intetics, знаю его команду и коллег, и хочу просто выразить респект за то, что Игорь сделал и о чем нам рассказал. Проще всего сказать "у меня нет времени", "мой рабочий день с 9 до 6 и ни минутой больше" и изобразить страуса перьями кверху, потому что раз всех все устраивает, то и мне, QA, больше всех надо что ли? А можно просто нести ответственность, как, например, описано у Натальи Руколь. А как нести ответственность, когда недостаточно ресурсов, Игорь нам и рассказал.
традиционный "кирпич" от Игоря. Фото - QA Club Minsk
Итак, принимаем проект. Есть стартовые проблемы (как же все знакомо) :

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

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

Всем лета!





вторник, 4 июня 2013 г.

Самообразование. Done! Coursera - Grow to Greatness: Smart Growth for Private Businesses, Part II.

Очередной курс онлайн-обучения Coursera пройден. На этот раз - вторая часть курса Grow to Greatness. Еще один отличный курс, многое взял на заметку и добавил в конспект (карту памяти  см. внизу поста).

Ed Hess, преподаватель курса Grow to Greatness
Чем же так хороши вообще курсы Coursera, и почему я бы вам рекомендовал попробовать для своего развития:
  • Представлены онлайн-курсы ведущих американских университетов по самой различной тематике и дисциплинам - https://www.coursera.org/courses. Онлайн-курса по тестированию, к сожалению нет, но довольно много курсов по Computer Science: от теории и искусственного интеллекта до программирования и безопасности. Да и по остальным темам есть интересные курсы, так что советую не ограничиваться только профильной тематикой.
  • Язык преподавания - английский (есть курсы на французском и испанском, их пока мало), есть возможность смотреть видеолекции с субтитрами. Одновременно с обучением, можно "прокачивать" свой English. Уровень английского - где-то Intermediate (B1)- Upper Intermediate (B2), если смотреть с субтитрами, практически все понятно с первого раза.
  • Хорошо выстроенный процесс обучения: кроме просмотра лекций, есть тесты (Quiz) как с единственным правильным, так и несколькими правильными вариантами ответов, эссе на заданную тему, оценка вашей работы коллегами (Peer Evaluation) - оценивают как вас, так и вы другие работы. И, наконец, во многих курсах есть финальный экзамен (Final Exam), ограниченный по времени и/или использованию сторонних материалов. Есть форум для обсуждения В перспективе появится работа в группах на форуме.
  • Есть чему поучиться у преподавателей. Очень высокий уровень каждого (или мне так повезло, я прослушал полностью 5 курсов, у каждого из профессоров есть свои "фишки", что-то взял на заметку).
  • Можно одновременно изучать несколько курсов. Но я бы, для лучшего усвоения, рекомендовал брать один. Количество курсов можно планировать по часам, которые даются в описании курса (например, "Workload: 4-6 hours/week" - эстимации для меня получились довольно точными, приблизительно так по времени и выходило). Можно записаться на несколько курсов, просмотреть первую неделю, оценить, насколько вам подходит тема данного курса и преподаватель, и решить, продолжать ли обучение).
  • Онлайн-обучение бесплатно. Все видеолекции, материалы. Если есть желание и необходимость - можно официально, с подтверждением, получить сертификат об окончании выбранного вами курса за энную сумму. Например, https://www.coursera.org/signature/course/introfinance/970308 Но в любом случае, создатели говорят, что курсы будут бесплатными всегда (см. интервью с создателем Coursera, целях проекта, статистику об онлайн обучении, можно почитать здесь - ссылка)

Немного о содержании. Первая часть курса (Grow to Greatness - Part 1) была о построении команд, мифах и реальности. Очень интересный и полезный курс, который мне пригодился: я проанализировал свой опыт работы в различных командах, что получалось, а что нет, как бы я сейчас строил процесс построения команды тестирования, рассказал об этом на SQA Days - 12 в Санкт-Петербурге и использую сейчас на практике.

Вторая часть курса делает акцент на взаимодействии с людьми: заказчиками, коллегами, подчиненными. Основные моменты:
  • Предприниматели тоже должны расти - первая неделя. Теория Дугласа МакГрегора (категории людей X и Y), 6 переходов в трех категориях, которые должен пройти предприниматель на пути к личностному росту, делегирование, лидерство, процессы, метрики;
  • Секрет высокой производительности - высокая вовлеченность подчиненных в работу. Вторая неделя. Как достичь высокой вовлеченности, чего хотят подчиненные, 4 принципа лидерства, ответ "да и" вместо "да, но", самые важные слова лидера;
  • Рост требует не только стратегии, но и системы - третья неделя. "Бизнес как мороженое", рост - органический процесс, как получить от подчиненных высокую вовлеченность, требования к системе организации, построение системы;
  • Строим продвинутую управленческую команду - неделя четвертая. Интервью, процесс найма, конфликт "повышение подчиненного - лояльность", какого менеджера нанять первым;
  • Самое главное - разбор кейсов, всего 4 кейса, по одному на каждую неделю. Теория и принципы разбираются на практических примерах уже успешных компаний. Must read! Интегрирующая все 4 недели часть курса, пожалуй, самая интересная и вдохновляющая.
Более подробно содержание курса вы можете посмотреть по моей составленной карте памяти:

пятница, 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