Ручное тестирование: виды, методы, инструменты, лайфхаки от QA Service Lab

Содержание:

• Цели ручного тестирования
• Этапы проведения ручного тестирования
• Виды ручного тестирования
• Чек-лист по ручному тестированию
• Ручное тестирование методы
• Плюсы и минусы ручного тестирования
• Лучшие практики ручного тестирования
• Мифы о ручном тестировании
• Используемые инструменты при ручном тестировании

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

Цели ручного тестирования

Цели ручного тестирования просты, и, в принципе, совпадают с общими целями тестирования программных продуктов:

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

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

Ручное тестирование может проводиться на всех этапах жизненного цикла ПО.

На ранних стадиях разработки:

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

На более поздних этапах разработки:

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

Во время поддержки и сопровождения:

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

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

Виды ручного тестирования

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

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

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

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

Чек-лист по ручному тестированию

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

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

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

Если простыми словами – это точечные, но детальные планы проверки небольшого участка функциональности либо аспекта качества, который содержит ожидаемый результат и с которым будет сравниваться фактический результат, после того как тест будет выполнен. К примеру, чтобы проверить, работает ли функция сложения в программе-калькуляторе, планируют проверку «5 + 23» и ожидают результат «28». Если же получится какой-то другой, то такой тест будет признан не пройденным и будет составляться баг репорт. К финалу основной стадии разработки ПО тестовые сценарии должны покрывать практически весь функционал продукта. Хороший тест-кейс должен быть ёмким, прозрачным и понятным не только автору, но и любому специалисту, которому также потребуется работа с этим документом.

Ручное тестирование методы

Существует много методов и подходов к проведению ручного тестирования. Вот несколько примеров применения ручного тестирования:

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

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

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

У ручного тестирования немало преимуществ. В первую очередь – это гибкость и адаптивность. Ручное тестирование позволяет быстро реагировать на изменения в требованиях и функциональности продукта. Ручное тестирование позволяет провести более глубокий анализ функциональности. Оно позволяет выявить более редкие и скрытые дефекты и ошибки, которые могут быть упущены при автоматизированном тестировании. Тестировщик может обратить внимание на детали, которые не всегда могут быть замечены программой. Чаще всего, только ручное тестирование позволяет оценить, насколько удобен и интуитивно понятен пользовательский интерфейс продукта с точки зрения пользователя. И конечно же, это низкая стоимость затрат для внедрения, что делает его более доступным для небольших компаний и стартапов.

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

Важно отметить, что ручное тестирование и автоматизированное тестирование не являются взаимоисключающими. Они должны использоваться вместе для достижения наилучших результатов. Потому что как автоматизированное тестирование не может полностью заменить ручное, так и ручное тестирование не может полностью заменить автоматизированное тестирование.

Лучшие практики ручного тестирования

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

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

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

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

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

Используемые инструменты при ручном тестировании

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

Это довольно лёгкий в освоении и настройке плагин, который позволяет создавать, настраивать и проходить свои тестовые сценарии. А если хочется альтернативы — есть Redmine, Yandex Tracker или Test IT. Но существуют и более упрощенные системы, доступные бесплатно. Например — Bugzilla, система управления ошибками, позволяющая отслеживать и регистрировать баги. А для бесплатного, но полноценного хранения тест кейсов и отслеживания тестовых прогонов – можно воспользоваться TestLink — сервисом для организации процесса тестирования с открытым исходным кодом. Он позволяет создавать и поддерживать взаимосвязанные между собой проекты, планы, наборы тестов и непосредственно тесты, а также оформлять отчёты и вести статистику о проделанной работе. BrowserStack и LambdaTest — проверенные сервисы для тестирования сайтов и мобильных приложений. Кстати, важный момент — оба в настоящий момент официально работают в России. Postman — классика для тестирования API. Позволяет вручную отправлять запросы, анализировать ответы и проверять интеграцию разных компонентов. Как возможная альтернатива — Insomnia.

Кроме того, для ручного тестирования веб приложений практически невозможно обойтись без Browser DevTools – это встроенные инструменты разработчика в браузерах (например, Chrome DevTools), которые помогают анализировать HTML, CSS, JavaScript, а также выявлять ошибки на уровне интеграций фронтенда и бекенда. А в случае с тестированием мобильных или десктоп приложений, просто не обойтись без снифферов траффика, таких как Fiddler, WireShark и Charles. Они помогают не только увидеть содержимое запросов и ответов, которыми обмениваются различные части приложения, но и провести дополнительные тесты, например подмену данных.

Команда QA Service Lab про ручное тестирование знает не понаслышке: некоторые наши сотрудники занимались тестированием еще в те времена, когда в России это даже не было отдельным видом деятельности в IT, а QA-отделы были только у самых крупных игроков рынка. Мы в компании сочетаем ручное тестирование с другими передовыми подходами в области обеспечения качества для того чтобы наши заказчики получали оптимальный результат в разумные сроки. Благодаря ручному тестированию, мы проводим большое количество проверок нетривиальных сценариев использования ПО, что позволяет нам находить и локализовывать самые сложные баги. Мы проводим ручное нефункциональное тестирование, для того чтобы глубже понимать пользовательский опыт, учитывать уникальные сценарии использования, находить неочевидные ошибки и адаптироваться к изменяющимся требованиям, что особенно важно в сложных и нестандартных проектах. Именно это обеспечивает высокое качество ПО, которым, в итоге, будут довольны и пользователи, и заказчики.