В эти выходные, 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, где бы она не проходила. Спасибо организаторам, докладчикам и участникам за отлично проведенное время!

Весна постепенно набирает обороты. Март уже заканчивается и скоро наступят солнечные (мы искренне надеемся) апрель с маем. Мы запланировали много событий на эту весну. Что же вас ждет?

29 марта состоится 14-ая встреча «Клуба анонимных разработчиков». Мы смело можем назвать ее одной из самых интересных встреч – ведь будет рассматриваться «горячая» тема облачной разработки. На суд участников будут представлены доклады о разработке на облаке Amazon и Windows Azure. Поэтому каждый найдет для себя что-то интересное. Встреча пройдет в уютном офисе ДатаАрт по адресу Бехтеревский переулок 14Е. Начало в 19:00.

6-7 апреля состоится новый тренинг «Инженерные практики в Agile». 2 тренера (Николай Алименков и Алексей Солнцев) в течение 2-ух дней познакомят участников с 8-ью современными инженерными практиками. Будут затронуты вопросы внедрения, поддержания и пользы от этих практик. Все практики будут демонстрироваться на реальных примерах и включают в себя многолетний опыт использования наших тренеров. Это один из лучших наших тренингов. Группа почти набрана, осталось всего 5 мест.

13-14 апреля мы впервые проведем новый тренинг Дмитрия Ефименко под названием «Практики эффективного, но экономного проектирования». Дима вложил в этот тренинг весь свой опыт по проектированию программного обеспечения. Тренинг отлично сочетает в себе информацию о процессах разработки и проектирования, работу с требованиями, инженерные практики и подходы, анализ и управление рисками, а также несколько интересных практических заданий. Участники даже будут писать реальный код. Группа еще формируется и не поздно присоединиться к составу участников.

21-22 апреля состоится важное событие в мире тестирования – международная конференция SQA Days 11. Наш тренер Николай Алименков выступит на конференции с докладом «А вы знаете что тестируют ваши тесты?». В докладе речь пойдет о связывании тестов с самыми важными артефактами вашего проекта – требованиями и кодом. Николай на практических примерах продемонстрирует как полностью контролировать что и как тестируют ваши тесты. Помимо этого, 20 апреля мы проведем популярный тренинг «QA в Agile». Этот тренинг позволит участникам познакомиться с ролью тестировщика в Agile процессах, грамотно настроить процесс QA в Agile команде, разобраться с ролью автоматизации тестирвания и современными веяниями в мире тестирования. Тренинг будет полезен как менеджерам, так и обычным тестировщикам.

В апреле проходит еще несколько интересных конференций в России и Украине, но побывать везде просто не хватает времени. Вот некоторые из них: CodeFest 2012, Cloud Foundry Open Tour 2012, Software People’12, РИТ++, Quality Assurance Day’12, Fun ConfeT&QA. Мы также постараемся провести очередную бесплатную онлайн конференцию IT Brunch. Тема еще окончательно не выбрана, но в этот раз мы планируем сделать ее более технической.

28 апреля пройдет еще один наш новый тренинг «Успешный старт проекта». Сергей Поволяшко подготовил этот тренинг на основании своего многолетнего опыта управления проектами. На тренинге вы сможете узнать какие активности стоит проводить на стадии инициирования проекта, какие риски есть и как с ними бороться, как оценивать проекты с финансовой и временной точек зрения, что необходимо включить в контракт и как это сделать. Если вы менеджер и ваша работа связана со стартом новых проектов, то этот тренинг для вас!

27-28 апреля Александр Белецкий проведет свой новый тренинг «Веб-разработка с использованием ASP.NET MVC». Этот тренинг рассчитан на программистов, знакомых с концепциями ASP.NET, возможно уже имеющие опыт с Web Forms, но желающих приобрести практические навыки с новой, популярной технологией ASP.NET MVC. Тренинг очень насыщенный и на нем будут рассмотрены практически все аспекты разработки современных веб приложений с использованием ASP.NET MVC.

11-12 мая в Москве состоится очередная конференция для разработчиков Application Developer Days-3. На протяжении двух дней участники смогут посетить множество совершенно разных докладов на тему разработки, а также пообщаться с коллегами. Николай Алименков выступит с докладом «Разработка распределенных приложений на AWS», в котором поделится своим опытом (более 2-ух лет) в разработке приложений в облачной среде. Николай рассмотрит сервисы, предоставляемые Amazon (самым популярным облачным провайдером на данный момент) и даст множество полезных советов тем, кто начинает или только задумывается над переездом в облака.

19 мая мы уже во второй раз соберем Java разработчиков в Киеве на большую конференцию для Java практиков – JEEConf 2012. В этот раз мы собрали еще более интересную программу. Докладчики приедут в Киев с разных стран и будут освещать различные инструменты, методики и практики из мира Java. Николай Алименков выступит на конференции с докладом «За что я ненавижу Hibernate?», в котором рассмотрит недостатки одного из популярных ORM решений и способы их обхода. На данный момент уже более 300 участников изъявили свое желание участвовать в конференции. Это будет действительно яркое событие наступающей весны.

Перед конференцией мы организуем ряд тренингов, посвященных Java разработке: «JavaScript for Java developers», «TDD в Java», «Introduction to Java EE 6″. Все тренинги проводятся опытными профессионалами индустрии. Группы наполняются очень быстро, поэтому поторопитесь занять себе место в составе участников.

