Что такое мануал тест

Чтобы создавать качественные программы и зарабатывать на них, бизнесу нужны не только разработчики, но и тестировщики. Это хорошая профессия для старта в 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-инженера с мануального тестирования — это все еще хороший ход. Таким образом вы изучите базовые принципы проверки качества и подготовитесь к тому, чтобы переходить на новый этап карьеры — к автоматизации. Главное — быть готовым постоянно изучать на практике новые инструменты. 

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

Детально разбираем то, как проводить ручное тестирование, когда оно лучше автоматизированного, что нужно уметь тестировщику и как он может построить свою карьеру от джуниора до тест- лида. Гид подготовлен совместно с руководителем отдела тестирования компании 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%, поэтому ручные тестировщики всегда будут пользоваться спросом на рынке труда.

1.

Manual QA course
Lecture 8. Виды тестирования. Часть 3
Дорофеев Максим

2.

Виды тестирования. По степени
подготовленности к тестированию.
— Тестирование по документации (formal
testing);
— Интуитивное тестирование (ad hoc
testing);
— Исследовательское тестирование
(Exploratory testing).

3.

Интуитивное тестирование.
Выполняется:
— При полном отсутствии плана и
документации;
— С использованием собственного опыта и
здравого смысла.

4.

Интуитивное тестирование. Ad — hoc
testing.
Плюсы:
— Находятся “хитрые и коварные” дефекты;
— Нет затрат на проектирование тестов;
— Ускоряется обучение новых сотрудников;
— Легкость в осуществлении.

5.

Интуитивное тестирование. Ad — hoc
testing.
Минусы:
— Нет гарантий по покрытию тестами;
— Высокий риск пропустить ошибку в стандартных
функциях

6.

Исследовательское тестирование.
Exploratory testing
Скорее подход, чем вид
тестирования.

7.

Исследовательское тестирование.
Exploratory testing
— более формальная версия Ad — hoc тестирования, не требующая
написания тест — кейсов, но подразумевающая, что каждый
последующий тест выбирается на основе результатов предыдущего.

8.

Исследовательское тестирование.
Exploratory testing

9.

Исследовательское тестирование.
Exploratory testing

10.

Исследовательское тестирование.
Вдохновение.
1. Информация
— Книги;
— Сайты;
— Документация по продукту.
2. Модель
— Сценарии использования;
— Требования;
— Функционал.

11.

Исследовательское тестирование.
Руководство.
—
Идеи;
Чеклисты;
Особенности функционирования;
Перечень рисков;
Покрытие.

12.

Исследовательское тестирование.
Результаты.
—
Баг — репорты;
Заметки;
Отчёты о состоянии ПО;
Другое.

13.

Исследовательское тестирование.
Плюсы.
— Возможность найти больше дефектов;
— Не нужно тратить время на предварительное описание всех
сценариев;
— Не нужна поддержка тестовых сценариев;
— Не происходит привыкание к тестовым сценариям;
— Не теряется цельное видение продукта;

14.

Исследовательское тестирование. Когда
применять?
— Мало времени;
— Сложности с требованиями;
— Небольшой проект;
— Пришел внезапный запрос на изменения;
— Тестировщики постоянно проходят одни и те же сценарии;
— Когда хочется перестраховаться.

15.

Исследовательское тестирование. Когда
одним исследовательским
тестированием не обойтись.
— Приложение стандартизировано;
— Проводится интеграционное тестирование;
— Тестовые сценарии отдаются на аутсорс;
— Длительный проект.

16.

Исследовательское тестирование.
Мифы.
— Исследовательское тестирование невозможно
проконтролировать.

17.

Исследовательское тестирование.
Мифы.
— Нельзя доверить тестирование первому
встречному.

18.

Исследовательское тестирование.
Мифы.
— Сложно “продать” исследовательское
тестирование заказчику, объяснить его
необходимость.

19.

Исследовательское тестирование. Что
не есть Exploratory Testing?
Заблуждение «Быстрые проверки – это и
есть исследовательское тестирование».

20.

