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!

Fun ConfeT&QA Осень-2013. Первый день. Обзор.

Всего две недели назад закончилась Chief, отгремели фанфары победителям и призерам (приятно, что в такой компании тестировщиков, мне удалось занять четвертое место и получить третий приз), как стартовала Fun ConfeT&QA. О формате Конфетки и ее плюсах и особенностях я уже рассказывал в одном из предыдущих постов, так что перейду сразу к докладам и докладчикам.

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

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

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

И в завершении - Алексей Баранцев с докладом "Баг не воспроизводится… Что делать?!". Отличный доклад от мастера, прекрасные запоминающиеся слайды, все четко разложено по полочкам. Как обычно, Алексей - один из главных кандидатов на победу в конфетке. Очень интересные истории про неуловимые баги. Рекомендуется к просмотру.
Небольшой конспект доклада:
- нашел баг - не значит поймал.
- если "нашел баг, но не знаю, что делал" - вспоминать поздно, нужно готовиться заранее: скринкасты, лог-файлы, дебаг, ручные заметки;
- "все повторяю в точности, но ... не воспроизводится" - ты уверен, что в точности?
- иногда - не надо все в точности: причина может быть в далеком прошлом, помним про скорость, баг может воспроизводиться только в первый раз;
- "пишите баг-репорты качественно"; +1
- помните про "эффект наблюдателя"
- игра "найди n различий". Проблема: не знаем, сколько всего различий и какие нам важны для бага;

В целом, получился очень информативный и насыщенный день, продолжение уже сегодня!

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

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

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

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

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

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

Конспект:

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

1. развертываемая функциональность исправна (deployable functionality OK)
2. производительность, безопасность (performant and secure)
3. удобство использования (usable)
4. полезность (useful)
5. успешность - бизнес-ценность (successful)

Подумайте над тем:

• Как эта пирамида будет выглядеть для вашего ПО?
• Что вам следует измерять?
• В какие области обеспечения качества вы можете инвестировать (свое время)?

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

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