Текст книги "Тестируем яблоко: смартфоны, планшеты и часы"

Составление тестовой документации

Тестовой документацией называется набор проверок, регулярно исполняемых в ходе релизного цикла. Если вы когда-либо интересовались авиацией, здесь довольно много аналогий. Если рейс – это релиз, то авиаконструкторы – это разработчики, пассажиры – пользователи, то экипаж воздушного судна – это тестирование, релиз-менеджмент и поддержка пользователей. Перед самым взлетом вы можете слышать, как по бортовой связи старший бортпроводник передает «внимание бортпроводникам – двери в положение armed, cross-check». Экипаж блокирует двери самолета и перепроверяет друг друга. Это всего лишь маленький фрагмент предполетных проверок, которые проходит экипаж.

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

Что из себя представляет чек-лист? Это перечень требуемых конфигураций самолета, для безошибочного выполнения полета. Пилоты – это, в первую очередь, люди. С каждым новым полетом все действия начинают выполняться «на автомате», но может случиться непоправимое, если, например, при посадке забудут выпустить шасси… Для того, чтобы это не допустить, и были разработаны чек-листы.

Например, при подготовке самолета к посадке, командир воздушного судна начинает зачитывать чек-лист:

– Шасси выпущены.

Второй пилот проверяет, запущены ли шасси. В случае утвердительного ответа КВС зачитывает следующий пункт.

– Посадочные огни включены.

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

– Закрылки выпущены…

Один читает, второй проверяет. Формального подхода здесь быть не должно.

Чек-лист по эксплуатации самолета

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

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

Таким образом, правильно написанная тестовая документация может убить сразу двух зайцев:

1. Сократить time to market – время от написанной документации до релиза функциональности на пользователей

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

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

Чек-листы

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

Чек-листы могут выполняться на разных уровнях. Можно написать чек-лист на компонент и проверять его каждый раз, когда его встраивают в новую страницу и видоизменяют, можно написать чек-лист на раздел приложения. При должной подробности чек-лист на компонент будет иметь 10—15 пунктов, чек-лист на раздел – до 1000. Зачастую нет смысла проходиться чек-листом по компонентам по отдельности, также не представляется возможным постоянно проверять раздел приложения (найдите человека, который согласится прогонять чек-лист на 1000 пунктов каждую неделю!), поэтому предлагаем использовать что-то посередине.

Попробуйте написать чек-лист на страничку отправки денег, где есть два поля ввода – у первого написано «Сумма оплаты – до 1000 рублей», а над вторым «Номер карты (строго 16 цифр)». Кроме того, на странице есть кнопка Отправить. С учетом различных тестовых данных и особенностями платформы у вас может получиться 30—50 пунктов.

Пункты чек-листа должны трактоваться однозначно. Предположим, у нас есть функция аудио/видеозвонков, и мы пишем чек-лист, чтобы покрыть ее проверками. Мы, конечно, можем написать один пункт «Включение микрофона», но лучше будет его разделить на два и проверять отдельно включение микрофона в аудиозвонке и в видеозвонке, так как использоваться будут разные микрофоны.

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

Преимущества:

1. Чек-лист легко читается;

2. По чек-листу быстро тестировать: в тест-кейсе нужно отмечать статус каждого шага, в то время как в чек-листе достаточно одной строчки;

3. Чек-лист – источник результатов для отчёта: можно быстро посчитать сколько проверок выполнено, в каком они статусе, узнать количество открытых репортов;

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

Недостатки:

1. Неопределенность тестового набора: каждый тестировщик выполняет пункт чек-листа по-своему;

2. Неопределенность тестовых данных;

3. Недостаточность детализации;

4. Сложнее обучить начинающих сотрудников: пункты чек-листа чаще абстрагируются от конкретных элементов интерфейса и описывают то, что нужно сделать;

5. Чек-лист менее эффективен для начинающих тестировщиков, лучше использовать тест-кейсы.

Тест-кейсы

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

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

