SQA Days-17. Обзор второго дня конференции

Был вечер первого дня, и было афтепати, и наступил второй день конференции SQA Days.

Как и в обзоре первого дня конференции, каждому докладу я поставил оценку за мастерство докладчика+презентацию и оценку за содержание доклада, принятой в шкале в  голосовании SQA Days: 1 балл - отлично, 0 баллов - хорошо. Минусы я не ставил. В обзор я дополнительно включаю доклады, которые я посмотрел на репетиции докладов SQA Days, состоявшейся благодаря встрече минского QA Club 23 мая.

Топ ожидаемых записей докладов, которые я пропустил (положительные отзывы коллег):

• Алексей Лянгузов "Беседа о тестовых данных"
• Алексей Петров "Организация эффективных процессов тестирования: Zephyr в шоколаде"

Никита Налютин "Миграция JIRA - безобразие или безрассудство"

(+1 докладчик и презентация, 0 содержание доклада)

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

• Переезд Джиры в маленькой и средней компании линейный (последовательно финансы и закупки, железо+софт, пользователи) и прогнозируемый
• В миграции участвует команда от администратора JIRA до отделов закупок и информационной безопасности

Алена Дашкевич "Улучшить KPI в два раза? Сделано!"

(+1 докладчик и презентация, +1 содержание доклада)

Доклад о тест-менеджменте и оптимизации процессов. Success story на проекте с командой в 150 человек, из них 50 тестировщиков. Целевой KPI для улучшения - часы тестирования на story points. При первом замере KPI =4.31 часа (тестирование - узкое место), после оптимизации - 1.29. Советы Алены - готовый чеклист для улучшений на проекте - анализируй для проекта и применяй:

• Метрики нужны не только для менеджеров, но и для себя, чтобы понимать проект мертв или жив
• Заказчик делает демо-сессии, которые выкладываются в базу знаний и помогает с расстановкой приоритетов
• Чеклисты вместо тест-кейсов (уточнить формат, степень детализации, содержание, цвета, специфические данные)
• Второй монитор: в одном смотрим приложение, во втором - пишем чек-лист
• CI и установка сборки
• Тестовые данные - автоматизированные скрипты для создания
• Работа с багами: общие правила создание, объединение по причинам, избегание дубликатов - проектный чат, в котором тестировщики обсуждают, заведен ли такой баг
• Анализ багов и ошибок пользователя, причин пропущенных багов
• Митинги - оптимизация, внедрение best practices, которые сработали у подкоманд, ретроспективы
• Полезные метрики для оптимизации: количество багов заказчика на 1 story point, количество раундов тестирования для фич (больше 2 - надо разбираться)

Александр Сербул "Тестирование высоконагруженных облачных веб-сервисов в Amazon - подводные камни и надводные скалы"

(+1 докладчик и презентация, 0 содержание доклада)

Докладчик сразу удивил страшной схемой (на фото) и образностью языка: "UML написан кровью" "менеджмЕнт" "менеджер - волшебник Изумрудного города". Докладчик и его стиль напомнили Евгения Гришковца. Слайды переполнены информацией, объем рассказа перекрывал вдвое время доклада. И Александру не хватило времени, чтобы все рассказать. Доклад получился несбалансированным: интересные "облачные" вещи смешались с очевидными процессными ходами и лирическими отступлениями. Улучшение доклада - оставить самое интересное о cloud и выкинуть известное, о чем говорили и написали. Похожий метод проходил с докладом моего коллеги Сергея Остапенкова "Обеспечение качества - практические советы" на SQA Days-15.

Александр Стельмах "Все твои ходы записаны"

(+1 докладчик и презентация, +1 содержание доклада)

Саша - мой коллега, эксперт в мобильном тестировании и организатор Mobile Testing Community в Минске. Саша рассказал о примерах из жизни, сборе аналитики в мобильных приложениях, ее типах, о причине паранойи пользователей и как учитывать в тестировании.

• "Гугл вы разрешили и попросили отслеживать вашу геолокацию. Недалеко ушел и Apple. Лучше проявил себя Windows Phone: он в Windows манере спрашивает: вы точно хотите, чтобы за вами следили?"
• Samsung и LG отсылают личную информацию и следят за вами в IPTV
• NSA взломало сим-карты Gemalto
• Virus Shield для Android - "пустышка"
• Сканер пальца взламывается по фото
• Определение пин-кода по взгляду

