#4 – Основы мануального тестирования

Что такое мануальное тестирование?

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

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

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

Написание тест-кейсов

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

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

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

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

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

Пример тест-кейса:

• Заголовок: Проверка авторизации с корректными данными
• Предусловие: Пользователь зарегистрирован в системе
• Шаги:
  1. Открыть страницу логина.
  2. Ввести корректный логин и пароль.
  3. Нажать кнопку "Войти".
• Ожидаемый результат: Пользователь успешно авторизован и перенаправлен на главную страницу.

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

Ожидаемые результаты и сравнение с фактическими

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

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

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

Ведение отчетности о багах

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

Основные элементы баг-репорта:

1. ID бага — уникальный идентификатор, который помогает отслеживать баг.
2. Название бага — краткое и точное описание проблемы.
3. Шаги воспроизведения — подробное описание всех действий, которые привели к обнаружению бага. Это позволяет разработчикам повторить ваши шаги и исправить проблему.
4. Ожидаемый результат — как система должна была работать.
5. Фактический результат — как система работает на самом деле.
6. Приоритет и серьезность — оценка важности и срочности исправления бага. Например, баг, блокирующий авторизацию всех пользователей, будет иметь высокий приоритет.

Такие отчеты помогают избежать путаницы и обеспечивают быструю реакцию команды разработчиков. Инструменты для ведения баг-репортов, такие как JIRA или Bugzilla, помогают систематизировать процесс и упростить взаимодействие между командами.