В день конституции наша команда десантировалась на конференции AgileDays-2008 — от нас было два докладчика, десяток участников и спонсорское участие.
Пара слов об аудитории в обоих смыслах:
Все действие происходило в переоборудованном буфете компании Luxoft, который широко известен в узких кругах — там регулярно проходят собрания различных IT-сообществ: тестировщиков, аналитиков, разработчиков.
По ряду косвенных признаков можно утверждать, что аудитория состояла скорее из тестировщиков, чем разработчиков, и занималась скорее entreprise-разработкой, чем массовыми web-проектами.Мы попробовали снять видео, это было достаточно сложно, ибо аудитория была забита под завязку (по крайней мере первые несколько часов) и удалось приткнуться с видеокамерой только в дальнем углу — это дало возможность снимать аудиторию (дискуссии, вопросы), но существенно ухудшило шумами качество аудиозаписи. Еще одна проблема — низкоскоростной DLP-проектор дал раздражающие мерцания при съемке экрана. Новости:Наши парни разработали специальный видеофильтр, который победил мерцание этого проектора! Звук тоже исправлен! Все более чем смотрительно!
Да, видео мы выкладываем в двух вариантах: флеш-видео в высоком разрешении (размещенном на профессиональном хостинге) и нормальных AVI-файлов максимально возможного разрешения (чтобы рассмотреть нетривиальный текст или живую демонстрацию программы), которых можно скачать перейдя (клик в правом нижнем углу) на страничку видео на хостинге, и проследовав по ссылке опять в правом нижнем углу. Мы проверяли — скачивания 700 мегабайтного файла с этого хостинга в московских домашних сетях идет со скоростью не меньше 1МБ/c и проходит меньше чем за 10 минут. Если что-то с видео «не слава богу» — не скачивается там, или обрезано — пожалуйста, сообщите почтой или комментарием. Объявление: если мы вручили вам на конференции флешки (с логотипом CustIS), пожалуйста, прочтитеэто объявление. Итак, вернемся к конференции. От нас было два доклада.Введение в непрерывную интеграциюДокладчик: Андрей Сатарин.Презентация, презентация-handout, статья.Есть аудиозапись.
Мы несколько опоздали к началу, поэтому рекомендуем скачать полное видео с сайта agiledays.ru.
Доклад про Continuous Integration, возможно уже несколько набил оскомину у продвинутых тестировщиков и разработчиков, — ведь мы по более-менее схожей теме уже проводили открытый семинар, доклад на конференции SECR-2008, не говоря уже о паре внутренних лекций. С другой стороны, в отличие от некоторых авторов (включая западных гуру), выступающих с одной темой годами, достигая в ней неизмеримых высот и глубин, мы считаем, что лучше «отбомбиться» по теме сразу и до конца, пока она актуальна, чтобы избежать обидных обвинений ([:|||||||:] ). И действительно, семинар показал, что в целом, концепция непрерывной интеграции у аудитории удивления не вызывает, споров полезна она или вредна, уже не ведется (примерно как ранее стало бессмысленно спорить о необходимости систем контроля версий), многие попробовали несколько различных продуктов, а многие даже гордятся возникающими сложностями — «наш проект настолько длинныйвелик, что даже самая непрерывная интеграция прерывается и превращается в ночные сборки» и «наша команда настолько распределенная, что наши сборки не поспевают за Солнцем…». Такие настроения было несложно предугадать, и продемонстрировать «карту в рукаве/рояль в кустах» — «слайды с ответами на ожидаемые вопросы». В целом мысль такова: долгое время сборки это либо проблема неправильных инструментов (не используются правильные менеджеры сборки, типа SCons, Ant, make, …), либо проблема архитектуры (наличие крупных ядер, где «все зависит от всего»). Конечно, такие случаи есть, и странно, что аудитория на них не указала (тогда бы мы показали еще слайдов). Например, классическая реляционная база данных, как известно, очень плохо стыкуется почти со всеми agile-практиками, и в случае continuous integration «кошерное» пересоздание тестировочной базы с нуля в большинстве случаев выглядит неподъемной задачей. Но и в этом случае можно «бороться за живучесть» концепции, применяя разные лайфхаки. Например, классический паттерн ускорения непрерывной интеграции — наращивание памяти на сборочном сервере, и использование tmpfs для файлов и специальных in-memory SQL СУБД для тестирования SQL СУБД функциональности. Но несмотря на все эти гитики, действительно, тема непрерывной интеграции не такая уж и обширная, в целом тянет на полдесятка статей, так например, книга «Continuous Integration» Пола Дюваля и К° (есть русский перевод — «Непрерывная интеграция»), явно имеет «надутый водой» объем.Безудержный Рефакторинг: как не убить себя об стену.Докладчик: Андрей БибичевПрезентация: http://agilerussia.ru/files/agiledays/Bibitchev.Refactoring.pdf
Поднята достаточно оригинальная тема. После десятков регулярных докладов agile-евангелистов о безусловной пользе рефакторинга, появления удобных инструментов, сделавших рефакторинг автоматизированным и доступным для применения в режиме «не приходя в сознание», наконец появился кто-то, чтобы остановить разогнанный маятник, одуматься, рассмотреть случаи, когда применение рефакторинга, как ковровых бомбадировок, вредно, и прояснить причины, почему собственно. Причем «разбор полетов» проходил не на абстрактных примерах (коде типа Foo/Bar), а на настоящих живых примерах на C# и Java из репозитория нашей компании и компании Microsoft.
Доклад концептуальный, не ограничивается рамками достаточно «канцелярского» названия, мыслей много. Основная драматургия: противостояние людей (опытных творцов, весельчаков и разумных лентяев) и механизмов (инструментов, жестких социальных организаций, регламентов и методологий). Мысль — жесткие/водопадные методологии разработки — это если ваши бойцы тупая пехота. Тогда да, муштра и вперед на минные поля — ненадежность отдельного солдата спасет дублирование и избыточность, и заплаченная цена будет оправдана.Но если у вас мощные, кросс-функциональные парни-коммандос, то нужно организовать им комфортную команду и обеспечить полную поддержку. Холить, лелеять, обеспечивать имFun иProfit. А то, что agile проекты иногда проваливаются, виновата не избалованность людей, а отсутствие способностей —в agile проекты нужно нанимать лучших, а дальше пускай они уже выкручиваются сами, главное их не обижать.В качестве метафор «подходов прошлого тысячелетия» автор использовал концепцию стимпанка, иллюстрируя ее картинкой из steampank-style календаря «The other side of the coin» (остальные картинки, если заинтересовали, можно найти тут [1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11] ).Со своей стороны, мы заметим, что это несколько натянутая, и нехарактерная визуализация стимпанка. Стимпанк — это не депрессивные ржавые железяки, чешущие зад лоснящегося мускулистого рабочего (ммм…?), а скорее идея максимальной эволюции старинных технологий, в предположении, что им так и не было найдено замены. А вершина эволюции — это всегда красиво (дредноуты времени Iмв, последние паровозы, американские автомобили эпохи дешевой нефти). Так что если хотите взглянуть, что есть стимпанк, лучше смотреть соответствующиеаниме-мультфильмы. Вообще видов тестирования очень много (Unit testing,Integration testing,System testing,Performance testing,Reliability testing,Security testing,Usability testing,Portability testing,Acceptance testing) и хорошо автоматизируется только первый (Unit testing), а автоматизация всего остального — это увы, всего лишь пропаганда вендоров, которые втюхивают дорогущие инструменты автоматизации. Так что в тестировании все остальное надо делать вручную «на коленке» и здесь на первый план выходит квалификация тестировщиков (люди — самый ценный ресурс!).
Следующая мысль — несправедливость Agile-благ для программистов и тестировщиков. Пророки Agile многое дали программистам —Refactoring,Unit-тестирование,Continuous Integration, парное программирование,Scrum со всеми его играми и т.п. Power и Fun, как и заказывали. Тестировщикам же из этого ничего не обломилось, кроме фреймворка FIT, но докладчик с негодованием открестился от этого убогого подарка («недопрограммирование» на вики-разметке, тотальная неполнота и ограниченность). С учетом предыдущей мысли, что для правильного тестирования все равно нужны крутые супертестировщики, возникает идея, что не «тестировщик — друг программиста», а «программист — студент, сдающий экзамен тестировщику». Т.е. нанимать надо самых лучших и задорого («Разве вы не знали, что тестировщики везде получают больше разработчиков?» Profit!), желательно из программистов достигших совершенства, и потерявших интерес к программированию («Саваоф Баалович был всемогущ. Он мог все. И он ничего не мог. Потому что граничным условием уравнения Совершенства оказалось требование, чтобы чудо не причиняло никому вреда.»), программистов надо отдать тестировщикам на съедение (отдать их код на Code Review), ведь единственная корректная метрика кода — это количество WTF-ов в минуту при проведении code-review.
Ну не говоря уж о том, что Scrum/Agile для тестировщиков означает одно — больше Fun-а, а Scrum Master должен быть помесью пионер-вожатого и массовика затейника! Местами этот фан выглядит несколько беспредельно. Только компания привыкла, что все вертикальные поверхности, включая шкафы-купе для одежды обклеены Scrum-taskами, возникают тестировщики и исписывают стены в туалетах (концепция «Testing on the Toilet»). Докладчик рассказал, что в Беларуссии была конференция SQA Days 4 на которой был доклад «Funny testing: как добавить драйва в работу» — какой еще Fun можно придумать команде что бы не работать. Ну и в целом, нужно смотреть видео. Хотя бы для того, чтобы узнать о силе волшебной фразы «Ну и что?». Тестирование в Agile проектах Докладчик: Илья Гаврилов Презентация: http://agilerussia.ru/files/agiledays/Gavrilov.TestingInAgile.pdf
Хотя название доклада похоже на название предыдущего доклада, тут совсем о другом, скорее о чисто тестировании, чем об Agile. Вполне можно представить этот доклад с небольшими изменениями для тем «тестирование в RUP-проектах», «modern testcase management» и т.п.
Т.е. упор действительно сделан на управление сценариями (use case), тестами (test-case и unit tests). Указывалась необходимость покрыть все сценарии тест-кейсами не меньше чем на 60%, и 80% кода (больше бессмысленно) — юнит-тестами.
В качестве универсального инструмента для ведения и сценариев тестирования, и расчета различных метрик и графиков докладчик рекомендовал Excel.
Основной вопрос, обсуждавшийся после доклада — это как держать все эти планы тестирования в актуальном состоянии. Предложение докладчика простое и очевидное: планировать их актуализацию также, как и все остальные работы, т.е. при оценке задачи сразу оценить какие изменения нужно делать не только в коде, но и в тестах.Unit testing with XML Докладчик: Дмитрий Всехвальнов Презентация: http://agilerussia.ru/files/agiledays/Vskehvalnov.XmlUnitTesting.pdf
По сути доклад был посвящен исключительно использованию библиотеки XmlUnit для написания unit-тестов, связанных с проверкой корректности сформированного XML-я.
Доклад состоял из двух частей:
перечисления задач, которые возникают при написании тестов на сформированный XML:
проверка эквивалентности структур с учетом и без таких нюансов как: неймспейсы, порядок атрибутов и тегов, пробельные символы, комментарии, управляющие конструкции;
вычисление XPath-выражений;
валидация по XSD/DTD;
XSLT-трансформации;
работа с разными XML и XSLT-процессорами.
живой демонстрации по написанию несложных тестов на Java:
проверка по точному совпадению;
проверка с игнорирование отдельных атрибутов (по их именам);
проверка с игнорированием целых узлов и их содержимого (опять же, по именам тегов);
валидация по XSD;
проверка существования узла по XPath-выражению;
проверка совпадения значения, извлеченного по XPath-выражению.
По сути, библиотека XmlUnit — это набор готовых ASSERT-ов для JUnit-а (Java-версия библиотеки) и NUnit-а (.Net-версия библиотеки). При этом .Net-версия, судя по описанию на сайте, развита значительно слабее своего Java-аналога.Тестирование Web 2.0Докладчик: Владимир КолесниковПрезентация: http://agilerussia.ru/files/agiledays/Kolesnikov.TestingWeb2.0.pdf
Краткий, 20 минутный доклад, как можно и нужно тестировать вебдванольные проекты.
Основной посыл доклада: очень много javascript-а, больше 4-х браузеров (каждый со своими нюансами и глюками), аудитория пользователей огромная — нужна гарантия качества. Далее перечислил что и как можно тестировать:
бизнес-логику — это оставил за рамками доклада, так как это стандартно не только для web-проектов и здесь все используют unit-тесты;
серверную часть — выполнение http-запросов к web-серверу и проверка их результата (ну здесь вроде как всё просто и понятно — во всяком случае так счел докладчик);
клиентский javascript — здесь нужны тесты, которые выполняются внутри браузера, для чего почти в каждой известной javascript-овой библиотеке классов (включая jQuery, Prototype, Dojo) есть свой набор функциональности для удобного написания и выполнения unit-тестов прямо внутри браузера;
автоматическое UI-тестирования при помощи инструментов, эмулирующих действия пользователя — здесь докладчик упомянул набивший многим оскомину Selenium. Далее докладчик в основном рассматривал именно unit-тестирование javascript-а и навороты вокруг этого. Когда его спросили всё же про автоматическое UI-тестирование, то он ответил, что этим занимается другой отдел и лично он не очень в курсе их успехов…
Еще запомнилось, что им сильно помогает логгирование исключений, произошедших на стороне клиента. Делают они это при помощиwindow.onerror, правда работает это только в IE и FireFox-е. Именно благодаря этому приему они узнают об успешности версии (если за несколько часов таких ошибок не поступает, значит версия успешна).
Как мы уже заметили, в аудитории было мало вебразработчиков, в основном тестировщики и разработчики enterprise-приложений, вероятно поэтому, вопросов доклад практически не вызвал.Working Effectively with Legacy Code
Доклад Майкла Физерса был «guest star» всего мероприятия, хотя стоит отметить, что не все смогли выдержать плотную конференцию до самого конца — слушателей было существенно меньше, чем в начале дня.
Но тема доклада всегда актуальна,Legacy Codeэто вечное проклятие невезучих программистов (т.е. тех, которых бросают на поддержку чужого кода), и legacy code вечен — да, старые информационные системы умирают, но проходит пару лет, и даже твой супер-крутой код становитьсяlegacy… . Трудно удержаться и не процитировать соответствующие комиксы Дильберта:
На модельном примере класса «расписание» (Schedule), написанном на Java, Физер показал как сделать его тестопригодным. Основной прием свелся к N-кратному применению Dependency injection. Причем, на наш вкус с некоторым перебором: даже статические helper-методы определения является ли день выходным или рабочим были перенесены в нестатический класс, а в тесте было предложено их «заглушить», написав соответствующего наследника. ИМХО это уже другая крайность: когда тестируется функциональностьровно одного класса, а всё, что он использует, либо заглушено при помощи Stub-ов, либо эмулируется при помощи Mock-ов (см. http://martinfowler.com/articles/mocksArentStubs.html). Это так можно получить результат как в репризе Райкина «претензии к пуговицам есть — нет, пришиты намертво…»
К сожалению, по просьбе Майкла, мы (пока?) воздерживаемся от публикации видео — Майкл хотел бы вырезать некоторые моменты. Возможно мы передадим видео Асхату Уразбаеву, и Асхат уже опубликует одобренную часть.
Мероприятие удалось! Очень удачно выбранный формат, резервирующий 20-25 мин, после каждого доклада на вопросы, делает осмысленным личное присутствие на конференции, а доступ к презентациям и видео — неограниченно расширяет аудиторию. Полезность мероприятия явно не уступает «стандартной» Software конференции, типа SEСR, — и это еще одно доказательство, что Agile-подход рулит и в организации конференций. Это подтверждают и отзывы.
Надеемся, что Асхат сможет продолжить линию таких миниконференций.
Если чуть-чуть уменьшить число участников (до 50), то мы могли бы предложить и свою площадку для участников — зал с креслами, мощным проектором и экраном с 4-метровой диагональю, в центре Москвы, в 5-минутной доступности от 5 станций метро.
[ Хронологический вид ]Комментарии
Войдите, чтобы комментировать.