Сбор аналитики приносит пользу:

• Парк устройств из статистики пользования
• Тестовые сценарии навигации по экранам
• Сбои приложения

Екатерина Засухина "Маленькое кладбище багов"

(+1 докладчик и презентация, 0 содержание доклада)

Блиц доклад о четырех уроках из жизни Екатерины в тестировании. Познавательный доклад для новичков.

• "Если что-то ломалось дважды, то оно неотвратимо сломается в третий раз"
• "Самое эффективное средство как для мотивации, так и для демотивации – личный пример"
• "Тестовые площадки могут не соответствовать продакшну"
• "Все инциденты нужно рассматривать не только с точки зрения быстрого устранения проблемы, но и с позиции «как не позволить проблеме повториться»"

Александр Мартинович "Как методы естественных наук могут помочь в тестировании"

(+1 докладчик и презентация, +1 содержание доклада)

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

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

Антон Капитаненко "ССР или Сколько Стоит Ретроспектива?"

(+1 докладчик и презентация, +1 содержание доклада)

Антон рассказал об оптимизации ретроспектив в распределенных командах из 15-20 человек. Оптимизации считались из баланса "стоимость возможных улучшений VS стоимость потерь" и применялись на этапах ретроспективы.

Александр Уланов ""Дедуктивный метод тестировщика". Ищем баги анализируя статистику"

(+1 докладчик и презентация, +1 содержание доклада)

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

Иванна Мельник "Мотивация - 36.6° Или MTWH как термометр определения температуры мотивации"

(+1 докладчик и презентация, +1 содержание доклада)

Иванна рассказала об инструменте отслеживания мотивации MTWH (Mood Tools Work Horizon). Сначала менеджер анализирует сотрудника по 4 параметрам по пятибальной шкале:

• Mood - с каким настроением человек пришел на работу
• Tool - технический уровень знаний
• Work - насколько человеку нравится то, что он делает и хорошо ли он выполняет работу
• Horizon - перспективы, какой следующий шаг по карьерной лестнице

Затем собственные  оценки менеджер "сравнивает" (ВАЖНО - не рассказывает) свои субъективные оценки с ожиданиями сотрудника и делает выводы и следующие шаги.

Анна Винькова "Тестирование тестировщиков. Нейрофидбэк в QA"

(0 докладчик и презентация, +1 содержание доклада)

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

Андрей Ладутько "Как оценить процесс тестирования на проекте"

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

Спасибо аудитории за активное участие на исходе второго дня, за вопросы и положительные отзывы в блогах (Рома Шейко, Андрей Мясников)! Я рад, что доклад получился. Но далек от мысли, что доклад прошел идеально: жду видеозаписи и буду смотреть, над чем еще нужно работать.

На этом обзор двух дней докладов конференции заканчивается. В следующем посте я поделюсь общими мыслями и идеями по конференции. Лета, и оставайтесь с Qastugama!

SQA Days-17. Обзор первого дня конференции.

После дня тренингов Рекса Блэка ("Risk Based Testing") и Пола Геррарда наступил первый день конференции SQA Days.

Сегодня я расскажу только о докладах первого дня конференции. О докладах второго дня и об общем впечатлении о конференции я расскажу отдельными постами. В обзор я дополнительно включаю доклады, которые я посмотрел на репетиции докладов SQA Days, состоявшейся благодаря встрече минского QA Club 23 мая.

Мой топ-3 докладов первого дня конференции:

• Paul Gerrard "How to Test the Internet of Everything"
• Сергей Атрощенков "Моделирование угроз для приложений"
• Vojtech Barta "QA as responsibility of Whole Team"

Мой топ-3 ожидаемых записей докладов, которые я пропустил (положительные отзывы коллег):

• Александра Волкова "10 принципов автоматизации, которые я не предам" - первое место конференции.
• Катерина Овеченко "Fuzzing - автоматическое тестирование безопасности"  -  мастер-класс. Выступление Кати в Москве на SQA Days-15 мне понравилось и запомнилось (запись не сохранилась).
• Роман Шейко "Принятие решений в тестировании на примере тестовой стратегии" - близкая мне тема, и Рома растет как докладчик и организатор Weekend Testing.

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

Сергей Атрощенков "Моделирование угроз для приложений"

(+1 докладчик и презентация, +1 содержание доклада)

