Кому-то этот пост покажется запоздавшим, кому-то — очевидным. Однако общаясь с коллегами из QA-сообщества я продолжаю сталкиваться с тем, что удаленная работа вызывает кучу неудобств: количество чатов в мессенджерах зашкаливает, нельзя прийти ногами и объяснить все на пальцах или в деталях передать особенности окружения для воспроизведения бага, — хотя все уже давно было создано и внедрено.
За последний год появилось куча новых тулов с прицелом на удаленку, но стоит ли бежать и смотреть их, когда есть старые добрые инструменты? В этой короткой подборке я постарался собрать несколько тулов, которые помогут тестировщикам и тестировщицам облегчить работу с коллегами по цеху, опсами и разработчиками.
ДИСКЛЕЙМЕР: На самом деле у каждого инструмента есть как минимум по несколько альтернатив, выбор из которых может привести к знатному холивару. Если у вас есть свои соображения на тему "автор дурак, надо было брать не Х, а Y", приходите в комментарии!
1. Continuous Integration (CI/CD) – CircleCI
CircleCI — система для сборки и развертывания, аналогичная Travis CI (Github), и работающая по тем же принципам — к CircleCI-аккаунту подключаются репозитории (в отличи от Travis — к CircleCI можно добавить любой репозиторий), сборки выполняются в контейнерах или виртуальных машинах, что позволяет избежать сложностей с конфигурированием окружений.
Система умеет отправлять результаты сборки на почту или в Slack/HipChat и другие мессенджеры. А с помощью скриптов можно задеплоить код в AWS ECS, S3, Heroku или в любое другое окружение средствами самого CircleCI.
Кроме того, CircleCI славится за хорошо реализованную автоматизацию параллельности, понятный дебаггинг, умение делать сборки по веткам и куче кастомизаций.
Альтернативы:
Jenkins — стандартный выбор CI/CD системы, быстрый, доступный, опенсорсный со всеми вытекающими плюсами и минусами.
GitHub Actions — новое решение для тех, кто хранит код на GitHub. Очень современный и крутой, но пока что в документации остается немало "белых пятен".
TeamCity — CI/CD решение от всеми любимых JetBrains с поддержкой шаблонов и кучей плюшек.
2. Общение – Slack
Назовите меня Капитаном Очевидность, однако Slack остается стандартом де-факто для общения команд. Он может быть не очень быстрый и жрет много памяти, однако система каналов, чатов и веток делает удобным для навигации в больших проектах.
Гибкость нотификаций и настроек позволяет настроить все так, чтобы не вскакивать от переписки флудеров посреди ночи, а хороший поиск и неплохие возможности как файлообменника делают его хорошей альтернативой большинству более новых решений.
Ну и большой плюс — скорее всего у всех уже есть опыт работы со Слаком, так что входной порог минимальный.
Альтернативы:
Microsoft Teams — гибкий и довольно удобный корпоративный мессенджер. Может быть как облачным, так и серверным. Мобильное приложение менее удобное, чем у Slack.
Telegram — тут все понятно, есть чаты и все. Быстрый легковесный, но не очень функциональный мессенджер для небольших команд.
3. DevOps – Docker
Скорее всего, ваши разработчики и опсы уже используют Docker, пора присоединяться! Нет смысла рассказывать про то, как контейнеры облегчают жизнь, позволяя делать безопасные и преднастроенные сборки. C Docker для воспроизведения найденных багов разработчикам не придется танцевать с бубном вокруг конфигурации локальной машины — можно просто поднять правильный образ!
Так что с Docker можно оптимизировать и расходы на инфраструктуру, и оверхед на общение, который на удаленке многим усложняет жизнь.
Альтернатив я не знаю, если честно. Докидывайте в комментарии.
4. Совместная работа над автотестами – Code With Me
Перейдем к неочевидным решениям. Code With Me — новый сервис для совместной разработки и парного программирования.
Делать код ревью в зуме с шарингом экрана — прошлый век! Согласитесь, намного лучше шарить не экран с IDE, а IDE с экраном. Разница понятна — возможность в реальном времени сделать ревью автотестов и внести правки, посмотреть, как старшие коллеги расковыривают непонятные проблемы слияния или вообще пописать тесты вдвоем. Понятно, что и онбордить новичков так удобнее — живое общение в отсутствие "кулерных разговоров" позволит поделиться толикой атмосферы в команде.
В Code With Me есть все плюшки IntelliJ: и инспекции с автодополнением, и хоткеи, и навигация. Можно пользоваться облачной версией или поднять собственный сервер, если вы не доверяете облакам.
Альтернативы:
VS Code Live Share — то же, но от Microsoft.
5. Управление тестовой инфраструктурой – Allure TestOps
Ну и последнее по порядку, но не по важности. Как только ваша удаленная автоматизация станет большой, вам понадобится контроль на всеми тестами, запусками, сбором и анализом результатов. Allure TestOps позволяет управлять вообще всеми тестами:
API, -web, мобильными, десктопными или мобильными;
на Java, Python, JS, Cucumber;
смоук, юнит, е2е
и бог знает какими еще!
Из коробки работает автообновление тестовой документации из репозитория, гибкие возможности для запуска и перезапуска наборов тестов на пайплайнах, интеллектуальный разбор результатов с обнаружением дефектов и flaky-тестов и собственный Query Language для гибкости в генерации дэшбордов.
Куча нативных интеграций с CI/CD системами (Jenkins, GitHub, GitLab, Bamboo, TeamCity), тестовыми фремворками и трекерами сэкономит кучу времени на написании и поддержке собственных велосипедов и костылей.
Альтернативы:
Katalon Studio + Runtime Engine — известный движок с бесплатной студией и недешевым движком автоматизации.
qTest — большой и очень "корпоративный" инструмент для управления тестированием. Говорят, использует AI для помощи тестировщикам.
На этом пока все. Главное, помните, что хорошие инструменты действительно экономят время и позволяют заниматься интересной работой, а не рутиной!
Комментарии (10)
saboteur_kiev
19.08.2021 03:50+2Смысл статьи не очень понятен. Чем конкретно эти инструменты отличаются от не удаленной работы? Те же самые CI/CD, те же самые чаты, докеры и так далее.
Это просто инструменты автоматизации.
ARG89 Автор
19.08.2021 13:33Если честно, то начинал статью как римоут, а потом вышло как вышло… В одном из ТГ-чатов такое же замечание сделали.
В общем, буду думать, как сделать более правильный римоут пост в будущем.
kochetkov-ma
19.08.2021 14:06+1В заголовке 'удаленной', но статья совсем не про это. И к QA отношение имеет только Allure Test Ops и походу это есть его реклама. Однако, отмечу, что это действительно топовое решение для автоматизации ). А ещё добавлю, что с точки зрения CI - GitLab CI идеален вместе с интеграцией с кубером. Минусить не буду, но статья кликбейтная и бесполезная.
irreality
19.08.2021 14:10Из специфичных для удалённой работы только Codewithme. Ожидал увидеть в статье именно про специфику...
ivanych
21.08.2021 00:02+1Я не понял кому эта статья адресована. Тестировщикам?
Т.е. предполагается, что тестировщик, сидя дома на удалёнке, должен взять Докер и засунуть в него тестируемую систему? Серьёзно?
А потом должен взять Дженкинс и наладить в нём запуск полученных в предыдущем абзаце образов и деплой в Хероку? Серьёзно?
И всё это не осилили сделать девопсы, которым за это немалые деньги платят, а тестировщик такой - хоба! - и сделал? Серьёзно?
Бред какой-то.
ARG89 Автор
23.08.2021 14:24+1А давайте представим, что у тестировщика есть коллеги (ну вдруг), у которых эти инструменты уже используются.
должен взять Докер и засунуть в него тестируемую систему? Серьёзно?
Или быть готовым взять используемый в разработке образ и знать, что с ним делать в CI-системе.
Суть в том, что на месте тестировщика хорошо бы понимать, как эти штуки используются и быть готовым присоединиться к стану их пользователя, а не говорить "бред какой-то".
Конечно, история с самостоятельным подъемом прод-подобной CI-системы выглядит утопично, но вы ведь привели крайний случай. И тогда порядок действий должен выглядеть как "с коллегами предложить использовать докер и дженкинс".
И всё это не осилили сделать девопсы, которым за это немалые деньги платят, а тестировщик такой - хоба! - и сделал? Серьёзно?
Или осилили, а тестировщику непонятно, зачем в это лезть, ведь "девопсы за много денег" сами разберутся, пусть работают".
ivanych
24.08.2021 08:52Нет, ничего из этого тестировщик с коллегами не вводят в строй. Если эти штуки есть - тестировщику скажут, как этим пользоваться и на каком участке происходит работа тестировщика.
Если ничего этого нет - внедрение этого тестировщиком в обход имеющихся процессов представляется не реалистичным.
saboteur_kiev
27.08.2021 00:58Или осилили, а тестировщику непонятно, зачем в это лезть, ведь "девопсы за много денег" сами разберутся, пусть работают".
В нормальном случае, девопсы настраивают инструменты так, что у тестировщика не будет прав влезть своими неумелыми руками и все поломать, потому что он знает как продукт тестируется, но не знает про все остальные интеграции с внешними системами, откуда берутся ресурсы и кто за них платит и как их заказывать, и как все это выводить на продакшен.
Если же тестировщик все это знает, то его позиция называется тестировщиком весьма условна.
shpaker
Дока конечно там с нюансами, но какие "белые пятна" вас беспокоят?
ARG89 Автор
Может быть, я неудачно слово подобрал, я о нюансах и говорил.
Переиспользование куска воркфлоу, например, совсем не очевидно. Но если с этим разобраться, то выяснится, что композитные Actions не поддерживают uses.