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!