Сценарий ручного тестирования

Гид по ручному тестированию приложений: преимущества, этапы и методологии

Детально разбираем то, как проводить ручное тестирование, когда оно лучше автоматизированного, что нужно уметь тестировщику и как он может построить свою карьеру от джуниора до тест- лида. Гид подготовлен совместно с руководителем отдела тестирования компании Agima Дариной Гордеевой.

Привет! Меня зовут Дарина Гордеева. Работаю в компании AGIMA руководителем отдела почти 3 года. В области тестирования и обеспечения качества более 6 лет. За это время прошла путь от джуниора до руководителя отдела, занимаясь тестированием железа, а также мобильных и веб-приложений, автоматизацией и настройкой процессов QA. Сегодня я расскажу вам про особенности, возможности и скрытые проблемы ручного тестирования.

Напомним, что любой читатель, воспользовавшийся промословом “Хабр” может получить скидку в 10 000 рублей на понравившийся курс, а самые усидчивые и внимательные могут собрать себе скидку в 25 000 рублей, разгадывая ребусы из материалов, подготовленных совместно с агентством Agima:

• Как с первого раза попасть в AppStore: пошаговое руководство;
• 8 этапов процесса разработки интерфейса мобильного приложения;
• А/В-тесты не работают. Проверьте, что вы делаете не так.

Оперативность, гибкость, возможность импровизации и другие плюсы

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

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

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

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

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

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

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

Автотесты не позволяют проверить удобно ли использовать новые возможности приложения — проверка юзабилити всегда осуществляется вручную.

Skillbox рекомендует: онлайн-курс Fullstack-мобильный разработчик.

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

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

Проблемы ручного тестирования и их решения

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

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

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

Усугубляет ситуацию вероятность того, что часть встреченных багов ещё не будет иметь строгого описания потому что причины их возникновения пока не понятны. Как бороться с такими повторными тестированиями? Либо найти уже источник ошибки и устранить его, либо — всё таки автоматизировать прохождение проблемных кейсов — в этом случае переход к программным тестам будет вполне оправдан как с точки зрения времени, так и финансово. (Нет, это не противоречит вышесказанному — потому что такие ситуации возникают уже в ходе активной разработки и к этому времени вы уже в любом случае развернёте процессы автотестирования).

В любом случае — появление первых кейсов, нуждающихся в регрессивных тестах или релиз второй версии приложения и соответствующее этим событиям масштабирование команды — тот момент, когда автоматизация станет актуальна (но не исключит ручное тестирование новых возможностей). На этом этапе автоматизация уже начнёт экономить время: разработчик сможет сам, ещё до передачи QA-отделу запустить регресс-тесты новой фичи, чтобы убедиться, что она не ломает существующий функционал, а тестировщику не придётся лишний раз проходить по набившим оскомину базовым кейсам. Ещё одно преимущество внедрения автотестов на этом этапе — их можно запускать по определённому расписанию — каждую ночь, в дни окончания спринтов или при публикации новых сборок приложения.

При этом нельзя забывать несколько вещей:

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

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

Этапы тестирования: что, когда и как

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

Тестировщик появляется в процессе создания приложения уже на ранних этапах. Вот у клиента появляется некая идея, бизнес-аналитики собирают из этого требования — а тестировщики уже в этот момент приступают к работе, проверяя эти требования.

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

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

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

Skillbox рекомендует: онлайн-курс Дизайн мобильных приложений

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

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

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

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

Следующий этап — проведение регресс-тестов. В ручном или автоматическом режиме проводится основной заранее запланированный массив тестов.

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

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

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

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

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

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

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

Время ребуса: отгадайте его и десятипроцентная скидка на любой из курсов Skillbox ждёт вас прямо сейчас или проявите усидчивость и соберите ответы на все ребусы — эти скидки суммируются между собой (но ни с какими другими скидками на курсы Skillbox).

