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

Мария Александровна Осина

Задумывались ли вы, как часто даже опытные тестировщики, изучая новые рабочие инструменты, думают про себя: «Если бы я только знал это раньше…»? Эта книга предназначена для профессионалов в сфере тестирования и содержит всю самую необходимую информацию об инструментах и лучших практиках, которые использует каждый инженер по тестированию iOS в своей работе. Благодаря этой книге вы не только лишь сможете начать тестировать эффективнее и качественнее, но и повысите свою цену на рынке труда.

Глава 1: Важные знания и умения для инженера по тестированию

Несмотря на большое количество бесплатных и платных курсов по освоению профессии инженера по тестированию, которые гарантируют освоение компетенций вплоть до уровня middle+ после прохождения трехмесячных курсов, есть кое-что, чему они научить не могут. Существуют некоторые черты характера, благодаря которым работа идет продуктивнее и кажется легче. Для начала попробуем их сформулировать.

Этот список не означает, что без этого хорошим инженером по качеству не стать. Все возможно, просто вам потребуется чуть больше упорства и времени. Джордж Бернард Шоу говорил «То, что мы называем успехом, в действительности является компенсацией всякого человека, который обделен талантом.» Так что в любом случае дерзайте и стремитесь.

Умение не идти на неоправданный риск

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

28 января 1986, мыс Канаверал

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

Роджер Бойсджоли работал старшим инженером компании «Мортон-Тиоколь», которая выступала подрядчиком по части проектирования шаттла, а также непосредственной разработки твердотопливных ракетных ускорителей. Вместе со своим начальником, Бобом Эбелингом, они находились в офисе компании. Боб позвал Роджера понаблюдать за запуском по ТВ, тот отказался — «Нет, я не хочу на это смотреть». Позже он признался, что отказался потому, что знал, чем это может закончиться.

За день до запуска Боб и Роджер шесть часов по телемосту убеждали инженеров НАСА отложить запуск корабля из-за того, что температура во Флориде опустилась ниже нуля, на что конструкция корабля не была рассчитана. Но топ-менеджмент «Мортон-Тиоколь» не беспокоился об этом. Они разрешили запуск и порекомендовали подопечным не паниковать. В общем, сказали то, что очень хотели услышать их коллеги из НАСА.

В день запуска, 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. Чек-лист менее эффективен для начинающих тестировщиков, лучше использовать тест-кейсы.

Тест-кейсы

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

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

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

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

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

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

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

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

Конец ознакомительного фрагмента.