Доклад
Не просто покликать: как собрать инструменты для ручного мобильного тестирования — от Bash-скриптов до ИИ
Зал 3
Я занимаюсь мобильным тестированием с 2014 года. За это время железо девайсов стало быстрее, Android стал сложнее, а многие привычки в тестировании почти не изменились.
Чтобы установить сборку, тестировщик хранит Bash-скрипт. Чтобы поменять нужную настройку, долго ищет ее в телефоне. Логины и пароли лежат в заметках. Наборы тестовых данных хранятся где придется или не хранятся совсем. Список устройств команда ведет в Google-таблице или Confluence. Иногда ради одной простой команды приходится устанавливать SDK Platform Tools или целую Android Studio.
Каждая из этих проблем сама по себе кажется небольшой. Но за день из них складывается много лишних действий. Еще хуже, когда найденный баг уходит разработчику без части важных данных. Не указали модель девайса. Забыли номер сборки. Не записали, была ли включена темная тема. Не сохранили данные, на которых сломалась форма ввода. Логи начали собирать уже после падения.
Когда-то я пытался решать эти задачи по отдельности. Для одной писал скрипт, для другой сохранял команду, для третьей делал заметку. В какой-то момент стало понятно, что проблема не в отсутствии еще одного скрипта. Нужен простой инструмент для всей команды, который помогает не потерять то, что происходило во время проверки. Почему бы тогда его не собрать?
В докладе мы разберем несколько обычных ситуаций. Подготовим устройство, одной кнопкой поменяем язык, тему и сеть, установим APK и узнаем точную версию сборки. Отзовем разрешения, заранее включим logcat и сохраним стек после падения. Поработаем с тестовыми данными и сохраним их для следующей проверки. Поговорим о тестовых аккаунтах и паролях, которые обычно копипастят из заметок вручную. Покажу, как можно хранить библиотеку устройств, чтобы у вас был честный ответ на вопрос, на каких устройствах команда действительно может проверить приложение.
В финале мы посмотрим, как это все можно делать с помощью MCP-интерфейса, через который LLM может управлять устройством, собирать логи и готовить отчет.
Доклад о том, как превратить «у меня упало или не работает» в понятную для разработчика историю, с которой можно сразу начинать исправлять дефект.