Формализация тестирования: тест-план, формат баг-репортов, отчётность

Для того, чтобы подготовиться к функциональному тестированию QA-инженер составляет тест-план. Это — документация, которая потребуется ему при тестировании продукта, список действий, которые ему нужно будет совершить. В тест-плане обозначаются сроки тестирования, описываются продукт или конкретная задача — для того, чтобы точно определить, что именно надо проверять. Детально описываются все основные тест-кейсы. Перечисляются виды тестирования, которые необходимы: функциональное и, например, нагрузочное. Описывается порядок автоматизации тех или иных кейсов и то, на каких этапах они будут автоматизированы.

Завершается тест-план описанием формата отчёта: нужно заранее объяснить, в каком виде будет предоставлен результат. Наиболее распространённым форматом отчёта является список тест кейсов со статусом их прохождения. Зная, насколько кейсы покрывают весь объём требований и прочитав отчёт, можно будет сделать вывод о текущем состоянии разработки приложения. Для этого достаточно будет посмотреть, сколько из них было успешно пройдено в той или иной сборке.

Финальной отмашкой, свидетельствующей о том, что продукт готов является статус “все требования покрыты кейсами, все кейсы пройдены успешно”.

Кроме того, в тест-плане формализуется формат отчёта по ошибкам. Это может быть баг-лист, список задач в трекере.

Задача тестировщика — предоставить наиболее полную информацию о качестве продукта всем участникам команды.

Что нужно знать и уметь, чтобы стать тестировщиком

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

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

Специалист по автоматизированному тестированию — это отдельная профессия, с абсолютно другим набором знаний. Качественное автотестирование — это не просто скрипты, но и понимание того, как приложение устроено изнутри, и специфические умения, вроде знания о том, как параллелить тесты или о том, как запускать их в облаке или на нескольких серверах. Только такой пул навыков позволяет с гордостью называть себя “автоматизатором с большой буквы”. Так что без знания языков, их фреймворков, принципов ООП и внимательной слежкой за развитием технологий настоящему автотестеру не обойтись.

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

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

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

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

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

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

Тестирование — лишь одна из многих областей мобильной разработки, которые мы рассматриваем в рамках курса “Fullstack-мобильный разработчик”. Сотрудничающие с нами профессионалы индустрии будут делиться с вами своим опытом и проверять ваши домашние задания, а итогом обучения может стать принятие на стажировку в крупную компанию. Приходите к нам учиться!

Skillbox рекомендует:

• Управление digital-проектами;
• Анимация интерфейсов;
• UX- дизайн.

• Определение
• Цели
• Типы
• Как проводить
• Мифы
• Ручное vs Автоматизированное

Что это

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

Любое приложение должно быть протестировано вручную прежде, чем автоматизировать процесс. Это необходимо для того, чтобы определить, целесообразно ли вообще внедрять автоматизацию. Для проведения ручного тестирования не нужно уметь пользоваться какими-либо инструментами. Один из фундаментальных принципов тестирования — 100% автоматизации невозможна. Поэтому ручное тестирование неизбежно в каждом проекте.

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

Цели

Главная цель ручного тестирования — убедиться, что в приложении нет ошибок и что оно работает в полном соответствии с требованиями.

Для этого на стадии тестирования создаются тест кейсы, которые должны покрывать (в идеале) 100% функциональности тестируемого приложения.

Также ручной тестировщик проверяет, что обнаруженные баги исправляются разработчиками и повторно тестирует то, что было исправлено.

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

Типы

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

Выделяют следующие типы тестирования:

• Тестирование “черного ящика” (Black Box Testing)
• Тестирование “белого ящика” (White Box Testing)
• Unit-тестирование
• Интеграционное тестирование (Integration Testing)
• Системное тестирование (System Testing)
• Приемочное тестирование (Acceptance Testing)

Как проводить