Первый доклад - и сразу сложный выбор между докладчиками: Рекс Блэк эстимировал в секции А, а Игорь Бондаренко рассказывал о безопасности мобильных приложений в секции С. Но в моем рейтинге победил Сергей Атрощенков, и вот почему:

• рекомендация Игоря Бондаренко, он член ПК и докладчик 8 конференций SQA Days, из них - 5 докладов по безопасности
• формат мастер-класса - взаимодействие со слушателями и запоминание лучше, чем в формате лекции
• близкая мне тема (работал над моделированием угроз за неделю до конференции)

Сергей рассказал об угрозах, проблемах с безопасностью, и моделировании угроз. Затем Сергей перешел к модели STRIDE и составляющим, построению диаграммы угрозы и применению к ней STRIDE, и об обработке угроз. И на десерт - рассказ о бесплатной Microsoft Threat Modelling Tool 2014 - она автоматически генерирует на основе построенной модели угрозы и отчеты по мненомонике STRIDE.

Соглашусь с отзывом Алексея Виноградова, что времени 40 минут на мастер-класс - мало и не достаточно для полноценного мастер-класса: 20 минут ушло на введение и "разогрев" аудитории в неспешном темпе, а вторые 20 минут - информационно плотные и быстрые.Но есть презентация и запись доклада, рекомендую к просмотру и работе со ссылками и тулой.

• Модель STRIDE в формате Mind Map - здесь

Paul Gerrard "How to Test the Internet of Everything"

(+1 докладчик и презентация, +1 содержание доклада)

Пол Геррард подготовил красочный футуристичный рассказ о будущем, которое ждет нас через 10-20 лет, - Internet of Everything, или Интернет Всего. Это тысячи взаимодействующих статических, мобильных устройств и приборов (сенсоры, автомобили, автобусы, электроинструменты в домах, больницах, на работе), взаимодействующих между собой и интегрированных в сотни сервисов и платежных систем. Возникают проблемы тестирования IoE, о которых говорил Пол Геррард и сделал прогнозы, как будут решать эти проблемы тестировщики через 20 лет:

• Области развития для тестировщика IoE: непрерывная доставка (Continuous Delivery), DevOps, автоматизация и компьютерная симуляция;
• Как эмулировать функциональное тестирование, интеграцию и взаимодействие тысяч приборов и сотен сервисов
• Тестирование производительности, нагрузочное и стресс-тестирование
• Тестирование сетей, тестирование безопасности на различных уровнях
• Тестирование Big Data: логистика, визуализация, backup / recovery
• Новая модель тестирования - описание здесь 
• "Automation will not make testing easy, it will make testing possible"

Тестовая стратегия IoE:

• Тест-дизайн на основе паттернов, использование оракулов
• Использование сильно отличающихся тестовых окружений: от моделирования окружения дома до города
• Программы для тестирования будут включать автоматизированную поддержку
• Большинство компонент будет тестироваться через API, web и другие сервисы

Rex Black "Case Studies in Success with Free Test Tool"

(+1 докладчик и презентация, 0 содержание доклада)

Рекс Блэк рассказал об успешном опыте внедрения бесплатных инструментов тестирования у заказчиков, с которыми он работает. Ключевая мысль доклада - "free tools are not free in terms of time", или на бесплатный инструмент мы тратим время, которое не бесплатно. Рекс Блэк рассмотрел бесплатные инструменты автоматизации пользовательского интерфейса, тестирования производительности, веб-сервисов, динамического и статического анализа, непрерывной интеграции, модульного тестирования, тест-дизайна, скриптовые инструменты.

