В эти выходные ездила в Питер, на конференцию Яндекса под названием "Тестовая среда". Раньше Яндекс устраивал более общие конференции, выделяя тестированию одну секцию, а тут, бац, — и полностью для тестировщиков, круто же 
Правда, мест было мало, и пригласили туда далеко не всех. Но вот мне повезло, меня пригласили! Так что подъем в 5 утра и здравствуй, Сапсан!
Последний бесплатный автобус на мероприятие отходил в 10.30, как раз, когда Сапсан приезжал на вокзал. Успеть за 5 минут проехать 2 остановки как-то сомнительно, так что взяли такси. Таксист поразвлекал нас разговорами, показал несколько достопримечательностей и указал на то, что здание, куда мы едем, все такое красивое, на нем выложены варианты костюмов к балету Стравинского "Петрушка", которые рисовал Бенуа. И правда, очень красивое здание!
А еще в нем есть банкомат Альфа-банка, что нас с коллегой очень обрадовало в связи с закрытием Мастер-банка, — не пришлось голову ломать, где теперь обналичивать...
Поднялись на 5 этаж, а там уже вовсю проходило открытие! Когда мы зашли, как раз всех докладчиков пригласили на сцену, чтобы они рассказали, кто о чем будет говорить, а зрители заранее поняли, кого им искать в кулуарах. Очень удобная схема, кстати. Конечно, для больших конференций типа SQA Days она не прокатит — все равно всех докладчиков не запомнишь, но для маленьких — самое то!
Докладчики выходят вперед, чтобы все их видели и запомнили, как они выглядят, рассказывают, о чем будет их доклад и где они будут стоять в кулуарах. А в коридоре стоят несколько разных столов с разной тематикой, докладчики там и тусят, всегда готовые ответить на твой вопрос.
А потом начались сами доклады!
1. Прочная основа для автоматизации тестирования
Артем Кошелев, Яндекс
И если все ок, то запускаются тесты, все прогоняется и дальше уже или все ок, или нотификации заинтересованным лицам.
Такая вот связка используется в Яндексе в отделе автоматизации. Как потом заметил Алексей Баранцев, этот доклад полезен с той точки зрения, что систем версионирования, сборщиков итд существует огромное множество, но очень хочется понимать, какие хорошо ладят друг с другом, хочется не копаться в многообразии, а иметь единую точку правды. И вот доклад описывает отличную связку. Еще и с замечательной подачей!
2. Как найти общий язык с результатами тестов
Второй докладчик поднял тему понимания результатов автотестов. Конечно, хорошо, когда их умеет читать только тот, кто писал тесты, но все же как-то не очень. И вот ребята придумали сделать свой продукт с блекджеком и преферансом. Open-source, так что you are welcome в помощь! Главная цель продукта — чтобы результаты читал не составить тестов, а другой человек.
Фактически их продукт, Allure являет расширением стандартного xUnit, к которому они прикрутили шаги и аттачменты.
После двух докладов был перерыв, во время которого гостей угощали вкуснейшими плюшками с мясом, творогом и прочими начинками. Оооо, как это было кстати голодному желудку, который уже 7 часов на ногах и не емши! Опять же, народу мало, очередей нет, супер ) Но вернемся к докладам.
3. Анализ данных для поиска ошибок
Илья — начальник в исследовательском отделе. Он считает, что всю нудную работу должен делать робот, а человек просто получать свою зарплату тестировщика
И они уже сделали проект с роботом, который даже выкладывали на хабре. И вот снова делают робота, которому можно скормить N примеров, он их научится парсить "вот тут должно быть то, вот тут се" и потом сможет тестировать и выдавать проблемы.
Как его делали? Ну как вообще тестируют верстку? На что обратит внимание человек? Что вот тут магазин упоминается дважды, дублируется, вряд ли это правильное поведение, а тут поиск выдал пустую страницу, что-то не то...
Вот и сделали робота, который строит некую модель по полученным примерам и потом уже сам понимает, что дублирование — это плохо. Что пустая цена тоже не ахти.
Модель — это набор правил, например:
А еще такой робот находит ошибки, которые человек мог бы и не заметить. Вот например...
Забавно, что пример был на книге "Лечение водкой и самогоном"
Вообще хочется отметить, что первые три докладчика были просто шикарны. И по стилю презентации, и по стилю ее подачи. Так ярко, задорно! Я прямо даже прониклась и поняла, почему к ним люди работать приходят. Слушаешь ребят, у которых глаза горят, которые с шутками-прибаутками рассказывают о чем-то сложном и думаешь: "Вау, классно, наверное, с ними работать!". Так что конференция еще и пиар-ход компании)))
Кстати, на заметку программному комитету SQA Days, видите эти фамилии в списке участников, знайте, надо брать!
4. Матчеры: маленький шаг для вас и огромный для ваших автотестов
Кирилл рассказывал о том, что когда мы пишем тест, мы хотим, чтобы он был простой и понятный, а все остальное куда-то прячем. Получается такой айсберг, маленький простенький над водой и огроменная глыбина под водой... Как-то нехорошо... А как сделать проще? Добавив матчеры!
Матчер = описание + логика.
Есть библиотечка hamcrest — в связке java + maven подключается в 5 строк. И сильно упрощает читабельность вашего кода! Ну а коллеги из Яндекса ее дополнили и сделали свою клевую версию))
После этого доклада был обед, во время которого устраивали экскурсии по офису. Очень симпатичный офис, надо сказать! Обои в виде библиотеки, книги, книги... Уютные уголочки, где можно сесть с коллегой и обсудить за кофе какие-то рабочие моменты...
Своя кухня в каждом крыле, душ в туалете, эх... Но вернемся к докладам!
5. Генерация тестовых данных. Библиотека ObjectBuilders
Денис поднял интересную тему. То, что вы нафигачили автотестов — еще полбеды. Но ведь вам их потом придется поддерживать! А это уже посложнее будет...
Для простой и легкой поддержки (а мы ведь ценим свое время!) нам нужна независимость, легкий перезапуск и прозрачность.
Правда, в тему независимости Денис высказал пример, который наглядно показал, что речь идет о GUI тестах, хнык. У нас не GUI...
Но продолжение меня заинтересовало. Вместо набора связанных объектов делаем граф. И в тестах мы описываем свойства графа! А не объектов. Делаем один дефолтный граф и в тесте его частично перекрываем...
У нас все немного по-другому, но чем-то похоже. Делаем дефолтное, потом в тестах перекрываем. Потом мы пришли к тому, что все эти перекрытия можно выкинуть нафиг, немного доработав сам фреймворк. А еще столкнулись с другой проблемой, с которой ребята из Яндекса не сталкивались (я уточнила во время сессии ответов и вопросов).
Но в любом случае, доклад натолкнул меня на мысль очередной статьи-размышлизма на конфлюенс по рабочим моментам. Это уже третья в очереди, теперь бы их еще все написать
6. Автоматизация в мобильном тестировании
Мобильные приложения я не тестирую, поэтому слушала для общего развития. Интересно. Ребята решили пойти на риск и проводить тестирование на эмуляторах, а не на реальных устройствах. Моя коллега, которая работает с мобилками, этому немного удивилась. Но докладом прониклась, долго пытала рассказчика в кулуарах и ходила потом счастливая, "вот бы и мне тут работать, тут так клево и интересно!".
Ох, смотрите, ребята из Яндекса, не прозевайте свой шанс
7. Графики и Яндекс.Танк
8. Автоматизация нагрузочного тестирования
Я объединила эти доклады в один, потому что рассказчики сами так планировали, сначала Алексей рассказывает концепцию, потом передает слово Григорию. Правда, организаторы уговорили его ответить на вопросы ))
Ребята рассказывали о своей программе нагрузочного тестирования - яндекс танке. Показывали, какие графики она умеет строить, как по ним что-то понять, как это все заавтоматизировать и прочая прочая... Очень хорошая вводная!
Графики строятся с помощью инструмента Graphite, а метрики сервера собираются для графита демоном diamond.
9. Игровые механики в тестировании
Закрывал конференцию Олесь с рассказом о том, какие фишечки они внедрили для игры внутри работы. Они сделали личные страницы сотрудников и там уже...
И да, прежде чем внедрять геймификацию, подумайте, а правда ли она вам нужна. Это тоже затраты на разработку и поддержку... Может, в маленьком компании оно и нафиг не сдалось, только потеря времени. И об этом не стоит забывать, просто кидаясь внедрять "прикольную новинку"!!!
На такой веселой ноте и закончилась конференция. Потом был небольшой перерыв и секция ответов на вопросы, а затем ребята разбрелись кто куда.
Я с конференции унесла несколько светлых идей, встретила знакомых людей, москвичей, с которыми видимся только на конференциях в других городах, питерцев, которых знаю только по скайпу, ну и прочая. Так что и позитив и знания. Здорово! Спасибо ребятам, будем через годик ждать продолжения!! Надо же хоть где-то видеться с коллегами
Правда, мест было мало, и пригласили туда далеко не всех. Но вот мне повезло, меня пригласили! Так что подъем в 5 утра и здравствуй, Сапсан!
Последний бесплатный автобус на мероприятие отходил в 10.30, как раз, когда Сапсан приезжал на вокзал. Успеть за 5 минут проехать 2 остановки как-то сомнительно, так что взяли такси. Таксист поразвлекал нас разговорами, показал несколько достопримечательностей и указал на то, что здание, куда мы едем, все такое красивое, на нем выложены варианты костюмов к балету Стравинского "Петрушка", которые рисовал Бенуа. И правда, очень красивое здание!
А еще в нем есть банкомат Альфа-банка, что нас с коллегой очень обрадовало в связи с закрытием Мастер-банка, — не пришлось голову ломать, где теперь обналичивать...
Поднялись на 5 этаж, а там уже вовсю проходило открытие! Когда мы зашли, как раз всех докладчиков пригласили на сцену, чтобы они рассказали, кто о чем будет говорить, а зрители заранее поняли, кого им искать в кулуарах. Очень удобная схема, кстати. Конечно, для больших конференций типа SQA Days она не прокатит — все равно всех докладчиков не запомнишь, но для маленьких — самое то!
Докладчики выходят вперед, чтобы все их видели и запомнили, как они выглядят, рассказывают, о чем будет их доклад и где они будут стоять в кулуарах. А в коридоре стоят несколько разных столов с разной тематикой, докладчики там и тусят, всегда готовые ответить на твой вопрос.
А потом начались сами доклады!
1. Прочная основа для автоматизации тестирования
Артем Кошелев, Яндекс
Артем рассказывал о работающей у них связке для автоматизации - Maven, Git, Jenkins.
Что будет, если мы собираем все через ant? Знаете, как там настраивать зависимости? Все складываем в некую папочку /lib, которая в итоге становится одной большой помойкой.
Решили перейти к maven. Он в этом плане удачнее, так как является, помимо всего прочего, еще и репозиторием артефактов. У тебя есть артефакты на локальной машинке, есть некое Community твоей фирмы и есть еще одно большое общее хранилище. Так что, если чего-то нет у тебя, идет обращение выше, а если нет и там, то еще выше.
Таким образом, весь утилитный код отделяется, остается только самое главное, самое основное. Профит!
Теперь посмотрим на систему версионирования. Кто знает про svn? Ага, в зале есть сочувствующие Как создавать бранч в svn?
Это когда у тебя ангел на одном плече появляется и говорит "Надо создать ветку", а на другом демон шепчет "Нет! Ты же помнишь, чем это обычно заканчивается!!". Очень, кстати, правдоподобно...
Как создавать бранч в svn?Это когда у тебя ангел на одном плече появляется и говорит "Надо создать ветку", а на другом демон шепчет "Нет! Ты же помнишь, чем это обычно заканчивается!!". Очень, кстати, правдоподобно...
А git - он просто провоцирует хорошие практики, потому что придерживаться их в нем очень просто и удобно!
Ну и, наконец, сама настройка CI с помощью Jenkins. Наколбасил у себя на компе, отправляешь pull-request. Твой код начинает анализировать Sonar:
- На сложность кода (чем проще код, тем сложнее в нем ошибиться!).
- На соответствие правилам кодирования.
- На дублирование кода.
Такая вот связка используется в Яндексе в отделе автоматизации. Как потом заметил Алексей Баранцев, этот доклад полезен с той точки зрения, что систем версионирования, сборщиков итд существует огромное множество, но очень хочется понимать, какие хорошо ладят друг с другом, хочется не копаться в многообразии, а иметь единую точку правды. И вот доклад описывает отличную связку. Еще и с замечательной подачей!
2. Как найти общий язык с результатами тестов
Второй докладчик поднял тему понимания результатов автотестов. Конечно, хорошо, когда их умеет читать только тот, кто писал тесты, но все же как-то не очень. И вот ребята придумали сделать свой продукт с блекджеком и преферансом. Open-source, так что you are welcome в помощь! Главная цель продукта — чтобы результаты читал не составить тестов, а другой человек.
Фактически их продукт, Allure являет расширением стандартного xUnit, к которому они прикрутили шаги и аттачменты.
- Аттачменты — возможность вставлять аттачи: json, txt, png и тому подобные.
- Шаги — тут важна возможность вложенности. Потому что бывает шаг "регистрация", который имеет подшаги "зайти туда, кликнуть сюда", но нам бы хотелось понимать в целом, на чем упал автотест, шаг верхнего уровня. Теперь это возможно!
После двух докладов был перерыв, во время которого гостей угощали вкуснейшими плюшками с мясом, творогом и прочими начинками. Оооо, как это было кстати голодному желудку, который уже 7 часов на ногах и не емши! Опять же, народу мало, очередей нет, супер ) Но вернемся к докладам.
3. Анализ данных для поиска ошибок
Илья — начальник в исследовательском отделе. Он считает, что всю нудную работу должен делать робот, а человек просто получать свою зарплату тестировщика
И они уже сделали проект с роботом, который даже выкладывали на хабре. И вот снова делают робота, которому можно скормить N примеров, он их научится парсить "вот тут должно быть то, вот тут се" и потом сможет тестировать и выдавать проблемы.
Как его делали? Ну как вообще тестируют верстку? На что обратит внимание человек? Что вот тут магазин упоминается дважды, дублируется, вряд ли это правильное поведение, а тут поиск выдал пустую страницу, что-то не то...
Вот и сделали робота, который строит некую модель по полученным примерам и потом уже сам понимает, что дублирование — это плохо. Что пустая цена тоже не ахти.
Модель — это набор правил, например:
- Блок А есть всегда.
- Если есть блок Б, есть и блок В.
А еще такой робот находит ошибки, которые человек мог бы и не заметить. Вот например...
Забавно, что пример был на книге "Лечение водкой и самогоном"
Вообще хочется отметить, что первые три докладчика были просто шикарны. И по стилю презентации, и по стилю ее подачи. Так ярко, задорно! Я прямо даже прониклась и поняла, почему к ним люди работать приходят. Слушаешь ребят, у которых глаза горят, которые с шутками-прибаутками рассказывают о чем-то сложном и думаешь: "Вау, классно, наверное, с ними работать!". Так что конференция еще и пиар-ход компании)))
Кстати, на заметку программному комитету SQA Days, видите эти фамилии в списке участников, знайте, надо брать!
4. Матчеры: маленький шаг для вас и огромный для ваших автотестов
Кирилл рассказывал о том, что когда мы пишем тест, мы хотим, чтобы он был простой и понятный, а все остальное куда-то прячем. Получается такой айсберг, маленький простенький над водой и огроменная глыбина под водой... Как-то нехорошо... А как сделать проще? Добавив матчеры!
Матчер = описание + логика.
Есть библиотечка hamcrest — в связке java + maven подключается в 5 строк. И сильно упрощает читабельность вашего кода! Ну а коллеги из Яндекса ее дополнили и сделали свою клевую версию))
После этого доклада был обед, во время которого устраивали экскурсии по офису. Очень симпатичный офис, надо сказать! Обои в виде библиотеки, книги, книги... Уютные уголочки, где можно сесть с коллегой и обсудить за кофе какие-то рабочие моменты...
Своя кухня в каждом крыле, душ в туалете, эх... Но вернемся к докладам!
5. Генерация тестовых данных. Библиотека ObjectBuilders
Денис поднял интересную тему. То, что вы нафигачили автотестов — еще полбеды. Но ведь вам их потом придется поддерживать! А это уже посложнее будет...
Для простой и легкой поддержки (а мы ведь ценим свое время!) нам нужна независимость, легкий перезапуск и прозрачность.
Правда, в тему независимости Денис высказал пример, который наглядно показал, что речь идет о GUI тестах, хнык. У нас не GUI...
Но продолжение меня заинтересовало. Вместо набора связанных объектов делаем граф. И в тестах мы описываем свойства графа! А не объектов. Делаем один дефолтный граф и в тесте его частично перекрываем...
У нас все немного по-другому, но чем-то похоже. Делаем дефолтное, потом в тестах перекрываем. Потом мы пришли к тому, что все эти перекрытия можно выкинуть нафиг, немного доработав сам фреймворк. А еще столкнулись с другой проблемой, с которой ребята из Яндекса не сталкивались (я уточнила во время сессии ответов и вопросов).
Но в любом случае, доклад натолкнул меня на мысль очередной статьи-размышлизма на конфлюенс по рабочим моментам. Это уже третья в очереди, теперь бы их еще все написать
6. Автоматизация в мобильном тестировании
Мобильные приложения я не тестирую, поэтому слушала для общего развития. Интересно. Ребята решили пойти на риск и проводить тестирование на эмуляторах, а не на реальных устройствах. Моя коллега, которая работает с мобилками, этому немного удивилась. Но докладом прониклась, долго пытала рассказчика в кулуарах и ходила потом счастливая, "вот бы и мне тут работать, тут так клево и интересно!".
Ох, смотрите, ребята из Яндекса, не прозевайте свой шанс
7. Графики и Яндекс.Танк
8. Автоматизация нагрузочного тестирования
Я объединила эти доклады в один, потому что рассказчики сами так планировали, сначала Алексей рассказывает концепцию, потом передает слово Григорию. Правда, организаторы уговорили его ответить на вопросы ))
Ребята рассказывали о своей программе нагрузочного тестирования - яндекс танке. Показывали, какие графики она умеет строить, как по ним что-то понять, как это все заавтоматизировать и прочая прочая... Очень хорошая вводная!
Графики строятся с помощью инструмента Graphite, а метрики сервера собираются для графита демоном diamond.
9. Игровые механики в тестировании
Закрывал конференцию Олесь с рассказом о том, какие фишечки они внедрили для игры внутри работы. Они сделали личные страницы сотрудников и там уже...
- Главная страница — зал славы. Попадают все, кто хоть как-то когда-то стрелял из танков. Один раз пострелял — и уже навсегда в зале славы! Есть, конечно, проблема, что страница уже большая, но зато прикольно))
- Рядом с людьми нарисованы звездочки — это звания. Капитан, адмирал и пр.
- Спасибки!!! О, я уже не в первый раз слышу про эту технику, и она мне очень нравится Тыкаешь на любого человека и тебе предлагают отправить ему сообщение: "Я хочу сказать тебе спасибо за что, что...". А человек получает в личку такую спасибку и тихо радуется. Это всякие там "спасибо, что ты у нас есть, спасибо за помощь" итд. А грустными зимними вечерами можно открыть свои спасибки и получить заряд позитива. Классная тема!!
- Командир танка — как в Foursquare, там можно стать мэром, а тут — командиром танка.
- "Красивые номерки" — номер запуска тестов. Тут есть печалька — красивые номерки часто уходят роботам
- Личная "стата".
- Бейджики — ачивки, ачивки!!! Всего около 20 штук самых разных.
И да, прежде чем внедрять геймификацию, подумайте, а правда ли она вам нужна. Это тоже затраты на разработку и поддержку... Может, в маленьком компании оно и нафиг не сдалось, только потеря времени. И об этом не стоит забывать, просто кидаясь внедрять "прикольную новинку"!!!
На такой веселой ноте и закончилась конференция. Потом был небольшой перерыв и секция ответов на вопросы, а затем ребята разбрелись кто куда.
Я с конференции унесла несколько светлых идей, встретила знакомых людей, москвичей, с которыми видимся только на конференциях в других городах, питерцев, которых знаю только по скайпу, ну и прочая. Так что и позитив и знания. Здорово! Спасибо ребятам, будем через годик ждать продолжения!! Надо же хоть где-то видеться с коллегами
Интересно, будет ли видео с конференции :)
ОтветитьУдалитьЭтот комментарий был удален автором.
УдалитьЛена, да, видео опубликуем недельки через 2.
УдалитьДля восстановления исторической справедливости таки нужно сказать, что таксист немного не угадал -- картинки на фасаде БЦ Бенуа это эскизы костюмов к балету Стравинского "Петрушка", а рисовал их, естественно, Бенуа :)
ОтветитьУдалитьКак же много Вы знаете, Алексей :)
УдалитьСпасибо))