1. Прочитать и понять документацию и (если есть) AUT (Application Under Test)
2. Создать черновики тест кейсов, которые покрывают требования, описанные в документации
3. Сделать ревью написанных тест-кейсов с тим-лидом
4. Выполнить тест кейсы
5. Сообщить о найденных багах
6. После того, как баги исправлены, еще раз выполнить тест-кейсы, которые не работали ранее для того, чтобы убедиться, что после исправлений разработчиков они работают.

Мифы

Ниже мы собрали распространенные мифы и факты, относящиеся к тестированию ПО:

Миф: Ручное тестирование простое. Любой может протестировать приложение вручную.

Это неправда. Тестировщики сегодня должны обладать широким набором навыков.

Миф: Тестирование гарантирует 100%-е отсутствие багов в приложении.

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

Миф: Автоматизированное тестирование более качественное, чем ручное.

Невозможно автоматизировать тестирование на 100%. Для максимально качественного тестирования продукта необходимы и ручные тестировщики.

Миф: Тестировать — очень просто.

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

Ручное тестирование vs Автоматизированное тестирование

Заключение

Ручное тестирование — неотъемлемая часть процесса разработки. Люди, вовлеченные в процесс тестирования работают с приложением точно так же, как с ним работают конечные пользователи. Невозможно автоматизировать процесс тестирования на 100%, поэтому ручные тестировщики всегда будут пользоваться спросом на рынке труда.

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

В
табл. 19.1 приведен пример сценария
для ручного
тестирования пользовательского
интерфейса
[7].

Ручное
тестирование пользовательского
интерфейса
удобно тем, что контроль корректности
интерфейса проводится человеком, т.е.
основным «потребителем» данной
части программной системы. К тому же
при чисто косметических изменениях в
интерфейсах системы, не отраженных в
требованиях (например, при перемещении
кнопок управления на 10 пикселей влево)
анализ успешности прохождения теста
будет выполняться не по формальным
признакам, а согласно человеческому
восприятию.

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

19.1.3.2. Сценарии на формальных языках

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

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

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

И
при передаче информации в тестируемый
интерфейс и при получении информации
для анализа могут использоваться два
способа доступа к элементам интерфейса
[7]:

• позиционный,
  при котором доступ к элементу
  осуществляется при помощи задания его
  абсолютных (относительно экрана) или
  относительных (относительно окна)
  координат и размеров;

• по
  идентификатору, при котором доступ к
  элементу осуществляется при помощи
  получения интерфейсного элемента при
  помощи его уникального идентификатора
  в пределах окна.

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

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

Соседние файлы в папке ++часть 2 Совр веб-техн

• #
• #
• #
• #
• #
• #
• #
• #
• #

Чтобы создавать качественные программы и зарабатывать на них, бизнесу нужны не только разработчики, но и тестировщики. Это хорошая профессия для старта в IT, потому что она востребована на рынке и ей можно относительно быстро обучиться с нуля. Для QA-инженера обучение не заканчивается после курсов. Чтобы получить хорошую работу и расти в профессии, нужно постоянно изучать новые технологии на практике и быть готовым учиться программировать. 

Рассказываем о том, что ждет тестировщика на работе, какие основные этапы, методы и виды тестирования нужно понимать, а также стоит ли бояться автотестов.

Чем занимается мануальный тестировщик?

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

Чего ждут работодатели от тестировщиков? Читайте в нашем свежем исследовании рынка. 

Из каких шагов состоит ручное тестирование? 

1. Читаем документацию и работаем с требованиями. Тестировщики узнают, как должно работать ПО, чего от него ждут разработчики и бизнес. На этом этапе QA-инженер может добавить требования, если они неполные, и сократить, если они невыполнимы.
2. Планируем тестирование. Определяем объем работы, бюджет, выбираем методы, типы и инструменты. 
3. Разрабатываем тестовые сценарии. Специалисты создают тест-кейсы — алгоритм проверки ПО, а также чек-листы и готовят среду для выполнения тестов. 
4. Проводим первое тестирование. Команда выполняет тесты и сообщает разработчикам об ошибках. 
5. Делаем повторное тестирование. Когда программисты исправили ошибки, тестирование повторяют, чтобы проверить, что после изменений все работает.
6. Готовим отчет о результатах. В итоговом документе описывают все тесты, выполненные во время разработки программы.