Как правило, один тест-кейс описывает небольшую последовательность действий с одним конкретным результатом. Например, успешную авторизацию на сайте для конкретного пользователя или добавление одного конкретного товара в корзину.

Одна из самых популярных test management system – TestRail

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

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

Подбор девайсов для тестирования

Очень часто в профессиональном сообществе появляются вопросы «Что чаще всего спрашивают на собеседованиях?», и ответ на него максимально банальный – чаще всего на собеседованиях спрашивают, какие девайсы тестировщик возьмет себе для тестирования приложения.

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

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

Шаг 1 – операционная система

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

Например, по состоянию на середину 2023 года приложение ВКонтакте поддерживает девайсы с операционной системой не старше iOS 14. В таком случае, для тестирования ВКонтакте нужно было бы подобрать хотя бы один девайс на iOS 14, iOS 15 и iOS 16 – от самой старшей до самой новой операционной системы. В процессе тестирования вы неоднократно будете сталкиваться с ситуацией, когда баг воспроизводится только на определенной оси – и не взяв в тестирование каждую ось, вы рискуете пропустить ОС-специфичный баг, который попадет на пользователей.

Вывод – берем хотя бы по одному девайсу от самой новой до самой старой поддерживаемой оси.

Шаг 2 – разные экраны

Каждый год Apple так или иначе немного модернизирует характеристики экрана на презентации нового iPhone или iPad. Но брать для тестирования по девайсу, выпущенному за каждый год, избыточно – достаточно изучить матрицу экранов от Apple:

Все экраны от Apple, в зависимости от модели девайса и года выпуска, входят в группу @1x, @2x или @3x, где число означает количество рядов пикселей в точке – чем выше значение, тем больше деталей вмещает одна точка. Соответственно, чем больше значение, тем выше качество изображения на экране.

Как мы видим, разрешение @1x было только у самых старых моделей айфонов, такие уже давно не в ходу, и тестировать на них не надо (а зачастую и невозможно). А вот по одной модели @2x и @3x взять стоит.

Также нужно иметь в виду, что с iPhone X появился первый девайс с челкой (notch), поэтому надо предусмотреть, чтобы в подборке был и челочный, и бесчелочный девайс.

Шаг 3 – не только лишь айфоны

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

Если и Apple Watch – ещё лучше, тоже возьмем их в набор.

Шаг 4 – посмотрите статистику вашего приложения

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

По возможности учитывайте, какие девайсы ваши пользователи используют чаще всего, и старайтесь включать популярные девайсы в пул для тестирования. Например, один из самых популярных на текущий момент телефонов – iPhone 11.

Режим разработчика

Еще один очень частый вопрос на собеседовании – рассказать, как включить Developer Mode на девайсе, и какой самый главный инструмент в работе тестировщика там есть. Скажете, простой вопрос для опытного инженера по тестированию?

Далеко не всегда! Довольно небольшой процент тестировщиков может ответить, что чаще всего в Developer Mode используется Network Link Conditioner, а уж как включить знают и того меньше человек – активировать Режим разработчика приходится нечасто, поэтому не все помнят порядок действий.

В общем, знание ответа на этот вопрос дает огромный плюс в копилку мнения о кандидате, поэтому давайте разберемся, что такое Developer Mode, как его включать и что такое Network Link Conditioner.

Как включить Developer Mode

Чтобы активировать Developer Mode, придется в определенном смысле «доказать» айфону, что у вас есть хотя бы некоторые пререквизиты к этому в виде компьютера на операционной системе MacOS. Дело в том, что настройки в Developer Mode предназначены только для профессионалов, понимающих значение своих действий, так как неосторожные действия могут вызвать нарушение приватности девайса и сделать уязвимее перед угрозами. Так как невозможно заниматься разработкой приложений на iOS без компьютера с macOS, разработчики Apple добавили обязательный шаг – подключение девайса к Маку.

Если у вас на компьютере нет Xcode – основного приложения, в котором идет разработка iOS-приложений – установите его с официального сайта Apple: https://developer.apple.com/xcode/