Завершит весеннюю гонку конференция AgileBaseCamp CREW DRILL в Харькове 26-27 мая. Это два дня, насыщенных докладами экспертов, воркшопами и вдохновляющими блицами. Панельные дискуссии и Open Space, демонстрации от практиков и два полномасштабных мастер-класса. Наши тренеры Александр Белецкий, Дмитрий Ефименко и Николай Алименков готовятся выступить с докладами. Программа конференции еще формируется.

А еще на апрель и май у нас запланированы корпоративные тренинги в Киеве, Днепропетровске, Воронеже и Москве. Приглашайте нас в свой город и мы с радостью приедем!

Вот такая интересная выдалась весна. Будем рады видеть вас на перечисленных мероприятиях!

В конце прошлой недели прошла вторая по счету конференция Selenium Camp. В этот раз конференция растянулась на два дня – 24 и 25 февраля. Первый день был целиком посвящен обучению. Мы организовали 3 потока мастер-классов и тренингов на целый день для более 50 участников. Программа получилась достаточно насыщенной: «Написание тестов с нуля на базе WebDriver и Java», «Selenium против AJAX», «Пробуем Selenium на практике», «Миграция с Selenium 1.0 на Selenium 2.0 (aka WebDriver)», «Тестирование веб приложений с WebDriver/Selenium».

Вечером того же дня ребята из automated-testing.info организовали посиделки тестировщиков. В качестве приглашенных докладчиков выступили David Burns и Алексей Баранцев. Было очень интересно послушать историю о развитии Selenium/WebDriver и получить множество полезных советов от людей, которые напрямую занимаются разработкой этого замечательного инструмента.

В это же время велась активная подготовка зала в БЦ «Парус» для основного дня конференции. А принять в гости предстояло около 350 участников. Зимой в Киеве очень мало площадок готовы принять комфортно такое количество людей. Мы приложили максимум усилий, чтобы все чувствовали себя свободно. Поэтому пришлось ограничить количество участников и отказать многим из тех, кто пытался зарегистрироваться в последнюю неделю.

Регистрация прошла успешно, без каких-либо очередей и суеты. Все получили яркие пакеты с материалами конференции, красочные бейджи и смогли вдоволь пообщаться за утренним кофе в холле. Холл в это время напоминал муравейник, который просто гудел от общения. В этом году мы впервые поменяли формат печатной программы конференции. Теперь она является одновременно и блокнотом для заметок. Участники могут делать заметки непосредственно около доклада, что позволяет структурировать записи и получить в итоге персональную «книгу участника».

Я открыл конференцию словами благодарности докладчикам за проделанную работу (а им пришлось пройти 4 этапа ревью), волонтерам за огромную помощь в подготовке конференции и организаторам за их огромные усилия по организации мероприятия. Украинские компании практически не поддерживают мероприятия для тестировщиков – в этот раз нас поддержала только компания SysIQ (наш постоянный партнер по различным конференциям), за что ей огромное спасибо. Я также рассказал о составе пакета участника и продемонстрировал карточки благодарности докладчикам. Это теперь обязательный атрибут каждой нашей конференции. Участники могут выбрать понравившиеся им доклады и написать слова благодарности докладчику. Вы не представляете как это приятно и сколько сил дает выступающим!

В этом году мы заключили договоренность с Mail.RU Group и компанией Воля об обеспечении надежного и быстрого интернета на конференции. Интернет держался стабильно и не падал на протяжении всего дня. По холлу постоянно бродили работники компании и проверяли качество соединения. Лично у меня были небольшие перебои утром, но оказалось, что они были вызваны настройками одного из ноутбуков в холле, который пытался раздавать интернет.

Программа конференции в этом году была на голову выше чем в прошлом. Это лично мое мнение. Доклады стали гораздо более техническими, практическими и злободневными. В этом году уже 3 иностранных докладчика посетили конференцию. Также в составе докладчиков было 3 члена команды разработки Selenium/WebDriver. Это очень здорово, потому что участники имели возможность из первых уст узнать подробности развития инструмента, ближайшие планы, технические детали.

Мы старались как могли сбалансировать нагрузку в программе между тремя потоками. Но все равно маленькую и уютную сцену для мастер-классов, рассчитанную на 50 человек, то и дело участники норовили расширить дополнительными стульями. Не переживайте, все доклады записывались на видео и будут выложены на сайте конференции в течение нескольких недель. Маленькая сцена пригодилась еще раз ближе к вечеру – на ней устроили серию Lighting Talks. Нашлось 5 желающих выступить с мини-докладами. Это очень здорово, когда у участников есть чем поделиться.

У меня самого в этот день было 2 доклада, поэтому мне удалось побывать далеко не на всех выступлениях. Из увиденного очень понравились доклады David Burns «The road to a standard» и «Selenium против AJAX» от Алексея Баранцева. David рассказал о текущем состоянии дел в продвижении WebDriver в качестве стандарта W3C. Это очень важное направление, потому что оно может революционным образом облегчить жизнь всех, кто тестирует приложения в браузерах. Производители будут сами заботиться о поддержании стандарта, что сделает тестирование проще, быстрее и стабильнее. Леша отлично рассказал технический доклад о тонкостях и особенностях работы WebDriver с AJAX приложениями. Огромное количество полезных советов, идей, известных проблем и обходных маневров к ним. Отличный доклад!