Какие есть виды ручного тестирования?

Модульное тестирование (Unit-тесты) предполагает проверку отдельных компонентов ПО или частей кода. Это эффективный способ тестирования, если готовое приложение обновляют или дополняют функционалом. Если добавить новые модули, ошибки в них могут повлиять на работу других, уже налаженных и протестированных частей программы. Вместо того чтобы ломать сервис таким образом, можно сначала протестировать модуль отдельно, а потом добавить его в систему.

Интеграционное тестирование (Integration Testing) проверяет, как отдельные части приложения работают вместе. Часто бывает, что страницу авторизации и личный кабинет приложения программируют разные специалисты. Их инструменты и подходы могут отличаться, из-за этого конечный сервис может работать с ошибками. На этом этапе уже не нужно проверять отдельные элементы, например страницу авторизации, — вы уже сделали это unit-тестом. Здесь важно запустить разные элементы в группе и проверить, что они работают корректно. Например, что авторизация запускает процесс создания личного кабинета и все данные пользователя в нем отражаются правильно. 

Системное тестирование (System Testing) нужно, чтобы понять, соответствует ли ПО исходным техническим требованиям. Это этап, когда модульные и интеграционные тесты уже прошли. Теперь время смотреть на готовый продукт, кликать по кнопкам, проверять, что все работает как задумано, сервисом удобно и приятно пользоваться. 

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

Что такое черный, белый и серый ящики?

Так называются методы тестирования. Они отражают то, сколько знает тестировщик о продукте на старте работы. Разберем каждый подход подробнее. 

Тестирование «черного ящика» (Black Box Testing) — метод, в котором тестировщик ничего не знает о коде или структуре продукта. QA работает с программой как конечный пользователь. Этим методом проверяют функциональность: делает ли приложение то, что должно? 

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

Тестирование «белого ящика» (White Box Testing), также известное как glass box или прозрачное тестирование, — это, по сути, проверка исходного кода. Тестировщик анализирует блоки системы по отдельности и ищет проблемы. 

Например, прозрачным тестированием можно проверить формы ввода контактов пользователя в интернет-магазине. Со стороны пользователя это выглядит так: вы нажали кнопку, email-адрес отправился в базу подписчиков магазина, вам на почту пришло письмо с промокодом на скидку. Если тестировать эту часть «черным ящиком», вы можете нажать на кнопку и не получить никакого письма. Зафиксировали баг, тест заканчивается. Методом «белого ящика» можно выявить, почему это происходит. QA-специалист смотрит, чтобы на уровне кода форма была надежно защищена от взлома и данные пользователей не утекли в руки мошенников. Также он следит, чтобы адрес почты отправился в базу данных, а дальше запустился процесс автоматической рассылки новостей об акциях и промокодах. 

Тестирование «серого ящика» (Grey Box Testing) объединяет методы тестирования «белого» и «черного ящика». Цель этого подхода — найти любые ошибки в пользовательском интерфейсе или в разработке. У тестировщика нет доступа к коду приложения, но он знает общую структуру сервиса и его ограничения.

Для примера вернемся к форме в интернет-магазине. Например, при оформлении заказа нужно ввести имя и фамилию, тестировщику нужно проверить работу текстовых полей. QA знает, что у системы есть ограничение по длине фамилии, например, в 100 символов. Задача тестировщика — найти фамилии длиннее 100 символов (самая длинная в книге рекордов Гиннеса состоит из 700). Также он должен проверить, как будет вести себя система, если ввести в поле больше 100 букв. Приложение должно как минимум не ломаться и выдавать уведомление об ошибке.

