Home

Автор: Эдуардо Фишер дос Сантос (Eduardo Fischer dos Santos))
Оригинал статьи
Перевод: Ольга Алифанова

Когда я начинал работать тестировщиком, все было просто. Я тестировал веб-приложения всего лишь в двух браузерах. Я мог ожидать, что абсолютное большинство наших клиентов использует Windows. Мне надо было учитывать только два вида ввода – мышь и клавиатуру. Нет, я не говорю, что тестировать веб-приложения легко; я абсолютно точно так не думаю. Но когда я перешел в мобильное тестирование, внезапно мне пришлось иметь в виду множество новых переменных, которых я не ожидал.

Каждую неделю я тестировал приложение до изнеможения. У нас были ручные тесты, юнит-тесты, статический анализ, E2E, и каким-то образом мы каждую неделю получали сообщение в Slack-канал о том, что у некоторых пользователей возникают проблемы. Иногда речь шла о производительности (например, экран слишком долго загружался), а иногда клиент просто сообщал, что приложение показывает черный экран, и им невозможно пользоваться. Команда безуспешно пыталась воспроизвести баг – как-то он всегда ухитрялся от нас скрыться.

Почему воспроизводить мобильные баги так трудно?

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

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

Представьте, что вместо веб-приложения у нас мобильное приложение. Какие вопросы надо задать? "Samsung или iPhone? Какая версия ОС? Не низок ли заряд вашей батареи? Пробовали ли вы использовать Touch ID или Face ID для авторизации? Не меняли ли вы телефоны в последнее время? Включен ли авиарежим?" Количество переменных только по отношению к состояния телефона может шокировать. Вы всегда недоумеваете, какая из них связана с багом и необходима для его воспроизведения.

Все не так плохо: фермы устройств

Несмотря на то, что нам немного затруднительно воспроизводить баги и предсказать, где они могут появиться, все не так ужасно, как в тестировании космических или авиационных систем. В этой области нам пришлось бы предсказывать проблемы, возникающие из-за температуры, скорости ветра, радиации, и других переменных. Мы не можем просто взять пару-тройку самолетов и прогнать наши тесты на реальных машинах; однако нам доступны симуляторы. Тестировать мобильное приложение все же попроще. Мы можем арендовать устройства у Google, Amazon или Microsoft для создания фермы устройств.

Ферма устройств – по сути, группа из множества устройств (телефонов, компьютеров или даже медицинского оборудования), взятая в аренду или приобретенная в собственность, виртуальная или реальная. При помощи этих ферм наше ПО можно тестировать на большом разнообразии железа. Покупка множества смартфонов для тестирования – это дорого как в смысле денег, так и в смысле рабочих рук, которые будут настраивать эту систему и управлять ей. Естественная альтернатива – брать их в аренду по необходимости через облачные платформы.

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

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

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

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

Использование ферм устройств для обнаружения багов до деплоя

Выше я объяснил, как можно использовать фермы устройств для воспроизведения багов. Однако мы хотим не просто воспроизводить баги прода. Мы хотим избежать их изначального попадания на прод. Конечно, прогон набора ручных тестов на одном устройстве уже занимает определенное время, поэтому использовать весь набор на каждом устройстве неразумно. Нам нужно другое решение – и это, конечно, запуск автотестов на нескольких устройствах, в идеале одновременно.

Безусловно, кажется, что прогон наших CI тестов / тестов разработки всего на одном устройстве – уже нетривиальная задача. На многих устройствах это не задача, а левиафан. Конечно, вам придется столкнуться с решением множества новых и неизвестных проблем, если сравнивать с тестированием на одном устройстве.

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

Более того, вам нужно будет осторожнее обращаться с состоянием системы. Предположим, вы делаете приложение для покупки билетов в кино. Если множество устройств попытаются купить одни и те же места, тесты будут падать. Однако если правильно обращаться со всеми этими сложностями, у вас будет очень надежная тест-машина.

Заключение

Фермы устройств решали столько крупных проблем в мобильном тестировании, что стали незаменимыми для эффективной стратегии тестирования мобильных приложений. Без них единственной альтернативой будет тестирование на одном-единственном устройстве единовременно, что означает, что мы можем "гарантировать" качество только для него. Несмотря на то, что внедрение и настройка процессов и наборов тестов для работы с несколькими устройствами – непростые задачи, невозможно убедить всех до единого пользователей пользоваться только одной маркой смартфонов.

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

Обсудить в форуме