Блэк не рассказал о бесплатных инструментах для управления тестированием, а на мой вопрос ответил, что "there is no data about test management tools". :(

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

• Для выбора инструмента GUI-автоматизации надо знать бизнес-контекст + посчитать ROI (разработка + сопровождение).
• Платная версия SoapUI содержит те же проблемы, что и бесплатная.
• Инструменты статического анализа показывают, что код написан синтаксически правильно, но не показывают, что код работает правильно.
• Скриптовые инструменты - слишком много инструментов и языков -> "Вавилонская башня".
• Лучше дописать готовый опенсорсный инструмент, чем писать самому инструмент с нуля.

Vojtech Barta "QA as responsibility of Whole Team"

(+1 докладчик и презентация, +1 содержание доклада)

Как метко заметила Рина Ужевко, "правильный доклад". Войцех рассказал как строить тестирование в Agile - "you cannot test quality in, you need to build it in". "Зубры" Геррард и Блэк задали высокую планку уровню докладов и ожиданиям слушателей от последующих докладчиков в секции А, но Войтех справился. Мне понравились и ответы на вопросы, они дали почувствовать практический, а не только теоретический опыт докладчика.

• All projects are based on Statement of Work (SOW), but it is hard to push to make the process real later in the project
• You need to have clear exit criteria
• There is no (dedicated) test phase in Agile
• Expectation agreements are important during
• Customer is ready to be involved whenever is needed
• Teach customers acceptance testing, but do not do instead of them

Юрий Малый "Monthly Operations Review"

(+1 докладчик и презентация, +1 содержание доклада)

Доклад о метриках и истории внедрения сначала на один проект, затем - на 4 других. Сборник универсальных метрик для проекта. Доклад легко воспринимается, на каждую метрику Юра приводит графики из рабочих проектов. Но чтобы собирать много метрик, вам нужно время и аппрув начальства. Если времени не хватает, собирайте там, где у вас "болит" (чтобы не тратить время и фокус) и подумайте об автоматизации сбора метрик.
Метрики, которые привел Юра, - burndown chart, velocity chart, hours of work, detailed activity trend (время на работы - development, testing, bugfix, meeting e t.c. - по спринтам), fault density (количество багов по компонентам), root cause category (причины багов), test case pass rate, test case quality coverage rate, automation efficiency, communication matrix.

Олег Коледа "Качественное тестовое задание? Без проблем!"

(+1 докладчик и презентация, +1 содержание доклада)

Блиц-доклад с примером технического тестового задания для миддлов и сеньоров. Задание - найти все ссылки на странице и составить список ссылок с ответами (HTTP response), которые они генерируют при нажатии. Тем, кто не видел доклад, рекомендую сначала скачать и попробовать пройти тестовое задание, которое составил Олег. (Спойлер) Чтобы найти все ссылки, вам понадобится знание html, firebug, обфускации, умение читать код и проверить ссылки в четырех браузерах.

Анастасия Симанович "Как повысить продуктивность команды тестирования: что говорят менеджеры, а что тестировщики "

(0 докладчик и презентация, +1 содержание доклада)

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

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

Наталья Руколь "Грабли тестировщика"

(+1 докладчик и презентация, 0 содержание доклада)

Доклад в формате "story telling" или 4 истории из жизни Натальи Руколь. Опыт и подача Наташи - на уровне "зубров". Главная идея доклада - "не бойтесь ошибаться, выходить из зоны комфорта - иначе не вырастете". Плюс начальное знакомство с алгоритмом и техниками решения проблем. В уровне сложности доклада я бы поставил одну звездочку, а не две.

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

Артём Рогудеев "О процессе интеграции на примере крупнейшего провайдера CAS в России"

(0 докладчик и презентация, 0 содержание доклада)

Сложный для восприятия доклад. Когда добавят запись - я пересмотрю доклад и возможно, поменяю оценку. Неконтрастные слайды в секции С едва читались, докладчик выступал первый раз на конференции, терминология (например, под интеграционным тестированием имелось ввиду системное интеграционное тестирование) - в итоге я понял процесс как тестируют CAS (Conditional Access System или система условного доступа), но итоговую картинку не сложил.

Екатерина Гайнутдинова "Делегирование. Повышаем шансы на исполнение."

(+1 докладчик и презентация, 0 содержание доклада)

Доклад Кати (как и доклад Наташи Руколь) по сложности не на две звездочки, а на одну. Катя рассказала о делегировании, сформулировала и объяснила с примерами 4 правила делегирования: сформулировать описание, указать принадлежность, выбрать страховку и установить точки контроля.

Роман Иовлев "Micro Model based testing"

(+1 докладчик и презентация, 0 содержание доклада)

О "тестирование на основе моделей, которое не так уж страшно", рассказывал и показывал пример Алексей Баранцев на конференции SQA Days-15. Роман рассказал об эволюции автоматизированного тестирования от автотестов и Page Object к BDD и тестированию состояний. Затем на примере Роман показал оптимизацию тест-кейса и перешел к генерации модели из тестов. Недостатки MBT - долгий первый результат и дополнительная поддержка модели - Роман предлагает решить с помощью перехода не к большим моделям, а к микромоделям, которые наглядны, понятны. Но есть две проблемы MBT:

• Нет Open-source инструментов, а платные - дорогие и сложные в освоении
• "Продать" заказчику MBT еще сложнее, чем продать BDD, ROI которого тоже еще надо обосновать в каждом конкретном проекте. Так что пока интерес к MBT чисто технический.

Первый день закончился, вечером ждало afterparty и второй день конференции, на который я шел с докладом. Но это уже другая, не менее интересная история. Продолжение следует. Лета, и оставайтесь с Qastugama!

>>продолжить чтение о докладах во второй день конференции

Тренинг Рекса Блэка "Risk Based Testing"

В январе я узнал две новости, которые зарядили май двумя события из разряда "must visit". Первая - в Минск снова едет конференция SQA Days! В 2012 году в Минске я впервые побывал на SQA Days-12 и выступил с докладом. Вторая - на конференцию приедут с докладами Рекс Блэк и Пол Джеррард! Но встал вопрос выбора, чей мастер-класс выбрать. И, как в 2008-м, когда я купил черную книгу "Ключевые процессы тестирования" (единственная книга Блэка, переведенная на русский язык), так и спустя 7 лет, я выбрал мастер-класс Risk Based Testing.

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

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

• вебинары Рекса Блэка "The Most Dangerous Fallacies of Risk-based Testing" и "Agile Risk based Testing A How to Guide"
• серия вебинаров Рекса Блэка "Risk Based Testing Videos (a year-long series)" в цифровой библиотеке на сайте - http://www.rbcs-us.com/software-testing-resources/library/digital-library
• статьи Quality Risk Analysis и A Case Study in Risk Based Testing
• выдержка из книги Рекса Блека о risk-based подходе - Advanced Software Testing Vol.2
• доклад Алены Дашкевич на SQA Days-12 "Risk-based testing management. От теории к современной практике"

Каждый участник получил ссылки на запись курса и сборник материалов для ревью и пересмотра. Курс состоял из 6 частей:

1. Определение Risk Based Testing (далее - RBT)
2. Идентификация рисков, связанных с качеством
3. Сбор и оценка рисков
4. Кейс-стади по RBT
5. Как формализировать или наоборот, увеличить точность RBT
6. Интеграция RBT в жизненный цикл разработки и тестирования

В первой части Рекс Блэк говорил о невозможности полного тестирования (как и Сэм Канер в курсе BBST: Foundations), определениях риска, quality and project risks, RBT и его преимуществах.

Риск - вероятность негативного результата (>0% и <100%)
Один человек не может знать все риски, но вместе с командой вы можете выделить большинство рисков. Вывод: не пытайтесь собрать все риски в одиночку.

Как организовать сбор рисков? Рекс Блэк предлагает серию митингов-брейнстормов "1-на-1" с заинтересованными лицами ("технарями" и "бизнесом") продолжительностью 90-120 минут каждый.

Вторая часть тренинга - идентификация рисков. Используйте фреймворки для обнаружения и классификации рисков (по аналогии с фазой тест-дизайна - чит-листы), содержащие список возможных рисков: чек-листы рисков, риски из старого стандарта качества ISO 9126 и нового стандарта ISO 25000 и другие. Пример категорий списка рисков Рекса Блэка - здесь.

Для каждой категории рисков назначается ответственный исполнитель и список тестов, которые отвечают за риск. "Граничный" риск, который попадает в две категории, делится на 2-3 риска так, чтобы каждый выделенный риск попал в отдельную категорию.

Quality risk -> test
Project risk -> manage, not test

В третьей части тренинга мы говорили о сборе и оценке рисков.

Анализ quality risks приводит к трем побочным продуктам, которые нужно собрать: проектные риски (ответственный - менеджер проекта), дефекты во входной документации (ответственный - бизнес-аналитик) и предположения, сущности (issues) и вопросы (ответственный - разработчик).

Каждый риск оценивается по двум параметрам: вероятность (Likelihood) и влияние (Impact). Есть много шкал для оценки параметров, самая распространенная - пятибальная: от 1 (наиболее вероятно) до 5 (очень маловероятно). Важно, чтобы все участники проекта:

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

 More "risky" features in agile must be delivered first (as early as possible).

Для оценки риска (RPN - risk priority number, номер приоритета риска) вероятность и влияние перемножаются и полученные произведения ранжируются. Риски с наименьшим произведением - самые важные. Для оценки необходимого количества тест-кейсов для каждого риска используется практический метод: от 20 для рисков с RPN = 1-2 до 0 для рисков с RPN = 16-25 (один из примеров, количество тест-кейсов зависит от проекта).

В четвертой части тренинга мы разбирали практический пример оценки рисков на реальном проекте: от анализа quality risks до "выравнивания рисков" (если риски "сваливаются" на начало или конец прямой RPN от 1 до 25).

Пятая часть тренинга рассказывает о возможных оптимизациях стратегии Risk Based Testing: формулы для эстимаций тестирования, таблица приоритетов рисков, failure mode and effect analysis (FMEA).

В шестой части тренинга Рекс Блэк говорил о применении RBT для последовательных и итеративных циклов разработки и для процесса тестирования (рассматривался generic test process, описание которого дается в ISTQB - Planning, Analysis, Design, Implementation, Execution, Evaluating exit criteria and Reporting, Closure).

RBT is ideal for sequential lifecycle.
In iterative lifecycle, you need to prioritize Bug Fix VS feature development.

Для каждой фазы процесса тестирования Рекс Блэк приводил графики и примеры оценки рисков. Например, на фазе дизайна - процент покрытия рисками с течением времени (похожа на диаграмму покрытия тест-кейсами продукта), на фазе выполнения тестов - круговые диаграммы с процентами рисков от наиболее до наименее вероятных, и для каждого процента рисков - круговая диаграмма со статусом тест-кейсов (Passed, Failed, Not Run).

И на десерт - еще одна практическая часть, работа с требованиями "почти реального" проекта. И автографы для желающих и фотография с Рексом Блэком на память.

Тренинг прошел быстро и продуктивно: прошло 8 часов, и за окном светило уже вечернее солнце. А мы, вооружившись методом Risk Based, готовились применить полученные знания на практике и встретиться с Рексом Блэком завтра, уже на первом дне SQA Days. Но это уже другая, не менее интересная история. Продолжение следует. Лета, и оставайтесь с Qastugama!

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

Всем привет!

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

SQA Days-17. How to assess QA process on the project from Andrey Ladutko

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

• Джоэл Спольски "Джоэл о программировании"
• Девора Зак "Управление для тех, кто не любит управлять"
• Фредерик Брукс "Мифический человеко-месяц или как создаются программные системы"

В июне добавлю обзор еще двух книг, следите за блогом!

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

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

Quality Assurance.

• Gojko Adzic - Your #1 BugMagnet requested feature now works- плагин для генерации входных значений в любое поле
• Elizabeth Hendrickson "I Prefer This Over That"
• Joel Montvelisky "5 tips to help you land your first job as a QA tester"
• Rosie Cherry "Thinking Positive In A Negative Testing World"
• Sticky Minds "When Really Good People Make Really Bad Decisions"
• Sticky Minds "What Are the Key Components of an Effective Test Strategy?"
• Sticky Minds "How to Attract and Retain Skilled Software Testers: An Interview with Judy McKay"
• Software Testing Blog "Three Surprising Findings From the Internet Trends Report for 2015"
• Ольга Киселева "Тур по ориентирам. The Landmark Tour"

Test Automation.

• Google Testing Blog "Multi-Repository Development"
• Алексей Булат "Как автоматизация портит тестировщика или почему нельзя без ручного тестирования"

Studying.

• Татьяна Черниговская «Как научить мозг учиться». Конспект лекции.

Gamification.

• Bunchball "Answering Your Top Gamification Questions"
• Top 5 Reads about Gamification

Management.

• Максим Дорофеев "Об опилках времени"
• Дмитрий Литвак "Пять минут  о трюке с НеДеланием."
• Радислав Гандапас о том, как правильно ставить цели и избавиться от каши в голове (видео)

Books.

• Норм Керт "Ретроспектива проекта", обзор Никиты Макарова
• Книги по тестированию и обеспечению качества QAHelp, раздел "Матбокс"

Other.

• Макс Крайнов "Безличные пассивные маразмы" - о том, как не надо обращаться в письме
• Максим Ильяхов "Три закона критики"
• Максим Ильяхов добавил оценку по шкале Главреда
• Стратоплан "10 симптомов того, что ты болен как профессионал"
• Мегамозг "Здоровый сон — 4 совета от космонавтов"

Bonus. Fun.

• Adme "20 иллюстраций о том, как смартфоны завладели нашей жизнью"
• Алексей Виноградов "Тестирование и футбол"
• QAHelp "Что нужно помнить тестировщику?"
• Максим Дорофеев "Вся боль прокрастинации в одном фото"

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

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

Продолжаю обзор 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.

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

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

Технико-тактические характеристики:

Год издания: 2013 (Манн-Иванов-Фербер)

Страниц: 224

Скорость чтения - выше среднего

Время на прочтение:  4-5 часов
Полезность - средняя

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

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

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

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

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

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

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

Приведу ключевые мысли и идеи из этой книги:

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

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

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

Благодаря акции 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 лет, некоторые вещи могут показаться слишком очевидными. Но автор аргументированно объясняет, почему он приходит к тем или иным действиям и выводам.

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

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

Для меня Максим Дорофеев один из лучших докладчиков и тренеров. Почему?

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

Доклады Макса со многих конференций есть в свободном доступе - http://cartmendum.livejournal.com/164238.html. Для тестировщиков рекомендую серию докладов  "Обезьянки против роботов" про плюсы и минусы автоматизации.

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

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

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

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

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

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

Только практика и действия помогут вам стать джедаем. И да прибудет с вами сила! Ставьте высокие цели и их достигайте :)