Заменят ли мануальных QA автотесты?

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

Автоматизированные тесты не могут найти абсолютно все баги. Они распознают только те, которые прописаны в их сценариях. Кроме того, сами автотесты могут содержать в себе ошибки кода, они не идеальны. Ручное тестирование в этом плане более гибкое. Живой QA может придумать нестандартные пользовательские сценарии, оценить эстетическую сторону сервиса и сугубо человеческий критерий удобства. 

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

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

Данил Ильин, директор и основатель IT-кадрового агентства HEAAD

«В целом порог вхождения на рынок тестировщиков невысок: junior-специалистов с охотой берут на работу с перспективой «на вырост». Так, за полгода-год усердной работы начинающий ручной тестировщик может вырасти до уровня middle. Самое важное в резюме — портфолио, которое начинающий специалист может собрать прямо сейчас: протестировать любой известный ему сайт или приложение. Главное — правильная логика тест-кейса и его грамотное описание».

Другие советы начинающим тестировщикам от экспертов читайте в этой статье.

Автор: Энди Найт (Andy Knight)

Оригинал статьи: http://automationpanda.com/2017/10/08/bdd-101-manual-testing/

Перевод: Ольга Алифанова

Философия разработки через реализацию поведения ставит во главу угла автоматизацию: спеки поведения должна превратиться в автоматизированные тесты. Однако BDD вполне может включать в себя и ручное тестирование. У ручного тестирования есть свое место и свои задачи, даже в BDD. Помните, поведенческие сценарии – это в первую очередь поведенческие спецификации, и их ценность выходит за рамки тестирования/автоматизации. Любой сценарий можно прогнать как ручной тест. Следовательно, встают вопросы, в каких случаях пользоваться ручным подходом, и как с ним управляться.

Когда следует подключать ручное тестирование?

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

• Отдача от автоматизации этих сценариев не оправдывает затрат.
• Сценарии не будут включаться в регресс или непрерывную интеграцию.
• Они временные (например, хотфиксы).
• Автоматизация этих сценариев будет чересчур сложной или хрупкой.
• Фича по своей природе нефункциональна (например, производительность, юзабилити, и т. д.)
• Команда еще учится BDD и пока не готова автоматизировать все сценарии.

Ручной подход также годится для исследовательского тестирования, при котором инженеры полагаются на опыт, а не на явно описанные тест-процедуры, и «исследуют» тестируемый проудкт на предмет багов и проблем качества. Оно дополняет автоматизацию, потому что оба эти стиля служат разным целям. Однако сами поведенческие сценарии несовместимы с исследовательским тестированием. Цель исследования – дать свободу действий инженерам, не сковывая их формальными тест-планами, и они находят проблемы, которые поймает только пользователь. Для исследовательского тестирования через реализацию поведения лучше не писать сценарии, а подойти к вопросу комплексно: тестировщики должны притвориться пользователями и обращаться с продуктом, как с коллекцией взаимодействующих поведенческих паттернов. Если исследование выявит пробелы в поведении, новые поведенческие сценарии должны быть добавлены в каталог.

Как организовать ручное тестирование?

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

Репозиторий

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

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

Тэги

Сценарии должны классифицироваться как ручные или автоматизированные. Когда фреймворк BDD прогоняет тесты, ему необходимо исключать неавтоматизированные. В противном случае отчеты о тестировании будут полны ошибок. В Gherkin сценарии классифицируются при помощи тэгов. К примеру, сценарий может быть отмечен или как @manual, или как @automated. Третий тэг, @automatable, можно применять, чтобы выделять сценарии, предназначенные для автоматизации, но еще не автоматизированные.