Мои доклады прошли достаточно ровно. Спасибо всем, кто пришел меня послушать. Я часто рассказываю вещи, которые на первый взгляд кажутся странными, но на практике приносят очень большую пользу. В результате, я получил много карточек обратной связи, которые потом очень приятно пересматривать. Это дает заряд энергии и стимул для новых выступлений.

Мы пытались в этот раз избежать проблем с гардеробом. Для этого был применен целый ряд мер. Похоже, больших очередей удалось избежать и участники нормально разошлись на обед. Ретроспектива, проведенная на основании отзывов участников, очень помогает нам делать конференции лучше с каждым разом.

Незаметно подошел момент закрытия конференции. Кроме традиционных слов благодарности докладчикам, волонтерам, организаторам, спонсорам и всем присутствующим, у нас был заготовлен розыгрыш призов. Это было чрезвычайно весело и интересно. Мы заранее огласили, что только заполненные анкеты обратной связи смогут участвовать в розыгрыше призов. Некоторые участники не вняли нашей просьбе, поэтому не всегда приз уходил с первой попытки. В общей сложности мы разыграли 3 книги, Amazon Kindle Touch и 1 сертификат на посещение любого тренинга от XP Injection. Компания SysIQ вдобавок разыграла 25 прикольных футболок, билет на конференцию SQADays 11, сертификат на курсы английского языка и лицензию на Intellij IDEA.

Таким образом, достаточно много участников ушли с конференции не с пустыми руками, а некоторые даже получили очень ценные призы. Очень приятно видеть на лицах участников искреннюю радость и улыбки.

Все материалы конференции будут выложены на сайте в разделе материалов. Сейчас там уже появляются отчеты и презентации докладчиков. В скором времени подоспеют видеозаписи и фотоотчеты.

Мы будем рады увидеть всех в следующем году на Selenium Camp 2013 и на других наших мероприятиях!

Осталось меньше месяца до проведения масштабного мероприятия, целиком посвященного продукту для тестирования web-приложений Selenium. Конференция Selenium Camp 2012 пройдет в Киеве 25 февраля. Кроме того, что это прекрасный повод пообщаться с коллегами, Selenium Camp будет интересен как отличная стартовая точка для тех, кто только задумывается о применении Selenium, а также для профессионалов, использующих его долгое время.

Уже зарегистрировано более 250 участников из разных городов Украины, России, Беларуси и Сербии. Состав участников очень интересный и конференция станет отличной площадкой для обмена опытом и знаниями.

Программа конференции на финальной стадии формирования и организаторы приготовили приятные сюрпризы. Выступления будут проходить параллельно на 3-ех сценах. Участники смогут посетить около 20 докладов. Помимо сильного состава докладчиков из СНГ, Selenium Camp посетят иностранные гости.

Первым принял предложение выступить David Burns. David – опытный разработчик тестов в Mozilla, один из разработчиков WebDriver, отвечает за Python драйвер, активно ведет блог theautomatedtester.co.uk и является автором книги «Selenium 1.0 Testing Tools: Beginner’s Guide».

Следующий докладчик является разработчиком сразу двух инструментов: Selenium/WebDriver и Watir. Это Jari Bakken. Jari создал проект watir-webdriver, где объединил эти два инструмента. На данный момент он работает инженером по тестированию в компании FINN.no, где занимается автоматизацией тестирования и инфраструктурой для тестирования.

Samit Badle также дал согласие выступить на конференции в этом году. Это еще один член команды разработки Selenium/WebDriver. Он также является автором многих плагинов для Selenium IDE и ведет свой блог о Selenium – blog.reallysimplethoughts.com.

Еще один гость из далекого зарубежья - Dmitriy Kovalenko. Дима за 8 лет в тестировании успел поработать во многих известных компаниях: Rosetta Stone Inc., ThoughtWorks, Centro, Groupon. Последние 2 года он работает в сфере DevOps. Имеет большой опыт работы с Selenium и делится им в своем блоге agilesoftwaretesting.com.

В преддверие конференции, 24 февраля, пройдет образовательный день. В этот день будут проводиться тренинги и мастер-классы для различного уровня участников. Более 50 человек примут участие в образовательной программе в этот день. Вы имеете уникальную возможность поучиться у профессионалов в области автоматизации тестирования с использованием Selenium.

Уже определено место проведения конференции – это конференц-залы бизнес-центра «Парус». Помимо наличия комфортных залов для проведения мероприятия, бизнес-центр очень удачно расположен в самом центре Киева. Адрес бизнес-центра: ул. Мечникова 2а. Схему проезда и ближайшие транспортные маршруты можно посмотреть на карте или найти на официальном сайте.

Напоминаем, что с 1 февраля начался последний этап регистрации, который продлится до 20 февраля. Если вы еще не приняли решение об участии, то самое время это сделать. Присоединяйтесь, будет интересно!

Завершая серию статей о стоимости качества подходим к практической части, а именно, как это посчитать? Для того, чтобы были конкретные данные, на основании которых можно было бы принимать какие-либо управленческие решения. Напомню о предыдущих статьях и для начала рекомендую их прочесть: «Стоимость качества. Часть 1 – Что это такое?», «Стоимость качества. Часть 2.1 – Зачем это надо?», «Стоимость качества. Часть 2.2 – Кому это надо?».

Так как сбор и интерпретация данных относится к дисциплине метрик, то здесь стоит обратить внимание на классический треугольник успешности и полезности измерений:

