какие тесты наиболее эффективны с точки зрения автоматизации
Какие тесты наиболее эффективны с точки зрения автоматизации
Что пишут в блогах
Продолжу хвастаться статусом книги.
I’m sticking with “bug” rather than adopt another word such as “fault,” which is the current fad in publications because:
Онлайн-тренинги
Что пишут в блогах (EN)
Introduction
Разделы портала
Про инструменты
Автор: Амир Гахрай (Amir Ghahrai)
Перевод: Ольга Алифанова
Как вы решаете, какие тесты автоматизировать, а какие оставить для ручного тестирования?
Перед тем, как вы начинаете автоматизировать тест, вам нужно выяснить, какую выгоду вы получите от автоматизации этого теста, учитывая время, силы и ресурсы, вложенные в автоматизацию.
Ниже перечислены факторы, которые стоит принять во внимание, решая, какие ручные тесты должны или не должны быть автоматизированы. Как говорится, только то, что вы можете что-то автоматизировать, не означает, что вы должны автоматизировать все и вся.
Вот некоторые идеи, помогающие выбрать хороших кандидатов на автоматизацию:
Тесты, которые должны быть автоматизированы:
В общем и целом, чем чаще прогоняется тест, тем лучше его автоматизировать.
Помните также, что тесты – не единственные кандидаты на автоматизацию. Задачи, например, настройка, создание тестовых данных для ручного тестирования – тоже прекрасные идеи для автоматизации.
Тесты, которые не нужно автоматизировать:
Вручную или автоматически: Пара слов о тестировании приложений
Автоматизированное тестирование — это одна из самых обсуждаемых тем среди инженеров по контролю качества. Новые системы тестирования программного обеспечения появляются постоянно, и каждый новый фреймворк получает титул лучшего.
Однако автоматизированное тестирование основывается на предположении, что программа используется так, как это задумали разработчики. Если полагаться только на автоматические тесты, то вскоре в коде появятся ошибки, и в то же время вы получите слабое представление о качестве интерфейса приложения.
Что касается ручного тестирования, то ему уделяют всё меньше внимания, поскольку такой процесс изнуряет сотрудников, а на роль исполнителя подойдет только специалист с особым складом ума. Однако «ручные» тесты отнюдь не уступают автоматизированным. Дело здесь в том, что подходы обладают разными областями применимости, поэтому сегодня мы рассмотрим некоторые достоинства и недостатки каждого решения.
Автоматизированное тестирование
По мнению Сары Фитжи (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. – Если разработчик допустит ошибку в скриптах, он рискует пропустить большой пласт ошибок, тогда как при ручном тестировании эти недочеты, скорее всего, будут обнаружены. Поэтому так важно использовать оба метода при разработке приложений. Один для экономии времени, второй для «шлифовки».
Лучшие практики автоматизации тестирования: решение, что и когда автоматизировать
Автоматизация тестирования обычно вводится в проект для решения таких проблем, как повторяющаяся ручная работа, работа с большими наборами данных или получение более быстрой обратной связи в пайплайне CI / CD. Из-за этого шума вокруг автоматизации тестирования вы можете подумать о том, чтобы автоматизировать «все». Возможно, вы уже выбрали фреймворк тестирования и команду, которая будет выполнять автоматизацию тестирования. Но серьезно ли вы задумывались о том, что вам следует автоматизировать или насколько это выполнимо для вас?
Исчерпывающее тестирование невозможно. Это один из ключевых принципов тестирования программного обеспечения. Перед тем, как начнется автоматизация тестирования, вам необходимо принять решение на основе данных о том, что вы будете автоматизировать, а что нет, и в каком приоритете. При принятии решения о том, что автоматизировать, следует учитывать несколько основных моментов, например уровень автоматизации, на котором вы будете создавать свои тесты. Автотесты можно разделить на три основных уровня: модульные тесты, интеграционные тесты и UI тесты. Вы должны оценить плюсы и минусы написания тестов на каждом из этих уровней, прежде чем приступать к их написанию.
Независимо от того, какой уровень автоматического тестирования вы выполняете, цель должна заключаться в автоматизации того, что приносит наибольшую пользу и учитывание областей, всегда тестируемых для каждого релиза, и областей, которые трудно тестировать вручную. Вам также следует обратить внимание на области, в которых требуется обрабатывать огромные объемы данных. Все эти факторы необходимо учитывать перед автоматизацией. Если вы создаете автотесты вслепую или по своей прихоти, это увеличивает вероятность того, что вы не получите от них столько пользы, сколько следовало бы.
Ниже подробно описаны пять критических областей/факторов, о которых следует помнить, когда вы рассматриваете возможность интеграции автоматического тестирования в свой текущий рабочий процесс.
Автоматизируйте ваши смоук тесты
Смоук тесты очень важно выполнять для получения уверенности, что ваше приложение функционирует на базовом уровне, после каждого изменения или при создании нового билда. Смоук тесты могут быть интегрированы в пайплайн CI / CD, чтобы убедиться, что блокирующие ошибки обнаруживаются на ранней стадии. Смоук тесты гарантируют, что наиболее важные аспекты и основные компоненты приложения работают правильно. Они тестируют области, которые всегда должны работать, и могут помочь вам понять, достаточно ли стабильна сборка или приложение для продолжения дальнейшего тестирования. Автоматизация смоук тестов может:
Помочь быстро обнаружить блокирующие ошибки, например, не загружается приложение/веб-страница, пользователь не может войти в систему, пользователь не может создать учетную запись или платежные сервисы не работают.
Обеспечивает более быстрое устранение новых и регрессионных багов. Смоук тесты по своей природе имеют большой охват и небольшую глубину. Это приводит к тому, что тестируется широкий спектр тест-кейсов, не углубляясь в приложение. Когда эти критические области заработают, вы сможете глубже изучить приложение, чтобы протестировать другие функции.
Приводит к меньшему количеству ручного труда и экономит время. Путем интеграции ваших автотестов в пайплайн CI/CD ваши смоук тесты сворершают проверку до завершения сборки. Это означает, что сборка не передается QA, если автотесты не пройдут смоук.
Автоматизируйте тесты, которые выполняются всегда, например, регрессионные тесты или тесты, которые всегда находятся в начале каждого рабочего процесса.
Это позволяет вам иметь набор стабильных тестов, жизненно важных для приложения. Например, создание учетной записи пользователя необходимо будет выполнить до того, как пользователь сможет войти в систему и просмотреть панель управления, совершать платежи и т. д. Создавая набор автоматизированной регрессии, вы можете:
Запускать тесты, которые быстро выявляют любые ошибки, возникающие в результате изменений в программном обеспечении. Эти изменения могут быть новыми функциями или исправлениями багов.
Иметь набор стабильных тестов. Регрессионные тесты обычно предназначены для существующих функций, что означает, что эти функции не являются новыми и были протестированы раньше. Это предотвращает появление флаки автотестов, из за которых вам пришлось бы тратить много времени на ручное тестирование, так как вы не уверены, действительно ли тесты провалились или нет.
Экономить время, так как теперь вы можете сосредоточить свои усилия на ручном тестировании на большем количестве крайних кейсов.
Автоматизируйте обширные тесты
Исчерпывающие тесты, такие как ввод больших наборов данных, тестирование формы или тесты, требующие от тестировщика многократного выполнения одного и того же процесса, но с большим разнообразием данных, должны быть автоматизированы. Вы можете создавать автотесты на основе данных, которые позволяют сэкономить время. Для различных форм автотесты позволяют вам быстро тестировать различные комбинации входных данных, например, отсутствуют ли поля, являются ли они неполными и т. д. Тестирование на основе данных очень полезно, поскольку оно позволяет вам изменять только данные, а не тестовый сценарий, чтобы получить разные результаты. Такие тесты очень многоразовые и эффективные.
Автоматизируйте тесты, требующие нескольких конфигураций
Автоматизируйте ваши тесты производительности
Ваш следующий шаг
Переведено командой QApedia. Еще больше переведенных статей вы найдете на нашем телеграм-канале.
От пирамиды тестов – к колесу автоматизации: какие проверки нужны на проекте
О задачах автоматизации тестирования и случаях, когда она необходима, мы уже писали на Хабре. А для выбора необходимых проверок удобно иметь под рукой наглядное пособие, не ограничиваясь знаменитой пирамидой автотестов. Предлагаем перевод статьи Кристин Джеквони (Kristin Jackvony), где графически показан еще один метод – колесо автоматизации.
Автоматизация тестирования, как правило, наиболее необходима в масштабных приложениях с большим количеством бизнес-функций, при внедрении CI/CD и регулярных релизов. Подробнее об этом мы рассказывали в статье «Что даёт автоматизация тестирования».
С разрешения Кристин Джеквони – автора блога Think Like a Tester и ряда популярных материалов о тестировании – мы перевели статью «Переосмысление пирамиды автотестов: колесо автоматизации» (Rethinking the Pyramid: The Automation Test Wheel). В конце статьи рассмотрим пример проверок из практики наших специалистов по автоматизации тестирования (SDET).
Каждый, кто занимался автотестами, слышал о Пирамиде автотестов. Обычно она имеет три слоя: тесты UI, API и Unit. Нижний слой, самый широкий, занимают Unit-тесты – это означает, что таких тестов должно быть больше, чем прочих. Средний слой – это API-тесты; идея в том, что их нужно запускать меньше, чем Unit-тестов. Наконец, верхний слой – это UI-тесты. Их должно быть меньше, чем остальных, т.к. они требуют больше времени на прохождение. Кроме того, UI-тесты наиболее нестабильные.
Пример пирамиды автотестов на Хабре. Метод описан в книге Майка Кона «Scrum: гибкая разработка ПО» (Succeeding With Agile. Software Development Using Scrum).
С моей точки зрения, в этой пирамиде две проблемы:
Я предлагаю другой подход к автоматизированному тестированию – Колесо автоматизации.
Каждый из типов тестов можно рассматривать как спицу в колесе. Нет спицы, которая была бы важнее других – они все необходимы. Размер сектора колеса не означает число тестов, которые должны быть автоматизированы. При этом нужно предусмотреть проверки по каждому указанному направлению, если в вашем проекте требуется обеспечивать качество в соответствующей области.
Unit-тесты (Unit Tests)
Unit-тесты – это самые маленькие автотесты, какие только возможны. Они проверяют поведение только одной функции или одного метода. Например, есть метод, который проверяет, равно ли число 0, тогда можно написать такие Unit-тесты:
Компонентные тесты (Component Tests)
Эти тесты проверяют разные сервисы, от которых зависит код. Например, если мы используем API GitHub, то можно написать компонентный тест для проверки того, что запрос на данный API получает ожидаемый ответ. Или это может быть просто пинг до сервера, проверка доступности базы данных. Должен быть хотя бы один компонентный тест на каждую используемую в коде службу.
Примечание: например, у нас в SimbirSoft к компонентным тестам, помимо проверки ответов сторонних сервисов, относятся проверки модулей одной системы, если её архитектура представляет собой набор таковых.
Сервисные тесты (Services Tests)
Такие тесты проверяют доступность веб-сервисов, к которым обращается приложение. Чаще всего работа с ними организована через использование API запросов.
Например, для API с типами запросов POST, GET, PUT и DELETE мы можем написать автотесты на проверку каждого типа запросов. Причем наши тесты будут проверять как позитивные, так и негативные типы сценариев, при которых некорректный запрос возвращает соответствующий код ошибки.
Тесты пользовательского интерфейса (User Interface Tests, UI Tests)
UI-тесты проверяют правильность реакции системы на действия конечного пользователя. К таким проверкам относятся, например, тесты, проверяющие ответ системы на заполнение текстовых полей или на нажатие кнопок.
Как правило, любая функциональность системы, которая может быть протестирована с помощью Unit, компонентного или сервисного теста, должна быть проверена с использованием упомянутого типа теста. Тесты же пользовательского интерфейса должны быть сосредоточены исключительно на выявлении ошибок во взаимодействии пользователя с графическим интерфейсом.
Визуальные тесты (Visual Tests)
Визуальные тесты проверяют отображение элементов интерфейса на экране. Они схожи с UI-тестами, но фокусируются на проверке внешнего вида интерфейса, а не на функциональности. Примерами таких проверок могут быть проверка правильности отображения изображения кнопки или проверка отображения логотипа продукта на экране.
Тесты безопасности (Security Tests)
Это тесты, проверяющие соблюдение мер безопасности и защиты данных. Они по механике похожи на сервисные тесты, но тем не менее рассматривать их следует отдельно. Например, тест безопасности может проверить, что токен авторизации не будет создан при недопустимой комбинации логина и пароля. Другой пример – создание GET-запроса с токеном авторизации для пользователя, не имеющего доступа к этому ресурсу, и проверка того, что будет возвращен ответ с 403 кодом.
Примечание: с сервисными тестами эти проверки роднит только способ вызова служб – через http-запросы. Цель таких тестов – исключительно в проверке защищенности системы и пользовательских данных от действий злоумышленника.
Тесты производительности (Performance Tests)
Автотесты производительности проверяют, что ответ на запрос приходит в рамках соответствующего периода времени. Например, если есть требование к системе, что GET-запрос никогда не должен занимать дольше двух секунд, то при превышении этого ограничения автотест вернет ошибку. Время загрузки web-интерфейса также можно измерять с помощью тестов производительности.
Тесты доступности (Accessibility Tests)
Автотесты проверки доступности служат для проверки самых разных вещей. В сочетании с тестами пользовательского интерфейса они, например, могут проверять наличие текстового описания изображения для слабовидящих. В рамках проверки доступности визуальные тесты могут быть использованы для проверки размера текста на экране.
Как выбрать методы проверки
Возможно, вы заметили, что приведенные выше описания тестов часто пересекаются друг с другом. Например, тесты безопасности могут выполняться в процессе тестирования API (сервисные тесты), а визуальные тесты – в процессе тестирования пользовательского интерфейса. Здесь важно, чтобы каждая область была проверена тщательно, эффективно и точно.
После выхода статьи «Переосмысление пирамиды автотестов: колесо автоматизации» (Rethinking the Pyramid: The Automation Test Wheel) вышел список факторов, помогающих определить необходимую долю тестов каждого типа в колесе автоматизации:
Из практики SimbirSoft
Мы считаем, что колесо автоматизации – полезный способ визуализации типов тестирования. Безусловно, мы давно используем описанные тесты, но картинка помогает проанализировать покрытие системы и держать всё перед глазами.
Если у вас отлажен процесс тестирования и вы регулярно прогоняете автотесты, это минимизирует риск попадания дефектов в продакшен. К тому же, автотесты помогают оперативно выявлять проблемы, которые могут возникнуть в процессе работы системы. Например, с помощью планового ежедневного прогона автотестов можно контролировать свой сайт, чтобы защитить себя от взломов.
Какие использовать проверки и в каком количестве – зависит и от требований, и от самой проверяемой системы. Так, в одном из наших продуктов – банковском мобильном приложении – по требованию клиента были подготовлены автотесты всех перечисленных ранее видов. Рассмотрим их примеры далее.
Unit Tests
Мы позаботились о том, чтобы каждая функция в коде приложения была покрыта тестами, проверяющими все возможные пути. При этом активно использовали моки, заменяющие собой другие части системы. Например, проверяя функцию конвертации рублей в валюту, мы подавали на вход функции поддерживаемые ей рубли, чтобы проверить, что на выходе получим валюту. Сравнение происходило с эталонными величинами. Также проверяли реакцию функции на невалидные данные.
Component Tests
Здесь мы проверяли компоненты мобильного банка. Так как у нас микросервисная архитектура, нужно было проверить доступность всех микросервисов, а также, как пример, доступность базы данных. Для сервиса, ответственного за расчетные счета клиента, мы выполняли запрос к базе данных для получения расчетного счета и проверки того, что счет может быть получен.
Services Tests
Мы проверяли API, через которое в предыдущем примере отправляются запросы к базе данных. Отправляли GET-запрос на получение номера расчетного счета и проверяли ответ на него. Обязательно отправляли какой-либо некорректный запрос, например, с несуществующим id клиента, и проверяли, что ответ соответствует ожидаемому.
UI Tests
Например, мы проверили корректную реакцию системы на заполнение полей счета, а также ответ системы на нажатие кнопки «Открыть вклад».
Visual Tests
Мы протестировали устройства с разными версиями iOS и Android и диагональю экрана и проверили расположение элементов приложения. Эта проверка была нужна, чтобы убедиться, что при любом сочетании этих параметров кнопки не наезжают на логотип и не скрываются за ним, становясь недоступными для нажатия.
Security Tests
Мобильный банк – финансовая система, поэтому его безопасность нужно было обеспечить на всех уровнях. В числе прочего мы проверяли аутентификацию только по правильным данным на уровне пользовательского интерфейса и получение информации только в ответ на запрос с корректным токеном на уровне сервисов.
Performance Tests
Одним из тестов было сравнение с эталоном времени ответа сервера на запрос приложения. Также мы проверили работу приложения при максимально ожидаемом количестве одновременно работающих пользователей в системе.
Accessibility Tests
Проверили голосовой поиск и отображение элементов разметки с активированным режимом для слабовидящих.
О том, как можно организовать автоматизацию тестирования с нуля, мы расскажем подробнее в одной из следующих статей.
Спасибо за внимание! Надеемся, что перевод был вам полезен.