Исследовательское тестирование. Что
не есть Exploratory Testing?
Заблуждение «Exploratory testing – это
недокументированный процесс».

21.

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

22.

Тестирование GUI. Заблуждения.
— Пользовательский интерфейс — самая простая часть проекта;
— Главное, чтобы работало, а как выглядит — неважно;
— Это никто не заметит;
— Оттестируем и исправим, когда будет время.

23.

Тестирование GUI. Хороший пример.
WEB.

24.

Тестирование GUI. Хороший пример.
Mobile.

25.

Тестирование GUI. Плохой пример. WEB.

26.

Тестирование GUI. Плохой пример.
Mobile

27.

Тестирование GUI. Задачи.
— Ошибки в функциональности посредством интерфейса;
— Необработанные исключения при взаимодействии с интерфейсом;
— Потеря или искажение данных, передаваемых через элементы
интерфейса;
— Ошибки в интерфейсе (несоответствие проектной документации,
отсутствие элементов интерфейса).

28.

Тестирование GUI. Фазы.
— Анализ требований к пользовательскому интерфейсу;
— Разработка документации;
— Выполнение тестов и сбор информации;
— определение полноты покрытия пользовательского интерфейса
требованиями;
— Предоставление информации о этапе тестирования.

29.

Тестирование GUI. Методы
— Ручное тестирование;
— Автоматическое тестирование.

30.

Тестирование GUI. Ручное тестирование.
Плюсы:
— Поиск “Косметических” дефектов;
— Анализ выполняется по формальным признакам, а согласно
человеческому восприятию.

31.

Тестирование GUI. Ручное тестирование.
Минусы:
— Требуются значительные человеческие и временные ресурсы;
— При проведении повторных циклов тестирования, время
затраченное на тестирование возрастает.

32.

Тестирование GUI. автоматизированное
тестирование.
Плюсы:
— Высокая скорость выполнения;
— больший объем покрытия;
— Не требуется участие людей.

33.

Тестирование GUI. Автоматизированное
тестирование.
Минусы:
— Анализ успешности будет выполнятся по формальным признакам;
— Невозможность поиска косметических дефектов;
— Высокая стоимость поддержки.

34.

Interoperability Testing.
Тестирование взаимодействия — это функциональное
тестирование, проверяющее способность приложения
взаимодействовать с одним и более компонентами
или системами и включающее в себя интеграционное
тестирование (integration testing)

35.

Виды тестирования связанные с
изменениями.
—
Дымовое тестирование (Smoke Testing);
Регрессионное тестирование (Regression Testing);
Тестирование сборки (Build Verification Test);
Санитарное тестирование или проверка
согласованности/исправности (Sanity Testing).

36.

Виды тестирования связанные с
изменениями. Smoke testing
Понятие дымовое тестирование пошло из инженерной
среды:
«При вводе в эксплуатацию нового оборудования
(«железа») считалось, что тестирование прошло
удачно, если из установки не пошел дым»

37.

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

38.

Smoke testing. Примеры тестов.
— Функция входа в систему;
— Функции связанные с управлением данных (Запись, хранение,
обработка, удаление, изменение и тд.);
— Функции связанные с доступом ко всем вкладкам.

39.

Smoke testing.
Для составления набора smoke — тестов, необходимо определить какие
задачи нужно решить нашему приложению, какие важные требования
мы должны соблюдать и в какой последовательности.

40.

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

41.

Smoke testing.
Аналогами дымового тестирования являются Build
Verification Testing и Acceptance Testing, выполняемые
на функциональном уровне командой тестирования,
по результатам которых делается вывод о том,
принимается или нет установленная версия
программного обеспечения в тестирование,
эксплуатацию или на поставку заказчику.

42.

Smoke testing.
Smoke — тесты — самые первые кандидаты на
автоматизацию!

43.

Sanity Testing.
Узконаправленное тестирование достаточное для
доказательства того, что конкретная функция
работает согласно заявленным в спецификации
требованиям.

44.

Sanity testing. Особенности.
— Глубокое исследование определенной функциональности
приложения.
— Это как правило ручное тестирование (Не лучший кандидат для
автоматизации);
— Проверка работы функции (модуля) в соответствии требованиям
(спецификациям);
— Это своего рода приемочное тестирование.