• Люди – должны быть обучены данной дисциплине, по крайней мере понимать зачем все это. И, естественно, должны иметь возможность (санкционированное время, желание, инструментарий и т.п.)
• Процессы – должны быть. Все рабочие процессы, например: как мы готовим тестовую документацию и тестируем, жизненный цикл дефекта, жизненный цикл задач и т.п. должны быть в том или ином виде описаны-оговорены и донесены до исполнителей
• Инструментарий – собственно те технические средства, которые помогают людям делать их процессы – тайм трекеры, баг трекеры, таск трекеры и т.п. Именно они, при корректной интеграции в процессы работы и при соответствующей настройке, позволяют и собирать данные, и обрабатывать, и презентовать.

В этой статье поговорим именно об инструментарии.

Для начала обратимся к такой дисциплине как Scope Management – управление объемом работ по проекту. В первую очередь это правило 100%, т.е. список работ по проекту должен отражать абсолютно ВСЕ работы и им должно быть место в расписании работ, плановые и фактические трудозатраты по ним должны быть оценены и отрапортованы. ВСЕ – в т.ч. инспекции документов, устранение дефектов, совещания, и даже участие в интервью по набору персонала на проект…

Хорошо помогают шаблоны списков работ (WBS – work breakdown structure).

Ключевым моментом является такая декомпозиция списка работ, где были бы выделены отдельные задачи (берем для примера разработчика), и, соответственно временнАя отчетность на:

• Инспекцию спецификаций (COQ)
• Разработку архитектуры
• Юнит тесты (COQ)
• Кодирование
• Инспекцию кода (COQ)
• Устранение дефектов после тестирования (COPQ)
• Разворачивание продукта в тестовом окружении
• Устранение дефектов по гарантийным обязательствам (COPQ)
• Устранение дефектов после инспекции кода (COPQ)
• И т.п.

В скобках указаны интересующие нас категории – COQ, COPQ. На самом деле, отнесение некоторых задач в какую-то категорию – это ваше решение, например, юнит тесты можно отнести и в разработку. Общие же рекомендации что есть что приведены в первой статье «Стоимость качества. Часть 1 – Что это такое?».

Как далеко идти с декомпозицией – решать вам в зависимости от того, что нужно и что вообще имеет смысл. Например, устранение дефектов после тестирования можно отнести как в общую для всех разработчиков задачу «Устранение дефектов», так и разделять, например, по модулям – «Устранение дефектов по модулю №1» и т.д.

Таким образом, если у вас есть такие компоненты:

• Корректная декомпозиция работ
• Таск-тайм трекер, который позволяет отразить и декомпозицию, и отчетность о затраченном времени
• Обучающие меры для сотрудников – как пользоваться таск-тайм трекером

То сбор данных по соответствующим категориям у вас настроен, и что немаловажно, интегрирован в рабочие процессы. И вы легко можете получать информацию о стоимости качества.

Конечно же, возникают некоторые тонкости в организации и процессов работы, и инструментария. Давайте посмотрим на примеры.

Что такое дефект и как его учитывать? Обычно, если тестировщик находит дефект, то он (дефект) попадает в систему управления дефектами как отдельная запись с описанием, серьезностью и другими параметрами. Но ведь дефекты, найденные, например, на инспекции кода, по существу, ничем не отличаются от дефектов, найденных тестировщиком. И они обычно никак не учитываются, в лучшем случае фиксируется время, потраченное на инспекцию кода. Но возникает резонный вопрос – а зачем это надо вообще? Если уж вы решили определять стоимость качества, то нужно, как минимум фиксировать время на инспекцию кода и время на исправление дефектов, найденных при инспекции. Если вам это не нужно – то не делайте, это будет пустая трата времени и раздражающий фактор для сотрудников. Если вы хотите таки фиксировать не только время на инспекцию, то можно осторожно попробовать использовать систему управления дефектами – например на каждый факт инспекции внести одну запись, к которой приложить список дефектов в коде. По крайней мере необходимость исправить код не потеряется и у вас будут данные о результатах инспекции.

Интенсивная работа с требованиями. А что если требования обсуждаются настолько интерактивно между заказчиком, аналитиком, разработчиками, тестировщиками, что четкая разница между формализацией требований, их инспекцией (обсуждениями) и устранением дефектов (рекомендации, выданные при обсуждениях) не видна? Или же не имеет смысла это разделять. Тут, наверное, лучший вариант – без фанатизма, просто отнести такой вариант работы в задачу «Разработка требований», т.е. к COQ или COPQ не относить вообще. Если же такого интерактива нет, а есть четкое разделение на формализацию, инспекции, и исправление дефектов, и, внимание!, вам действительно надо выделять COQ и COPQ, то предлагаю такой же подход, как и в предыдущем примере – с использованием системы управления дефектами.

Завершая цикл хочу сказать, что серьезно «заводиться» со стоимостью качества и метриками стоит лишь в том случае, если у вас есть:

• Великая цель – зачем это делать и кому от этого будет лучше
• Подготовка по теме – как это работает
• Здравый смысл – в разумной реализации Великой цели

Надеюсь, что это было вам полезно.

Оригинал статьи здесь.

Продолжаю серию статей о стоимости качества. Две предыдущие: «Стоимость качества. Часть 1 – Что это такое?» и «Стоимость качества. Часть 2.1 – Зачем это надо?». В этой же статье рассмотрим «Кому это надо?». Очень рекомендую обратить внимание на предыдущие статьи, т.к. они представляют собой логическую цепочку рассуждений.

