Лето – традиционная пора отпусков. Люди менее активны и не готовы терять солнечные деньки в погоне за новыми знаниями и навыками. Поэтому летом мы обычно проводим мало публичных мероприятий и работаем по большей части в корпоративном формате. Но уже середина августа, лето скоро закончится и мы рады огласить расписание публичных тренингов на ближайшее время.
30-31 августа пройдет тренинг Андрея Дзыни “Selenium 2/WebDriver на практике для начинающих”. Это отличная возможность для тестировщиков и разработчиков освоить этот важный и полезный инструмент для автоматизации работы с браузером (речь идет не только о тестировании). Тренинг имеет очень практическую направленность и предполагает множество живой работы с кодом под руководством тренера. Регистрация уже открыта.
В рамках конференции XP Days Ukraine 2013, которая запланирована на 11-12 октября, пройдет еще несколько тренингов. Все они состоятся 9-10 октября и будут посвящены инженерным практикам.
Тренинг «Agile Testing» от Андрея Дзыни. Что крутого в этом тренинге и почему я настоятельно рекомендую его посетить всем тестировщикам? Я уже давно повожу тренинг QA в Agile, в котором освещаю процесс постановки процесса тестирования со стороны менеджера, лидера команды, разработчика. Уже наверное ни для кого не секрет, что мы научились разрабатывать без тестировщиков, распределяя эту роль между остальными членами команды. Андрей же в своем тренинге рассматривает процесс тестирования изнутри, со стороны тестировщика. При этом в программе есть как процессные вещи (планирование, работа с требованиями, коммуникация в команде, демо, командные практики) так и сугубо практики тестирования (автоматизация, приемочное тестирование, скриптовое и исследовательское тестирование, инструменты и подходы к тестированию в Agile). Таким образом этот тренинг очень сбалансирован и дает участникам общее представление о роли, целях и подходах к работе тестировщика в Agile проекте.
Если сказать кратко, то этот тренинг учит тем вещам, которые позволяют тестировщику оставаться желанным и полезным специалистом даже для команд, которые справляются на первый взгляд без тестировщиков. Еще одна отличительная особенность тренинга – наличие множества практических сессий. Андрей ухитрился сбалансировать программу и давать возможность попробовать большую часть знаний на практике. Благодаря этому описанные подходы усваиваются гораздо лучше. Вы можете ознакомиться с детальной программой тренинга и убедиться в этом самостоятельно.
Тренинги «TDD в .NET» и «TDD в Java» проведут опытные разработчики и тренеры Сергей Калинец и Pawe? Lipi?ski. TDD – одна из наиболее полезных для разработчиков инженерных практик. Она помогает разрабатывать надежный и простой код быстро с высоким уровнем качества. Но не так просто начать работать по TDD. Нужно осознать и попробовать на практике базовые принципы, научиться двигаться к цели небольшими шагами. Данные тренинги отлично решают эту задачу. Попутно вы сможете узнать много полезных подходов, инструментов и хитростей, которые сделают вас продуктивнее.
И наконец, тренинг «Инженерные практики в Agile» от Николая Алименкова – это обзор основных Agile инженерных практик. Николай уже много лет является экспертом в этой области и поделится своими практическими наработками на тренинге. Цель тренинга – рассказать о семействе основных инженерных практик, применяемых в Agile, дать изначальный толчок к их внедрению в команде. За 16 часов будут рассмотрены 8 инженерных практик и подходов:
Все они взаимосвязаны между собой и дают максимальное преимущество, если применяются вместе. Каждая из них поддерживает остальные, дополняя и расширяя. Данный тренинг представляет отличную возможность разобраться в данной области и наметить для себя план внедрения практик в свой проект.
Расписание будет пополняться и мы постараемся провести еще много полезных тренингов этой осенью.
Не хочешь пропускать ничего интересного? Подпишись на ленту RSS или следи за нами в Twitter!
Давно мы ничего не проводили публичного в Харькове. Андрей Дзыня решил приехать туда в июле одновременно с докладом на встречу сообщества и тренингом Agile Testing. Встреча запланирована на 19 июля и пройдет под флагом вопроса “HOW TO MANAGE TESTING IN DYNAMIC WORLD: Practical Approach”. Тренинг пройдет 19-20 июля.
Что крутого в этом тренинге и почему я настоятельно рекомендую его посетить всем тестировщикам? Я уже давно повожу тренинг QA в Agile, в котором освещаю процесс постановки процесса тестирования со стороны менеджера, лидера команды, разработчика. Уже наверное ни для кого не секрет, что мы научились разрабатывать без тестировщиков, распределяя эту роль между остальными членами команды. Андрей же в своем тренинге рассматривает процесс тестирования изнутри, со стороны тестировщика. При этом в программе есть как процессные вещи (планирование, работа с требованиями, коммуникация в команде, демо, командные практики) так и сугубо практики тестирования (автоматизация, приемочное тестирование, скриптовое и исследовательское тестирование, инструменты и подходы к тестированию в Agile). Таким образом этот тренинг очень сбалансирован и дает участникам общее представление о роли, целях и подходах к работе тестировщика в Agile проекте.
Если сказать кратко, то этот тренинг учит тем вещам, которые позволяют тестировщику оставаться желанным и полезным специалистом даже для команд, которые справляются на первый взгляд без тестировщиков. Еще одна отличительная особенность тренинга – наличие множества практических сессий. Андрей ухитрился сбалансировать программу и давать возможность попробовать большую часть знаний на практике. Благодаря этому описанные подходы усваиваются гораздо лучше. Вы можете ознакомиться с детальной программой тренинга и убедиться в этом самостоятельно.
Стоимость участия в двухдневном тренинге составляет 2000 гривен (обед включен). Регистрация уже открыта!
Не хочешь пропускать ничего интересного? Подпишись на ленту RSS или следи за нами в Twitter!
Большую часть наших мероприятий мы проводим в Киеве. Но иногда выбираемся и в другие города. 7-8 июня во Львов едет Андрей Дзыня с тренингом Agile Testing.
Что крутого в этом тренинге и почему я настоятельно рекомендую его посетить всем тестировщикам? Я уже давно повожу тренинг QA в Agile, в котором освещаю процесс постановки процесса тестирования со стороны менеджера, лидера команды, разработчика. Уже наверное ни для кого не секрет, что мы научились разрабатывать без тестировщиков, распределяя эту роль между остальными членами команды. Андрей же в своем тренинге рассматривает процесс тестирования изнутри, со стороны тестировщика. При этом в программе есть как процессные вещи (планирование, работа с требованиями, коммуникация в команде, демо, командные практики) так и сугубо практики тестирования (автоматизация, приемочное тестирование, скриптовое и исследовательское тестирование, инструменты и подходы к тестированию в Agile). Таким образом этот тренинг очень сбалансирован и дает участникам общее представление о роли, целях и подходах к работе тестировщика в Agile проекте.
Если сказать кратко, то этот тренинг учит тем вещам, которые позволяют тестировщику оставаться желанным и полезным специалистом даже для команд, которые справляются на первый взгляд без тестировщиков. Еще одна отличительная особенность тренинга – наличие множества практических сессий. Андрей ухитрился сбалансировать программу и давать возможность попробовать большую часть знаний на практике. Благодаря этому описанные подходы усваиваются гораздо лучше. Вы можете ознакомиться с детальной программой тренинга и убедиться в этом самостоятельно.
Стоимость участия в двухдневном тренинге составляет 2000 гривен (обед включен). Группа уже практически сформирована, осталось 4 вакантных места. Торопитесь зарегистрироваться!
Не хочешь пропускать ничего интересного? Подпишись на ленту RSS или следи за нами в Twitter!
21 февраля буду выступать на IT-People PechaKucha в Киеве. Программа собралась весьма неплохая. Долго думал о чем таком интересном можно было бы рассказать без упора на специализацию. В итоге решил поговорить о профессиональном разработчике и современным требованиям к нему.
Доклад называется «Портрет профессионального разработчика». Какой он, современный профессиональный разработчик? Что должен знать и уметь, чтобы не только работать на интересном проекте и получать высокую зарплату сегодня, но и иметь стабильный завтрашний день? Технологии и процессы не стоят на месте, а вместе с ними и требования к разработчикам. Чтобы оставаться «на плаву» надо работать над своими знаниями и навыками. Именно об этом мы и поговорим в течение 6 минут 40 секунд…
Если вы успели зарегистрироваться, то приходите послушать. Если нет, то я обязательно выложу слайдкаст этого выступления через некоторое время.
Недавно у меня появился аккаунт на Хабре и я опубликовал на статью “Не обманывайте своих заказчиков”. Было много обсуждений в комментариях и я решил сделать более детальное рассмотрение данной темы.
Я достаточно много занимаюсь не только разработкой, но и постановкой процессов, в том числе тестирования. И всегда несколько скептически относился к ручному тестированию, точнее к той его части, которая отвечает за «обеспечение работоспособности существующей фунциональности» (в простонародье регрессионное тестирование). Что же плохого в этом тестировании и почему многие компании его тогда используют?
Проблема достаточно несложная, но ее суть не лежит на поверхности. Представьте себя на месте заказчика. Вы приходите с набором требований к исполнителю, в данном случае будем рассматривать в роли исполнителя команду разработки. Вы договорились о всех деталях с командой и она готова начать работать над вашим продуктом. Вы как умный и опытный заказчик грамотно расставили приоритеты и выдаете команде требование за требованием в правильном для бизнеса порядке. Вроде пока все звучит неплохо и ситуация не напоминает проблематичную.
Но вот проходит месяц-другой и выясняется неприятная деталь — на тестирование тратится все больше и больше времени. Оно вполне логично — ведь готовой функциональности в продукте становится все больше и надо постоянно контролировать, что она по-прежнему работает. Это эффект называется «регрессионная спираль смерти» (термин подсмотрен в выступлении Макса Дорофеева «Обезьянки против Роботов»). Эта спираль развивается со временем и становится все шире и шире. И если раньше тестировщики успевали «пробежаться» по продукту за несколько часов, то вскоре на это начинает уходить несколько дней.
Все очень просто — отдавая заказчику «готовую» работу мы не даем ему способа бесплатно и легко контролировать ее работоспособность в будущем. Утрируя, это может звучать так: «Мы закончили работать над X, Y и Z. Но уже через пару недель есть шансы, что они перестанут работать нормально…» Но как же так? Ведь заказчик заплатил за полное завершение работ. Как же ему теперь быть? Ему предлагается очень простое решение — плати нам постоянно дополнительную плату за то, что мы будем контролировать работоспособность на протяжении жизни продукта.
Получается, что стоимость одной конкретной функциональности будет продолжать расти на протяжении всего проекта. И чем быстрее работает команда, тем быстрее будет расти стоимость затрат на поддержание регрессии. Это же нечестно! В жизни бы мы никогда не согласились на такое. Представляете, вы заказываете ремонт, а вам предлагают платить дополнительные деньги за то, чтобы при работе над кухней не развалилась гостиная…
Почему же при всей ущербности подобной модели она не перестанет применяться? Тут есть несколько причин:
При этом, во многих современных продуктовых компаниях к такого рода затратам относятся скептически и не поддерживают идею ручного регрессионного тестирования. В таких компаниях нет позиции monkey тестировщика, так привычной для рынка аутсорсинга.
Для того, чтобы работать честно, надо пересмотреть «критерии готовности» команды разработки и расширить их наличием автоматизированных приемочных тестов. Перед работой над определенной функциональностью хорошая команда (заметьте, я не использовал слово Agile) задает заказчику вопросы о том, как функциональность должна работать и как заказчик будет проверять готовность. Это и есть процесс формирования приемочных критериев. Они представляют из себя мини-контракт между заказчиком и командой на реализацию этой функциональности.
Речь идет о работе над требованиями на очень короткий срок — обычно одна итерация. Если заказчик не может на такой срок сформулировать требования во всех деталях и ответить на все вопросы, то у вас уже проблемы. Работа над приемочными тестами помогает выявить их на самой ранней стадии.
Не стоит ожидать от заказчика, что он придет и выложит вам приемочные критерии на блюдечке. Вопросов «а как вы проверите, что это работает», «а давайте рассмотрим на примерах», «а как это будет использоваться» в умелых руках достаточно, чтобы получить набор критериев на практике. Главное чтобы не приходилось в процессе разработки делать предположения и обращаться к “здравому смыслу”. Это очень опасно и может привести к переделкам и недовольству заказчика.
Дальше хорошая команда снабжает эти критерии приемки конкретными примерами, данными и «прикручивает» к работающему продукту. Таким образом, добавляется возможность с помощью приемочных тестов в любой момент времени проверить, работает ли та или иная функциональность в продукте после любых изменений. Запустить эти автоматизированные приемочные тесты может любой, обычно они добавляются к Continuous Integration серверу и запускаются на каждое изменение или в ручном режиме.
Почитайте как работает на примере одной команды командное написание приемочных тестов и про эволюцию необходимости таких тестов к запуску в облаке.
Но ведь есть же модульные тесты? Зачем еще раз делать ту же работу? Модульными тестами хороший разработчик покрывает код, чтобы убедиться, что его точечная идея для класса, функции, метода или их связки работает правильно. К сожалению, модульные тесты не способны обеспечить проверку даже возможности запуска приложения, не говоря уже о его функциях. Плюс, приемочные тесты написаны на языке, понятном заказчику, в отличии от модульных тестов. Если искать связь, то модульные тесты рождаются из приемочных, в то же время играя роль приемочных тестов на уровне кода.
И теперь никто не тратит время на ручное регрессионное тестирование. Это время тратится на исследовательское тестирование, на помощь команде разработки завершить свою работу вовремя и с высоким уровнем качества, на обеспечение работоспособности канала донесения требований от заказчика к команде разработки. Заказчик при этом имеет под рукой мощный инструмент контроля качества и работоспособности своего продукта, при этом понимая, что заплатил за это не напрасно.
Кто-то может подметить, что понадобится время на написание и поддержку такого рода автоматизированных тестов. Затраты на написание конечно же включаются в оценки выполнения работ по разработке. А вот стоимость поддержки будет зависеть напрямую от уровня команды. Грамотно написанные тесты будут основаны на правильных инструментах и фреймворках, которые абстрагируют тестовую логику от деталей вашего продукта и дают возможность изменять что-то только при серьезных изменениях в продукте. И пусть себе требования на здоровье меняются, но скорее всего не вся функциональность перепиливается каждую неделю, особенно в большом проекте.
Не все легко покрыть автотестами. Но из моего опыта, люди зачастую просто не знают, не хотят или не умеют этого делать. Для веб проектов есть Selenium, для совершенно произвольных есть Sikuli. А еще уйма специализированных инструментов. Можно замечательно с помощью Selenium тестировать UI (расположение элементов, верстку, отработку JavaScript). Советую посмотреть мое выступление на одной из конференций по поводу подобного тестирования. В разделе материалов можно найти больше на эту тему. Если не получается протестировать через конечный пользовательский UI, то можно тестировать API бизнес логики. Это все равно будет лучше чем ничего. Тогда ручное тестирование может быть сосредоточено больше на тестировании UI слоя.
Есть еще одно преимущество от наличия таких тестов – возможность делать рефакторинг. Рефакторинг — последовательность изменений, которая изменяет внутреннюю структуру программы без изменения ее внешнего поведения. При рефакторинге тесты не меняются. Более того, без них невозможно убедиться, что внешнее поведение не изменилось, а значит называть это рефакторингом.
Эти же тесты придут вам на помощь и на этапе сопровождения. На этом этапе часто меняется только часть функциональности, а остальная должна продолжать работать стабильно. И вот тогда польза от приемочных тестов колоссальная. Мало того, по ним можно понять как должна была работать та или иная часть приложения. Потому что доменные знания теряются за документами, в которых устаревают практически моментально.
Задумайтесь, стоит ли продолжать обманывать своего заказчика. Или лучше работать так, чтобы можно было гордиться результатами своего труда, при этом убирая максимум скучной ручной работы и оставляя только интересную творческую составляющую? Если вы выбираете второй подход, то вам нужно обеспечить прозрачность и расписать все плюсы и минусы на самом раннем этапе. На более поздних этапах вводить описанное в статье тестирование может быть гораздо труднее и затратнее.
Не хочешь пропускать ничего интересного? Подпишись на ленту RSS или следи за нами в Twitter!
Интересная дискуссия разгорелась в комментариях к моей недавней статье про автоматизацию тестирования. Мне кажется, она вышла за рамки той статьи и было бы неплохо продолжить ее с чистого листа. Тем более, это может быть интересно более широкому кругу для обсуждения.
Итак, началось все вот с такого комментария. Вот самая интересная часть, из-за которой разгорелась дискуссия:
Правда вот я что понял: Николай всегда всё про интернеты и интернеты, но кроме «интернет-софта» есть ещё много другого разного и не везде ваши подходы (да и ваще эджайл) применим. А от повальной увлечённости Скрамом и Канбаном просто тошнит уже.
Впрочем я тоже считаю, что чистый Quality Control не нужен, Quality Assurance – то есть когда происходит реальное тестирование до написания первой строчки кода и убирается любая двусмысленность в том что и как нужно реализовывать и в каком порядке – это идеальный вариант. А потом тестирование чисто юнит-тестами и «автоматизацией» + небольшой QC перед релизом и всё ок.
Вообще у программистов должно быть минимум свободы и минимум вариантов для выбора как реализовывать. Свобода – это рабство, жаль, что всякие ратующие за «полёт творчества» в ИТ этого не понимают.
И тут мы оставили тестирование и пустились в разбор процессов. 🙂 Вот мой ответ:
Много другого-разного конечно существует, но давайте посмотрим реалиям в лицо. Какая разница с какого типа проектами использовать Scrum или Kanban? Это процессы, которые позволяют организовать работу над любого рода проектом (даже не IT). У вас есть свой процесс, который лучше и помогает вам делать быстро и качественно проекты? Расскажите о нем, напишите.
По поводу свободы и вариантов реализации вы заблуждаетесь. Но вероятнее всего из-за того, что вы не программист или просто ваши проекты были достаточно банальными с точки зрения технологий и решаемых задач. Часто надо перебрать много вариантов, чтобы только выбрать потенциально возможный. И тут тестирование – это не банальщина, потому что надо оценить насколько решение справляется с поставленной задачей.
Вот такой последовал ответ:
«По поводу свободы и вариантов реализации вы заблуждаетесь. » – да ладно, хотите поспорить с Оруэллом? Вы ж не забывайте, что «незнание – сила» в дополнение к «свобода – это рабство». То есть правильный подход – это когда те, кто разрабатывают – делают всё в жёстких рамках, а те, кто пользуются – максимально ограничены в возможности выбора и всё закрыто защитой от дурака и нет никакой информации о возможности что-то как-то менять. Шикарный пример – продукция компании Эппл.
«И тут тестирование – это не банальщина, потому что надо оценить насколько решение справляется с поставленной задачей.» – если обрезать все двусмысленности, нечёткие трактовки и детализировать принципы работы системы, жёстко формализовать дизайн по всем аспектам, то реально если не 90, то минимум 80% тестирования, которое требует внешнего контроля (мануальное или полуавтоматическое, всё таки человеческий фактор убрать хрен получится, автотест не скажет «не удобно») можно перевести в процессы до написания первой строчки кода, причём первая имплементация потребует больше тестирования, но чем дальше в лес – тем меньше будет требоваться прямого тестирования, при этом при планировании нового функционала или обновлений будет намного проще убрать лишние риски и уточнить реально важные детали.
Становится интереснее и я принял вызов:
Тут есть одно весьма строгое допущение – «жёстко формализовать дизайн по всем аспектам». Если вы про дизайн и архитектуру кода, то сделать это практически невозможно. В современных проектах они никогда не зафиксированы и всегда находятся в состоянии развития. Вы по-моему пытаетесь применить немного старомодное мышление: зафиксируем требования, зафиксируем дизайн, статически это протестируем, а уже потом за код сядем. Не работает! Доказано практикой многих лет многими проектами…
Но получил вот такой ответ, который задел за живое (именно поэтому решил перенести в отдельную статью эту дискуссию):
Как раз строго наоборот, практика многих лет разработок чего бы то ни было говорит обратное: чем жёстче стандартизация и чем выше требования соблюдать изначальный дизайн от А до Я – тем выше качество результата. То есть если к разработке ПО применить методики разработки, к примеру, марсоходов или ядерных бомб – качество ПО возрастёт.
«В современных проектах они никогда не зафиксированы и всегда находятся в состоянии развития.» – и это адовая проблема, отсутствие жёсткого контроля за происходящим порождает беспредел. То есть не просто «контроля» – контроль как бы есть, но есть отличное мнение, что если раз дать откусить палец, то в следующий раз отгрызут руку, поэтому контроль быть жёстким, а отношение таким: налажал – отгребаешь. Я не ошибусь, если скажу, что сча весь код всего десктопного и мобильного софта состоит из говна и заплаток. Из всего софта, что я пользовал за последний год единственным решением, которое не содержало явных и очевидных глюков – это Вин8, причём чисто сама ось+вин эксплорер, без учёта метро-софта и родного десктопного софта – там ещё тот адок. И то – официально уже вроде 20 апдейтов или даже больше встало, но это всё таки ОСь – многкомпонентная система. А так то релизы один глюкавее другого, все соревнуются не в качестве, а в скорости выпуска, в результате софт превратился в бесконечный поток ширпотребного поноса, который вылетает, глючит и обновляется каждый день, потому что «нафига тестировщики нужны?» или потому что «мы всё сделаем по ХР и со Скрамом». Мир сходит с ума, одни слушают Адель, Бибера и Леди Гагу, другие релизят каждый день новую версию продукта, потому что отладить, отдебажить и месяц-два потестить – нет времени. А о нормальном планировании я вообще молчу. Эхх, нет сча эффективного менеджмента, Ден Кеннеди абсолютно прав.
Почему это меня так зацепило? Да потому что нельзя сравнивать обычные коммерческие проекты с разработкой марсоходов и ядерных реакторов. У них целый ряд ключевых отличий, которые делают их столь же похожими как похожи снегирь и верблюд:
Теперь по поводу частых релизов. Вы думаете это просто? Нет, это гораздо тяжелее попыток выкатить все раз в полгода и потом неделю праздновать, если удалось или по выходным чинить баги в продукте, который может уже и не нужен в таком виде никому. Бизнес развивается гораздо интенсивнее в наши дни и все хотят зарабатывать на продукте деньги. Поэтому делать релизы редко становится убыточным.
Вдобавок, уменьшается стоимость дефектов. Многие проекты четко контролируют работоспособность основного критического для бизнеса функционала. Если нашелся дефект где-то еще, то это не беда. Оно никак не повлияет на бизнес и дешевле быстро починить и накатить обновление. Поэтому, частые релизы – это не от глупости менеджеров или их неграмотности. IT очень быстро меняется и требования к разработке растут с каждым днем. Кто-то может их удовлетворить, а кто-то может пенять на отсутствие “эффективного менеджмента”…
Не хочешь пропускать ничего интересного? Подпишись на ленту RSS или следи за нами в Twitter!
Поклонники Agile подходов спокойно ушли на зимние каникулы – до весны больших Agile событий на просторах СНГ не предвидится. А вот весной будет повод снова собраться вместе. 29 и 30 марта на конференции AgileDays’13 появляется возможность отлично провести время в кругу Agile экспертов и 700 участников конференции из сотни самых продвинутых компаний России и СНГ. А это значит, что можно будет погрузиться в культуру Agile, познакомиться с коллегами и обменяться опытом внедрения изменений в процессы больших и маленьких компаний.
Организаторы AgileDays’13 – компания ScrumTrek и сообщество AgileRussia пригласили лучших экспертов индустрии: Джеффа Паттона (Jeff Patton), Алистера Коберна (Alistair Cochburn), Гойко Аджича (Gojko Adzic), Дэвида Хассмана (David Hussman) и других с самыми интересными и полезными докладами на сегодняшний день:
Я тоже не мог пройти мимо и подал заявку на доклад. Если не случится ничего непредвиденного, то буду выступать на тему “Эволюция Agile или погоня за идеальным процессом”. Вы начинаете замечать, что команда переросла Scrum. Не переживайте, это совершенно нормально! Но куда двигаться дальше?
Agile подходы тоже не стоят на месте и эволюционируют. Появляются новые методологии и практики. Может быть отказаться от итераций? Kanban? Может быть изменить процесс разработки и поставки новых фичей? Continous Delivery? Может быть больше внимания уделить инженерной части? XP? В докладе мы поговорим о том, как и почему стоит развивать свой Agile процесс, когда стоит начинать эволюционировать и как не потеряться на этом пути. Ну и конечно же, мы затронем тему идеального Agile процесса и каким он может быть.
До встречи на конференции!
Не хочешь пропускать ничего интересного? Подпишись на ленту RSS или следи за нами в Twitter!
Я заметил, что больше всего сложностей с внедрением Agile подходов вызывает работа над приемочными тестами. Кто-то вообще над ними не работает, кто-то делает это “для галочки”. Но, на мой взгляд, это одна из самых важных и полезных Agile практик, особенно в итеративных подходах.
Все начинается с митинга по планированию итерации. Задача, которая стоит перед командой и Product Owner – не просто обсудить план работ на следующие две недели, но и зафиксировать как можно больше деталей, чтобы избежать проблем в конце итерации. На каждую итерацию команда и Product Owner подписывают внегласный контракт о выполнении определенного объема работ, который определяется совместно. Но в любом договоре стоит оговаривать правила приема-сдачи готовой работы. Без четко сформулированных приемочных критериев все договоренности остаются размытыми и обе стороны могут этим воспользоваться.
Приемочные критерии становятся самой важной целью планирования. Их четкая формулировка позволяет обеим сторонам избежать проблем и недопониманий. Процесс обсуждения приемочных критериев порождает массу вопросов, которые могли не появиться в противном случае. Приемочные критерии станут в дальнейшем почвой для разработки автоматизированных приемочных, функциональных, интеграционных и модульных тестов. Любой написанный тест должен так или иначе иметь отношение к приемочному критерию.
Не менее важный аспект приемочных критериев – хранение информации о функциональности. Когда ваш продукт развивается интенсивно, в него быстро добавляется все новый и новый функционал. Но через некоторое время удержать все это в голове становится очень и очень непросто. Приемочные тесты, которые порождены правильными приемочными критериями, способны не просто сохранить эту информацию, но и привязать ее напрямую к приложению. То есть, в любой момент времени мы имеем возможность не просто освежить в памяти работу определенной части приложения, но и посмотреть ее в действии.
Ну и наконец, приемочные тесты становятся своего рода охранниками реализованной функциональности, живой постоянно активной спецификации к ней. Это своего рода регрессионная защита, цель которой постоянно контролировать сформулированные однажды приемочные критерии и не допускать их поломки в будущем.
Тема очень интересная и я показал лишь несколько моментов, связанных с работой над приемочными критериями и тестами. Для более детального изучения я рекомендую книгу Gojko Adzic “Specification by Example”. Книга действительно очень классная и в прошлом году стала самой популярной книгой на Agile тематику. К сожалению, у Gojko не получилось вырваться на нашу конференцию XP Days Ukraine в этом году. Но мы пригласили его партнера David Evans, тренера и разработчика с 25-летним стажем в IT, приехать и провести тренинг “Specification by Example” перед конференцией. Тренинг подготовлен по материалам книги и будет полезен всем, кто работает в Agile команде, начиная от бизнес аналитиков и заканчивая разработчиками. Данный тренинг в Европе проводится по цене около 1500 евро, но мы сумели договориться на специальную цену для Украины – 3200 гривен. Тренинг пройдет 14-15 ноября и еще есть 5 вакантных мест. Торопитесь зарегистрироваться!
Не хочешь пропускать ничего интересного? Подпишись на ленту RSS или следи за нами в Twitter!
В эти выходные я выступал еще на одной конференции – AgileEE 2012. Долго не буду томить рассказом о том, как прошла конференция. Расскажу только, что мне понравилось, а что не очень. Начнем с позитивного:
Что не понравилось:
Я выступал на тему эволюции Agile процессов. Что там дальше за Scrum? Куда двигаться опытной команде? Почему и как эволюционировали современные Agile процессы? На эти и другие не менее важные вопросы я постарался дать ответ в своей презентации:
Судя по количеству оставленных карточек со словами благодарности, доклад участникам понравился и показался полезным.
Не хочешь пропускать ничего интересного? Подпишись на ленту RSS или следи за нами в Twitter!
25 сентября я принял участие в онлайн конференции Chief ConfeT&QA с докладом “Почему тестирование занимает так много времени”. Теперь я могу смело опубликовать материалы доклада, потому что по результатам зрительского голосования он занял первое место. Мой доклад выбрало больше 50% проголосовавших участников. Спасибо всем, кто за меня голосовал. Я рад, что сумел донести до вас полезные мысли.
На этот доклад меня вдохновила статья Болтона, которая в далеком 2009 году заставила меня пересмотреть взгляды на тестирование и помогла в дальнейшем избегать очень многих проблем: часть 1, часть 2. С тех пор эта тема является обязательным блоком моего тренинга “QA в Agile”.
О содержании доклада говорить нет смысла – проще просто его посмотреть. Есть версия слайдкаста:
Есть вариант видео:
Участники задавали много вопросов. Ответы на самые интересные я приведу тут:
Вопрос: Работали ли вы когда-нибудь тестировщиком?
Нет, я не работал тестировщиком. Но мне не раз приходилось ставить процесс тестирования на проекте с нуля, а также много-много раз консультировать компании по вопросам тестирования и проводить тренинги на эту тему.
Вопрос: Николай, так вроде бы это ты тот человек, у которого в проекте нет тестировщиков. Два предположения, это только предположения или все таки опыт?
От вас ничего не утаить. 😉 Да, на текущем проекте мы уже 3 года живем без тестировщиков. Параллельно с этим и до этого проекта мы работали совершенно разными составами команд и там было разное количество тестировщиков. Все, что я рассказываю, из личного опыта. К сожалению, не всегда приятного. 🙂
Вопрос: Где написание/поддержка тесткейсов?
В данном докладе оно не рассматривалось, потому что тут у меня тоже немного другие подходы и это отдельная тема для долгого обсуждения.
Вопрос: Как эстимировать работу тестировщика? Имеется в виду, что время на работу очень сильно зависит от качества работы девелоперов.
Если вы не делаете оценки в стиле Agile, то в тестировании вы полагаетесь сугубо на интуицию и попытки обезопасить себя буферами времени. В Agile команде вы не оцениваете тестирование как активность, вместо этого вы оцениваете насколько сложно/долго команде сделать ДО КРИТЕРИЯ ГОТОВНОСТИ определенную функцию продукта. А кто и как в команде будет что делать вас мало интересует. Тестирование должно оставаться в рамках каждой задачи, а не быть отдельной фазой в этом процессе. Посмотрите в материалах выступлений мой старый доклад “QA в Agile”.
Вопрос: Обычно верификация багов, найденных на данной итерации, переносится в следующую итерацию и нагрузка планируется, чтобы таких завалов не было.
О! Это очень долгая тема. У меня несколько другое отношение к понятию бага. Детальнее можно прочитать в этой статье.
Вопрос: Как-то непонятно. Неужели в планировании не было учтено, что вообще найдут баги?
Учтено то может и было, но как учесть сколько найдут. Это ведь зависит от разработчиков. Можно использовать накопленную за большой срок статистику, но ее еще надо накопить. И от колебаний в 20-30% она не защитит (на примере второй команды, которая делала мало багов). А это значит, что тестирование может не влезть в итерацию и снова проблемы…
Вопрос: А разве тестировщик виноват в том, что так много багов?
Ни в коем случае. Виноваты разработчики. Вина тестировщика в том, что он не “обеспечил качество” в процессе разработки. Для этого он должен был на этапе планирования помочь разработчикам понять правильно требования, обеспечить как можно раньше (желательно до реализации) весь набор приемочных критериев и тестов, смотреть на ранние результаты работы разработчика до конечной сдачи работ и т.д.
Вопрос: Кажется, хорошо так себя мотивировать, но рассчитывать на отсутствие дефектов – странно.
Так я не призываю на это рассчитывать. Над этим надо работать. Настоящая работа QA инженера – не допустить дефектов. Работа тестировщика (QC инженера) – проверять работу продукта, когда на его качество уже не повлиять. Поэтому мне ближе QA инженеры, часто в лице разработчиков. 🙂
Вопрос: Хорошее качество кода будет стоить достаточно дорого, дороже чем долгое тестирование. И часто заказчик выбирает именно долгое и более дешёвое тестирование и ре-тест, чем оплатить дорогущих девелоперов.
Долгое тестирование не улучшает качество кода. Его приходится все равно исправлять вашим дорогущим программистам, а чем позже они это сделают, тем больше времени (читать денег заказчика) они потратят. Гораздо дешевле не допустить плохого кода, чем его потом исправлять. А особенно ситуация усугубляется в случае большой ручной регрессии.
Вопрос: Понятно, что внедрившись ранее – ошибок будет меньше. И все же, как это спасет от того, что ошибки таки есть и “производительность” по сравнению с идеалм меньше в 5 раз?
Ну вот тут от вас и зависит как сделать чтобы “меньше” означало не в 5 раз, а на 5-10% к примеру. 🙂
Вопрос: Код ревью – не панацея. Ревьювить можно отступы и стилистику написания кода. На дев машине никто не гарантирует стабильность и следовательно время будет тратиться больше, что тоже не даст достаточный профит.
Из моего опыта, ревью кода устраняет огромное количество проблем, если оно делается обязательным для каждой задачи. В моих проектах это так уже больше 5 лет. В результате, мы можем работать без тестировщиков и выпускать отличный продукт, которым, без преувеличений, пользуются миллионы людей и множество компаний. Но для этого надо знать, как правильно делать ревью. Об этом мы рассказывали не раз в докладе “Code Review”, запись которого можно найти в материалах выступлений. По поводу стабильности на машине разработчика – тут все зависит от его стиля разработки. Если он работает, разбивая задачу на законченные куски, то с чего тут взяться нестабильности? Да и речь идет о первичном тестировании, которое не должно быть слишком детальное. Его задача – найти быстро наиболее видимые проблемы.
Вопрос: Вопрос к тебе как к разработчику. Внедрив инженерные практики наши разработчики стали еще хуже себя вести, теперь они отдают продукт еще позже, потому что хотят сделять конфетку. В результате в конце итерации просто нет времени на тестирование. Есть такой эффект?
Я на этот вопрос отвечал уже после доклада. Возможно, команда не понимает сути Scrum и как в него вписывается тестирование. Также, возможны случаи перфекционизма, когда инженерные практики существуют только ради факта применения инженерных практик. В нормальном процессе описанного эффекта быть не должно.
Вопрос: Что делать, если тебя “не пускают” в ранние этапы?
Для вас это означает, что вы не можете влиять на качество, а значит, предсказать продолжительность тестирования. Вам надо продать идеи руководству, команде, менеджерам. Продажа никогда не была простым делом. Но без нее никуда. Отличное место для продажи – это ретроспектива (у вас же она есть?). Давите на “больные мозоли”, забрасывая идеи по избеганию проблем. Предлагайте попробовать и делайте все от вас зависящее, чтобы команда в этих попытках не разочаровалась. А для этого вам важно полностью понимать какие могут быть подводные камни и как их обходить.
Вопрос: Какие есть реальные примеры коротких циклов обратной связи, что конкретно надо применять?
Писал об этом чуть выше. Договаривайтесь с разработчиком о разбиении его работы на стадии и раннем легковесном тестировании результатов. Обсуждайте с ним тестовые сценарии, чтобы он вложил их в модульные тесты.
Вопрос: Автотесты “глупые”, да, они много покрывают, но! Всегда есть “непокрытые2 участки, которые не заметили сразу. Как же не проверить еще раз в регрессии?
Автотесты глупые, но вы же умные. 😉 Нашли непокрытые участки и расширили набор автотестов. Автотесты должны пополняться постоянно из других активностей тестировщика, когда он видит, что повторная проверка уже попахивает роботизацией человека. 🙂
Вопрос: Если регрессию нельзя автоматизировать, то что тогда?
Тогда вы в печальном положении. Регрессионная спираль смерти вас все равно нагонит. Вы можете облегчить боль за счет хорошего покрытия модульными тестами и облегченного тестирования в регрессии (например, по чеклистам вместо тестовых сценариев).
Вопрос: Что делать в ситуации когда разработчики отдают новый функционал на тестирование за несколько часов до демо? Тестирование на локальных машинах не всегда возможно и не всегда имеет смысл (тк могут быть блокировки).
Тут важно понять, что для вашей команды входит в состояние ГОТОВО, которое согласовано с заказчиком. Если это полностью протестированный функционал, который готов к заливке на живые продакшен сервера, то выкатывание его за пару часов до демо не имеет смысла. Его ведь не успеют протестировать. Поэтому надо менять процесс разработки. Обсудите эти проблемы на ретроспективе.
Вопрос: А как насчет эксплоратори в регрессии?
Я только за, но делать его нужно в определенные запланированные моменты. Проверки основные стоит автоматизировать, чтобы регрессию можно было делать сотни раз за итерацию и она не допускала ошибок.
Не хочешь пропускать ничего интересного? Подпишись на ленту RSS или следи за нами в Twitter!