Подключите девайс к Маку и дайте все запрашиваемые разрешения на айфоне (потребуется ввести пароль от девайса).

После этого откройте приложение Xcode и в верхней панели откройте Window – Devices and Simulators.

Убедитесь, что ваш девайс отображается в списке Devices – откроется примерно такое меню. Даже если будет написано, что возникли ошибки в процессе подготовки девайса к разработке, это не помешает активировать Режим разработчика.

Далее на девайсе откройте Настройки – Конфиденциальность и безопасность – Режим разработчика – включить. После этого появится алерт с предложением перезагрузить девайс для применения настроек, перезагружаем.

После перезагрузки подтвердите включение Режима разработчика.

Все готово – осталось только открыть Настройки и найти точку входа в инструменты разработчика.

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

Network Link Conditioner

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

Прежде всего, откройте Настройки – Developer – Network Link Conditioner (ближе к началу списка).

Перед вами откроется список режимов ограничения сети – так вы сможете сымитировать скорость, стабильность и ширину канала, например, при 3G или Edge-соединении, либо даже настроить потери 100% (это очень полезная настройка, чтобы проверить, как приложение работает с таймаутами при отсутствии сети).

Чтобы включить выбранную настройку ограничений, активируйте свитчер Enable. После тестирования не забывайте отключать Network Link Conditioner – сколько же раз тестировщики пользовались своим девайсом после окончания работы и никак не могли понять, почему сегодня так медленно работает интернет, совсем забывая, что недавно для работы они включали Network Link Conditioner.

Чтобы выбрать желаемый режим, нажмите на него (чтобы режим заработал, надо активировать свитчер Enable). Нажмите значок информации около режима, чтобы увидеть больше информации о нем:

Редактировать пресеты нельзя, но можно сделать копию пресета и выставить собственные параметры. Для этого нажмите Duplicate Profile, введите нужные значения и нажмите Сохранить.

Итак, сегодня мы научились включать Developer Mode и самый полезный инструмент в нем, Network Link Conditioner.

Permissions

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

Как обеспечивать безопасность персональных данных пользователя, когда он пользуется этими приложениями? Как обеспечить пользователя выбором, отправлять ли в приложение данные о посещенных страницах, то есть куки, позволять собирать данные с микрофона, камеры, из Галереи, из книги контактов или с датчика GPS? Для этого были придуманы пермишены.

Это небольшое модальное окно, которое возникает при первом запросе приложения к чувствительным данным после установки. При согласии пользователя данные предоставляются полностью или ограниченно, при отказе – iOS блокирует попытки приложения попасть туда. Приложения обычно самостоятельно обрабатывают кейс повторного запроса после отказа пользователя – к примеру, рисуют заглушку c диплинком в пункт этого приложения в нативном приложении «Настройки».

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

1. NSPhotoLibraryAddUsageDescription – Приложение может добавлять фотографии в галерею

2. NSPhotoLibraryUsageDescription – Приложение имеет доступ к галерее

3. NSCameraUsageDescription – Приложение имеет доступ к камере

4. NSLocationAlwaysUsageDescription – Приложение имеет постоянный доступ к геолокации

5. NSLocationWhenInUseUsageDescription – Приложение имеет ограниченный доступ к геолокации – только когда оно активно (находится в foreground)

6. NSLocationUsageDescription – Неактуально, нужно использовать одно из двух выше

7. NSContactsUsageDescription – Приложение имеет доступ к списку контактов

8. NSCalendarsUsageDescription – Приложение имеет доступ к календарю и может добавлять или изменять события в нём

9. NSRemindersUsageDescription – Приложение имеет доступ, может добавлять или изменять пункты в приложении Напоминания

10. NSHealthShareUsageDescription – Приложение имеет доступ к данным из приложения Здоровье

11. NSHealthUpdateUsageDescription – Приложение открывает доступ к своим данным для приложения Здоровье