Здесь рассмотрим, в каких ситуациях следует (или не следует) озаботиться стоимостью качества и относительной величиной его доли в общем объеме работ. Давайте рассмотрим несколько вариантов. Но для начала вспомним классическую диаграмму стоимости изменений (Cost of Change), но будем ее понимать в контексте стоимости устранения дефектов, т.к. график по своей сути не меняется.

Смысл в том, что чем дальше мы продвигаемся по времени, тем дороже обходится устранение дефектов. Например, если не удалось выявить несоответствие в требованиях вначале (что на самом деле очень дешево сделать), то потом скорее всего придется «перепедаливать» на значительно бОльшую сумму.

Представленный ниже список вариантов далеко не исчерпывающий, рассмотренные ситуации и выводы по ним в вашей деятельности могут отличаться от приведенных ниже. А также могут быть и комбинации этих вариантов.

Вариант 1. Проект типа Fixed Price.

Соответственно, и скорее всего, помимо бюджета четко зафиксированы объем работ и сроки. Здесь нужно в первую очередь обращать внимание на требования и критерии приемки. Оставим в стороне дискуссию о возможной неполноте и изменчивости требований, о применимости этого типа контракта, это регулируется другими механизмами. Здесь становиться очевидным, что нужно стараться минимизировать COPQ, т.к. это напрямую влияет на доход и, возможно, на штрафные санкции, и-или на расходы по гарантийным обязательствам. Но с другой стороны минимизация COPQ выражается в увеличении COQ, и тут тоже нужно не переусердствовать. На помощь приходит вышеуказанная диаграмма «Стоимость устранения дефектов». Напрашивается вывод, что имеет смысл уделить особое внимание процедурам из COQ как можно раньше. А именно – постановке процессов обеспечения качества и реализации мер контроля (инспекции спецификаций, архитектуры, кода, тестовой документации и т.п.). См. подробности в статье «Стоимость качества. Часть 1 – Что это такое?». Стоимость процедур COQ легко считается и планируется, и также легко соотносится со штрафными санкциями.

Кому это надо? Компании Исполнителю, т.к. это ее доход и репутация. Говоря о процедурах из COQ, то немного бОльший фокус должен быть на эти меры на начальных стадиях, т.к. последствия от их неприменения скорее всего аукнутся относительно бОльшими расходами на COPQ.

Вариант 2. Служба поддержки (или любая деятельность, которая по своей сути не есть проектом, а есть повседневной операционной деятельностью, или для простоты – конвейером).

Этот вариант является просто идеальной почвой для «экспериментов» по выявлению наилучшего соотношения COQ, COPQ и собственно стоимости предоставления услуг. Путем внедрения улучшений можно определить какой процесс и какое соотношение COQ и COPQ способствует наилучшему соотношению стоимости, количества и качества результатов деятельности. Под COPQ в этом случае подразумеваются переделки из-за некорректного выполнения запроса на поддержку.

Кому это надо? Компании Исполнителю для снижения расходов и увеличения удовлетворенности пользователей, клиентов. Но опять же, тогда, когда есть явные проблемы. Если все всех устраивает, то нужно ли что-то менять или считать?

Вариант 3. Проект или долгосрочное партнерство по контракту типа Cost Reimbursable.

Контракт Cost Reimbursable предполагает что Заказчик оплачивает исполнителю его расходы плюс прибыль. Есть несколько разновидностей. Не вдаваясь в подробности, это хорошо подходит для долгосрочного outstaffing, в основном по разработке, развитию или поддержке больших продуктов. Здесь особенность в том, что Исполнитель не очень заинтересован сокращать свои расходы, т.к. на каждый доллар расходов он получает некий % прибыли. И если у Заказчика нет жестких требований к процессам работы, то так или иначе это расслабляет Исполнителя. И этот «расслабон» по традиции уменьшает усилия, входящие в COQ и увеличивает COPQ. В таком типе взаимоотношений Заказчик обычно имеет гораздо бОльший контроль над процессами и в принятии решений, чем в Fixed Price. Поэтому…

Кому это надо? Я бы сказал 50-50 и Заказчику и Исполнителю. Заказчику – для снижения своих расходов и увеличения производительности Исполнителя. Исполнителю – для поддержания репутации и, как результат для сохранения взаимоотношений. Причем, в силу долгосрочности отношений, это также является благодатной почвой для улучшений и оценки их эффективности.

Вариант 4. Деятельность или продукт для систем класса life critical или mission critical.

Здесь, очевидно, доля COQ будет (и должна быть) очень высока, причем все ее аспекты, а особенно превентивная составляющая. И она может легко превышать и собственно долю разработки и долю COPQ. Обычно только достаточно зрелые компании могут обеспечить выполнение процедур, из которых состоит COQ.

Кому это надо? И Заказчику и Исполнителю, причем для обоих фокус скорее не в снижении расходов, или в скорости работы, а в качестве (надежности) таких систем.

Вариант 5. Пилотные проекты с целью развития бизнеса.

Здесь могут быть какие угодно варианты о том, что важно или нужно. От «слепить» что-то побыстрее, до демонстрации зрелости процессов работы. Также играет роль бизнес перспектива, Исполнитель легко может сработать себе в убыток, чтобы заполучить «вкусного» заказчика. Говоря о COQ и COPQ для этого варианта, и основываясь на собственном опыте скажу, что это вариант очень похож на mission critical. Но есть и отличия. К COPQ здесь можно, без преувеличения, прибавить стоимость упущенной возможности, т.е. потенциальную сумму контракта (если вы потеряли потенциального заказчика именно из-за плохого качества «пилота»).

