Введение
Задумывались ли вы, как часто даже опытные тестировщики, изучая новые рабочие инструменты, думают про себя: «Если бы я только знал это раньше…»?
Авторы книги — Мария Осина и Роберт Гадеев — в процессе развития по пути инженеров по тестированию и сами постоянно сталкивались с этой проблемой: если полезная информация по тестированию где-то и есть, то она или разрознена по разным материалам, курсам, учебникам и статьям, или находится под закрытым доступом.
Наше искреннее убеждение заключается в том, что информация хочет быть свободной — так однажды сказал американский писатель Стюарт Бранд на The Hackers Conference в 1984 году, и мы полностью разделяем это мнение. Систематизируя знания, которыми мы сами овладели за время работы в топовых IT-компаниях, мы хотели, чтобы и другие инженеры по тестированию смогли применять полученные умения и улучшать процессы в своих компаниях, и в конечном результате менять целую индустрию к лучшему. Мы снабдили книгу как солидной базой по теории тестирования, так и большим количеством практических примеров из собственного профессионального опыта — теория без практики мертва, практика без теории слепа.
Эта книга предназначена для профессионалов в сфере тестирования и содержит всю самую необходимую информацию об инструментах и лучших практиках, которые использует каждый инженер по тестированию iOS в своей работе. Благодаря этой книге, вы не только лишь сможете начать тестировать значительно быстрее, эффективнее и качественнее, но и повысите свою цену на рынке труда — согласитесь, в такие времена всегда важно владеть самыми актуальными хард-скиллами, чтобы не остаться за бортом IT-индустрии.
В первой главе мы обобщили важнейшие знания и умения, которыми должен обладать любой тестировщик — без этой базы не получится выстроить качественные процессы тестирования в компании и невозможен дальнейший профессиональный рост. Как правильно составлять баг-репорты, чтобы разработчики могли потратить как можно меньше времени на вникание в суть ошибки; как вести качественную тестовую документацию; как подбирать девайсы для тестирования, чтобы не пропустить ни один критический баг, и многие другие навыки и знания вы получите, изучив эту главу.
Инженеры по тестированию также обязательно оценят главу про тестирование на watchOS с уникальным содержанием — несмотря на то, что эта платформа идет рука об руку с iOS, по сей день не было выпущено ни одной книги, в которой были бы представлены методики тестирования приложений на часах от Apple. Также вы узнаете об уникальной методике тестирования RADIUS, которая гарантирует обширное покрытие тестируемой функциональности приложения на Apple Watch, удовлетворенность пользователей, а также своевременное нахождение багов в приложении, что значительно сократит время на тестирование и разработку функциональности, позволив сэкономить финансовые и временны́е ресурсы компании.
Особое место в книге мы выделили инструменту Charles — программе-анализатору сетевого трафика, настоящему «швейцарскому ножу» в области тестирования, которым вы, без сомнения, будете пользоваться буквально каждый день. Мы свели воедино все инструменты, умение пользоваться которыми поможет решать рабочие задачи в разы эффективнее и быстрее.
Опытных тестировщиков, желающих и дальше углубляться в процессы тестирования и релизного цикла в целом, заинтересуют главы про Xcode (главный инструмент разработки и отладки мобильных приложений на iOS, iPadOS и watchOS), инструменты дистрибуции мобильных приложений и постепенной раскатки функциональности. Теоретическая база и значительный опыт, полученный в топовых российских IT-компаниях ВКонтакте и Яндекс, а также в международных компаниях, дает авторам возможность делиться с коллегами самым передовым и обширным опытом в использовании этих инструментов и связанных с ними лучших практиках.
Глава 1: Важные знания и умения для инженера по тестированию
Несмотря на большое количество бесплатных и платных курсов по освоению профессии инженера по тестированию, которые гарантируют освоение компетенций вплоть до уровня middle+ после прохождения трехмесячных курсов, есть кое-что, чему они научить не могут. Существуют некоторые черты характера, благодаря которым работа идет продуктивнее и кажется легче. Для начала попробуем их сформулировать.
Этот список не означает, что без этого хорошим инженером по качеству не стать. Все возможно, просто вам потребуется чуть больше упорства и времени. Джордж Бернард Шоу говорил «То, что мы называем успехом, в действительности является компенсацией всякого человека, который обделен талантом.» Так что в любом случае дерзайте и стремитесь.
Умение не идти на неоправданный риск
Когда идет работа с продуктом, который увидят пользователи, любая ошибка может стоить компании ресурсов. Маленькая ошибка, к примеру, неверно покрашенная кнопка, может повлиять на UX и уводить пользователей не туда, куда его должен вести интерфейс. Критическая ошибка может вообще понести за собой инцидент или стоить кому-то жизни, в такой ситуации умение отстоять отмену релиза или безотлагательное исправление ошибки, умение отметать любой процент риска дорогого стоит. История знает такие случаи.
Огромное облако в небе появилось после взрыва двух миллионов литров ракетного топлива. На земле в этот момент еще никто не понимал, что произошло. Персонал НАСА был в шоке. Сотрудники еще долго не могли объяснить произошедшее, и только два человека могли адекватно объяснить, что произошло, мало того, они предполагали до запуска, что он может обернуться трагедией. Они оба наблюдали за запуском по телевидению из штата Юта.
Роджер Бойсджоли работал старшим инженером компании «Мортон-Тиоколь», которая выступала подрядчиком по части проектирования шаттла, а также непосредственной разработки твердотопливных ракетных ускорителей. Вместе со своим начальником, Бобом Эбелингом, они находились в офисе компании. Боб позвал Роджера понаблюдать за запуском по ТВ, тот отказался — «Нет, я не хочу на это смотреть». Позже он признался, что отказался потому, что знал, чем это может закончиться.
За день до запуска Боб и Роджер шесть часов по телемосту убеждали инженеров НАСА отложить запуск корабля из-за того, что температура во Флориде опустилась ниже нуля, на что конструкция корабля не была рассчитана. Но топ-менеджмент «Мортон-Тиоколь» не беспокоился об этом. Они разрешили запуск и порекомендовали подопечным не паниковать. В общем, сказали то, что очень хотели услышать их коллеги из НАСА.
В день запуска, 28 января 1986 года Эбелинг все же уговорил Бойсджоли вместе посмотреть запуск. Во время обратного отчета инженеры взялись за руки, но когда они увидели, что шаттл оторвался от стартового стола и начал набирать высоту, они расслабились. «К счастью, пронесло!» — сказал Бойсджоли. Однако их спокойствие длилось чуть больше минуты — на экране показалось огромное белое облако дыма, что нельзя было назвать штатной ситуацией. «Потом настала тишина, — вспоминает Бойсджоли. — Казалось, все в этом мире замолкло. Я пошел в свой кабинет и долго стоял, уставившись в стену, пытаясь прийти в себя…».
Весной 1986 года Роджер выступил свидетелем перед следствием, которое изучало причины трагедии. Его показания обескуражили топ менеджмент «Мортон-Тиоколь», потому что он обнародовал документы, о которых внутри предпочли бы забыть, а снаружи не хотели бы знать. Чуть позже начальство намекнуло ему, что его карьерный путь в этой компании завершен.
Что же стало причиной трагедии «Челленджера»? Конструкторский просчет. Проблемной деталью были резиновые кольца, герметизирующие швы деталей боковых ускорителей. Во время запуска шаттла одно из таких колец вблизи соединения с внешним топливным баком разрушилось. В баке находятся кислород и водород в жидком виде, и когда он разрушился, вещества смешались, и произошел взрыв. Хотя проблема была еще на стартовом столе, при начале работы двигателей стык сегментов разгерметизировался, открыв путь горящим газам вовне. Из-за холодной погоды резиновое кольцо уплотнения уже не было эластичным и не обеспечило изоляцию, как в предыдущих запусках. Утечка прожгла место соединения ускорителя и топливного бака. У шаттла был шанс пережить запуск, потому что продукты горения топлива закупорили пробоину, но сильный порыв ветра выбил пробку, и газ начал бить во внешний топливный бак, пробив его стенку. Никто из персонала не заметил, что работа двигателей изменилась. Когда двигатели включились на полную мощность в верхних слоях атмосферы, ускоритель провернулся на верхнем креплении, ударил по баку, и его содержимое воспламенилось. Сам шаттл разрушился не от огня, а от колоссальных перегрузок в 20 атмосфер, в 4 раза превышающих максимально допустимое значение. Шаттл буквально разорвало, а твердотопливные ускорители продолжили лететь сами по себе.
За год до рокового дня Роджер прибыл на мыс Канаверал, чтобы провести рабочую инспекцию, и уже тогда обнаружил, что эти заслонки могут стать проблемой. Изучая части ракетоносителя, примененные в предыдущем запуске, он понял, что только благодаря второму, страховочному кольцу уплотнителя все произошло без проблем, первое не сработало.
«Ведь тогда только чудом не произошло взрыва», — вспоминал потом Бойсджоли. Свои сомнения он высказал инженерам НАСА, те задокументировали его выводы, однако все было забыто. Пока Бойсджоли пытался добиться от начальства реакции, народу показали экипаж новой миссии «Челленджера», которая полетит следующей зимой. В многонациональную компанию впервые попал гражданский пассажир, учительница Криста Маколифф, которая одержала победу в большом конкурсе, обойдя 11 тысяч других участников.
Запуск шаттла откладывали дважды — сначала он должен был стартовать 25 января, но тем утром была нелетная погода. Во второй раз, когда экипаж занял свои места, персонал НАСА обнаружил, что основной люк не может закрыться из-за сорванной резьбы шурупа, удерживающего ручку люка. Запуск снова отложили. В третий раз, с полудня 28 января на мысе Канаверал начало заметно холодать, и пусковой команде нужна была консультация с инженерами. В шесть вечера после внутренних совещаний НАСА обратились с «Мортон-Тиоколь» с вопросом «Можно ли осуществлять запуск при температуре пять градусов ниже нуля по Цельсию?» Начальство подрядчика подтвердило, однако по регламенту нужно связаться с инженерами космического центра в Хантсвилле, штат Алабама.
Те перезвонили уже руководству «Мортон-Тиоколь», чтобы обсудить текущее положение дел, и в этом обсуждении участвовал и Роджер Бойсджоли. Он твердо настаивал на отмене полета, поскольку уплотнители не были рассчитаны на температуру ниже +12 градусов, однако его доводы не выглядели исчерпывающе для его коллег, к тому, же, все уже устали переносить запуск по разным причинам и мечтали, чтобы он наконец состоялся. НАСА выразили сомнения по поводу обоснованности аргументов Роджера, однако согласились отложить полет. Но в этот момент в переговоры вступает один из четырех вице-президентов компании «Мортон-Тиоколь», который попросил еще пять минут на обсуждение вопроса и принятие окончательного решения. Эти пять минут превратились в тридцать, и, к сожалению, менеджеры-оптимисты согласовали запуск в этот же день. НАСА запросили документальное подтверждение решения, и получили факс.
Всё остальное — уже известная всем печальная история.
Роджер до сих пор не может забыть ужасные события, связанные с катастрофой «Челленджера». Он сожалеет, что не предпринял больше мер, чтобы предотвратить запуск. Бойсджоли думает, что даже если бы он обратился к специалистам или СМИ, трудно было бы убедить их остановить запуск. Все равно они бы связались с НАСА, и там им, вероятно, сказали бы, что нет причин для паники.
Боб Эбелинг скончался в 2016 году. Его дочь, которая также работала в НАСА, говорит, что в день трагедии отец был очень расстроен. Он заявил, что мог бы остановить запуск только угрожая пистолетом и взяв в заложники руководство. Эбелинг, который работал в НАСА около 20 лет, ушел из организации через несколько месяцев после катастрофы. Дочь также отметила, что за несколько недель до смерти Боб перестал обвинять себя в катастрофе после радиопередачи, посвященной 30-летию трагедии.
Готовность к обучению и самообучению
В деле обеспечения качества, как и во всей сфере информационных технологий, поговорка «Век живи — век учись» является правилом игры, а не просто присказкой. Помимо техник тест-дизайна, которые непосредственно являются рабочим инструментом тестировщика, мы должны постоянно держать руку на пульсе обновлений операционных систем, которые тестируем и в которых работаем, языков программирования, библиотек и фреймворков, которые используем для написания автотестов, TMS (test management system), в которых храним свою тестовую документацию, CI/CD платформы и сервера, которые позволяют нам разгружать локальные мощности от постоянных сборок и прогонов автотестов.
В нашей команде есть традиция собираться и смотреть две ежегодные презентации Apple — WWDC (Worldwide Developers Conference) и Keynote, на котором показывают новый iPhone. Для нас эти события похожи на финал кубка мира по футболу, Евровидение или Superbowl, или даже празднование Нового Года. После WWDC обычно идет неделя воркшопов для разработчиков от инженеров команды Apple, на которых они более подробно рассказывают о новшествах своей платформы. Мы также не пропускаем эти мероприятия, потому что они дают нам возможность узнать о самых последних тенденциях и инструментах, которые помогут нам повысить качество нашей работы, а также подготовить наши продукты к обновлению операционки, а наши CI/CD сервера к сборке на новом SDK.
Умение работать в команде и эффективно коммуницировать с другими членами команды
Все в компании работают над развитием и процветанием продукта. Для эффективной работы постоянно придумываются, внедряются, переосмысливаются, оптимизируются и уничтожаются процессы — регламенты, позволяющие всем работать максимально продуктивно и слаженно. Процессы можно сравнить с производственной линией на фабрике — там из сырья спустя несколько манипуляций получается продукция, так и в IT-сфере — из идеи получается готовая фича, радующая пользователей. Процессы с изменением вводных (новые инструменты для работы, новые люди пришли, старые ушли, etc.) могут страдать, и каждый специалист может что-то сделать для их улучшения — иногда даже простой чат-бот, который присылает результаты прогона автотестов, экономит огромное количество человеко-часов всем участникам релиза.
Теперь рассмотрим более приземленные пункты, которым довольно просто обучиться — это та необходимая матчасть, которая облегчает работу тестировщикам в любом проекте.
Составление баг-репортов
Качественный баг-репорт должен состоять из нескольких базовых пунктов:
1. Заголовок
2. Окружение
3. Приоритет и серьезность
4. Шаги воспроизведения
5. Ожидаемое поведение
6. Фактическое поведение
7. Сопроводительные аттачи (скриншоты/скринкасты)
Пойдем по порядку.
Заголовок
Это первое, что видит любой пользователь таск-трекера. Заголовок должен быть написан так, что прочитав, становится понятно, в чем проблема. В идеале ваш заголовок должен как можно короче ответить на 3 вопроса: Что? Где? Когда?
Что? Пропадает кнопка входа.
Где? В форме регистрации — иногда вопрос Где? становится избыточным, и его можно опустить.
Когда? При нажатии на поле ввода пароля.
Нельзя расписывать заголовок более чем на одно среднее предложение, это только тормозит работу — и вашу, и того, кому придется читать заголовок. На планированиях и грумингах менеджеры вместе с разработчиками разбирают завалы задач, выбирая, что взять в работу в ближайшее время, а что может подождать. Никто не любит эти встречи (поверьте!), так что пишите заголовки настолько коротко и понятно, насколько можете.
Окружение
Сюда входит все, что помогает локализовать ваши условия воспроизведения бага. На каком девайсе вы поймали ошибку? Какая iOS у вас установлена? Какая версия приложения используется? Если баг сетевой, какую сеть вы использовали? Может влиять и оператор связи, поэтому, укажите его, если подозреваете, что в этом кроется причина ошибки. Распишите как можно подробнее, и разработчику не придется задавать вам вопросы поверх вашего баг-репорта.
К окружению мы также относим предусловия. В предусловиях описываются действия, которые нужно выполнить, и параметры, которые нужно применить перед выполнением шагов, позволяющих воспроизвести баг. Это описание не имеет какого-то четкого формата, просто придерживайтесь логического порядка. Многие пишут предусловия отдельным пунктом, но мы предпочитаем объединять их с окружением для упрощения.
Приоритет и серьезность
Приоритет является атрибутом, определяющим необходимую скорость устранения бага.
Первоначально приоритет бага определяется инициатором, но затем он корректируется менеджером продукта. Именно менеджер имеет общее представление о тестируемой системе и понимает, насколько срочно нужно исправить тот или иной баг.
Виды приоритетов:
1. Top. Назначается экстренным ситуациям, которые очень отрицательно влияют на продукт или даже бизнес компании. Такие баги нужно устранять немедленно.
2. High. Назначается багам, которые должны быть устранены в первую очередь.
3. Normal. Обычный приоритет, назначается по умолчанию. Эти баги устраняются во вторую очередь, в штатном порядке.
4. Low. Назначается багам, не влияющим на функциональность. Исправление таких багов происходит в последнюю очередь, если есть время и ресурсы.
Серьезность — это атрибут, характеризующий влияние бага на общую функциональность тестируемого продукта.
Степень серьезности бага больше касается функциональности, поэтому она присваивается тестировщиком. Именно он чаще всего оценивает, насколько конкретная функция может влиять на общую работу тестируемого продукта.
Пример классификации серьезности багов:
1. Blocker. Блокирующая ошибка. Она делает невозможной всю последующую работу с программой. Для возобновления работы нужно исправить Blocker.
2. Critical. Критическая ошибка. Нарушает работу основной функциональности. Баг проявляется постоянно и делает невозможным использование основных функций программы.
3. Major. Существенный баг. Затрудняет работу основной функциональности или делает невозможным использование дополнительных функций.
4. Minor. Незначительный баг. На функциональность системы влияет относительно мало, затрудняет использование дополнительных функций. Для обхода этого бага могут быть очевидные пути.
5. Trivial. Тривиальный баг. Не влияет на функциональность проекта, но ухудшает общее впечатление от работы с продуктом.
Существуют практики, когда два атрибута объединяются в один — приоритет — и устанавливаются тестировщиком. В таком случае любому другому участнику релизного процесса запрещено изменять приоритет без обсуждения с инициатором баг-репорта.
Шаги воспроизведения
Наилучшим способом описания шагов воспроизведения ошибки является составление пронумерованного списка с последовательностью действий пользователя, приводящих к проявлению ошибки. Используйте простые предложения, например:
1. Пользователь открывает вкладку «Статистика».
2. Нажимает на кнопку «Сохранить».
3. Обновляет страницу.
Фактический результат
Фактический результат — это проблема, которая возникает, когда пользователь выполняет шаги, указанные выше. Опишите результат, указав, что происходит, где и когда. Это поможет разработчику понять проблему. Краткое и четкое описание пригодится также команде тестирования в будущем.
Ожидаемый результат
В этом разделе опишите ожидаемый результат шагов. То есть, изложите, как приложение должно было бы себя вести. Ошибка также может быть ожидаемым результатом, если тестировщик проверяет негативный сценарий. Например, если пользователь вводит неправильные учетные данные, он не должен войти в систему, вместо этого он должен увидеть сообщение об ошибке.
Прикрепленные файлы
Это дополнительные материалы, которые можно добавить к баг-репорту. Часто с визуальными руководствами бывает проще воспроизвести баг. Особенно, если баг сложно описать словами. Добавление скриншотов или коротких видео поможет избежать недопонимания. Только не забывайте, что визуальные материалы должны быть релевантными и понятными.
Составление тестовой документации
Тестовой документацией называется набор проверок, регулярно исполняемых в ходе релизного цикла. Если вы когда-либо интересовались авиацией, здесь довольно много аналогий. Если рейс — это релиз, то авиаконструкторы — это разработчики, пассажиры — пользователи, то экипаж воздушного судна — это тестирование, релиз-менеджмент и поддержка пользователей. Перед самым взлетом вы можете слышать, как по бортовой связи старший бортпроводник передает «внимание бортпроводникам — двери в положение 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. Чек-лист менее эффективен для начинающих тестировщиков, лучше использовать тест-кейсы.
Тест-кейсы
Тест-кейс — это форма записи проверки, которую проводит тестировщик. По сути, это алгоритм действий, по которому предполагается тестировать уже написанную программу. В нём подробно прописаны шаги, которые нужно сделать для подготовки к тесту, сама проверка и ожидаемый результат. Почти как баг-репорт, но нет фактического результата — мы его вписываем каждый раз, когда проводим проверку по тест-кейсу.
Тестировщик выполняет тест-кейс последовательно, шаг за шагом. Если фактический результат соответствует ожидаемому — всё хорошо. Если нет, тестировщик анализирует, что произошло. Это может быть ошибка в программе, в тест-кейсе из-за его неактуальности или в тестовом стенде. Если дело в программе, инженер составляет отчёт об ошибке и отправляет его разработчикам. Если в тест-кейсе — исправляет сам. Если в стенде — обращается к техническим специалистам.
Как правило, один тест-кейс описывает небольшую последовательность действий с одним конкретным результатом. Например, успешную авторизацию на сайте для конкретного пользователя или добавление одного конкретного товара в корзину.
Благодаря тест-кейсам специалисты всегда знают, как и что протестировать оптимальным количеством проверок, и не забывают о нюансах, так как записан каждый шаг. И им не приходится каждый раз заглядывать в документацию продукта или спрашивать команду, что и как должно работать.
Обычно тест-кейсы пишут к задачам, которые нужно периодически повторять. Основные функции системы следует проверять в каждой новой версии — это называется регрессионное тестирование. Например, при каждом обновлении проверять функцию регистрации для системы, которая может работать только с зарегистрированными пользователями. Тест-кейс каждый раз служит инструкцией, являясь по сути многоразовым.
Подбор девайсов для тестирования
Очень часто в профессиональном сообществе появляются вопросы «Что чаще всего спрашивают на собеседованиях?», и ответ на него максимально банальный — чаще всего на собеседованиях спрашивают, какие девайсы тестировщик возьмет себе для тестирования приложения.
Да, вот так просто — какие девайсы вам понадобятся, чтобы протестировать приложение. Как бы это ни звучало парадоксально, довольно часто тестировщики с трудом могут рассказать, какая подборка девайсов позволит в достаточной мере протестировать функциональность — хотя это то, с чем каждый инженер по тестированию работает каждый день.
В этом разделе мы предложим варианты для подборки девайсов — как только вы начнете понимать, по каким параметрам нужно выбирать девайсы, вы сможете легко проходить собеседования — по крайней мере, вы будете знать, как отвечать как минимум на один важный вопрос.
Шаг 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 передает его в ваше приложение.
Бесплатный фрагмент закончился.
Купите книгу, чтобы продолжить чтение.