Блог
На чтение 2 мин Просмотров 299 Опубликовано 11.03.2023 Обновлено 04.05.2023
Что такое ручное тестирование?
Ручное тестирование — это процесс проверки программного обеспечения на наличие ошибок, проводимый вручную.
В отличие от автоматического тестирования, при котором тесты запускаются с помощью специального программного обеспечения, при ручном тестировании тестировщик проверяет функциональность программы вручную. В этой статье мы расскажем, зачем нужно ручное тестирование и как оно проводится.
Зачем нужно ручное тестирование?
Проверка пользовательского интерфейса
Одной из главных задач ручного тестирования является проверка пользовательского интерфейса программы. Тестировщик проверяет, как программа взаимодействует с пользователем, находит ошибки в интерфейсе и проверяет, что программа работает правильно в разных сценариях использования.
Ручное тестирование | Manual testing
Пройди бесплатные курсы тестировщика прямо сейчас!
Проверка функциональности
Ручное тестирование также помогает проверить, что программа выполняет все задачи, для которых она была создана. Тестировщик проверяет работу программы в различных сценариях использования и находит ошибки, которые могут привести к неправильной работе программы.
Проверка безопасности
Ручное тестирование позволяет проверить, насколько безопасна программа. Тестировщик может найти ошибки в коде, которые могут привести к утечке данных или другим проблемам безопасности.
Проверка производительности
Ручное тестирование также позволяет проверить производительность программы. Тестировщик может проверить, насколько быстро программа выполняет определенные задачи, и найти ошибки, которые замедляют работу программы.
Как проводится ручное тестирование?
Планирование тестирования
Первым шагом при проведении ручного тестирования является планирование. Тестировщик должен определить цели тестирования, выбрать тестовые сценарии и разработать план тестирования.
Выполнение тестов
После того как план тестирования разработан, тестировщик начинает выполнение тестов. Он проверяет, как программа взаимодействует с пользователем, как выполняются задачи и находит ошибки в программе.
Фиксация ошибок
Повторное тестирование
После исправления ошибок разработчиком, тестировщик проводит повторное тестирование, чтобы убедиться, что ошибки были исправлены и программа работает правильно.
Оценка качества
После завершения тестирования, тестировщик проводит оценку качества программы и готовит отчет о тестировании. В отчете содержится информация о том, какие ошибки были найдены, какие были исправлены, и какая оценка качества программы получена после тестирования.
Тестировщик с нуля / Урок 1 / Что такое тестирование по
Заключение
Ручное тестирование является важным процессом, который позволяет проверить качество программного обеспечения. Оно помогает найти ошибки, которые могут привести к неправильной работе программы, утечке данных или другим проблемам безопасности. При проведении ручного тестирования необходимо правильно планировать тестирование, выполнять тесты, фиксировать ошибки и проводить повторное тестирование.
Поделиться с друзьями
Основатель сайта. Специализируюсь на веб-дизайне, веб-разработке и обожаю технологии. Рассказываю об актуальных профессиях.
Источник: top-prof.ru
Home
Философия разработки через реализацию поведения ставит во главу угла автоматизацию: спеки поведения должна превратиться в автоматизированные тесты. Однако BDD вполне может включать в себя и ручное тестирование. У ручного тестирования есть свое место и свои задачи, даже в BDD.
Помните, поведенческие сценарии – это в первую очередь поведенческие спецификации, и их ценность выходит за рамки тестирования/автоматизации. Любой сценарий можно прогнать как ручной тест. Следовательно, встают вопросы, в каких случаях пользоваться ручным подходом, и как с ним управляться.
Когда следует подключать ручное тестирование?
Автоматизация – не серебряная пуля, и не дает ответ на все вопросы тестирования. Сценарии должны писаться для всех поведений, но в следующих случаях их, скорее всего, не стоит автоматизировать:
- Отдача от автоматизации этих сценариев не оправдывает затрат.
- Сценарии не будут включаться в регресс или непрерывную интеграцию.
- Они временные (например, хотфиксы).
- Автоматизация этих сценариев будет чересчур сложной или хрупкой.
- Фича по своей природе нефункциональна (например, производительность, юзабилити, и т. д.)
- Команда еще учится BDD и пока не готова автоматизировать все сценарии.
Ручной подход также годится для исследовательского тестирования, при котором инженеры полагаются на опыт, а не на явно описанные тест-процедуры, и «исследуют» тестируемый проудкт на предмет багов и проблем качества. Оно дополняет автоматизацию, потому что оба эти стиля служат разным целям. Однако сами поведенческие сценарии несовместимы с исследовательским тестированием.
Цель исследования – дать свободу действий инженерам, не сковывая их формальными тест-планами, и они находят проблемы, которые поймает только пользователь. Для исследовательского тестирования через реализацию поведения лучше не писать сценарии, а подойти к вопросу комплексно: тестировщики должны притвориться пользователями и обращаться с продуктом, как с коллекцией взаимодействующих поведенческих паттернов. Если исследование выявит пробелы в поведении, новые поведенческие сценарии должны быть добавлены в каталог.
Как организовать ручное тестирование?
Ручное тестирование встраивается в BDD так же, как и автоматизированное: оба формата разделяют общий процесс спецификации поведений. Различаются они в том, как именно прогоняются тесты. При создании сценариев, которые не будут автоматизированы, надо держать в голове несколько особенностей:
Репозиторий
И ручные, и автоматизированные поведенческие сценарии должны храниться в одном и том же репозитории. Естественный подход к их организации – это по фичам вне зависимости от способа прогона тестов. Все сценарии также должны подлежать какой-либо форме контроля версий.
Более того, все сценарии должны находиться рядом, чтобы их можно было задействовать генерирующими документацию инструментами вроде Pickles. Эти инструменты упрощают распространение спецификаций и шагов в команде. Благодаря им «большой тройке» проще сотрудничать. Люди, далекие от технической стороны вопроса, вряд ли углубятся в программерские проекты.
Дополнительные комментарии
Осмысленность поведенческих сценариев достаточно проблематична для ручного тестирования, потому что шаги не дают всей информации, которая может понадобиться тестировщику. К примеру, тестовые данные могут и не быть прописаны в спецификации явным образом. Лучший способ дополнить информацию в сценарии – это добавлять комментарии. Gherkin позволяет писать комментарии с любым количеством строк. Комментарии дают дополнительную информацию для читателя, но игнорируются автоматизацией.
Кажется очень заманчивым просто добавить новые шаги в Gherkin, покрывающие доп. информацию для ручного тестирования. Однако это не очень хороший подход. Принципы «хорошего Gherkin» должны применяться ко всем сценариям вне зависимости от того, автоматизируются они или нет. Высококачественная спецификация нуждается в поддержке, чтобы сохранить ее цельность, документировать при помощи инструментов, и в будущем автоматизировать.
Пример
Ниже – пример фичи, демонстрирующий, как писать поведенческие сценарии для ручных тестов.
Фича: поиск Google
Сценарий: Поиск в поисковой строке
Если веб-браузер находится на домашней странице Google
Когда пользователь вводит «панда» в поисковую строку
Тогда на странице результатов показываются ссылки, связанные со словом «панда».
Сценарий: Поиск картинок
# Убедитесь, что среди картинок есть изображения поедающей бамбук панды
Если отображены результаты поиска Google для «панда»
Когда пользователь нажимает на ссылку «Изображения» на верху страницы с результатами
Тогда изображения, связанные с запросом «панда», отображаются на странице результатов.
Не больно-то и много различий с другми поведенческими сценариями.
Источник: www.software-testing.ru