Кому это надо? Однозначно Исполнителю. По-моему, пилотные проекты «вкусного» класса должны рассматриваться как mission critical, с особым вниманием процедурам из COQ.

Вариант 6. Качество устраивает.

В своей деятельности сталкивался с ситуациями, когда заказчик совершенно осознанно диктовал условия по занижению COQ по причине бюджетного ограничения. А именно, или исключались некоторые процедуры по контролю качества, и-или была явно недостаточная пропорция разработчиков или тестировщиков. Заказчику нужно было «напедалить» как можно больше. Причем Заказчик совершенно осознавал к чему это приведет, и его совершенно устраивало то среднее качество, которое он получал. К счастью, такие заказчики были достаточно технически развиты и адекватны.

Кому это надо? В этом случае больше Заказчику, т.к. он совершенно осознает что делает и отдает себе отчет о результатах.

В итоге, чтобы понимать, кто и в каких ситуациях заинтересован в улучшениях, затрагивающих соотношение затрат на COQ, COPQ и разработку продукта (и процедуры входящие в них), нужно проанализировать среду обитания проекта, деятельности. Надеюсь, что приведенные выше варианты прояснили как это можно сделать.

Просьба не воспринимать буквально следующие цифры, это скорее относительные взаимоотношения доли COQ и COPQ в общей стоимости проекта, деятельности. Приведу по тем вариантам, где есть опытные данные.

• Вариант 1. COQ + COPQ – 40-50% от общей стоимости
• Вариант 3. COQ + COPQ – 30-40% от общей стоимости
• Вариент 4. Опытных данных нет, но осмелюсь предположить что COQ + COPQ – 50-80% от общей стоимости
• Вариант 5. COQ + COPQ – 40-60% от общей стоимости
• Вариант 6. COQ + COPQ – 20-30% от общей стоимости, но из COQ + COPQ бОльшая доля принадлежит COPQ

В следующей статье «Стоимость качества. Часть 3 – Как это посчитать?» поговорим о практических вопросах сбора и интерпретации данных для подсчета COQ + COPQ.

Продолжаю тему «Стоимость качества», начало было в предыдущей статье «Стоимость качества. Часть 1 – Что это такое?». Здесь выскажу некоторые соображения о том, зачем и когда нам вообще нужно беспокоиться о стоимости качества и качестве как таковом, а также какая польза от того, что мы его можем определить. Под качеством здесь понимается не только качество конечного и промежуточных результатов работы, но и качество инженерных и управленческих практик, принимаемых решений.

Наиболее очевидны ситуации, когда что-то явно идет не так и нужно как-то реагировать. В общих чертах это типичные проблемы со сроками, качеством, бюджетом, а соответственно недовольные заказчик, руководство, команда проекта. Реагировать – значить что-то менять, улучшать, и в большинстве случаев это что-то – рабочие процессы или какие-то организационные моменты.

Но, возникают вопросы:

• Как доказать и убедиться, что улучшение полезно, для кого или чего именно?
• Как понять, чьим интересам улучшение соответствует, или не соответствует?

Небольшое отступление, скорее всего есть инициатор такого изменения, и скорее всего есть участники проекта, с которыми нужно согласовать (доказать целесообразность) внедрение этого изменения и/или получить их разрешение. Ну а убедиться, что изменение помогло нужно наверное всем в нем участвующим.

Основные согласующие-разрешающие участники это заказчик и руководство, они хорошо понимают язык денег и производительности, т.е. количество пригодных результатов, произведенных проектной командой за эти деньги. Соответственно на этом языке и будем стараться говорить далее.

Еще одно необходимое отступление – по поводу производительности. Это некоторое количество работы в единицу времени. Количество работы «по научному» – размер (size). Наиболее понятный пример – Velocity (Story Points per Sprint), где Story Point – одна единица размера. Это конечно не идеальный способ, но все же существенно лучше чем человеко-часы. Или же, за единицу размера могут приниматься какие-то дискретные виды работ (например, разработка стандартного баннера). Тема размера – это отдельная довольно серьезная дисциплина, по этому поводу есть небольшая ознакомительная статья, а более полный комплект доступен здесь (за подписку).

Для плавного перехода к практическому применению давайте сначала для наглядности посмотрим на следующие диаграммы, иллюстрирующие потенциальное влияние изменений. Предположим, что у нас работает стабильная по составу команда, и за последнее время в среднем соотношение затрат между видами работ такое (из спринта в спринт, из месяца в месяц и т.п.). Где «Создание продукта» – это все что не «Total Quality Costs – TQC» (см. Часть 1), т.е. кодирование, требования и т.п.

Соотношение №1

Исходная ситуация. Соотношения приводятся только в демонстрационных целях, у вас могут быть иные.

Предположим, что кого-то такая ситуация не устраивает, то ли по стоимости, то ли по производительности, то ли по качеству.

Решили что следующие улучшения могут быть наиболее полезными:

• ввести инспекцию спецификаций,
• или же добавить нагрузочное тестирование,
• или же ввести инструментарий прослеживаемости (traceability) требований

Пусть это будут Соотношения №№2-4 соответственно. И пусть они для простоты будут внедряться независимо, по-одному. Рассмотрим потенциальные варианты.

Соотношение №2

