Привет! Меня зовут Миша, я тестировщик из Контура, а именно – из Контур.Маркета. И в роли тестировщика я столкнулся со множеством однообразных действий, которые хочется автоматизировать. Быстро надоело по 100 раз в день перезапускать службу, удалять локальную базу, указывать в конфиге адрес одного из стейджей… Я написал на коленке пару питоновских скриптов, которые запускались по горячим клавишам при помощи программы AutoHotKey. Первый в жизни реально полезный код после тысяч строк алгоритмов сортировок и поиска – можно ехать на остров и пить коктейли :) 

Хах, если бы. Пока скрипты распространялись по команде, приходилось значительно дополнять их и рефакторить. Например, заменил AutoHotKey на питоновскую библиотеку keyboard, чтобы получилось единое приложение с понятным выводом. А также выделил свою библиотеку, обертку над keyboard для удобного создания команд на основе горячих клавиш. Код разросся до 3000 строк – и всё это делалось в свободное время, потому что в рабочее время мне хватало других задач.

Приложение развивалось совсем не так, как я ожидал. И именно об этом хочется сейчас поговорить (а не, например, о нюансах переключения окон скриптами). Поделиться тем, что я сделал ужасно глупо и в чем испытал разочарование. Думаю, что стоит проговаривать даже очевидные ошибки: легко что-то упустить, если делать вид, что все и так всё понимают.  

Ожидание 1: все будут контрибьютить

В команде разработки люди делятся на два типа: одни уже знают питон, а другие легко его освоят. И те и другие с радостью присоединятся к новой движухе, ведь некоторые действия тестировщики выполняют вручную по 1000 раз, и это нельзя терпеть, это бьет во времени выпуска фич в целом. Главное – начать, а дальше придут умные люди и помогут все исправить!

Во-первых, не стоит рассчитывать, что люди будут подключаться на голом энтузиазме. Разработчикам хватает своей системы с ее техдолгом. А тестировщикам – автотестов, писать которые нужно понятней, востребованней и почетней. Если есть желание дополнительно позаниматься написанием кода, то вряд ли выбор падет на сумбурный проект на чужом языке.  

Во-вторых, проект не должен слишком сильно выходить за пределы системы планирования. Если я ожидаю участия других членов команды, то надо понимать, как именно должно быть организовано это участие? Другими словами, в таск-трекере должны быть задачи, и они должны обоснованно претендовать на ресурсы в формате, принятом в команде. Возможно, они должны быть не обычными задачами, а идеями для хакатона – в любом случае, нужно играть роль автора и фича-лида. А если получить ресурс регулярно не удается, возможно, и задача сама не так востребована – делать ее вообще не стоит.  

В-третьих, язык программирования и его экосистема имеют значение. Разработчики на C# и котлине (эти языки приняты в продукте, в котором я работаю) реально смотрят на питон, если не свысока, то, как минимум, со стороны, даже если имеют опыт работы с ним. И это действительно особый мир, который требует погружения – со своими синтаксическими особенностями (list comprehensions, контекстными менеджерами), библиотеками (для работы с запросами и с клавиатурой) и инструментами (виртуальные окружения и IDE). 

Ожидание 2: горячие клавиши – это круто

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

Во-первых, разработчики уже пользуются большим количеством горячих клавиш. В оперативную память, зарезервированную под эти цели, не влезет еще десяток комбинаций. Поэтому вместо восторга я услышал: «О нет, еще горячие клавиши?! А можно вызывать команды в консоли?..» Пришлось добавить специальный консольный режим.  

Во-вторых, есть особые случаи, при которых горячие клавиши попросту не работают. Например, при подключении к удаленным ПК.

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

В-четвертых, стоит поставить под сомнение исходную идею: действительно ли горячие клавиши позволяют сэкономить кучу времени, а пользователи ощущают и ценят этот эффект? Понятно, что есть здесь свой шик, но стоит ли ради него использовать специальную библиотеку и обертку над этой библиотекой, заставлять пользователей забивать голову новыми комбинациями? Возможно, вместо этой космической ручки стоит использовать карандаш – решение в лоб без лишних фантазий.

Ожидание 3: аудитория – люди в той же роли, что и я 

Я тестировщик одного продукта Контура и пользоваться будут тестировщики моей команды. Как может быть иначе? Мы же постоянно взаимодействуем, а сложности при использовании продукта легко закрыть личным общением: ответами на вопросы или даже удаленным подключением к чужому ПК.

Во-первых, реальная аудитория оказалась больше. Это разработчики (проходят основной сценарий), тестировщики из соседних команд (проверяют интеграцию), дизайнеры (проводят UI-ревью), эксперты (воспроизводят баги на проде по репортам поддержки). Многим из них не нужен ежедневный инструмент, который постоянно запущен и предлагает добавить себя в быстрый запуск. Также они не будут гибко настраивать под себя конфиг и изучать ридми в поисках скрытых возможностей. Им нужно просто нажать на кнопку и получить результат. До последнего момента мои скрипты работали не так – об этом я еще расскажу в конце статьи.  

Во-вторых, с увеличением аудитории теряется контроль над использованием инструмента. Автор уже даже не знает список всех пользователей и не может проконсультировать каждого лично. Поэтому все должно быть просто и понятно само по себе. Например, я стал выводить список команд с подсказками, понятную инфу про результат, обрабатывать ошибки и некорректный ввод. И делать то, о чем пользователь не должен думать: самостоятельно запускать скрипты из-под админа, перезапускать при блокировке экрана и переключаться в нужный момент.  

Ожидание 4: всеми возможностями будут пользоваться одинаково активно

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

