можно ли автоматизировать тестирование удобства приложения
Вручную или автоматически: Пара слов о тестировании приложений
Автоматизированное тестирование — это одна из самых обсуждаемых тем среди инженеров по контролю качества. Новые системы тестирования программного обеспечения появляются постоянно, и каждый новый фреймворк получает титул лучшего.
Однако автоматизированное тестирование основывается на предположении, что программа используется так, как это задумали разработчики. Если полагаться только на автоматические тесты, то вскоре в коде появятся ошибки, и в то же время вы получите слабое представление о качестве интерфейса приложения.
Что касается ручного тестирования, то ему уделяют всё меньше внимания, поскольку такой процесс изнуряет сотрудников, а на роль исполнителя подойдет только специалист с особым складом ума. Однако «ручные» тесты отнюдь не уступают автоматизированным. Дело здесь в том, что подходы обладают разными областями применимости, поэтому сегодня мы рассмотрим некоторые достоинства и недостатки каждого решения.
Автоматизированное тестирование
По мнению Сары Фитжи (Sarah Fittje), инженера контроля качества в компании Project A Ventures, если тест подразумевает выполнение большого числа повторяющихся задач, то его имеет смысл автоматизировать. Классический пример — регрессионное тестирование, позволяющее обнаружить серьёзные баги, поэтому его важно регулярно проводить в полном объеме до запуска конечного продукта (кстати, если вам интересно, можете почитать руководство для QA-специалистов от Сары, его вы можете найти по ссылке).
При этом не стоит думать, что настройка автоматических тестов позволит серьезно сэкономить. Написание и поддержка написанных скриптов требует определенных навыков в области QA, которыми обладают не все тестировщики, следовательно, компании придется платить своим специалистам больше (однако штат тестировщиков все же удастся сократить).
Также стоит отметить, что достаточно сложно внедрять автоматизированные тесты для большого приложения с большим функционалом – так вы рискуете потерять видение общей картины и не сможете покрыть тестами весь функционал. Однако настраивая систему автоматизированного тестирования с первых дней проекта, вы получаете возможность ускорить циклы контроля качества и наладить последовательную проверку работы приложения.
Однако важно понимать, что автоматизированное тестирование не сможет помочь в определении недостатков внешнего вида интерфейса и качества взаимодействия пользователя с продуктом. Рассмотрим направления для применения автоматизации:
Тестирование графического интерфейса
Этот тип тестирования нацелен на проверку front-end-части приложения. Без помощи автоматизации очень трудно учесть все возможные комбинации взаимодействия пользователя с интерфейсом в веб-браузерах, мобильных устройствах и прочих системах (важно понимать, что такой тест не сможет оценить UX, как было отмечено выше).
Регрессионное тестирование
С помощью этого типа тестирования разработчики находят баги, вызванные улучшениями функций приложения. Под давлением частых обновлений разработчикам приходится трудиться в бешеном ритме и иногда идти на компромиссы, чем непременно пользуются баги, «закрадываясь» в код программного обеспечения. Вручную отследить недочеты каждого релиза достаточно проблематично.
Функциональное тестирование
Это тестирование для проверки выполнения функциональных требований, то есть работает ли приложение в соответствии с ожиданиями. Определяется, насколько точно реализуются задуманные функции, проводится анализ на соответствие стандартам, оценивается защищённость решения. На повторение функционального тестирования уходит много времени, даже при небольшом изменении в приложении, поэтому выполнять все действия «руками» может быть накладно.
Ручное тестирование
Автоматизированное тестирование помогает добиться высокого качества, но на данный момент оно ещё не заменило ручные тесты полностью. Это связано с тем, что пользователи могут совершать абсолютно неожиданные действия, которые сложно учесть в автоматических тестах.
Пока пользователь привыкает к приложению, он способен ошибаться, не завершать нужные шаги, вводить неожиданные значения и так далее. Пользователи знают гораздо меньше о вашем продукте, но в итоге именно они будут им пользоваться. Поэтому клиентское одобрение — самый ценный индикатор качества интерфейса.
Когда для оценки работы программы ключевую роль начинают играть поведенческие особенности человека и интуиция, то стоит обратить внимание на ручное тестирование — здесь важнее поставить себя на место пользователя. Тестировщик может подходить творчески к процессу проверки функциональности: придумывать неожиданные идеи, имитировать необычные варианты использования — это помогает раскрыть критические ошибки, которые «не заметит» автоматизированное тестирование.
Пара юзкейсов ручного тестирования:
Юзабилити-тестирование
Это тестирование служит для проверки удобства использования приложения с точки зрения пользователя. Такую расплывчатую по своим целям задачу компьютер решить не может — машине нужны четкие формулировки.
Ad hoc тестирование
Разовое тестирование, направленное на проверку одного аспекта программы. Для такого типа тестирования нет формально определённых правил, оно проводится импровизационно — тестировщик может использовать любые доступные средства для поиска багов. Фактически ad hoc тесты – это попытка «угадать» возможную ошибку.
Комбинированный вариант
Как мы отметили выше, разные типы тестирования обладают разными сферами применимости. Автоматические тесты не заменят ручные, но они могут быть использованы для экономии рабочего времени при отработке больших однообразных наборов действий. Ручное же тестирование выполняется долго, но без него не обойтись, если вы хотите добиться высокого качества продукта. На данный момент только комбинация этих подходов способна обеспечить высокие стандарты по отношению к функциональности и удобству использования продукта.
В качестве примера такого подхода Сара Фитжи приводит процесс тестирования онлайн-магазина natue, когда после успешного внедрения новых функций в тестовом проекте, QA-команда запускала автоматизированное регрессионное тестирование.
«Пока выполнялась автоматизированная проверка, мы одновременно проводили ручное тестирование новых функций, учитывая промежуточные результаты регрессионного теста, – рассказывает Сара. – Если во время ручного или автоматизированного тестирования обнаруживались баги, то они исправлялись, а тесты запускались заново». Если же все проходило успешно, то команда Сары повторяла проверку уже перед самим запуском финальной версии.
Еще один пример приводит Стивен Аллен (Steven Allen), инженер компании TestGrid.io. Он говорит, что в iOS полноценное автоматизированное тестирование долгое время было недоступно. Несколько лет назад Apple начали выпускать инструменты для автоматизации, но они пока что не совершенны. Поэтому использовать только средства автоматизации не получается – приходится прибегать к ручному тестированию.
Разработчики автоматизируют тесты, чтобы работать эффективнее и успевать больше, но нельзя описать скриптами все возможные варианты использования приложения и учесть все ошибки. Некоторые вещи очень легко пропустить – например, если на экране входа появилось лишнее поле ввода пользовательского имени, но при этом всё остальное работает правильно.
«Очень сложно написать идеальный код для автоматических тестов, – говорит Джозеф Миллар (Joseph Millar), специалист отдела контроля качества компании Lucid Software. – Если разработчик допустит ошибку в скриптах, он рискует пропустить большой пласт ошибок, тогда как при ручном тестировании эти недочеты, скорее всего, будут обнаружены. Поэтому так важно использовать оба метода при разработке приложений. Один для экономии времени, второй для «шлифовки».
Автоматизация тестирования мобильных приложений: сравнение инструментов
Автоматизация тестирования помогает решить сразу несколько проблем — в том числе если речь идёт о мобильных приложениях. Вместо того чтобы вручную проводить рутинные трудоёмкие процедуры, специалисты могут делегировать значительную их часть фреймворкам. Автоматизация упрощает проверку и помогает ускорить регрессионное тестирование, а также даёт возможность использовать ранее недоступные типы тестирования.
Мы сравним несколько инструментов, которые зарекомендовали себя на рынке и продолжают развиваться. Эти знания помогут выбрать, какое решение использовать для тестирования того или иного мобильного приложения.
Данная статья вряд ли откроет новые горизонты для профессионалов, но может быть полезна новичкам, решившим освоить азы мобильного тестирования, и в некоторой мере — специалистам среднего уровня.
Классификация инструментов
Первое, от чего следует отталкиваться — это непосредственно платформа, на которой работает приложение. Исходя из этого, классифицируем перечень инструментов следующим образом:
Автоматизация тестирования приложений на Android
UI Automator
Мощный инструмент тестирования с продвинутой внешней интеграцией. Это значит, что данный фреймворк не только позволяет тестировать само приложение, но также способен “общаться” с операционной системой и другими приложениями — например, активировать и деактивировать Wi-Fi, GPS, открывать меню настроек в ходе теста и производить другие внешние взаимодействия.
Предназначение UI Automator — тестирование “чёрного ящика” (black-box testing). Это значит, что анализ производится с позиций внешнего пользователя без доступа к коду.
К основным особенностям относятся:
Espresso
Более лёгкий по сравнению с UI Automator инструмент, не подходящий для взаимодействия с внешними приложениями, но удобный для тестирования “белого ящика” (white-box) с доступом к исходному коду конкретного приложения или тестирования “серого ящика” (grey-box), при котором имеется доступ к некоторым внутренним процессам и структуре.
Вместе с тем, Espresso выделяется мощным API https://github.com/hamcrest. Интерфейс добавляет удобные методы для проверок в автотестах, например:
assert_that(1, less_or_equal(2)). Для тестирования webview при этом используются специальные методы.
UI Automator и Espresso взаимно дополняют друг друга и могут использоваться в комплексе в рамках одного проекта.
Автоматизация тестирования iOS-приложений
XCUITest
Инструмент для black-box тестирования без обращения к коду приложения. Работает только с нативными продуктами — к сожалению, провести cross-app тесты не получится.
С другой стороны, нативный характер фреймворка является преимуществом с той точки зрения, что при использовании XCUITest степень взаимопонимания разработчиков и тестировщиков находится на гораздо более высоком уровне, чем в случаях, когда одни и вторые используют разные языки.
Полезным дополнением является test recorder, который даёт возможность писать тесты путём записи действий в приложении даже тем, кто не работает с кодом.
Инструмент позволяет избежать типичных ошибок и лишних, недоступных пользователю манипуляций с кодом. Однако, при этом XCUITest имеет и некоторые недостатки.
XCUITest, в отличие от Espresso, работает в отдельном потоке, во время тестирования нужно дождаться появления определенных элементов и параметров. Актуальное состояние приложения не считывается, и задержки в обновлении данных могут привести к невозможности обнаружения запрашиваемых элементов.
EarlGrey
У EarlGrey акцент сделан на воспроизведении пользовательского опыта. Пока элементы на экране не представлены визуально, имитация работы с приложением не запускается.
При этом отмечается ряд удобств и преимуществ. Во-первых, специалистам нравится то, как фреймворк синхронизирует запросы, UI и потоки. Не нужно никаких waitforview и wait.
Во-вторых, как уже было сказано, особое внимание уделено отслеживанию видимости элементов. Инструмент обладает дополнительным слоем проверки подгрузки интерфейса и воспроизводит пользовательские жесты — свайпы, нажатия — непосредственно на уровне событий приложения.
Универсальные инструменты
Универсальные инструменты (или “комбайны”) позволяют не ограничивать свой выбор только Android или iOS, а работать с обеими платформами.
Такие инструменты применимы для тестирования приложений следующих видов:
Detox
На наш взгляд, Detox удобен для приложений, написанных на React Native. Тесты пишутся на JavaScript, при этом iOS и Android приложения генерируются из одного и того же кода JavaScript и максимально похожи. Это позволяет использовать одинаковые тесты для обеих платформ.
Ключевая особенность Detox — тестирование по принципу “серого ящика”. В данном случае фреймворк имеет некоторый доступ к внутренним механизмам, что позволяет соотносить внешнее поведение приложения с тем, что происходит на более глубоком уровне.
Detox может обращаться к памяти и отслеживать выполняемые процессы. Принцип grey-box помогает бороться с неустойчивостью, выражающейся в том, что при сквозном тестировании:
Detox не нуждается в WebDriver, работая с нативным драйвером через JSON. Он задействует нативные методы прямо на устройстве. Внутри данного фреймворка применяются EarlGrey для iOS и Espresso для Android.
Фреймворк работает как с эмуляторами, так и с физическими устройствами.
Appium
Преимущество Appium состоит в том, что писать тесты под каждую из платформ можно с помощью единого API, не прибегая к преобразованию приложения в какой-либо особый, совместимый с фреймворком вид.
При тестировании используются фреймворки от вендоров — то есть вы работаете именно с исходным приложением. Для Android 4.2+, соответственно, применяется UiAutomator/UiAutomator2, а для iOS 9.3+ — XCUITest. В качестве оболочки фреймворков используется WebDriver (он же — Selenium WebDriver).
В целом, это гибкий инструмент, который можно доработать под нужды проекта без необходимости подстраиваться под ограниченный набор языков разработки.
Ranorex
Платный комплексный инструмент для тестирования десктопных, мобильных и веб-приложений. Позволяет проводить тестирование как с применением программирования, так и вовсе без использования скриптов. Предоставляет возможность тестирования не только через эмуляторы, но также на живых девайсах.
Инструмент даёт возможность создавать и настраивать тесты, а также управлять ими централизованно. Вы можете создать тест в центре управления и запускать его в различных внешних средах и на любых девайсах.
Легко интегрируется с существующей CI-средой: с такими системами управления заявками, как Jira и TFS, а также с системами контроля версий — например, Git и SVN.
В Ranorex прокачано data-driven тестирование с подгрузкой данных из SQL, CSV, Excel.
Инструмент подходит абсолютно для любого устройства, поддерживает параллельное тестирование на каждом из них.
Сочетает все три подхода к тестированию: black-box, white-box и grey-box.
TestComplete
Платная среда для автоматизации тестирования мобильных, веб и десктопных приложений. Поддерживает Android и iOS, а в разрезе типов приложений: нативные, веб-приложения и гибридные.
Ориентированный, в основном, на функциональное и юнит-тестирование, инструмент также предоставляет возможность проводить многие другие виды тестирования:
Данный инструмент распознаёт объекты и элементы управления, предлагая специальные команды для эмуляции взаимодействия пользователя с ними. Интегрируется с Jenkins, Git и Jira, что позволяет запускать непрерывное бесшовное тестирование.
Подводя итоги
Планируя тестировать то или иное мобильное приложение, обратите внимание на перечисленные выше инструменты. Каждый из них имеет свои особенности, а иногда и ограничения.
Рассмотрим на примере. Если перед вами стоит задача протестировать небольшое приложение в сжатые сроки, в первую очередь нужно учитывать такие факторы, как тип тестируемого приложения и опыт ваших специалистов. Если тесты пишет разработчик, лучше выбрать родной язык и инструмент для его платформы (см. в таблице ниже). Если тестами занимаются специалисты SDET, которые знакомы с другими языками (Java, JavaScript, Python и др.) и работали с Selenium, удобно использовать Appium. Если опытного SDET в команде нет, а тесты будут писать специалисты QA, лучше выбрать платные фреймворки, поскольку в них есть утилиты для записи тестов и более стабильная техподдержка, чем в open source фреймворках.
Из нашей практики:
Мы работали с одним интернет-магазином, у которого было два мобильных приложения – на iOS и Android. Для покрытия тестами основных пользовательских сценариев мы выбрали Appium по нескольким причинам:
В заключение предлагаем вашему вниманию таблицу, которая поможет подобрать инструмент для вашего проекта. Стоит отметить, что в некоторых случаях приведенное в таблице деление является условным. Где-то для простоты сделано обобщение и приведены только самые основные параметры. Инструменты тестирования постоянно развиваются, поэтому при выборе фреймворка важно проверять актуальную документацию.
Можно ли автоматизировать тестирование удобства приложения
Что пишут в блогах
Заказать — https://shop.testbase.ru/buy/book. Пока самовывоз (см ниже где и когда!!). С почтой разберемся чуть позже.
Где: Кострома / онлайн
2 декабря буду выступать в Костроме. Приходите увидеться очно, или подключайтесь онлайн.
Онлайн-тренинги
Что пишут в блогах (EN)
Blogposts:
Разделы портала
Про инструменты
Автор: Кристин Джеквони (Kristin Jackvony)
Оригинал статьи: http://thethinkingtester.blogspot.com/2018/09/usability-and-accessibility-testing.html
Перевод: Ольга Алифанова
Тестирование удобства использования и доступности – это два зачастую игнорируемых типа тестирования приложений. Тестирование удобства использования относится к пользовательскому опыту и проверяет, насколько приложение легко в использовании и интуитивно понятно. Тестирование доступности проверяет, насколько легко пользователям с ограниченными возможностями взаимодействовать с приложением. Об обоих типах – в сегодняшней статье.
Тестирование удобства использования
Тестирование удобства использования часто называют тестированием пользовательского опыта (UX), и в компаниях покрупнее есть специальные UX-дизайнеры, чья цель – сделать приложение приятным и удобным для пользователей. Даже если в вашей команде таких дизайнеров нет, проверка приложения с учетом качества пользовательского опыта – всегда хорошая идея. Вот четыре способа это сделать:
Тестирование доступности
Тестировать доступность важно, потому что 15% населения каким-либо образом ограничены в возможностях, а мы хотим, чтобы нашими приложениями пользовалась максимально широкая аудитория. Три основных типа тестирования доступности – это визуальная доступность, доступность подвижности, и аудиальная доступность. Вот несколько советов по каждой:
Мы, как тестировщики, хотим, чтобы пользователи получили максимальное удовольствие от работы с нашим приложением. Удобство использования и доступность помогут убедиться, что пользователи достигнут своих целей в приложении эффективно и легко.
Что дает автоматизация тестирования
При создании IT-решений ошибки обходятся дорого, это особенно заметно в медицине, где от качества ПО зависят человеческие жизни, или в сфере банкинга, где возможны крупные финансовые потери. Автоматизация тестирования позволяет организовать постоянную проверку качества продукта. Давайте разберемся, в каких случаях она необходима.
Одни компании ошибочно считают, что автоматизация – пустая трата времени и средств, другие – что это крутой тренд и «таблетка» от всех болезней. Рассмотрим, где золотая середина и в чем смысл автоматизации.
Зачем тестировать
Малейшая ошибка в программном обеспечении грозит огромными расходами. Чем лучше выстроены процессы разработки, тем меньше риски. Однако, если обратиться к фактам, мы видим, что недочеты допускают даже такие гиганты, как Google, Microsoft или ведущие банки.
Например, одна из знаменитых “аварий” финансового мира произошла в Первом национальном банке Чикаго в конце 90-х: в одночасье счета клиентов безосновательно выросли на 900 миллионов долларов. Тогда старший вице-президент банка Джеймс Ланкастер признал, что дело в «программной ошибке в компьютере» – которую, к счастью, никто не успел использовать.
Дорогостоящие ошибки бывают и в других отраслях, казалось бы, не связанных напрямую с IT. Известный пример – аварии при запуске космической техники, в частности, в 2017 году Роскосмос утратил спутник стоимостью 2,6 млрд рублей.
При работе с масштабными IT-решениями, например, системами дистанционного банковского обслуживания (ДБО), важно постоянно тестировать не только работу отдельных функциональностей, но и их взаимодействие. В условиях сжатых сроков, когда ведущие банки каждый месяц обновляют свои приложения, проверить все вручную невозможно – на это как минимум не хватит времени.
При создании IT-продуктов для бизнеса обычно сочетают два подхода:
Что дает автоматизация
Это одно из достаточно новых направлений в разработке, окруженных большим количеством мифов. Чаще всего бизнес обращается к автоматизации, веря, что она:
В свою очередь, два последних утверждения действительно справедливы: грамотная автоматизация тестирования помогает и в ускорении релизов, и в увеличении покрытия кейсов. При этом ручное обеспечение качества и автоматизация, как правило, одинаково важны и используются в комплексе. Кроме того, каждый проект индивидуален, и иногда в автоматизации нет необходимости.
Когда автоматизация обязательна
Задачи автоматизации
Как правило, мы привлекаем экспертов SDET для решения следующих задач:
Результаты
Автоматизация помогает выстроить баланс:
Кроме того, при необходимости можно ускорить релизы. Например, если в спринте разработки нужно проверить около 400 кейсов, то их ручная проверка займет до двух недель, а автотесты можно провести ночью и проанализировать за 4 часа.
Бизнес, благодаря автоматизации, получает возможность в любое время убедиться в том, что ключевые функции системы работают правильно и проверить, нет ли ошибок (а если они есть, то в чем заключаются).
Пример
Предположим, что на текущий момент в мобильном банке нужно проходить до 700 кейсов, каждый – от 70 до 100 раз в год. Ручной проверки требуют менее 25% кейсов, остальные 75% можно автоматизировать.
Затраты времени при ручной проверке:
Затраты времени при автоматизации:
Ночной прогон тестов занимает 8 часов, но без участия человека, поэтому не учитывается.
Прочие затраты времени:
Конечно, каждый кейс имеет свои особенности, поэтому временные затраты могут быть разными. Мы постоянно анализируем, сколько времени нужно на написание автоматических тестов, поддержку, анализ результатов.
В среднем, автоматизация экономит от 30 до 50% времени как минимум, позволяя выделить больше времени, например, на развитие и улучшение продукта.
Как происходит автоматизация тестирования
У каждой IT-компании есть свои особенности в автоматизации тестирования, как и в других рабочих процессах. Мы в SimbirSoft придерживаемся следующих методов, которые помогают оперативно выстроить работу с проектами наших клиентов.
Процесс тестирования начинается с разработки стратегии – тест-плана, основы для составления отдельных тест-кейсов. Для автоматизации SDET инженеры выбирают ключевые, часто используемые сценарии работы пользователя с продуктом – такие сценарии дают около 80% бизнес-ценности.
После этого мы создаем основу для дальнейших автотестов, настраиваем стенды и workflow по работе с ними, CI для регулярного запуска тестов на различных ветках. Мы выбираем, какие подходы к подготовке тестовых данных мы будем использовать (API, доступ к базам данных, генерация синтетических данных, использование данных с прода). Инженеры SDET пишут тесты, которые покрывают ключевые сценарии работы с продуктом, анализируют полученные результаты и необходимость дальнейшей автоматизации.
Мы разрабатываем автоматизированные тесты, используя все наиболее востребованные языки программирования – Java, Python, Kotlin и др. Наши основные инструменты и технологии – Appium, TestNG | JUnit, RobotFramework | Pytest, Selenium | Senenide, Allure, TeamCity, Jenkins, JMeter.
Какие тесты нужно автоматизировать в первую очередь – зависит от особенностей конкретного продукта. Большинство компаний автоматизируют smoke тесты, регрессионные тесты для проверки уже готовых функциональностей, а также кейсы для проверки различных параметров (например, валидных и невалидных данных при регистрации).
Мы в своей практике выстраиваем процессы автоматизации тестирования уже на старте разработки, параллельно с ручным тестированием. Эта работа – не единоразовая, она ведется непрерывно, особенно на крупных проектах, в том числе банковских.
Подводя итоги
Баланс ручного и автоматизированного тестирования позволяет постоянно контролировать качество IT-продукта. Некоторые проекты проверяют вручную, другие задачи можно успешнее решить с помощью автоматизации. Тестирование вручную используют в тех случаях, когда люди незаменимы, например, если нужна локализация, описание ошибок, ручная проверка юзабилити. В небольших проектах часто тесты пишут сами разработчики.
Ручное тестирование в комплексе с автоматизацией проводят при создании крупных IT-продуктов, где работает несколько команд (например, в банковских приложениях), где есть сложные алгоритмы и бизнес-логика. Этот метод помогает выстроить процессы тестирования продукта и снизить риск дорогостоящих ошибок, что бывает особенно важно при работе в условиях жесткого графика релизов.
Спасибо за внимание! Надеемся, что статья была вам полезна!