Инспекция спецификаций помогла, она, как часть COQ (+5%), помогла существенно сократить COPQ (-10%), высвободив ресурсы. Причем, высвобождение может пойти либо на увеличение производительности (Соотношение №2), либо на экономию средств (Соотношение №2.1).

Соотношение №3

Введение нагрузочного тестирования, очевидно, не помогло – производительность команды понизилась (-5%), т.к. время на него тратится, а COQ повысился (+5%). Заметим, что проверка достижения запланированной нагрузки на приложение тоже входит в TQC, а дефекты, вызванные, якобы, нагрузочными проблемами, таковыми не оказались. Значит, «копали не туда».

Соотношение №4

Внедрение инструментария traceability (+5% COQ) на первый взгляд, не сказалось ни на производительности, ни на экономии средств. Но снизило COPQ (-5%), что можно рассматривать как позитивное явление, т.к. часть дефектов всегда просачивается заказчику, а их меньшее количество вообще означает и меньшее их обнаружение заказчиком, что, как минимум, носит положительный репутационный характер.

Из этих рассуждений, а также забегая немного вперед, скажу, что нет какого-то универсального рецепта о корректном соотношении между COQ, COPQ и общей стоимостью проекта, все зависит от приоритетов по производительности проекта, стоимости, качества, интересов основных заинтересованных лиц.

Подводя итог можно сказать, что:

• Во-первых, если что-то кого-то в проекте не устраивает, то проблемы есть, и надо что-то улучшать
• Во-вторых, если проблемы есть, но непонятно что конкретно может помочь, то можно предположить несколько наиболее полезных улучшений
• НО, в-третьих, нужно понимать, чьим интересам какое улучшение соответствует, или не соответствует. Т.к. даже от самого очевидного улучшения не все участники проекта могут быть счастливы . Об этом в следующей Части 2.2
• В-четвертых, нужно определить, каким образом будет оцениваться успешность улучшений, так чтобы было поменьше субъективных ощущений и побольше цифр и фактов. Об этом в еще одной – Части 3.

Спасибо за внимание, продолжение следует.

Оригинал статьи здесь.

Хочу предложить вашему вниманию несколько статей, посвященных стоимости качества. Эта, первая часть, приводит некоторые базовые положения на эту тему. В остальных же буду приводить свои соображения по поводу практического внедрения и применения.

Давайте подумаем, во что выливается плохое качество продукции, причем, неважно о чем речь, то ли о программном продукте, то ли о производстве автомобилей. И не только плохое качество продукции, но и плохое качество процесса производства продукции.

Давайте на примере. Допустим, разрабатываем какое-нибудь более-менее сложное приложение без достаточного внимания таким практикам как бизнес анализ и проектирование (элементы процесса). Вдобавок к этому имеем некачественный код, и для полного «счастья» не выделяем достаточного времени на тестирование.

В совокупности вся эта «радость» приводит к:

• Внутренним переделкам, устранению дефектов. Плохо
• Внешним претензиям от заказчика, опять же ведущим к переделкам, а то и к штрафным санкциям. Очень плохо
• Потере репутации и бизнес возможностей. Невыносимо плохо

Итак, существуют такие основные понятия:

• Общая стоимость качества (Total Quality Costs – TQC), что включает:
  • Стоимость качества (Cost of Quality – COQ)
  • Стоимость плохого качества (Cost of Poor Quality – COPQ)

В разных источниках по-разному определяют, что именно относиться к COQ или COPQ (а то и вообще не разделяют), мы же здесь посмотрим на наиболее распространенное распределение. Причем, я не претендую на абсолютную правоту, в вашей практике вы можете захотеть сделать это немного по-другому.

• Стоимость качества (Cost of Quality – COQ)
  • Cтоимость превентивных мер (Prevention Costs), например
    • Настройка и внедрение процессов (разработки ПО), в организации и/или на проекте
    • Обучение процессам, инженерным и управленческим практикам, концепциям качества
    • Подбор на этапе инициирования проекта совместимых методологий, технологий, типов контрактов, фаз, которые бы наиболее эффективно достигали бизнес целей проекта/продукта
    • Идентификация и внедрение улучшений в организации и/или на проекте
    • Планирование качества на проекте – виды работ, направленные на обеспечение качества на проекте
  • Стоимость контроля (Appraisal Costs), например
    • Инспекции спецификаций, архитектуры продукта
    • Инспекции кода
    • Разнообразные виды тестирования продукта, как конечного, так и промежуточных результатов
    • Приемочное тестирование
    • Ассоциированные затраты на разворачивание тестовых сред
    • Аудиты процессов, результатов
• Стоимость плохого качества (Cost of Poor Quality – COPQ)
  • Стоимость устранения внутренних дефектов (Internal failure costs), например
    • Затраты на «багфикс» и переделки кода, документа, архитектуры
    • Затраты на непригодные к дальнейшему использованию результаты работы
    • Вынужденные ре-тестирование и ре-инспекции
  • Стоимость устранения внешних дефектов (External failure costs), например
    • То же, что и для внутренних, но обнаруженных заказчиком, плюс
    • Обработка претензий заказчика
    • Затраты по гарантийным обязательствам
    • Контрактные штрафные санкции
  • Стоимость непрямых убытков (Indirect poor-quality costs), сложно количественно оценить, но это
    • Потеря внешней репутации, потенциально ведущая к сокращению, потере бизнеса
    • Потеря внутренней репутации – демотивация, сокращение персонала