Во-первых, принципы создания хороших программных продуктов везде одни. Для начала важно понимать свою аудиторию и ее реальные проблемы, затем – привычные способы их решения. И только потом предлагать новые инструменты. Например, мне и в голову не пришло, что для кого-то работа в консоли может как раз быть привычной (потому что у меня не было такой привычки), а то, что при этом запускаются горячие клавиши – взрывом мозга.  

Во-вторых, важно получать обратную связь от использования сервиса. Если бы я собирал метрики, то точно бы знал, какие скрипты и как часто используются. Если бы я сообразил добавить ссылку на форму обратной связи куда-нибудь, то наверняка бы узнал о неудобствах, о которых люди постеснялись написать мне лично.  

Пример скрипта, который вряд ли кому-то нужен – генератор ИНН и КПП, потому что таких сервисов куча. Есть и обратный пример, когда люди активно благодарили меня и без всяких анкет – виртуальный сканер. Если вы пользуетесь кассами самообслуживания, то могли заметить, как маркировка захватывает все новые товарные группы – мы в Контур.Маркете их поддерживаем и тестируем. Форматы кодов маркировки слегка отличаются для воды, пива, молока, соков... Раньше тестировщики притаскивали товары в офис, приходили сами и брали сканер в нашем обширном парке техники. Скрипт позволяет этого избежать, полностью работать удаленно и не захламлять офис бутылками упаковками от творожных сырков.

Ожидание 5: опенсорс привлечет внешних пользователей  

Запуск скриптов по горячим клавишам – самостоятельная проблема, которую я решил созданием обертки к библиотеке keyboard. Логично эту обертку тоже превратить в библиотеку, которую можно будет использовать внутри Контура и за его пределами для произвольных скриптов. Сила опенсорса поможет улучшить её – на гитхабе появятся обратная связь, тикеты и мердж-реквесты!

Во-первых, гитхаб – та же помойка, как и весь остальной интернет. Ощущения абсолютно такие же, как при выкладывании первых постов в ЖЖ 3000 лет назад – волнительно, удивительно и никакой реакции (но спасибо за звездочки коллегам).  

Впоследствии я стал обращать внимание на опенсорсные проекты, которыми пользуюсь сам. Как правило, они предоставляют широкие возможности в определенный сфере, имеют развернутую документацию (по которой понятен масштаб проекта) и развиваются много лет инициативными людьми. На гитхабе тысячи и десятки тысяч звездочек, на ютубе есть видео, на Хабре и медиуме – статьи. Вероятность того, что я бы сам наткнулся на свой же проект и стал его использовать примерно нулевая.  

Заопенсорсить код, конечно, стоит: нет смысла его прятать. Но просто выкладывать сырой продукт и ожидать реакции – это наивно.  

Во-вторых, подозреваю, что силами одного разработчика сложно сделать что-то заметное. Тем более, силами неопытного разработчика-тестировщика, по остаточному принципу и без связи с корпоративным интеллектом - с подходами, выработанными в Контуре. А даже если сделать, по заветам маркетинга, у проекта должна быть врожденная виральность и активное продвижение в сообществе: статьи, выступления, видео.  

Ожидание 6: запустить питоновский скрипт несложно 

Питон установлен на всех ПК, а если не установлен – почему бы и не поставить? Остается только клонировать репозиторий и подключить зависимости уже готовым батником. Затем время от времени обновлять сам репозиторий (чтобы получать обновления скриптов) и заново запускать батник (потому что библиотека для запуска горячих клавиш живет своей жизнью и тоже порой обновляется).

В процессе я даже не понимал, что это абсурдная ситуация. А ведь даже сама установка питона вызывает сложности. Порой команда python -m main в консоли ведет не к выполнению скрипта main, а к переходу в майкрософт стор – тогда надо отключить псевдонимы приложений и переустановить. Порой установлен допотопный питон 2 версии – тогда надо поставить третий. Слишком старый питон третьей версии тоже станет проблемой, и слишком новый – возможно, тоже. Также по умолчанию запуск происходит не в виртуальном окружении, поэтому может возникнуть конфликт зависимостей.  

В общем, люди хотят просто экзешник одним файлом. И я такой экзешник с ходу не смог сформировать автоматически – видимо, как раз из-за разделения на скрипты и внешнюю библиотеку. Но я понял, что для командного инструмента это действительно прикольная тема. Ну, скачаешь ты 10 лишних мегабайт. Зато вообще не надо думать, как программа запускается.  

Единственный нюанс – кроссплатформенность. У нас в компании андроид-разработчики пользуются линуксом и iOS. Для линукса создать исполняемый файл легко – достаточно виртуалки. А вот для iOS нужен реальный мак. И в любом случае придется протестировать работу на других ОС, ведь в «кроссплатформенных» библиотеках могут вскрыться неожиданные ограничения.  

На какие изменения меня вдохновила эта статья 

Я этого совершенно не планировал, но: 

1. Снова порефакторил приложение: убрал зависимость от собственной внешней библиотеки и файл конфига.

2. Сформировал экзешники

3. Создал страничку на конфлюенсе со списком инструментов. В том числе рассказал, как вносить изменения и формировать новые exe – для этого я подготовил специальный скрипт.  

4. Добавил ссылку на анкету обратной связи

5. Переосмыслил подход к околорабочим пет-проектам

В будущем не хочется городить новые велосипеды на новых языках, пока не возникнет крайней необходимости. Скорее, развивать существующие. Большие проекты хочется воспринимать как другие рабочие активности: с определением проблем и целей на старте, декомпозицией, участием в общем планировании и своевременной оценкой результатов. Хотя я не жалею о полученном увлекательном опыте – люблю сам набивать шишки :)