45.

Sanity Testing vs Smoke Testing
Эти виды тестирования имеют «вектора движения»,
направления в разные стороны. В отличии от
дымового (Smoke testing), санитарное тестирование
(Sanity testing) направлено вглубь проверяемой
функции, в то время как дымовое направлено вширь,
для покрытия тестами как можно большего
функционала в кратчайшие сроки.

46.

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

47.

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

48.

Regression Testing.
3 основных типа регрессионного тестирования:
—
Регрессия багов (Bug regression) — попытка доказать, что
исправленная ошибка на самом деле не исправлена
Регрессия старых багов (Old bugs regression) — попытка доказать, что
недавнее изменение кода или данных сломало исправление старых
ошибок, т.е. старые баги стали снова воспроизводиться.
Регрессия побочного эффекта (Side effect regression) — попытка
доказать, что недавнее изменение кода или данных сломало другие
части разрабатываемого приложения

49.

Build Verification Test.
Тестирование направленное на определение
соответствия, выпущенной версии, критериям
качества для начала тестирования. По своим целям
является аналогом Smoke testing, направленного на
приемку новой версии в дальнейшее тестирование
или эксплуатацию. Вглубь оно может проникать
дальше, в зависимости от требований к качеству
выпущенной версии

50.

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

51.

Build Verification Test.
Если сборка не соответствует критериям качества, то команда
тестирования вправе ее отклонить (Reject), приложив список ошибок.
Дальнейшие варианты действий:
— Если сборка не работает по вине билд — мастера, то принимается
решение о проведении перевыкладки версии (Re — deploy);
— Если сборка действительно не соответствует критериям качества, то
производится откат (Roll back) на предыдущую версию.

52.

53.

54.

55.

Вопросы и ответы

56.

https://www.guru99.com/smoke-sanity-testing.html
https://software-testing.org/testing/otlichie-sanitarnogo-sanity-testing-otdymovogo-smoke-testing-vidov-testirovaniya.html

Сравните с автоматизацией тестирования .

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

Обзор

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

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

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

1. Выберите план тестирования высокого уровня, в котором выбрана общая методология, а также определены и приобретены такие ресурсы, как люди, компьютеры и лицензии на программное обеспечение.
2. Напишите подробные тестовые примеры , определяя четкие и краткие шаги, которые должен предпринять тестировщик, с ожидаемыми результатами.
3. Назначьте тестовые примеры тестировщикам, которые вручную следуют инструкциям и записывают результаты.
4. Составьте отчет об испытаниях с подробным описанием выводов тестировщиков. Отчет используется менеджерами, чтобы определить, можно ли выпустить программное обеспечение, а если нет, то он используется инженерами для выявления и устранения проблем.

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

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

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

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

Этапы

Есть несколько этапов. Они есть:

Модульное тестирование

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

Интеграционное тестирование

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

Системное тестирование

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

Приемочное тестирование пользователей

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

Выпуск или тестирование развертывания

Команда на месте отправится на объект клиента, чтобы установить систему в настроенной клиентом среде, и проверит следующие моменты:

1. Независимо от того, запущен ли SetUp.exe.
2. При установке есть удобные экраны
3. Сколько места занимает система на HDD
4. Система полностью удалена при выборе удаления из системы.

Преимущества ручного тестирования

• Низкая стоимость эксплуатации, так как не используются программные инструменты
• Большинство ошибок выявляются при ручном тестировании.
• Люди наблюдают и судят лучше, чем автоматизированные инструменты

Сравнение с автоматическим тестированием

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

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

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

Смотрите также

• Метод испытания
• Юзабилити-тестирование
• GUI тестирование
• Тестирование программного обеспечения
• Автоматизация тестирования без кода

использованная литература

Детально разбираем то, как проводить ручное тестирование, когда оно лучше автоматизированного, что нужно уметь тестировщику и как он может построить свою карьеру от джуниора до тест- лида. Гид подготовлен совместно с руководителем отдела тестирования компании 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- дизайн.