Рубрика "Почитай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.

• Хабр "Интервью с Джеймсом Бахом для DUMP2015"
• Michael Bolton "Blog: Very Short Blog Posts (27): Saving Time"
• Software Testing Blog "Auditing and Software Testing: What’s the Connection?"
• Rob Lambert "How do you measure the effectiveness of a tester? The only calculation you need." 
• Rob Lambert "How to get started in software testing – a few resources" 
• Joel Montvelisky "Peripheral vision and peripheral testing"
• Software Testing Help "6 Questions to Determine if a Candidate is Fit for the QA Job"
• Sticky Minds "Six Tips for Building a Better Load Testing Environment"
• QA Platform "World Quality Report 2015. Рекомендации. Часть 2"
• Ольга Киселева продолжает переводы серии туров Виттакера, следующий - "Тур, отмененный из-за дождя. The Rained-Out Tour "
• Наталья Логинова о книге "99 идей как стать круче в тестировании"
• Сергей Нестеренко перевел статью "Тестджамперы — взгляд на тестирование в Agile проектах "
• Сергей Нестеренко "Тестирование поля ввода номера кредитной карты"

Test Automation.

• Google Testing Blog "Just Say No to More End-to-End Tests" 
• Software Testing Help "10 Best Practices and Strategies for Test Automation"
• Eric Jacobson "Which Tests Should Be Automated? "
• Eric Jacobson "Don’t Bother Calculating ROI For Test Automation "
• Sticky Minds "Blunders in Test Automation: An Interview with Dorothy Graham" 
• Augusto Evangelisti "BDD is – BDD is not"

