Как заниматься парным программированием, если коллеги сидят поодиночке в разных квартирах? И если не подозвать коллегу со словами «смотри, как это делается», с помощью чего записать для него скринкаст? А какие инструменты для тестирования особенно актуальны при удалёнке?  Весной на TechTrain это обсудили Всеволод Брекелов (vbrekelov) и Артём Ерошенко (eroshenkoam). Им близок мир тестирования, поэтому получился уклон в эту сторону, но упомянуто и много универсального. Зрителям обсуждение понравилось — поэтому теперь мы сделали его текстовую расшифровку. Если вы знаете, какие ещё инструменты стоило бы упомянуть, то расскажите о них в комментариях. А мы тем временем готовим следующий TechTrain: это бесплатное IT-мероприятие, которое пройдёт онлайн уже 18 сентября (в следующую субботу). Так что если этот материал вас заинтересует, то и на новые доклады стоит обратить внимание. Шёл 2020 год. Январь. Никто не подозревал о надвигающейся угрозе. Коалиция бактерий во главе с коронавирусом уверенно приближала апокалипсис. Софтверные компании ещё даже не начинали готовиться к войне. И это было их ошибкой. Вирус обрушился на индустрию в апреле. Сначала мы потеряли возможность выпить имбирного смузи с печёной ватрушкой. Потом канули в Лету спортзалы и бассейны. Офисы стояли до последнего. Но и они сдались. В конце мы потеряли офлайн. На дворе был июнь. Несколько крупных компаний во главе с Zoom объединились, чтобы спасти IT. В будущем об этой битве будут слагать легенды… А мы эти легенды воспоём. Артём: Я занимаюсь автоматизацией тестирования уже больше 10 лет. Работал в крупных компаниях (например, Яндекс). Сейчас занимаюсь консалтингом и являюсь сооснователем компании Qameta Software, которая делает систему управления тестированием. Всеволод: Я уже больше 10 лет работаю в IT. Занимался автоматизацией тестирования, разработкой и менеджментом. Сейчас работаю в компании Synthesized в качестве Engineering Lead, где мы умеем синтезировать очень большие данные. Артём: Да, это довольно популярная тема сейчас с учётом того, что данных для тестирования надо всё больше и больше. Я уверен, что когда-нибудь твой спич на Heisenbug будет очень интересен. Сегодня я хочу поговорить с вами про удалёнку. Сева, как у тебя прошёл переход на неё? Что в твоей жизни изменилось с приходом удалёнки? Всеволод: У меня не получилось перейти на удалёнку сразу, как у всех. Я на неё перескакивал постепенно. Поначалу у меня были ощущения, что удалёнка — это классная тема и не нужно никуда ездить. Потом на меня нахлынуло, что я работаю с утра до ночи из дома, и почему-то всё время митинги, и ты не можешь даже пойти поесть. А потом я более или менее настроил для себя весь сетап (включая свет для видеосвязи), пытаюсь сделать меньше митингов и пользуюсь инструментами, которые помогают настроить работу в команде, чтобы меньше синхронизироваться в реальном времени. Артём: Об этих инструментах мы и поговорим. Если говорить про меня, то мой переход на удалёнку прошёл довольно легко. Во-первых, я почти всё время и так мог работать на удалёнке. И в этот раз практически ничего не изменилось. Я и правда стал меньше ходить в офис. Я тоже стал смотреть на инструменты, которые обеспечивают коллаборацию в команде. Если говорить про нашу команду, то у нас получается примерно так: вторник, среда и четверг — те дни, когда можно прийти в офис, чтобы что-то обсудить. Обычно мы их используем, чтобы плотно поштурмить; остальные дни работаем из дома. Мы добиваемся движения вперёд за счёт использования инструментов, о которых и пойдёт речь. Хочется рассказать, как из состояния «как жить» перейти в состояние, когда у вас настроенные процессы, для всех всё прозрачно и т. д. Артём: На удалёнке, на мой взгляд, планирование — одна из основных проблем. Когда я пять лет работал в крупной компании, больше всего времени мы уделяли именно планированию, где надо всем собраться. Было примерно так. Был офис Москва — Санкт-Петербург, и люди постоянно ездили в командировку, потому что там можно было дойти до человека ногами. Всеволод: Это обычная история. С другой стороны, когда все начинают думать, что легко планировать на созвоне или заранее подготовиться, обычно это превращается в хаос. Довольно непросто это делать, скажем честно. Артём: Сева хочет поделиться, как на проекте использует Miro. Всеволод: Наверняка многие слышали про Miro и его используют.  В основном мы используем Miro для брейншторминга и планирования. У него есть крутая фича — интеграция с Jira или другими системами. Мы можем брать существующие шаблоны, например, шаблон для планирования проекта, и просто вставить. Если вам хочется что-то планировать или создавать задачи, то это делается так. Мы с Артёмом решили рассказать на следующем этапе про инструменты погружения в код:  Есть задача, и мы хотим, чтобы её кто-то сделал. Как мы заводим эту задачу, чтобы точно был человек, который это сделает? Мы можем прямо из Miro сконвертировать наш проект из Jira:  Прямо здесь вы можете выбрать тип issue, приоритет задачи, ответственного человека. Все настройки, которые вы делаете в Jira, могут быть здесь. Также вы можете прилинковать эпик. Мы конвертируем и получаем:  Задача, которую мы просто написали руками, превратилась в Jira-задачу, которая при этом будет показывать прогресс на этой доске. Как понять, где эта задача? Кликаете сверху, и у вас сразу открывается Jira-проект, в котором заведена задача:  Она была выложена в бэклог, где я указан как исполнитель. Тут уже могу заассайнить на Артёма и добавить описание, что нужно сделать в этой задаче.  Это очень удобно, потому что вы ставите задачу всего за пару кликов. Условно вы напланировали что-то с командой и не хотите, чтобы каждый был Jira monkey. Вы можете передать эту задачу кому-то, и он все эти задачи сконвертирует. Артём: Допустим, я использую Miro для разных задач, в том числе описываю структуру микросервисов, процессы и т. д. Получается, Miro используется как обычная маркерная доска, но при этом нужно показать менеджерам какой-то контроль. Они должны понимать, когда у нас будет что-то сделано, кто ответственный за эту задачу и т. д. Собственно, в Miro мы командой разработчиков сидим и планируем, потому что это удобно. А потом мы переключаемся на Jira, синхронизируем с ней все тикеты (а синхронизировать мы можем любые сущности вплоть до описания подсистемы) и т. д.  Всеволод: Мы собираемся, планируем, и вопрос обычно стоит, как собираться. Тут наступает момент, как мы вообще организовываем встречи. Т. е. мы пишем обычно в Slack или Telegram «Тёма, я хочу с тобой поговорить на полчаса. Когда тебе удобно?». Ты смотришь в календарь и говоришь, что тебе удобно с 3 до 5. А я говорю, что мне удобно с 2 до 2:30. И получается, что сегодня никак, и дискуссия длится очень долго. Так, конечно, неудобно договариваться. Артём: Да, у меня часто бывают созвоны с клиентами, и это головная боль. Я прямо в почте пишу «Когда тебе удобно?» и т. д., поэтому тебя понимаю. Было бы удобно иметь единое место, где мы можем планировать эти встречи. Всеволод: Многие знают, что есть инструмент Calendly, который интегрируется с вашим календарём (Google, Apple и другие). И в нём вы настраиваете свою доступность:  У вас будет своя страница, которая публично доступна любому человеку, и он может зайти на неё и запланировать, например, 15-, 30- или 60-минутный созвон. Часто используется для саппорта, когда ты можешь связаться с какой-то компанией, но в целом сотрудники это тоже могут использовать. Всё, что вам нужно, — скопировать ссылку, передать другому человеку, он переходит по ней, видит доступность вашего календаря, выбирает удобную дату и время и подтверждает:  Далее он уже набирает имя и пишет e-mail:  При этом он может добавить несколько гостей. Так можно организовать митинг за пару кликов. При этом важно не забыть про агенду, которую я обычно рекомендую писать для митингов, потому что без агенды митинги обычно заканчиваются ничем. После того, как я запланирую мероприятие, приглашение приходит мне и человеку:  Выбранное время становится недоступно, поскольку всё обновляется в реальном времени. Позже мы покажем, как сильнее интегрировать эти штуки в свой workflow. Артём: Тема реально очень удобная. Я о ней узнал от зарубежных коллег, потому что надо было с ними синхронизировать митинги, и это становится адом. Особенно, если у вас разные часовые пояса. Сейчас мы у себя активно внедряем Calendly. Как ты правильно сказал, мы используем его в саппорте. Артём: У нас есть несколько проектов, и они непосредственно связаны с кодом. Всеволод: Онбординг происходит из-за того, что обычно все погружаются либо в код тестов, либо в код приложения. Я очень часто использую расширение Octotree для Chrome, которое умеет навигироваться. Когда ты заходишь на GitHub, то можешь прямо в нём перемещаться, как в IDE:  При этом после обновления страницы всё остается на своих местах. Это удобно, потому что ты обычно перемещаешься между папками и переходишь к коду. Понятно, что и в GitHub есть Codespaces, с которым можно это делать. Но Octotree — это простой легковесный плагин, который позволит вам пробежаться по опенсорс-проектам и посмотреть код. Всеволод: Code With Me — это плагин, который разработали в компании JetBrains. Аддон позволяет вам и вашему товарищу поработать над кодом вместе. Кирилл Скрыган — Code With Me Behind the Scenes Рассмотрим простую историю. Я пришёл на проект, и мне непонятно, где что писать. Я вроде неглупый парень, но там столько кода, что не очень понятно. Вы нажимаете Enable Access и даёте полный доступ по ссылке:  Ссылка копируется, и вы передаёте её товарищу. Он может её открыть в браузере или прямо в IDE. Самое интересное, в процессе организовывается созвон. И не надо никакого Zoom. Артём: Кроме того, я могу выполнять код непосредственно в IDE Севы. И даже имею доступ к терминалу. Например, могу запустить тест и посмотреть, как он будет выполняться:  Всеволод: Один из кейсов — когда какие-то тесты не проходят. Артём может отдебажить вместе со мной, что у меня не так, и проверить настройки Java, Maven и другое. Артём: Также можно использовать брейкпоинты. Это действительно очень крутой инструмент онбординга. В своё время я упустил информацию про него. Но сейчас мы занимаемся образовательной программой, где я преподаю в школе. И когда нужно один на один объяснить или показать что-то человеку, то Code With Me здесь идеален. Как всё выглядит с моей стороны:  В процессе также можно переключаться между хостами. Возможности Code With Me реально безграничные. И первый раз, когда Сева мне настраивал сетап, он не дал разрешение, и я не мог запускать код на его машине. Это было исключительно хождение по коду. Поэтому по умолчанию у вас будут настройки, которые запрещают это делать. Артём: Projector представляет набор контейнеров, в каждом из которых запакована IDE, доступ к которой вы можете получить по порту. Грубо говоря, вы поднимаете вашу IDE в Docker-контейнере и можете скинуть кому-нибудь URL на неё и работать вместе. На мой взгляд, с приходом таких решений мощные компьютеры для разработки станут не нужны. Вы сможете просто поднять на мощной машине вашу любимую IDE и после этого работать с ней через веб-интерфейс. Давайте сделаем это. Я сделал простенький docker compose-файл и запустил его:  Теперь нам надо попасть в порт 8887. Я беру свой IP-адрес и делаю доступ к порту:  У нас появляется IDE. Дальше я могу с ней работать как со стандартной IDE — например, изменить строку Hello, Kotlin! на Hello, Java!:  Я могу также выслать URL Севе, и он откроет на своём планшете:  Я могу менять код, и Сева видит это в реальном времени. То есть, грубо говоря, это одна и та же IDE. Всеволод: Давай я изменю строку с Hello, Java! на Hello, Артем! и запущу код:  Наверное, хоткеи и прочее не так удобно будет настраивать. Но всё запускается, и вы можете хоть с телефона посмотреть, что вам показывают. Артём: Если я сделаю git clone, скачаю и открою новый репозиторий, то он тоже отобразится на экране. То есть можно работать один в один, как у вас на локальном компьютере. В одном из докладов я рассказывал про разработку IDE-плагинов. Когда я рассказывал про то, как можно расставлять аннотации над кодом на основе TMS-тестов, мне нужно было физическое действие. То есть мне надо было нажать на кнопку, потом выполнить действие. И мне задали вопрос, можно ли это спрятать в CI? Сейчас у нас есть Docker-контейнеры, и ничто не запрещает вашему плагину запустить логику в бэкграунде. Вы поднимаете IDE, она сразу же открывает ваш проект и выполняет логику по работе с проектом. Основные критерии её использования: Но Code With Me, мне кажется, сейчас реально интереснее, потому что он встроен именно в вашу IDE. Всеволод: Когда кто-то сейчас онбордится, то можно использовать различные способы. Теперь показывать код человеку в реальном времени не требует больших усилий. Артём: Мы можем к слову github в адресе репозитория дописать 1s, и у вас появится IDE:  Здесь JetBrains не монополисты. Например, в VS Code есть функция Live Sharing, которая появилась раньше. Круто, что тенденция идёт в этом ключе, и коллаборация становится проще. Многие вещи теперь можно сделать из удалёнки. Всеволод: после того, как мы все запланировали и проонбордили, нам нужно как-то коммуницировать. Артём: Я использую ngrok для решения следующей задачи. Например, я сделал какую-то разработку у себя локально и не хочу её пока деплоить. Я могу сделать новый макет, документацию и вывести какую-то новую ручку REST. Как мне её перенести другому человеку (Севе)? Для этого у меня есть специальный репозиторий. Запущу документацию:  У меня стартует сайт, и мы видим документацию по моему продукту:  Здесь есть список изменений, которые мне нужно расшарить Севе:  Как видите, документация доступна только на localhost. Я запоминаю порт, по которому она доступна (в данном случае 1313), и в консоль пишу ngrok http 1313:  Ngrok создаёт внешний IP-адрес, по которому будет доступна моя документация, и она появляется в Интернете. Я могу в документации изменить какой-то файл, и люди будут сразу же видеть изменения. До этого я использовал ngrok для тестирования интеграций, потому что я разрабатываю какую-то систему локально, а после того, как я изменил данные, надо извне протестировать интеграцию с GitHub. Мне приходит запрос с GitHub, и я делаю все штуки. Артём: В последнее время я очень много работаю с документацией, и мне нужно записывать ролики к ней. Мы делаем фичу, и чтобы пользователю было понятно, что произошло, мы сразу же вставляем логику работы с нашим продуктом. Для этого я использую программу Monosnap:  Я могу выбрать, какую часть экрана снимать. Также я могу указать аудиодорожки, которые хочу снимать. Также я могу вставить видео прямо из веб-камеры, чтобы была видна моя реакция. Остаётся нажать кнопку Record, а затем после записи — Stop. Полученные видео я могу сохранить как в MPEG, так и в GIF. После записи я использую ImageOptim. В неё закидываю GIF и сжимаю без потери качества:  Мы с Севой ради эксперимента взяли доку Cypress, загнали все их файлы в ImageOptim и получили сжатие 20%. По сути, репозиторий теперь выкачивается на 20% быстрее. Всеволод: Loom — это тоже инструмент для захвата экрана:  Можно выбрать запись экрана, запись веб-камеры или всё вместе. Также она умеет делать скриншоты. Мне нравится в ней то, что когда вы делаете запись, у вас есть таймер, по которому вы можете успеть подготовиться. Также во время того, как вы пишете, у вас есть слева меню, с помощью которого вы можете спросить, что происходит в блоке кода:  После того, как мы записали видео, оно сразу открывается в облаке. Инструмент платный, но есть бесплатные возможности. И классно, что мы можем прямо в облаке посмотреть видео с ускорением или же его обрезать. Я сделал всего пару кликов и расшарил ссылку Артёму. Но на мой вкус, самое полезное в Loom — это возможность оставлять комментарии. Для того, чтобы коллаборировать, сейчас не обязательно созваниваться и можно использовать разные инструменты. Можно записывать видео с экрана, скриншоты. Можно в том числе с помощью ngrok делать трансляцию экрана или же показать заказчику свёрстанный макет, если не хотите заморачиваться с деплоем. Артём: Автоматизация тестирования набирает обороты, и хочется рассказать про интересные подходы, которые здесь появляются. Рассмотрим возможности инструмента QA Wolf:  Давайте напишем тест для https://techtrain.ru. Слева появляется код теста, а справа — непосредственно браузер:  Закроем уведомление, перейдём к программе, отмотаем программу до какого-то состояния и выберем «Какие тулы ты бы взял на удалёнку»:  Вот такой простенький тест. После этого мы можем его запустить, и у нас явно тест запускается. То есть это инструмент Record&Play. На мой взгляд, это крутой подход. Единственное, раньше в QA Wolf можно было всё делать с помощью консоли, и он генерировал тесты локально. Сейчас они сделали такую обёртку, что, на мой взгляд, спорное решение. Понятно, почему они делают — у них появилась вкладка Pricing. Но изначальная логика, по мне, была правильнее. Надо дать пользователям возможность писать тесты либо в их среде разработки, либо в другом месте. Артём: Инструмент, собственно, работает также. Но его отличительная особенность заключается в том, что он умеет отдельно генерировать Playwright-тесты. Всеволод: Так как Playwright портируется на разные языки, он на самом деле умеет в своём окне генерировать код не только на JS, но и на Python, C# и скоро на Java. Артём: Если говорить про будущее веб-тестирования, то оно точно за подобными инструментами генерации кода, поскольку экономит кучу времени. И полгода назад, когда мы тестировали QA Wolf, к нему было много вопросов. Например, если вы начинаете typed-тесты, то он делал несколько type. Сейчас же он всё схлопывает, и инструменты сильно «поумнели».  Артём: С появлением большого количества тестов всё чаще возникает вопрос: как понять, что у нас вообще тестируется, а что — нет? Артём: Первый инструмент, который я хочу вам показать, — Swagger-coverage. По нему мне часто пишут в личку «спасибо за этот тул». У нас есть petstore — default-сайт для тестирования, и в нём мы видим ручки, которые у нас есть:  Это стандартная Swagger-документация. Мы пишем наши тесты и не понимаем, какие API-ручки и с какими данными покрыты, а какие — нет. Для того, чтобы это поднять, я написал тест, где буду дёргать ручку /pet/{id}:  Я ожидаю, что получу правильный ответ. Я сначала создаю pet, а затем проверяю, что по такому ID у меня мой pet и создан. Запускаем тест и смотрим отчёт:  По итогу мы получили, что: Если посмотреть вглубь, то увидим, что мы как раз вызывали ручку POST и проверяли это с определёнными данными:  И потом мы вызывали ручку GET, где проверяли код 200:  С помощью Swagger-coverage вы можете быстро понимать, что у вас покрыто. Работает он следующим образом. У вас есть Swagger-документация. Во время выполнения тестов тул запоминает, какие ручки с какими значениями были вызваны. И потом Swagger report строится на основе разницы между тем, по каким ручкам мы пробегали, и Swagger-документацией. Получается красивое отображение, в котором вы сразу же видите, что у вас покрыто, и можете легко планировать ваше тестирование. Артём: Есть аналог Swagger-coverage — Reqover. Инструмент взаимодействует примерно так же, но его отличие в том, что это Docker-контейнер. То есть если там статический report, и этот report на файлах, то здесь вы видите Docker-контейнер, который снимает данные в режиме реального времени. Мне кажется, оба инструмента не конкурируют, а скорее дополняют друг друга. При этом если вы зайдёте и запустите Reqover, то у него будет похожая вёрстка report, как у Swagger-coverage. Артём: Ещё один инструмент, о котором хочется рассказать, — Allure TestOps, над которым работаю я. Основная его идея в следующем. У нас есть много тестов, которые написаны на разных языках. Они помечены аннотациями:  Да, это немного больно размечать, но современные end-to-end тестировщики научились делать тут всякие вещи. Мы видим, какой микросервис наш тест проверяет, какая issue проверяется и т. д.  Запустим наши тесты из задачи Jenkins:  И они отображаются в общей системе:  Отсюда мы можем сразу же перезапустить тесты:  При этом у нас перезапустятся именно автотесты, задача перезапустится ещё раз, а последние два теста не запустятся. У нас есть общее представление всех тестов внутри проекта и компании. Мы можем быстро посмотреть, какие у нас есть API-тесты, UI-тесты, тесты на конкретную issue (если надо посмотреть, какие тесты запускаются):  Также там есть интеграция с Jira и т. д. То есть Allure TestOps — некая база тестов. Кроме того, есть дашборды, где вы можете посмотреть, сколько автотестов есть у каждого сотрудника, каждой команды на каждую конкретную фичу и т. д.:  Allure TestOps позволяет собрать всю автоматизацию тестирования в одном месте, знать, какие тесты есть, кто их написал, как часто они запускаются и т. д. Всеволод: Мы уже подходим к таким инструментам, которые можно встраивать как плагины или расширения в Chrome. Всеволод: Одно из таких расширений разработала компания Toptal — Web Developer Checklist. Он делает примерно то же самое, что и Lighthouse. Он выполняет проверку веб-страницы вашего сайта на разного рода метрики. Например, насколько у вас accessible-сайт, нормально настроен SEO, хорошо открывается в мобильных приложениях и т. д.:  Мы можем посмотреть, что не так, и инструмент предлагает решение проблем. Всеволод: Многие слышали про Lighthouse, но тем не менее хочется о нём рассказать, чтобы у вас был джентльменский набор из разных инструментов. Lighthouse встроен в Chrome Web Tools. Соответственно вы можете сделать некий тест вашего веб-приложения. Вы выбираете, какие категории тестов вы хотите провести: Как только вы запускаете тесты, Lighthouse перезагружает ваш сайт, и вы получаете отчёт по метрикам:  Артём: Это реально прикольный инструмент, о нём знают все фронтенд-разработчики, но не все тестировщики. Многие сейчас делают персональные блоги и сайты. И эти инструменты позволяют иметь роботизированного компаньона. Всеволод: Тут точно так же есть подсказки. Если у вас проблемы с кодом, то Lighthouse пишет, что нужно подменить:  Всеволод: Я думаю, многие используют Slack. У нас есть бот Alice:  Он нам говорит: «Ребята! У вас должен был быть стендап в 2:45, то есть через пять минут». Мы хотим синхронизироваться с Тёмой и отвечать на 4 простых вопроса: Артём: Получается, что кто-то берёт на себя роль человека, который всех пинает. И как человека, который постоянно делает стендапы, меня это немного напрягает. И этот бот решает проблему. Всеволод: Также есть интеграция с Calendly. Я могу создать событие и предложить Артёму созвон, например, на 15 минут. В асинхронное время Артём может зайти и запланировать со мной звонок. Точно так же сделана интеграция с Jira. Вы можете получать репорты, какие задачи вам нужно сделать, кто что уже сделал и т. д. Также имеется интеграция с Loom, который мы показывали ранее. Понятно, что видео могут проигрываться по внешней ссылке, но вам захочется, скорее всего, смотреть прямо в Slack. Здесь он подгружает весь интерфейс видеоплеера Loom без необходимости переключаться на другие инструменты. Поэтому вы можете посмотреть, какие инструменты используете, и, возможно, найти интеграцию со Slack. Они упростят вашу жизнь и уменьшат переключение между контекстом. Артём: Так или иначе Slack завоёвывает рынок (хоть Teams и начинает активно отвоёвывать часть рынка) за счёт таких интересных интеграций. Ждём, когда внутри Slack можно совершать различные действия, например, перезапускать тесты, проводить код-ревью и т. д. Тогда это будет единая платформа, куда будут присылаться события. Артём: Если вы знаете ещё какие-то инструменты, то делитесь с нами. Мы обязательно их попробуем и расскажем в будущем. Редактор