В завершении этой статьи приведу классическую фразу Philip B. Crosby, который внес значительный вклад в практики управления качеством и теорию менеджента:

- «Quality is free. It’s not a gift, but it’s free. The ‘unquality’ things are what cost money.»

Он же ввел принцип «Ноль дефектов, – сделай правильно с первого раза».

Далее, в следующих статьях, постараюсь изложить некоторые дальнейшие соображения по поводу стоимости качества, как минимум видится вот это: а – «Зачем и кому это надо?»; б – «Как это работает?».

Оригинал статьи здесь.

Многие уже полным ходом готовятся к новогодним праздникам. И правильно – осталось ждать совсем немного. Первая половина января 2012 года однозначно пройдет в праздничной эйфории. Что же готовит нам вторая половина января?

28 января в Киеве пройдет очередная конференция AgileBaseCamp, на этот раз посвященная продуктовой разработке и имеющая название «From Idea To Product».

Экспорт ресурсов и создание продуктов – две полярные ментальности в сфере программной разработки. Аутсорсинг помогает отрасли идти в ногу с мировыми технологиями и подходами в работе. Однако, организаторы хотели бы сфокусироваться именно на продуктовой разработке, как процессе создания ценности.

Для кого эта конференция?

• Разработчиков, тестировщиков, специалистов по UI-UX, QA
• Менеджеров продуктов и топ-менеджеров продуктовых компаний
• Гиков и технологических предпринимателей

Какие темы будут затронуты в программе?

• Формирование идеи продукта
• Изучение пользователей и проектирование взаимодействия
• Инженерные и технологические аспекты разработки
• Построение команды и процесса создания ценности

На конференции планируется рассмотреть различные аспекты создания продукта, но, даже погружаясь в технические детали, фокус будет держаться на ценности результата.

Что делает этот кемп не похожим на другие?

• Организаторы пригласили спикеров с опытом создания продуктов, участия в стартапах или ведения собственного бизнеса
• Проводилось исследование интересов аудитории конференции для того, чтобы осветить популярные темы и ответить на острые вопросы

На данный момент еще есть возможность зарегистрироваться на конференцию по цене ранней регистрации – 750 гривен.

На конференции выступит один из наших тренеров, Александр Белецкий, с докладом «Continuous Delivery в продуктовой разработке». Continuous Delivery стал краеугольным камнем современной веб разработки и является современным трендом в высококлассных командах и компаниях. Это практический доклад, который будет интресен .NET разработчикам, а так всем заинтересованным в вопросах непрерывной поставки.

В преддверие конференции, 27 января, мы запланировали тренинг «QA в Agile». Это один из моих любимых тренингов, на котором тестировщики смогут лучше понять свою роль и подходы к работе, которые используются в Agile методологиях. Также им будет предложены несколько рабочих QA процессов в командах, работающих по Scrum. Много интересных презентаций, различные полезные практики и игровые симуляции делают этот тренинг очень познавательным и полезным. Вы можете узнать больше о тренинге и ознакомиться с отзывами в детальной программе тренинга. Регистрация на тренинг уже открыта и количество мест ограничено.

Таким образом, конец января получится достаточно интересным. Будем рады вас видеть!

Я с удивлением обнаружил, что до сих пор не опубликовал анонс конференции Selenium Camp 2012. В 2011 году Selenium Camp 2011 стал нашей первой конференцией. Именно с момента ее проведения мы начали заниматься масштабными мероприятиями международного уровня в Украине. Надо срочно исправляться!

25 февраля, мы приглашаем вас в Киев на конференцию Selenium Camp 2012, целиком посвященную продукту для тестирования web-приложений Selenium. Selenium Camp – это конференция, целью которой является собрать вместе всех, кто так или иначе использует Selenium.

Конференция Selenium Camp стала первой в мире конференцией, целиком посвященной Selenium. В 2011 году участие в конференции смогли принять более 300 участников. Конференция получилась действительно международной, не смотря на то, что подавляющее большинство участников было из СНГ. Мы принимали гостей из Чехии, Эстонии, Молдавии, Великобритании, России, Беларуси и Украины. 17 докладчиков из различных стран представили вниманию участников 3 мастер-класса и 15 докладов. В качестве приглашенного гостя выступил David Burns – один из ключевых разработчиков Selenium, занимающийся драйверами под .NET и Python.

В этом году в мире Selenium многое изменилось – вышел Selenium 2.0 (aka WebDriver), в котором полностью изменилась архитектура, API и принципы работы. Selenium набирает все большую популярность и становится негласным стандартом в тестировании веб-приложений. Его начинают поддерживать производители браузеров и разнообразных инструментов для тестирования. 2011 год можно по праву считать началом новой эры в жизни этого инструмента. А это значит еще больше интересных практик, подходов, решений и инструментов. Докладчикам будет что рассказать и чем поделиться с участниками конференции.

Программа конференции не стоит на месте и уже заявлено 5 докладов от докладчиков из Украины, Беларуси, Чехии и UK! David Burns одним из первых принял наше приглашение выступить на Selenium Camp 2012. Мы ожидаем множество интересных докладов и мастер-классов.

В этом году мы планируем собрать 400 участников. Уже открылся этап предварительной регистрации, в течение которого будет действовать минимальная цена 600 гривен. Чтобы принять участие в конференции по указанной цене, вы должны зарегистрироваться и оплатить свое участие до 1 января 2012 года.