12. NFCReaderUsageDescription – Приложение имеет доступ к NFC-считывателю

13. NSBluetoothPeripheralUsageDescription – Приложение имеет доступ к Bluetooth-устройствам

14. NSMicrophoneUsageDescription – Приложение имеет доступ к микрофону

15. NSSiriUsageDescription – Приложение может создавать и обрабатывать кастомные команды Siri (Intents, не путать с Shortcuts)

16. NSSpeechRecognitionUsageDescription – Приложение может использовать распознавание голоса

17. NSMotionUsageDescription – Приложение может использовать гироскоп и акселерометр устройства

18. NSVideoSubscriberAccountUsageDescription – Приложение имеет доступ к аккаунтам стриминговых сервисов (только для tvOS)

19. NSAppleMusicUsageDescription – Приложение имеет доступ к данным аккаунта Apple Music

20. NSFaceIDUsageDescription – Приложение может использовать Face ID

Push-уведомления

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

Мы не можем отправлять уведомления просто на устройства: тогда пуш получат все, и случится что-нибудь подобное скриншотам ниже.

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

На первый взгляд схема покажется сложной, однако стоит один раз в ней разобраться, чтобы понимать основы.

Первичная настройка и получение разрешения на отправку пушей

1. При создании приложения мы регистрируем APNS ключ от нашего аккаунта разработчика.

2. Настраиваем наш бэкенд для взаимодействия с APNS

3. В приложении первично настраиваем работу с уведомлениями, добавляя энтайтлмент (разрешение) aps-environment в код.

4. При первом запуске приложения запрашиваем разрешение у пользователя на отправку через пермишен класса UNUserNotificationCenter и получаем токен устройства методом registerForRemoteNotifications

5. После этого iOS устройство генерирует и возвращает Push токен вашему приложению через метод didRegisterForRemoteNotificationsWithDeviceToken в классе UIApplicationDelegate.

Отправка пушей с бэкенда в APNS

1. Наш бэкенд генерирует JSON со всей информацией, которую мы хотим видеть в уведомлении, и формирует запрос в APNS, используя APNS ключ, зарегистрированный ранее и полученный Push-токен устройства.

2.Запрос отправляется в APNS через TLS соединение, APNS распознает связанный Push-токен и доставляет уведомление в соответствующее устройство iOS.

Обработка пушей на устройстве

1. Когда уведомление долетает до устройства, iOS передает его в ваше приложение.

2. Если приложение запущено, уведомление обрабатывается в методе didReceiveRemoteNotification класса UIApplicationDelegate.

3. Если приложение не запущено, уведомление будет отображаться как стандартное iOS уведомление в шторке Notification Center или на экране блокировки.

Silent-пуши

Частенько даже опытные тестировщики теряются с ответом на вопрос, что такое сайлент-пуши, предполагая, что это обычный пуш, который придёт на устройство беззвучно. Silent-пуши – разновидность Push-уведомлений, которая, однако, используется не для отображения видимой информации для конечного пользователя, а для фонового обновления информации в приложении, которое выключено. Чтобы обновить информацию, технически вы «пробуждаете» ваше приложение из неактивного состояния и отправляете обновление. Это может быть использовано для обновления информации с сервера.

Технически payload (нагрузка) для обычных пуш-уведомлений и silent пуш-уведомлений в основном отличается тем, что silent пуш-уведомления не содержат информацию, которая будет отображаться в уведомлении на устройстве пользователя. Они используются исключительно для передачи данных и активации приложения в фоновом режиме.

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

С другой стороны, payload для silent пуш-уведомлений обычно содержит только необходимые данные, которые приложение должно обработать. Пример silent пуш-уведомления:

В приведенном примере ’aps’: {} является пустым, поскольку у silent пуш-уведомления отсутствует отображаемое содержимое. Вместо этого, полезная нагрузка содержит дополнительные данные, которые могут быть необходимы приложению для обработки или выполнения определенных задач в фоновом режиме.

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