Кому-то этот пост покажется запоздавшим, кому-то — очевидным. Однако общаясь с коллегами из 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: и инспекции с автодополнением, и хоткеи, и навигация. Можно пользоваться облачной версией или поднять собственный сервер, если вы не доверяете облакам.

Альтернативы:

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)


  1. shpaker
    18.08.2021 17:32
    +1

    GitHub Actions — новое решение для тех, кто хранит код на GitHub. Очень современный и крутой, но пока что в документации остается немало "белых пятен".

    Дока конечно там с нюансами, но какие "белые пятна" вас беспокоят?


    1. ARG89 Автор
      19.08.2021 07:43

      Может быть, я неудачно слово подобрал, я о нюансах и говорил.

      Переиспользование куска воркфлоу, например, совсем не очевидно. Но если с этим разобраться, то выяснится, что композитные Actions не поддерживают uses.


  1. saboteur_kiev
    19.08.2021 03:50
    +2

    Смысл статьи не очень понятен. Чем конкретно эти инструменты отличаются от не удаленной работы? Те же самые CI/CD, те же самые чаты, докеры и так далее.

    Это просто инструменты автоматизации.


    1. ARG89 Автор
      19.08.2021 13:33

      Если честно, то начинал статью как римоут, а потом вышло как вышло… В одном из ТГ-чатов такое же замечание сделали.

      В общем, буду думать, как сделать более правильный римоут пост в будущем.


  1. kochetkov-ma
    19.08.2021 14:06
    +1

    В заголовке 'удаленной', но статья совсем не про это. И к QA отношение имеет только Allure Test Ops и походу это есть его реклама. Однако, отмечу, что это действительно топовое решение для автоматизации ). А ещё добавлю, что с точки зрения CI - GitLab CI идеален вместе с интеграцией с кубером. Минусить не буду, но статья кликбейтная и бесполезная.


  1. irreality
    19.08.2021 14:10

    Из специфичных для удалённой работы только Codewithme. Ожидал увидеть в статье именно про специфику...


  1. ivanych
    21.08.2021 00:02
    +1

    Я не понял кому эта статья адресована. Тестировщикам?

    Т.е. предполагается, что тестировщик, сидя дома на удалёнке, должен взять Докер и засунуть в него тестируемую систему? Серьёзно?

    А потом должен взять Дженкинс и наладить в нём запуск полученных в предыдущем абзаце образов и деплой в Хероку? Серьёзно?

    И всё это не осилили сделать девопсы, которым за это немалые деньги платят, а тестировщик такой - хоба! - и сделал? Серьёзно?

    Бред какой-то.


    1. ARG89 Автор
      23.08.2021 14:24
      +1

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

      должен взять Докер и засунуть в него тестируемую систему? Серьёзно?

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

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

      Конечно, история с самостоятельным подъемом прод-подобной CI-системы выглядит утопично, но вы ведь привели крайний случай. И тогда порядок действий должен выглядеть как "с коллегами предложить использовать докер и дженкинс".

      И всё это не осилили сделать девопсы, которым за это немалые деньги платят, а тестировщик такой - хоба! - и сделал? Серьёзно?

      Или осилили, а тестировщику непонятно, зачем в это лезть, ведь "девопсы за много денег" сами разберутся, пусть работают".


      1. ivanych
        24.08.2021 08:52

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

        Если ничего этого нет - внедрение этого тестировщиком в обход имеющихся процессов представляется не реалистичным.


      1. saboteur_kiev
        27.08.2021 00:58

        Или осилили, а тестировщику непонятно, зачем в это лезть, ведь "девопсы за много денег" сами разберутся, пусть работают".

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

        Если же тестировщик все это знает, то его позиция называется тестировщиком весьма условна.