Неделя после прошедшей 9-12 октября конференции XP Days Ukraine 2013 была очень насыщенной и никак не хватало времени сесть и написать организаторский отчет. Хотя, по сути, и писать то особо нечего. Это была первая конференция, в которой мне с точки зрения организации все понравилось. А я ооочень редко остаюсь доволен, потому что везде вижу недостатки. 🙂
Начнем пожалуй с тренингов. В этом году мы решили немного сократить их количество и провели только 4 параллельных тренинга. Как обычно это TDD в Java и .NET, инженерные практики в Agile и Agile тестирование. Тренинги поселили около 70 участников. Мы все еще ищем удобное помещение для того, чтобы проводить все тренинги в одном месте. Это бы сильно упростило жизнь и нам и участникам.
На саму конференцию мы в этот раз заведомо ограничили количество мест, выставив на продажу 300 билетов. Все они были распроданы за 2 недели до мероприятия, что не может не радовать. Не смотря на переход к двухдневному формату, количество участников растет с каждым годом.
Мы уже достаточно много провели конференций, чтобы набить шишки с регистрацией участников. Поэтому в этот раз все прошло очень гладко и без очередей. Очереди за два дня конференции были только в гардероб в первый день и рассосались за 5-7 минут, а также в мужской туалет (серьезное отличие от конференций для тестировщиков). В этом большая заслуга наших замечательных волонтеров, за что им огромное спасибо!
Мы перестаем влазить в стены конференц-центра в БЦ “Парус”, поэтому в перерывах между докладами в холле было немного тесновато. Это является стоп-фактором роста конференции и мы тщательно ищем альтернативные места проведения. Но зато в этот раз мы еще лучше продумали расстановку докладов по залам. В итоге, ни на одном докладе сцена B не была переполнена и в обоих залах были свободные места. Позитивную атмосферу передает небольшой фотоотчет с места событий:
Мы не имели возможности обеспечить участников обедами, но постарались компенсировать их отсутствие вкусными и обильными кофе-паузами. За что получили немало позитивных отзывов от участников. Было и вкусно и много.
Мы практически решили проблемы с интернетом. В этот раз был подключен выделенный канал 50 MB/s и профессиональное оборудование Cisco. Единственной проблемой за 2 дня стал DHCP сервер, который не удалял старые IP адреса и поэтому часть участников не могла присоединиться. Жаль что в первый день мне никто не сказал об этом, потому что проблему быстро решили как только стала понятна ее причина.
Скажу пару слов о докладах. Во-первых все докладчики очень хорошо подготовились. И те, кто выступает уже не первый раз, и те, кто на сцене впервые. Большое им спасибо за их труд! Все они с честью выдержали наши стадии процесса ревью докладов и приложили максимум усилий к своим презентациям. О выборе основных направлений и тем для этой конференции я уже писал. Лично я остался очень доволен тем, как эти темы были раскрыты. Мы обработали анкеты обратной связи и выбрали лучших докладчиков по отзывам участников. В этом году мы впервые запустили еще одну отдельную форму обратной связи по программе конференции. Мы хотим собрать мнения и отзывы участников, чтобы в следующем году сделать программу еще более интересной и полезной.
В оба дня конференции мы позаботились об afterparty и заказали столики в Натюрлихе. Первый день конференции совпал с матчем на ЧМ между Украиной и Польшей, что добавило веселья. Около 70 участников болели вместе с нами. Была очень теплая и дружеская атмосфера. Об успехе вечерних посиделок можно было судить по ленивому утреннему потоку участников на следующий день. 🙂 Во второй день людей на вечеринке было поменьше, ведь очень много участников приехали их других городов. Но, тем не менее, afterparty удалось на славу!
На закрытии конференции мы по традиции разыграли призы и подарки от нас и спонсоров конференции. В этом году впервые столько компаний нас поддержали. Мы очень благодарны за поддержку! Спонсоры два дня развлекали участников, дарили подарки и сувениры, а на закрытие подготовили ценные призы. Дисковые накопители, вертолет, майки, книги – много кто ушел с конференции не с пустыми руками. Я даже забыл о том, что мы собирались разыграть 3 лицензии на Intellij IDEA. Пришлось сделать это уже позже случайным выбором анкет обратной связи.
Я бы хотел отдельное спасибо сказать участникам за их конструктивную обратную связь. С каждым годом мы совершенствуемся, а ваши подсказки дают нам возможность это делать. А такое количество позитивных отзывов и благодарностей позволяет понять, что мы делаем действительно полезное и важное дело. Спасибо вам!
В заключение, немного о моих докладах. Их должно было быть два, но судьба распорядилась иначе. У нас снова произошел форс-мажор и один из докладчиков вынужден был срочно улететь из Киева. Поэтому я заменил его и рассказал свой старый доклад о Continuous Delivery:
Второй мой доклад был в секции мини-докладов и я рассказывал о важности роли Technical Lead для успеха Agile проекта:
Последний доклад был на тему тестирования уровня доступа к БД в Java и особенно работе над этим уровнем по TDD:
Мы с нетерпением ждем XP Days Ukraine 2014. Уже есть много новых задумок по программе и формату конференции. Ждем вас в следующем году!
Не хочешь пропускать ничего интересного? Подпишись на ленту RSS или следи за нами в Twitter!
22 декабря прошла очередная конференция IT Brunch на тему “Инженерные практики XP”. Тематика инженерных практик и подходов выбрана не случайно. Во-первых, недавно в Киеве прошла конференция XP Days Ukraine 2012, которая собрала всех тех, кто интересуется тематикой инженерных практик и eXtreme Programming (XP). И «по горячим следам» мы решили представить часть выступлений более широкой аудитории. Во-вторых, большую часть процесса разработки составляет именно написание кода. Методология XP (eXtreme Programming) предлагает набор инженерных практик, которые помогают делать качественные продукты быстро и с меньшими рисками.
Я выступил на ней с обзорным докладом на тему XP: что из себя представляет, откуда взялся, какие практики содержит и как их применять. Вот слайдкаст выступления:
Было достаточно много вопросов и я постарался на них подробно ответить. Если вы не успели задать свой вопрос или он у вас появился после прослушивания доклада, то поделитесь им в комментариях и я постараюсь ответить.
Вопрос: Я правильно понимаю, что Scrum и XP практически одно и то же, но про Scrum должны знать менеджеры, а про XP программисты и тогда все будут внедрять одно и то же и будут счастливы?
Ответ: Не совсем. Я бы сказал, что Scrum – это сугубо менеджерские практики, а XP гораздо ближе именно к разработке, потому что все практики привязаны к реальному процессу разработки продукта. Но схожесть в некоторых подходах определенно есть – они ведь и из Agile семейства. 🙂
Вопрос: Якщо вирішив впроваджувати XP в команду новачків – що порадите?
Ответ: Это не так просто, потому что большая часть практик в XP требует достаточно грамотных членов команды. Начните с code review, обязательно донесите ценности continuous integration и тестирования на уровне разработчиков. Дальше двигайтесь в сторону TDD. Но процесс будет очень неспешным.
Вопрос: Как насчет автоматизированных тестов?
Ответ: Автоматизированные тесты важны и полезны!
Вопрос: Как продать программистам использование XP практик? Или нужно вводить эту практику распоряжением сверху?
Ответ: Введение сверху почти никогда не заканчивается добром. Надо донести основные ценности и потом предложить варианты решения. Если с первого раза не получилось продать, отойдите на шаг назад и попробуйте еще раз чуть позже. Покажите положительные примеры других команд, книги, статьи, отправьте на хорошую конференцию.
Вопрос: Как Вы проводите code review? Используете какой-то чеклист или что-то другое?
Ответ: Чеклист обязательно есть и находится на Wiki. После долгого использования он уже у всех в головах, но бывает кто-то что-то забывает. А так никаких специализированных инструментов – мы все сидим в одном месте.
Вопрос: А можно ссылки для Contious Integration схем, которые Вы привели? Спасибо!
Ответ: TeamCity и Jenkins поищите в гугле. Думаю легко найдете. 😉
Вопрос: Code review, pair programming – досвідчений + новачок?
Ответ: Это полезная пара, если все понимают как и для чего они в ней. Обучение идет очень быстро. Но в то же время очень опасная пара, потому что при неправильном понимании будет потерянное время и куча эмоций. 🙂
Не хочешь пропускать ничего интересного? Подпишись на ленту RSS или следи за нами в Twitter!
Я уже писал о моем выступлении на Java Tech Talks#5 в Одессе. Похоже, компания Lohika решила сделать эти встречи постоянными и собирать Java разработчиков как минимум раз в месяц. Это здорово, когда людям есть чем поделиться и собираются участники послушать. 12 декабря состоится очередная встреча – Java Tech Talks#7.
Темы выступлений достаточно интересные. В докладе “Spring around the bend” Егор Сигарев обещает поведать тайны и нюансы использования Spring, о которых не догадываются большинство разработчиков. Второй доклад “Мир без JSP. Thymeleaf 2.0” мне еще ближе – ведь я давно отказался от “классических” Java технологий для пользовательского интерфейса веб-приложений. Мне по душе шаблонизаторы как FreeMarker или Mustache. C Thymeleaf я незнаком и было бы интересно узнать об альтернативном подходе. В общем, я даже немного жалею, что не живу в Одессе и пропущу эту встречу. Придется ждать видео. 🙂
Кстати, уже готовы записи моего выступления на тему использования Hibernate:
Не хочешь пропускать ничего интересного? Подпишись на ленту RSS или следи за нами в Twitter!
Почти 2 месяца назад я выступал на очередной онлайн конференции Auto ConfeT&QA с докладом “Не изобретайте велосипед! Грамотные функциональные тесты с WebDriver и Thucydides.”. Доклад занял лишь четвертое место по результатам голосования участников, поэтому материалы его публикуются только сейчас. Вторая причина запоздалой публикации – поломка моего нового ноутбука, на котором хранились все материалы. Я кое-как восстановил их и решил опубликовать.
При подготовке доклада я сильно переработал мои старые презентации по Thucydides, чтобы в данном докладе больше подчеркнуть, что надо делать и зачем, а не с помощью какого конкретно инструмента. Получилось, на мой взгляд, достаточно неплохо для 30-ти минут. Эту тему я собираюсь разобрать более глубоко на конференции Selenium Camp 2013 в своем одноименном докладе. А вот и слайдкаст выступления:
Не хочешь пропускать ничего интересного? Подпишись на ленту RSS или следи за нами в Twitter!
В эти выходные я выступал еще на одной конференции – AgileEE 2012. Долго не буду томить рассказом о том, как прошла конференция. Расскажу только, что мне понравилось, а что не очень. Начнем с позитивного:
Что не понравилось:
Я выступал на тему эволюции Agile процессов. Что там дальше за Scrum? Куда двигаться опытной команде? Почему и как эволюционировали современные Agile процессы? На эти и другие не менее важные вопросы я постарался дать ответ в своей презентации:
Судя по количеству оставленных карточек со словами благодарности, доклад участникам понравился и показался полезным.
Не хочешь пропускать ничего интересного? Подпишись на ленту RSS или следи за нами в Twitter!
Во вторник я вернулся с конференции YaC 2012 и наконец-то нашел время поделиться своими впечатлениями. В первую очередь, я хочу поблагодарить организаторов за приглашение выступить и заботу о докладчиках на протяжение всего пребывания в Москве. Для нас все было организовано отлично, начиная от встречи в аэропорту и заканчивая after-party. Но обо всем по порядку.
Я прилетел в воскресенье, потому что организаторы хотели провести экскурсию по офису Яндекса и показать площадку, где предстояло выступать. Да и зачем рисковать с пробками в день конференции. 🙂 Москва встретила не очень радушной погодой по сравнению с теплой осенью в Киеве. Таксист с табличкой Яндекс встретил в аэропорту и отвез в гостиницу “Космос” – огроменное здание советской постройки к олимпиаде.
Выглядит гостиница очень монументально, да и номеров там несчетное множество. Правда советская атмосфера в отеле царит до сих пор и в этом плане мало что поменялось. В воскресенье и понедельник там устраивали конференцию 1С-ники, поэтому в фойе болтался гигантский шар с надписью 1C.
Площадка конференции в этом году располагалась в ВДНХ. Я пришел в то время, когда сцены еще только обустраивались и сразу удивился количеству аппаратуры, которое устанавливали в разных местах. Создавалось ощущение, что будут работать десятки камер и снимать каждый закуток. Сцены было 4 и достаточно несбалансированных: около 2000 (не знаю сколько точно), 350, 350 и 500. Секцию тестирования организаторы поставили на главную сцену после обеда, что меня удивило, потому что редко когда тестированию выделяют такие большие залы. 🙂
Вечером докладчиков собралось побольше и нас дружно повезли в офис Яндекса. Перед этим я успел прокатиться вот на таком забавном аттракционе:
Сначала нам провели экскурсию по офису. Офис достаточно симпатичный, для себя отметил большое количество переговорок и велосипедов на улице. Еще в офисе работает удивительная система охлаждения без кондиционеров на трубах с водой, которые спрятаны под “деревянными обоями”. Офис сделан с должным уровнем креатива – повсюду стены, на которых можно писать и рисовать маркерами, что сотрудники и делают. 🙂 Было удивительно, что так мало людей сидят с несколькими мониторами, хотя может просто мы были не в комнатах разработчиков. Фотографировать, к сожалению, запрещено.
После экскурсии организаторы сделали фуршет с вином и кучей еды. Нас было не очень много, но зато все познакомились и отлично поболтали. На нашей секции должен был выступать Anthony Voellm из Google, который рассказал много интересного о работе в Google и отношении к тестированию в этой компании. Вечер мы решили продолжить со старыми знакомыми из Яндекса в ближайшем пабе…
С самого утра было понятно, что в ВДНХ что-то происходит для IT-шников. От метро тянулись многочисленные группы людей с рюкзаками IT-шной внешности. Причем много и постоянным потоком. На подходе к 75-ому павильону нас ждали очереди из участников конференции. Докладчики получали свои бейджи в отдельной VIP комнате, а остальные – в забавных машинах, которые печатали бейджи на месте по QR-коду. Не видел таких до этого, прикольное решение. Все участники получили мешки с кучей ништяков от Яндекса: конфеты, наклейки, протирашки и т.д.
А народ все прибывал и прибывал. К моменту открытия в главном зале все было забито. Поговаривали, что в остальных залах тоже было полно народу, которые смотрели открытие в трансляции. Технически сцена была организована просто великолепно: 4 огромных экрана, целая команда для работы со звуком и трансляции с камер, специальные мониторы перед сценой для докладчиков, классные микрофоны и мощный звук. В общем, придраться было не к чему. На втором этаже с участниками знакомился забавный робот, который был очень общительным и милым:
Открывали конференцию несколько ведущих людей в компании. Яндекс на этот день подготовил немало сюрпризов – свой собственный браузер, несколько новых сервисов и новый логотип. Браузер и логотип стали предметом жарких дискуссий в интернете. Статья на Хабре собрала сотни комментариев и множество примеров народного творчества на тему нового логотипа. Не берусь судить насколько полезным будет новый браузер, но с точки зрения автоматизации тестирования он точно новых проблем не создаст. 🙂
Я побывал на нескольких докладах, из которых отметил бы доклад из фронтенд секции “Профилирование и ускорение сложных JavaScript-систем на примере API Яндекс.Карт”. Тема действительно интересная и собрала толпу народа (стоя слушали столько же участников сколько сидя). Незаметно подошло время обеда и я обрадовался, что был докладчиком. Очереди за едой были огромными. Оно и неудивительно – ведь на конференции было 3-4 тысячи человек. Ближайший МакДоналдс тоже не остался в обиде и, думаю, заработал недельную выручку за день. 🙂
После обеда началась наша секция тестирования. Я остался очень доволен выступлениями. Не ожидал услышать столько всего интересного, причем в такой живой подаче. Мне кажется, что тестировщики должны были уйти с конференции с целой пачкой новых идей. Организации автоматизации тестирования в Яндекс многие компании могут только позавидовать. Лично мне нравятся тестировщики из Яндекс за то, что, когда им рассказываешь новые идеи, они говорят: “Классная идея, надо подумать как у нас применить..” вместо “Это невозможно в нашей команде, да и вообще в нашей компании!”. Вот презентация моего выступления, видео будет позже:
Наша секция была последней на конференции, но на этом все не закончилось. Все организаторы и докладчики отправились праздновать и веселиться на after-party в паб. Там было много общения, пива и веселья. Не смотря на завершение конференции, нас отвезли в отель и на следующий день утром доставили в аэропорт. Такая забота оставляет только приятные впечатления.
Подводя итоги, я хочу сказать, что это была действительно самая большая и интересная технологическая IT конференция в Восточной Европе с кучей разных секций, большим количеством докладчиков как из Яндекса, так и приглашенных, а также очень разношерстным составом участников. Желаю конференции и дальше развиваться и набирать обороты. Спасибо организаторам за возможность выступить! В следующем году приеду обязательно, даже если и не в статусе докладчика…
Не хочешь пропускать ничего интересного? Подпишись на ленту 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!
В эту субботу, 9 июня, состоялась третья по счету бесплатная онлайн конференция IT Brunch. В этот раз она называлась “Учимся на чужих ошибках”. Тема выбрана не случайно. Ведь больше всего в IT мы делаем именно ошибок, к нашему большому сожалению. Причем, ошибок на всех этапах разработки программных продуктов – планировании, проектировании, выборе технологий, работе с заказчиком, тестировании и т.д. Наша индустрия славится количеством проваленных проектов, но при этом мы все равно не учимся на чужих ошибках и допускаем их снова в очередном проекте. А ведь гораздо лучше слушать про ошибки других людей, учиться на них и не допускать их в своей практике.
Я выступал с докладом “Коварный tracer bullet development”, в котором поведал историю одного проекта, где мы решили попробовать новый для нас подход к разработке – Tracer Bullet Development. Пересказывать содержание доклада не буду, вот слайдкаст выступления:
Есть еще видео вариант:
От участников поступило множество вопросов и я хотел бы еще раз ответить на них в этом обзоре. Если вы не успели задать свой вопрос или он у вас появился после прослушивания доклада, то поделитесь им в комментариях и я постараюсь ответить.
Вопрос: Как вышли из проблемы заглушек?
Ответ: Через некоторое время от заглушек отказались. Чем больше становилось логики, тем тяжелее было поддерживать заглушки в актуальном состоянии. На это тратилось слишком много усилий.
Вопрос: А писали ли тесты на функционал с заглушками? И не сложно было их рефакторить?
Ответ: В этом была одна из идей – можно писать тесты на заглушки, а потом прозрачно использовать их для интеграционного тестирования реальных сервисов. Сейчас я понимаю, что надо было больше времени уделить провайдерам данных, чтобы сами тесты вообще не пришлось менять. А так нужно было делать достаточно много изменений, чтобы они заработали с реальными сервисами.
Вопрос: А как насчёт жизни без тестировщиков? Ошибка или нет? 😉
Ответ: Нет, это не ошибка. Я считаю, что каждой команде было бы полезно поработать без тестировщиков, чтобы приучить себя выпускать продукт нормального качества, а не рассчитывать на тестирование. Многие технические вещи начинают делаться разработчиками, когда они понимают, что тестировать кроме них некому. Они стараются сделать это как можно проще и быстрее, автоматизируя свою работу. А заказчик начинает брать на себя больше ответственности за приемку функциональности. В общем, одни плюсы. 😉
Вопрос: Как убедить заказчика в “правильности” идеи небольших функциональных команд?
Ответ: Нужно показать ему преимущества: меньше времени тратится на коммуникацию, команды работают практически независимо, можно более гибко подходить к выбору функциональности для реализации, меньше риски в случае проблем с одной из команд и т.д. Рекомендую взглянуть также на методологию FDD (Feature Driven Development).
Вопрос: Как вышли к общей ответсвенности за продукт?
Ответ: Когда команда отвечает целиком за разработку функциональности, а не только части ее, которая скрыта за интерфейсом, то ответственность повышается. Некого обвинить, в конце итерации нужно показать результат.
Вопрос: Николай, получается использание заглушек оправдано на начальных этапах развития проекта? Когда на их поддержку не выделяется много ресурсов, а их использование позволяет полноценно вести разработку всех модулей?
Ответ: Именно так. Как только сервис начинает становиться сложнее, надо переключаться на реальную реализацию, иначе будет много времени тратиться на поддержку.
Вопрос: Как быть если есть много маленьких проектов?
Ответ: Небольшие функциональные команды работают замечательно и в этом случае. Делается конвейер задач, каждая из которых представляет собой законченную функцию системы. Команда берет ее на реализацию и делает. Управлять этим можно с помощью Kanban (как пример).
В эти выходные, 21 и 22 апреля, Киев принимал самую масштабную на просторах постсоветского пространства конференцию тестировщиков – SQADays. Конференция в Киеве стала 11-ой по счету, что уже говорит немало о ее популярности. Не смотря на мои “разработческие корни”, я в очередной раз подготовил доклад на тему тестирования и принял участие в конференции в качестве докладчика. Но о моем докладе чуть позже…
В субботу меня мучала температура, поэтому я приехал практически перед официальным открытием. Тем не менее, времени вполне хватило, чтобы пообщаться со многими знакомыми. Приятно видеть на конференции столько знакомых лиц, причем из разных городов. Это отличная возможность поболтать и поделиться полезной информацией. Генеральный партнер конференции, компания Lohika, установила в холле оригинальный стенд с кислородными коктейлями. У участников появился шанс окунуться в воспоминания из детства. 🙂
Местом проведения был выбран КИМО, что поначалу меня немного шокировало. Ведь в образовательных заведениях по-прежнему царят “советские” устои, да и помещения не претендуют на звание современных. Но скажу сразу, что мои опасения мало в чем подтвердились. Огромным плюсом стал размер залов и холла. Складывалось ощущение, что никакой конференции и нет вовсе, а просто “пожилые” студенты с бейджами бродят из аудитории в аудиторию. Везде хватало мест и никто не теснился.
Сразу отмечу удобство программы, которая одновременно является и блокнотом. Мы позаимствовали этот формат для наших конференций. Это реально очень удобно – вы создаете свою версию “книги знаний”. Но, к сожалению, информация о докладах в программе была устаревшей и для навигации я в основном пользовался листиком с расписанием докладов. 🙁 Как организатор подобных мероприятий, я еще сильно напрягался с односторонним бейджем – он все время норовил перевернуться чистой стороной наружу. 🙂 Двухсторонние бейджи гораздо приятнее в этом отношении.
Вот наступило долгожданное открытие конференции. Много слов благодарности, мини-речи приглашенных зарубежных гостей и информация для участников – все это растянулось на полчаса. Скоротать это время помог интернет. Он работал практически всегда адекватно. Много участников общались в Twitter по хештегу #sqadays12 (старый хештег #sqadays атаковали спамеры). В ленте можно найти много всего интересного.
Первый доклад Ярона Цубери я пропустил в пользу мини-доклада на тему советов по смене работы от Алексея Лянгузова. Леша сам только сменил работу после долгих лет, проведенных в компании Sun, и ему было чем поделиться. Много полезных советов, пометил себе эту презентацию на случай ухода с текущего насиженного места. Надо отметить, что зона стендовых докладов была оборудована грушами-подушками, которые просто мега-удобные. У меня такая есть дома. Теперь мы постараемся на следующих наших конференциях делать лаунж-зону с такими же грушами. 🙂
Очень хотелось проснуться, а растворимый кофе на кофе-брейке пить совершенно не хотелось. 🙂 Поэтому мы отправились в близлежащий “Кофе-Хаус”. Оказалось, там достаточно много участников конференции также коротали время. Вообще, кофе-брейки стали самым слабым местом конференции. Кипяток был на вес золота, его постоянно не хватало. Женщины в столовской одежде разливали его из большой кастрюли, заливая насыпанный в стаканчики растворимый кофе и чай в пакетиках. До еды я так ни разу и не добрался, но, по слухам, она разлеталась очень быстро. Я больше расстраивался отсутствию постоянного доступа к горячей воде, потому что мне нужно было принимать лечебные процедуры полоскания. 🙁
Следующим в моем списке стал доклад Эдуарда Плаксина по грамотной отчетности нагрузочного тестирования. Много полезных советов из жизни, немного не хватало огонька в глазах, а так очень даже неплохой доклад. Прослушав его, можно избежать многих ошибок в своей практике составления отчетов.
На обед я решил пойти во вторую смену и остался на доклад Тани Зинченко. Она захватывающе рассказывала о своей команде и о процессе, который они у себя построили. Некоторые вещи мне было очень странно слышать “под соусом” Agile. Но доклад порадовал очень позитивным настроем и полной отдаче своему делу. Так держать!
Обед я провел в компании Андрея Дзыни и Алексея Лупана. Спасибо им большое за интересную беседу, обмен идеями на будущее и просто хорошую компанию. Правда обед разочаровал. Давно я не кушал в столовках и не ощущал “столовочного сервиса”. Но тут ничего не поделаешь – такое уж место проведения. Иначе бы мы просто все остались голодными. 🙂
После обеда я отправился на главную сцену послушать про серебряную пулю автоматизации тестирования от Наташи Руколь и Игоря Любина. Доклад получился достаточно динамичным, слайды яркие, тема важная. Иногда не хватало живого диалога от Игоря, но это можно списать на отсутствие опыта публичных выступлений. В целом, доклад поднимал достаточно интересные вопросы по поводу внедрения автоматизации тестирования и неправильного ее применения.
Следующим по расписанию шел мой доклад. Я выступал в зале В с докладом “А вы знаете что тестируют ваши тесты?”. В докладе я рассказал каким образом можно контролировать покрытие требований, кода и UI элементов приложения тестами, при этом получая информативный и красивые отчеты. Анализ и понимание покрытия тестами позволяет спать спокойно не только тестировщикам, но и менеджерам. А это очень важно во многих проектах. 🙂 Но лучше слов за меня все расскажет презентация:
Как только появится звук, я сделаю слайдкаст. Также я выложил проект, на котором я демонстрировал все примеры, на свой аккаунт на GitHub. Пользуйтесь на здоровье!
После своего доклада я много общался в кулуарах, познакомился с ребятами из “Одноклассников”, обсудил с Лешей Баранцевым некоторые инструменты и подходы из моего выступления, практически убедил на реальных примерах одну из участниц конференции в неправильности подхода выделенных функциональных команд. Вообщем, с пользой провел время.
Первый день конференции закрывал Алексей Баранцев с темой о важности граничных значений и тестирования на границах. Мне доклад очень понравился. Тема достаточно узкая, поэтому Леша медленно и интересно ее раскрывал, с кучей классных примеров из не-IT тематики. В завершение, всех ждал мультик о “целеустремленном тестировщике”, который сильно поднял настроение и стал замечательным завершением дня.
Во второй день я немного опоздал на первый доклад из-за плохого самочувствия и “попал в лапы” к Стасу Фомину. Он показал и рассказал про базу знаний, которую они собирают в компании на протяжение многих лет, продемонстрировал прогресс в его подходах к съемке и подготовке материалов, а также поведал много чего интересного. Стас – увлеченный человек и это здорово (хотя и негативно повлияло на его работу в компании)!
На второй доклад я пошел к Мишу Полярушу послушать про Robot Framework. Давно хотел посмотреть его в действии и мне это удалось. Миша показал на простых примерах как легко можно начать работать с этим инструментом и какие интересные возможности открываются перед тестировщиком. Круто, я люблю практические доклады с живыми примерами!
На следующий доклад я снова остался на главной сцене послушать про внутренние “облака” в компании Parallels. Кирилл Казаков очень уверенно доносил информацию, но практической ценности в докладе я не увидел. Мало какие компании берутся за построение собственного “облака” – это затратно как по времени, так и по деньгам. Гораздо проще начать использовать публичные сервисы и отбросить паранойю по поводу кражи исходников и прочих “ценностей”.
На обед я отправился немного пораньше, поэтому не стоял в очереди и хватило времени поболтать с Сашей Баглаем, с которым мы знакомы уже давно и он помогал нам в качестве волонтера на многих конференциях. Обсудили конференцию, будущие мероприятия, волонтерство, рынок Java разработчиков и, если бы не наплыв желающих пообедать, могли продолжать еще долго. 🙂
После обеда мой выбор пал снова на главную сцену – там два Сергея (Атрощенков и Бережной) вещали про нежелание заказчиков давать “свободу” тестировщикам. Выступление было несколько смазанным по техническим причинам – микрофоны ужасно фонили и просто не давали возможности сосредоточиться на выступлении. Идея доклада была достаточно узкой, но хорошо разжеванной – не заигрывайтесь с инструментами и подходами, а стремитесь решать выгодные с точки зрения ROI проблемы. Даже с нелюбимыми мной матрицами 2 на 2, доклад получился неплохой. 🙂
Следующий выбранный мной доклад, пожалуй, был единственной “ошибкой”. Я отправился слушать Александра Башарина про оценки тестирования. Доклад был очень запутанный и скучный. Зато поиграли в шахматы онлайн в паре с Игорем Любиным (да, сдал с потрохами). Надо же как-то выходить из ситуации. 😉
На кофе-брейке мне опять ничего не досталось, с трудом выборол для себя немного кипятка в лекарственных целях. Поэтому на доклад Ани Скуминой я отправился в приподнятом настроении. Она рассказывала о нестандартных подходах к тестированию usability. Отличные слайды, поставленная приятная речь, легкий и интересный материал – я остался доволен. Важно помнить, что тестировщик тестирует usability продукта, просто его используя. А это круче многих специализированных тестов. 🙂
В это время твиттер разрывался от крутости доклада на сцене В. Я попал на последнюю часть и тоже был очень доволен. Олесь Сегеда в режиме реального времени демонстрировал уязвимости различных типов и способы борьбы с ними. Живое шоу действует на участников как нельзя лучше и доклад был воспринят на ура. Все отчаянно начали вписывать Олеся в анкету-опросник с голосованием за лучший доклад. Я себе пометил доклад для обязательного просмотра, как только появится видео.
Закрывали конференцию Наташа Руколь и Андрей Мясников. У них получился очень живой и насыщенный доклад в стиле боя в Mortal Combat. В схватке схлестнулись тестирование по сценариям и методом свободного поиска. Они наносили друг другу удары в виде аргументов и язвительных историй. То и дело зал присоединялся и выдавал свои комментарии. Отличная подача материала и, как принято, “победила дружба”. Всякое тестирование важно, если его применять по месту и с умом. На этой ноте и завершилась официальная часть конференции.
За последним докладом последовало вручение призов от спонсоров и от организаторов за лучшие доклады. Очень заслуженно призы получили Олесь Сегеда, Миша Поляруш и Аня Скумина. Правда призы были несколько странными для IT-конференции – утюг, термос и еще что-то. 🙂 Мне же в подарок досталась мышка за самое активное участие в twitter-ленте конференции. Мелочь, но приятно!
На afterparty я не попал по состоянию здоровья, поехал долечиваться. В целом, конференция понравилась. Мне посчастливилось попасть на яркие и интересные доклады, а также завести несколько полезных знакомств. Также я поделился в своем докладе наработками и мыслями на тему тестирования. А не для этого ли мы и приходим на подобные мероприятия? Надеюсь выступить на следующей SQADays-12, где бы она не проходила. Спасибо организаторам, докладчикам и участникам за отлично проведенное время!
13-15 февраля с 17 до 19 часов по московскому времени проходила онлайн конференция для специалистов по автоматизации тестирования – Auto ConfeT&QA. Организаторы собрали докладчиков из России, Украины и Беларуси, которые представили на суд слушателей 10 докладов. Уровень организации был достаточно высоким, докладчикам помогали подготовиться к выступлению, репетировали с ними доклады, делали ревью презентаций. В результате все выступили достойно.
Я тоже принимал участие в качестве докладчика с докладом «TDD c помощью функциональных тестов на WebDriver». Я давно хотел выступить на данную тему и как раз представилась неплохая возможность это сделать. TDD (Test Driven Development) является популярным подходом среди разработчиков. Сначала пишется тест, а только потом на основании этого теста пишется реализация. Эта практика дает много преимуществ, позволяя сосредоточиться на небольшом аспекте функциональности и автоматизировать проверку правильности его реализации. Таким образом, разработчик сразу думает о вариантах использования и реализует минимальный необходимый функционал.
TDD можно применять не только на уровне модульных тестов, но и на уровне функционального тестирования. Это дает возможность задуматься о структуре и особенностях функциональности еще до ее реализации. Вам не придется мучиться в попытках протестировать приложение, которое не задумывалось для тестирования (сложные локаторы, непонятная структура страниц, запутанные связки элементов). В качестве сопутствующего эффекта, TDD позволяет сократить время на ручную проверку разработчикам и автоматизировать 100% функциональных тестов.
Многим понятны преимущества TDD, но они не знают с чего начать. Некоторым кажется, что написание теста до появления реализации вообще невозможно. В своем докладе я рассказал не только о преимуществах и особенностях данного подхода, но и на примерах продемонстрировал, как работать с TDD на практике. Были рассмотрены варианты распределения ролей, техники написания тестов и особенности их использования. В качестве основного инструмента для тестирования использован WebDriver.
Доступен слайдкаст доклада:
Так как я показывал живую демонстрацию, то посмотреть доклад в полном объеме можно на видеозаписи:
Лично мне понравилось несколько докладов. Отлично выступил Алексей Баранцев на тему “Разработка стратегии автоматизации”. Леша очень опытный докладчик, особенно в онлайн режиме. Доклад был насыщен полезными советами, которые помогут многим начать автоматизировать и снизить риски провала.
Яркий и живой доклад получился также у Ольги Киселевой, которая выступала первый раз. У нее была очень спорная тема “Можно ли писать автотесты на родном языке?”, которая вызвала много споров и дискуссий. Но сам доклад никого не оставил равнодушным.
Еще я для себя отметил доклад “Обходные пути в автоматизированом тестировании”, с которым выступал Дмитрий Жарий. Не всегда получается жить в идеальном мире и к нему приходится приспосабливаться. Именно о таких способах обходить препятствия и рассказывалось в докладе. Просто и со вкусом.
Остальные докладчики тоже молодцы. Спасибо всем за подготовку и потраченное время!
Организаторы проводили голосование среди участников за лучший доклад на конференции. Результаты опубликовали сегодня. С отрывом в один голос я занял второе место после Алексея Баранцева. Леша благородно отказался от приза по причине причастности к организации конференции. В результате, первый приз достался мне – игровая приставка Xbox 360 + сенсор Kinect. Я несказанно рад этому факту! Значит, мои усилия были интересны людям и приносят пользу. А теперь мое выступление принесло пользу и мне лично. 😉
Я буду с удовольствием выступать в очередной онлайн конференции из этой серии – Chief ConfeT&QA. На этот раз с докладом “Жизнь без тестировщиков: миф или реальность?”. Не подумайте, я не против тестировщиков. Наоборот – я за то, чтобы они занимались интересной работой и приносили большую пользу проекту. Подробности можно будет услышать на моем выступлении.
Участники задавали достаточно много вопросов после доклада. Ниже вы можете найти мои ответы:
Вопрос: Какими средствами CI докладчик пользуется (советует пользоваться) наряду с TDD?
Лично я уже давно почти везде пользуюсь TeamCity (http://www.jetbrains.com/teamcity/). Отличный UI, множество уникальных фичей, отличная интеграция с различными IDE, поддержка для практически всех известных мне инструментов, классная архитектура и т.д. Бесплатная версия подойдет для большей части проектов и не вызовет проблем или нехватки чего-то. На втором месте Jenkins (http://jenkins-ci.org/). Основной аргумент за него – бесплатный с огромным сообществом, а это значит куча плагинов под все, что только можно придумать. Но UI достаточно беден и нужно конфигурировать плагины самостоятельно.
Вопрос: А если ошибки возникнут потом при эксплуатации? Те тесты, которые не предусмотрели в “чек-листе”, согласованном с клиентом?
То, что мы не предусмотрели, не могло быть реализовано. Оно должно быть реализовано как отдельная доработка. А там действует все тот же TDD. На любой баг или недоработку сначала пишем тест, а потом уже начинаем работу…
Вопрос: По факту все же получается, что тест пишется паралельно с реализацией?
В большей части случаев (из моего опыта) тесты написать проще, чем реализацию функциональности. Поэтому тесты появляются достаточно быстро, но не полностью до начала разработки. Зато их обсуждение происходит перед началом работ, а этого хватает для получения практически всех преимуществ.
Вопрос: А какую test management system посоветуете?
В идеале – никакую. Я уже говорил о дублировании усилий на поддержку тестов и тест кейсов. Я вижу этот процесс как полную автоматизацию, поэтому предлагаю избегать использования test management систем. Они заведомо склоняют нас к дублированию.
Вопрос: Авто тесты лучше писать до разработки приложения или после и кто должен за это отвечать?
Конечно же их лучше писать до разработки. В этом и есть подход TDD. Таким образом вы сможете получить весь спектр преимуществ, о которых я упоминал в докладе.
Вопрос: Что делать если UI достался от legacy проекта?
Legacy код будет проблематичным для всех, включая тестировщиков. Но TDD заставляет работать над проблемами всей командой. Разработчики будут помогать победить проблемы. Вам придется разработать с течением времени тонкую прослойку над вашим нетестируемым UI и в будущем будет на порядок легче.
Вопрос: Опиши детальнее возможности инструмента testdox.
TestDox – это очень простой, но удобный инструмент. Он ставится как плагин к IDE и позволяет разбирать названия тестовых методов на слова. Таким образом можно включать гораздо больше полезных данных в название теста, причем писать просто на английском языке, избегая особенностей языка программирования (подчеркиваний, camel case и прочих). Поддерживается редактирование, список тестов, создание новых тестов. Таким образом, данный плагин приближает вас на шаг к тестам в качестве документации. Остается только подключить мозг. 🙂
Вопрос: Что ты думаешь по поводу BDD?
BDD – отличная практика, которая является подмножеством TDD. Вместо тестов рекомендуется начинать с поведенческих шаблонов приложения, причем оформлять их в человеческом виде (в основном предложениями английского языка). Не всегда дополнительные расходы времени на специализированный инструмент действительно оправданы. Если никто со стороны бизнеса не заглядывает в эти тесты, то возможно стоит перейти на уровень технических тестов с DSL.
Вопрос: Прокомментируй еще раз рекомендации с чего начать.
Начать стоит с того, чтобы осознать четко для себя зачем и почему стоит работать по TDD. После этого стоит донести свои мысли и идеи до всех членов команды. Причем не то, что вы собираетесь работать по TDD, а то, какие преимущества могли бы получить все от этого. Если у вас получится это сделать, то все будут хотеть применить TDD. А потом дело лишь в стратегии. Вам нужно найти удобный момент и начать внедрение. Поддержка команды поможет вам сделать это достаточно быстро (я имею ввиду начать). А дальше у вас будет освобождаться все больше времени за счет 100% автоматизации новой функциональности и вы сможете укрепить свои позиции. И не забудьте подготовиться морально к тому, что придется поломать мозг, как свой так и коллег. 🙂 Удачи!
