Продолжение. Обзор первого дня -
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 ретвита. Ну а суровость Андрею за правду жизни: "если в продукте есть косяки, которые появились из-за непонимания заказчиком и разработчиком друг друга, то не заказчик дурак, а ты виноват. Виноват всегда исполнитель." Так вот. Ну а вместе - отличный "тройной" доклад.
