6 разочарований при создании командного инструмента. python.. python. автоматизация ручного тестирования.. python. автоматизация ручного тестирования. автоматизация тестирования.. python. автоматизация ручного тестирования. автоматизация тестирования. Блог компании Контур.. python. автоматизация ручного тестирования. автоматизация тестирования. Блог компании Контур. командные инструменты.. python. автоматизация ручного тестирования. автоматизация тестирования. Блог компании Контур. командные инструменты. ошибки новичков.. python. автоматизация ручного тестирования. автоматизация тестирования. Блог компании Контур. командные инструменты. ошибки новичков. Тестирование веб-сервисов.

Привет! Меня зовут Миша, я тестировщик из Контура, а именно – из Контур.Маркета. И в роли тестировщика я столкнулся со множеством однообразных действий, которые хочется автоматизировать. Быстро надоело по 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. Переосмыслил подход к околорабочим пет-проектам

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

Автор: misha_voyager

Источник

Rambler's Top100