Как организовать процесс учета и выдачи тестовых устройств
Работа отдела мобильного тестирования неразрывно связана с мобильными устройствами. Устройств огромное множество, и каждое обладает уникальными характеристиками: начиная от размера экрана и заканчивая количеством камер. Для обеспечения соответствующего качества разрабатываемых продуктов мобильный тестировщик должен проводить проверки на большом количестве девайсов, учитывая при этом специфику продукта, предпочтения пользователей и уникальность того или иного устройства.
Если у вас в компании всего несколько тестовых девайсов и с ними постоянно работают один-два тестировщика, то здесь подойдет самое простое решение: вики-страница или гугл-документ. Но если тестировщиков больше трех, начинаются проблемы. Так, когда в нашей команде было всего пять тестировщиков и мы вели вики-страницу, уже тогда я начал сталкиваться с некоторыми ограничениями такого подхода.
Например:
-
когда тестировщики брали устройство, они иногда забывали отмечать это на «Вики», и приходилось искать и выяснять, у кого какой девайс;
-
если за устройствами приходили тестировщики из других команд, нам приходилось отвлекаться, выдавать девайсы и фиксировать всё на «Вики».
А поскольку команд, которым периодически что-то нужно проверить на мобильном устройстве, в нашей компании много, то приходилось делать это достаточно часто.
Сейчас парк тестовых мобильных устройств компании насчитывает свыше 80. Ответственность за каждое из них лежит на мне, и, естественно, я хочу понимать:
-
у кого сейчас какой телефон или планшет;
-
какие из устройств сейчас свободны;
-
в каком они состоянии.
Я решил модернизировать подход к учету тестовых устройств и определил ряд требований к разрабатываемой системе. Так, система должна:
-
Хранить базу всех имеющихся у нас устройств, их технические характеристики и версии операционной системы.
-
Фиксировать устройство за конкретным сотрудником, если он берет девайс.
-
Списывать устройство с конкретного сотрудника, если он возвращает девайс.
-
Хранить историю по использованию устройств.
-
Обеспечивать постоянную зарядку и готовность к работе всех тестовых девайсов.
-
Иметь систему нотификаций для автоматического оповещения сотрудников о необходимости вернуть устройство в шкаф.
-
Иметь веб-интерфейс, где любой сотрудник может посмотреть, какие девайсы сейчас свободны, и забронировать себе необходимые.
Собрав инициативную группу тестировщиков мобильной команды, мы приступили к реализации плана.
Стенд тестовых устройств v.1.0 (СТУ-1.0)
-
Шкаф с несколькими полками, на которых располагались устройства.
-
Рядом висел планшет, к которому был подключен RFID -считыватель.
-
Для планшета нами было написано приложение, которое отвечало за процесс взятия/возврата устройств в шкаф.
-
У каждого устройства было свое место на полке, а на задней крышке располагался QR-код.
Алгоритм взятия/возврата устройства:
-
Тестировщик подходит, прикладывает пропуск к RFID-считывателю, в приложении открывается экран и включается передняя камера на планшете.
-
Тестировщик берет нужное ему устройство и сканирует QR-код с задней крышки. Таким образом отсканированное устройство фиксируется за конкретным сотрудником.
-
После того как тестировщик отсканировал одно или несколько устройств, он нажимает кнопку «Завершить», сессия пользователя закрывается и все устройства записываются на него.
-
Процесс возврата устройств схож: прикладываем пропуск, сканируем QR, возвращаем девайс в его ячейку, подключаем зарядный провод.
Данный вариант отлично себя зарекомендовал – у нас получился прозрачный процесс. Но, как говорится, нет предела совершенству.
Стенд тестовых устройств V.2.0 (СТУ-2.0)
Что улучшили:
1. Доступ к шкафу.
Проблема:
В версии СТУ-1.0 девайсы лежат в открытом шкафу, есть возможность взять их без сканирования. Хотя такой кейс достаточно редкий, но иногда случается, например, если в компанию пришел новенький и еще не знает правил работы со шкафом тестовых устройств. Плюс каждое утро ответственный должен открыть ключом шкаф, а вечером закрыть его, дабы не оставлять все устройства без присмотра.
Решение:
У версии СТУ-2.0 в роли замка выступает Promix-SM101.11 НЗ (Шериф-1), 24 В. Данный механизм соединен с Raspberry Pi, который в свою очередь общается с Mac Pro. Когда сотрудник прикладывает пропуск к считывателю, идет проверка пользователя в базе, и, если все хорошо, замок открывается, предоставляя доступ к широкому выбору устройств в шкафу. В остальных случаях шкаф закрыт.
Ограничение доступа к шкафу электронными средствами обеспечило:
-
безопасность самих устройств;
-
отпала необходимость в дежурном;
-
полностью исключена возможность взять устройство без фиксации данной активности.
2. Сканирование QR
Проблема:
В версии СТУ-1.0 необходимо отсканировать QR-код каждого взятого или возвращенного устройства, вернуть их в конкретные ячейки и подключить питание.
Решение:
В СТУ-2.0, когда сотрудник прикладывает пропуск, идет проверка в базе на соответствие, и, если система убедилась, что такой сотрудник есть в базе, дверь открывается и стартует сессия пользователя. А когда шкаф закрывается, сессия завершается и система опрашивает Raspberry Pi, что в них есть, сравнивает с тем, что было до начала сессии, а весь дифф списывает или записывает на пользователя.
Таким образом, пользователь берет или возвращает одно или несколько устройств без необходимости сканировать каждое из них. Плюс нет необходимости возвращать их в конкретную ячейку – достаточно просто установить устройство в свободный слот и подключить зарядным проводом или вытащить для себя необходимый девайс. А избавление от необходимости сканировать каждое устройство упростило процесс и сократило время на процедуру взятия или возврата устройства.
Почему именно Raspberry Pi?
В основе нашего шкафа стоит Mac Pro, но сам по себе он способен распознать только 18 устройств (1 USB Hub с 12 девайсами и 1 USB Hub с 6 девайсами). Мы решили сделать наш шкаф модульным, чтобы он был расширяем и взаимозаменяем в случае поломки. Теперь у нас несколько Raspberry Pi, к ним подключены USB Hub’ы с 10 устройствами в каждом, а уже они, в свою очередь через свитч, подключены к Mac Pro. Это позволяет контролировать все устройства в системе.
Опрашивая Raspberry Pi, система понимает, к какому хабу подключен тот или иной девайс, на какой полке и в какой ячейке он находится.
Схема выглядит следующим образом:
3. Веб-интерфейс
Кроме того, в версии СТУ-2.0 реализован веб-интерфейс, в котором можно посмотреть:
• какие устройства сейчас находятся в тестовом стенде;
• какие устройства находятся на руках у тестировщиков;
• технические характеристики устройств;
• история каждого девайса с информацией, кто его брал за последнее время;
• прочая служебная информация.
Это добавляет прозрачности работе с тестовыми устройствами – всегда понятно, что, где и у кого находится. Удобный способ выявления и оповещения должников.
Метрики
Появились метрики, которые дают возможность оценить загруженность того или иного устройства. Таким образом мы можем понимать, что пользуется большим спросом, и учитывать это при закупках новых девайсов.
4. Карма
Если пользователь часто нарушает правила, скажем не возвращает девайсы вовремя, у него изменяется значение «Карма». При достижении определенного порога шкаф больше не будет открываться данному пользователю, а администратор будет видеть таких должников и проводить с ними разъяснительную работу. Это позволяет точечно воздействовать на нарушителей и добавляет элемент геймификации.
Планы по улучшению
Сейчас проводим ресерч на тему раскатки тестовых билдов на все устройства или выборочно. Доделываем веб-интерфейс и готовим возможность бронирования устройств.
Итог
Разработанная нами система позволяет убрать ряд проблем с учетом, хранением и эксплуатацией тестовых устройств, собирать метрики, которые участвуют в принятии решений о дополнительных закупках устройств, избежать участия дополнительных сотрудников в процессе работы с тестовыми устройствами, тем самым освобождая время под более важные задачи. Ну и добавляет комфорта самим тестировщикам.
Опубликовано 28.12.2020