У некоторых фрейморков вопрос тэгов решен очень изящно. В Cucumber-JVM тэги можно создавать как классовые опции средства запуска. Это означает, что тэги можно установить как «~@manual», чтобы избежать ручных тестов. В SpecFlow любой сценарий со специальным «@ignore»-тэгом будет автоматически пропущен. В любом случае я рекомендую использовать специальные теги, чтобы выделять ручные тесты, потому что для игнорирования тестов может быть масса причин (к примеру, известные баги).

Дополнительные комментарии

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

Кажется очень заманчивым просто добавить новые шаги в Gherkin, покрывающие доп. информацию для ручного тестирования. Однако это не очень хороший подход. Принципы «хорошего Gherkin» должны применяться ко всем сценариям вне зависимости от того, автоматизируются они или нет. Высококачественная спецификация нуждается в поддержке, чтобы сохранить ее цельность, документировать при помощи инструментов, и в будущем автоматизировать.

Пример

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

Фича: поиск Google

@automated

Сценарий: Поиск в поисковой строке

Если веб-браузер находится на домашней странице Google

Когда пользователь вводит «панда» в поисковую строку

Тогда на странице результатов показываются ссылки, связанные со словом «панда».

@manual

Сценарий: Поиск картинок

# Домашняя страница Google: http://www.google.com/

# Убедитесь, что среди картинок есть изображения поедающей бамбук панды

Если отображены результаты поиска Google для «панда»

Когда пользователь нажимает на ссылку «Изображения» на верху страницы с результатами

Тогда изображения, связанные с запросом «панда», отображаются на странице результатов.

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

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

Обсудить в форуме

1. Функциональное (ручное) тестирование.
2. Цели функционального тестирования.
3. Виды функционального тестирования.
4. Как выполнить функциональное тестирование?
5. Мифы о ручном тестировании.
6. Ручное тестирование против автоматизированного тестирования.
7. Инструменты для автоматизации ручного тестирования.
8. Заключение.

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

Один из основных принципов тестирования программного обеспечения гласит: «100% автоматизация — невозможна». Совокупность с тем фактом, что функциональное тестирование необходимо для проверки возможности автоматизации, делает ручное тестирование обязательным.

Функциональное тестирование программного обеспечения — самый примитивный метод из всех видов тестирования. Концепции ручного тестирования не требуют знания какого-либо инструмента тестирования.

Цели функционального тестирования

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

Виды функционального тестирования:

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

• Тестирование черного ящика
• Тестирование белого ящика
• Модульное тестирование
• Тестирование системы
• Интеграционное тестирование
• Приемочное тестирование

Как выполнить функциональное тестирование?

1. Прочитайте и поймите документацию проекта программного обеспечения. Кроме того, изучите тестируемое приложение/систему (AUT), если оно доступно.
2. Спроектируйте тестовые случаи, которые охватывают все требования, указанные в документации.
3. Просмотрите и определите базовые тестовые случаи с руководителем группы, клиентом (если применимо).
4. Выполните тестовые случаи на AUT.
5. Зафиксируйте ошибки в баг-трекере.
6. Как только ошибки будут исправлены, снова выполните неудачные тестовые примеры, чтобы убедиться, в корректном функционировании приложения/системы.

Мифы о ручном тестировании

Ниже приведены несколько распространенных мифов и фактов, связанных с тестированием:

Миф: Любой может проводить ручное тестирование.
Факт : Тестирование требует множества навыков.

Миф: Тестирование гарантирует 100% отсутствие дефектов в продукте.
Факт: Тестирование пытается найти как можно больше дефектов. Выявление всех возможных дефектов невозможно. Однако, как показывает практика нашей компании: 96 — 99% вполне достижимый показатель.

Миф: Автоматизированное тестирование более эффективно, чем ручное.
Факт: 100% автоматизация тестирования невозможна. Ручное тестирование программного обеспечения также необходимо.

Миф: Тестировать легко.
Факт: Тестирование может быть чрезвычайно сложным. Тестирование приложения на возможные варианты использования с минимальным набором тестов требует высоких аналитических навыков.

Ручное тестирование VS автоматизированного тестирования