Показаны сообщения с ярлыком SQA Days. Показать все сообщения
Показаны сообщения с ярлыком SQA Days. Показать все сообщения

четверг, 18 июня 2015 г.

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

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

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

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

Никита Налютин "Миграция 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 докладов первого дня конференции:
      Мой топ-3 ожидаемых записей докладов, которые я пропустил (положительные отзывы коллег):
      Перехожу к докладам в хронологическом порядке. Каждому докладу я поставил оценку за мастерство докладчика+презентацию и оценку за содержание доклада, принятой в шкале в  голосовании 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!

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


          вторник, 16 июня 2015 г.

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

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

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

          Конспект не претендует на полный сборник идей и мыслей, прозвучавших на тренинге. Для знакомства с техникой Risk Based Testing (RBT), дополнительно рекомендую источники:
          Каждый участник получил ссылки на запись курса и сборник материалов для ревью и пересмотра. Курс состоял из 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!


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

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

          Всем привет!

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



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

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

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

          Quality Assurance.


          Test Automation.

          Management.

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

          четверг, 1 мая 2014 г.

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

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

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

          •  внутренний тренинг в компании с игровыми элементами, тут пригодились и мои знания по геймификации. Пилотный запуск оказался успешным, продолжение следует.
          • Участие и выступление в конференции SQA Days-15, обзор уже писал: первый день и второй день
          • Участие в тренинге Майкла Болтона "Критическое мышление для тестировщиков". Обзор и конспект можно почитать здесь - http://qastugama.blogspot.com/2014/04/training-michael-bolton-critical-thinking.html
          • С 21 апреля прохожу курс BBST:Foundations, нагрузка получается 10-12 часов в неделю, много практических заданий, самостоятельного чтения, работы в группах, и все это в условиях довольно жестких сроков для каждого задания. 
          Так как сейчас практически все "свободное" время у меня уходит на обучение BBST, то в конце мая планирую написать о курсе и впечатлениях, а пока, если будет время - продолжу серию про экзамены ISTQB и пополню  коллекцию - Книжную Полку (прочитанные книги есть, дело за обзорами).


          Теперь к ссылкам. Разбиение на группы остается прежним-традиционным:

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


          Quality Assurance.

          Studying.

          Gamification.

          Management.

          Books.

          Other.

          Bonus. Fun.

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

          воскресенье, 27 апреля 2014 г.

          Тренинг Майкла Болтона "Критическое мышление для тестировщиков". Мой обзор.

          На конференции SQA Days-15 в Москве было много классных докладчиков, но приглашение на юбилейную конференцию Майкла Болтона - это вишенка на вкусном торте. Полуторачасовой доклад собрал полную аудиторию: в конце второго дня Майкл дразнил пивом, троллил продукты Майкрософт, но главное - разбирался вместе со слушателями, в чем проблема?

          А на следующий день, 20 апреля, Майкл Болтон проводил восьмичасовой тренинг "Критическое мышление для тестировщиков". Анонсы про тренинг были еще за 2 месяца до конференции, участникам SQA Days была скидка 10% на тренинг, но народу собралось непривычно мало: всего 15 человек (в том числе я с коллегами Игорем Бондаренко и Сергеем Остапенковым) приняло участие. Довольно неожиданно, ведь нечасто к нам приезжает звезда по тестированию такого уровня...

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

          Мой нижеприведенный конспект не отразит все то множество мыслей и идей, затронутых на тренинге, но поможет вам (и мне) восстановить хронологию событий, как это было, и узнать что-то новое. За более подробной информацией обращайтесь к первоисточнику на последующих тренингах, или почитайте статьи Болтона на его сайте - http://developsense.com/

          Слайды Майкла Болтона с конференции Eurostar по данной теме "Critical Thinking for testers" можно взять здесь - http://www.developsense.com/presentations/2012-11-EuroSTAR-CriticalThinkingForTesters.pdf

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


          Рефлекс важен, но критичное мышление - это рефлексия.
          Что ты видишь - это все, что есть (c) Майкл Болтон ("What you see is all there is")
          Технологии более сложные, чем вещи, происходящие в реальной жизни. Но тестировщики не должны быть одурачены.
          Тестировщик - тот, кто знает, что вещи могут быть разными.

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

          Алгоритм поиска закономерности - creep and leap.
          No experience about the past can logically be projected into the future, because we have no experience OF the future.
          Passing tests cannot prove software is good. 
          Critical thinking is thinking about thinking with the aim of not getting fooled (c) Michael Bolton.

          Затем Майкл говорил о тестировании и проверках (testing-vs-checking) - я публиковал в блоге перевод исходной статьи - http://qastugama.blogspot.com/2013/09/blog-post_6.html И немного о том, что все думают, что делают тестировщики (сравнивают продукт со спецификацией, круги described-actual), и что тестировщики делают на самом деле (круги imagined-described-actual) - вначале мы сами обсуждали данные круги, затем обсуждали свои результаты с Майклом. И на десерт данного блока - задача "сломанный калькулятор": я уронил калькулятор, возможно, он поврежден, как я должен проверить его работоспособность.

          Следующая часть - блок про предпосылки, утверждения и выводы. И о том, что делает утверждения более опасными (безосновательными и ведущими к ложным выводам). О помогающих вопросах, чтобы не попасться в ловушки (Huh? Really? So?) - эти вопросы также позволяют восстановить контекст.


          It is silly to say “don’t make assumptions.” Instead say “let’s be careful about risky assumptions.”


          Book "Perfect Software and Other Illusions About Testing" by J. Weinberg


          Следом  - практическая задача-диаграмма с одним ветвлением: A < 70? Если да, то выполняем 1, если нет, то выполняем 2. И вопрос, сколько кейсов. Очевидный ответ 2 неправильный: каждый блок диаграммы может содержать несколько действий, каждое из которых тоже необходимо проверять:

          Things that don't appear on diagram are easy to forget.
          The feature worked. -> I've not yet seen any failures in the feature.

          Далее мы говорили о "безопасном языке" (в тестировании это оценка и использование безопасных формулировок с целью избежания ложной уверенности) и вербальных эвристиках (Unless, And also, Or Not, So far & Not Yet), разбирали статьи с безопасным языком.

          The Regression Testing Fantasy “I rerun my old tests to ensure that nothing has broken.”

          Books:
          Gerome Groopman "How Doctors Think"
          Gerd Gigerenzer "Gut Feelings: The Intelligence of the Unconscious"

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

          Восемь часов пролетело очень быстро, не хотелось расходиться, да и была еще возможность попить пива с Болтоном второй раз за два дня, но впереди ждали поезд и Минск :) Московские три дня пролетели очень быстро, продуктивно, насыщенно, много знакомств, общения со старыми знакомыми, новые идеи, мысли, пивное афтепати в Гамбринусе, критическое мышление Майкла Болтона... Вобщем, нужно встречаться, хотя бы раз в полгода. До встречи на следующей SQA Days!

          четверг, 24 апреля 2014 г.

          SQA Days-15 в Москве. День второй.

          Продолжение. Обзор первого дня - http://qastugama.blogspot.com/2014/04/sqa-days-15-1st-day.html

          После первого дня и афтепати пришел второй день, причем с не менее интересными докладами: Объяснение довольно простое - в субботу выступали Александров, Налютин, Руколь, Баранцев, Цепков и Болтон. Причем к докладу Майкла Болтона организаторы поставили в параллель Алексея Баранцева и Максима Цепкова с очень интересными темами, так что казавшийся еще до конференции очевидным выбор - "Ну конечно, Болтон!" - растерял былую уверенность и склонился к нашим гуру: все-таки у нашего трио с Intetics - меня, Сергея Остапенкова и Игоря Бондаренко - еще был впереди целый восьмичасовой тренинг от канадского гуру в мире тестирования. Но обо всем по порядку.

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

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

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

          Далее от требований переходим к либо чек-листам, либо к непосредственному тестированию "прямо по требованиям", либо к тест-кейсам.

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


          Григорий Сенин "Waterfall revisited: практические метрики тестирования"

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

          Q = P3 * P2 * P1
          • P3 - коэффициент багов = количеству закрытых багов ко всем найденным (Closed / All Found). "Третий (красный) стакан" системы.
          • P2 - процент выполненных тестов из числа написанных (Test Executed / Tests Desinged). "Второй (синий) стакан" системы.
          • P1 - процент написанных тестов из числа всех тестов (Test Designed / Test Planned). "Первый (серый) стакан" системы.
          Затем были рассмотрены примеры из цикла жизни продукта, как выглядят эти стаканы в данных случаях:
          • Разработка в разгаре (Р3 = 0, дефекты не исправляются)
          • Разработка на финише (Р1 = 1, кейсы написаны)
          • Шлифовка подсистем (Р2 = Р3, все найденные баги исправляются)
          • Разработчики задерживают тестирование (Р2 близко к нулю, Р3 равно нулю)
          • Требования задерживают разработку (Р1 = Р2 = Р3)
          После этого докладчик на практических примерах показывал работу с показателями, взаимосвязь "стаканов" с burndown-chart'ом в Agile (прогноз скорости исправления, "зазор качества" и тем, откуда взять данные для подсчета коэффициентов-"стаканов".

          В целом, идея интересная, простая и наглядная, поэтому выглядит заманчивой: не требует значительных затрат для подсчета.



          Игорь Бондаренко "Crystal Agile, или как мы приспособили процесс разработки для обеспечения максимального качества".

          Лучший "процессный" доклад конференции. Как мне кажется, он бы не затерялся и на менеджерской конференции, и на Agile-конференции. О том, как процесс из "классического" скрама из-за особенностей проекта и процесса (один тестировщик на проекте, и больше заказчик не хочет) превращается Crystal-процесс, при этом сохраняя требования к Crystal: ориетирован на людей, легкий и "stretch-to-fit". Процесс перехода занял 5 лет и все еще продолжается, поэтому не бойтесь экспериментов и работайте над качеством всей командой. И да, будьте человеком, который недоволен текущим процессом: кто как не мы должен быть рупором для улучшений. Авторские шаги получения данной методологии:
          • Отказываемся от TDD в пользу BDD;
          • Планирование - "метод взвешенных экспертных оценок";
          • Формируем резерв спринта: загружаем спринт на 9 из 10 дней. Если появляются "горящие задачи" - тратим время на них, либо по приоритету, на уменьшение технического долга;
          • Митинги - стэндапы не нужны
          • Автоматизация: "наличие некрасивого теста лучше, чем его полное отсутствие"
          • SOAP UI - для сервисов
          • Вовлечение разработчиков в автоматизацию



          Александра Ковалева "Планирование трудозатрат на тестирование"

          Отметил для себя хороший и доступный уровень подачи доклада Александры еще на конференции SQA Days-12 в Минске, затем у нее был доклад про тестирование локализаций, вошедший в десятку на SQA Days-13 в Питере. Да и тема была для меня актуальная, поэтому мой обед ушел ко второй смене, а внимание - к планированию трудозатрат от Александры.

          Планирование тестирования состоит из следующих шагов:
          • Определение требований к тестам
          • Оценка рисков
          • Разработка стратегии тестирования
          • Оценка ресурсов
          • Разработка тест-плана
          • Создание графика работ
          Все шаги были доступно и с долей юмора преподнесены, информация есть на слайдах, а видео я порекомендую ждать тем, кто хочет увидеть реальный пример составления графика работ по тестированию на MS Project. Баланс теории и практики на 40 минут, хотя изначально, как я понял, он был составлен на 1 час 30 минут. Но... время ограничено, а другие докладчики тоже постарались, поэтому на конференции было всего 2 полуторачасовых доклада: упомянутый в первом дне конференции доклад Катерины Овеченко и завершающий второй день и всю конференцию Майкл Болтон.



          Андрей Ладутько "Организация времени в тестировании".
          Мой доклад, засветившийся только в обзоре моего коллеги Игоря Бондаренко, поэтому моя оценки субъективны и могут не соответствовать реальности :) Первая версия этого доклада завоевала третье призовое место на ConfeT&QA в октябре 2013 года, а затем, анализируя отзывы по докладу, меня посетила идея попробовать хронометраж в своей работе и рассказать подробнее об этом мощном и недооцениваемом инструменте тайм-менеджмента. Отброшенной оказалась еще часть теории, я добавил обзор хронометража и его эволюцию, как для себя, так и для коллег с поправкой на специфику работы каждого тестировщика.

          Ask 100 testers to describe their job and you'll get 100 different answers.
          Lucas Dargis.

          Таким образом, от первоначального доклада осталась лишь треть, в пожеланиях к докладу, прозвучавших на репетиции доклада в минском QA Club'е, были еще больше практики и личного примера. Надеюсь, мне удалось этого добиться в выступлении, а пока я поставлю в планах подготовить текстовую версию данного доклада в блоге, как я в свое время делал с докладом по организации времени в тестировании на SQA Days-13: первая и вторая части.

          Станислав Башкирцев, Юлия Атлыгина "Тестирование в опенсорс" (блиц).

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



          Дарья Костюк "Путь к трассировке требований: от идеи к инструменту" (блиц).

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


          Алексей Баранцев "Тестирование на основе моделей: "ужас-ужас" или всё не так страшно?"

          Сначала Алексей немного "потроллил" менеджерские доклады конференции и заявил техническую тему: Model Based Testing, или тестирование на основе моделей. С помощью Selenium Webdriver'a Алексей в прямом эфире закодировал простейший кейс с одним cостоянием системы и двумя возможными переходами "login-logout" и используя "магию" неизвестного фреймворка, генерирующего тесты на основе моделей (вместо традиционных линейных тестов). Но вот в "магии" вопрос остался открытым: то ли это бесплатная свободно распространяемая библиотека (что очень хотелось бы), либо новейшая закрытая разработка. Но подход интересный, а доклад оказался не таким уж сложным для понимания: я бы вместо трех заявленных звезд сложности оставил две. Но в целом, доклад и подход интересный, что тоже ожидалось, если вы были раньше или смотрели видео докладов Алексея.

          Рина Ужевко, Андрей Мясников, Максим Цепков "Вы и Заказчик: решаем проблемы, а не отрабатываем требования".

          Последний доклад московской конференции, партия, разыгранная на 3 докладчика, причем каких! Все имеют опыт выступления на конференциях, являются призерами конференций, и каждый со своей стороны - игры, продуктовая и заказная разработка - показывал на кейсах проактивно-сотрудническую работу с заказчиком. Итого, самая эмоциональная часть получилась у Рины (досталось же ленте малоизвестной соцсети Лицокнига), самая аналитическая - у Максима, а самая суровая и "мемистая" - у Андрея: мем про путиницу с большим отрывом занял второе место после боевого тестирования данных на проде работником Сбера, набравшего к моменту написания статьи 202 ретвита. Ну а суровость Андрею за правду жизни: "если в продукте есть косяки, которые появились из-за непонимания заказчиком и разработчиком друг друга, то не заказчик дурак, а ты виноват. Виноват всегда исполнитель." Так вот. Ну а вместе - отличный "тройной" доклад.


          На этом я заканчиваю с докладами, в следующей статье я напишу о семинаре Майкла Болтона. Коллеги, было очень приятно завести новые знакомства, встретить старых знакомых, пообщаться в кулуарах и баре, побывать в Москве, обменяться идеями, послушать ваши интересные доклады, поделиться своим опытом. До встречи на следующей SQA Days!