Studying.

•  UTest "Learn How to Get Your First uTest Paid Project"

Gamification.

•  Bunchball "What You Need to Make Your Gamification Project Succeed"
• "Top 5 Reads About Gamification: Let The Games Begin!"
• Лайфхакер "10 игр, которые научат ребёнка программированию"

Management.

• Quality on Time "Always working estimation techniques: 90% confidential interval"
• Максим Дорофеев "Срочное не важное vs важное не срочное. Что выбирает мозг?"
• Rob Lambert "10 Reasons Why Being A Scrum Master Sucks – And a job opportunity"
• Рэнди Райс "10 способов демотивировать свою команду тестирования", перевод Натальи Логиновой
• Максим Дорофеев "Еще раз о пользе записывания (или о вреде запоминания)"
• Владимир Кривенко "Ошибочная оценка сроков как причина провала проекта"

Books.

•  Лайфхакер "В библиотеку тем, кто хочет познать себя: книги, которые стоит прочитать"
• "Джим Кемп и процессный подход"
• Хабр "Конспект выходного дня: Миф о многозадачности"

Other.

•  Максим Ильяхов, создатель "Главреда", запустил третью версию Советов
• "Искусство ошибаться: 32 примера достойных 404 страниц"
• Алексей Лупан "Каждое дело должно заниматься своим делом"
• Константин Панфилов "Почему дисциплина гораздо важнее мотивации"
• "Цитата дня: как Google на самом деле проводит собеседования"

Bonus. Fun.

• Сергей Нестеренко "Если бы классики работали тестировщиками "
• Сергей Нестеренко "Если бы на НТВ выходили новости тестирования"

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