Ручное тестирование с нуля: что учить новичку и как начать путь в QA

🧪 Что вообще делает ручной тестировщик?

Самая популярная версия:

«Ну он там сидит и нажимает кнопки».

Примерно как сказать, что программист:

«Ну он буквы на клавиатуре печатает».

Технически — не поспоришь. Но есть нюанс. 😎

Задача тестировщика — проверить, работает ли продукт так, как должен, и найти ситуации, в которых что-то идёт не по плану.

Например, есть форма регистрации.

Разработчик проверил:

• ввёл почту;

• ввёл пароль;

• нажал «Создать аккаунт»;

• аккаунт создался.

Красота. Можно домой.

Тестировщик приходит и спрашивает:

• А если email пустой?

• А если в нём 300 символов?

• А если вместо email написать котик?

• А пароль из одного символа?

• А вставить пробелы?

• А нажать кнопку десять раз подряд?

• А отключить интернет прямо во время регистрации?

• А открыть всё это в Safari?

• А на телефоне?

• А дважды зарегистрироваться с одной почтой?

Разработчик: 😐

Вот примерно здесь и начинается тестирование.

🧠 Первое, что нужно прокачать — не инструмент, а мышление

Новички часто начинают с вопроса: «Какую программу нужно установить тестировщику?»

Но главный инструмент QA уже установлен. Это способность постоянно задавать вопрос:

«А что будет, если?..»

Хороший тестировщик ищет:

• граничные значения;

• неожиданные действия пользователя;

• неправильные данные;

• противоречия требованиям;

• нестандартные сценарии;

• странные комбинации действий.

Пользователь вообще редко ведёт себя так, как задумал разработчик.

Если рядом с надписью «НЕ НАЖИМАТЬ» есть кнопка — кто-нибудь обязательно её нажмёт.

И тестировщик должен сделать это первым. 😂

📚 Шаг 1. Разберись с базовой теорией тестирования

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

Что такое баг?

Баг — ситуация, когда фактическое поведение программы отличается от ожидаемого.

Ожидаем: после нажатия «Сохранить» профиль обновляется.

Фактически: появляется ошибка 500.

Поздравляем. 🐞

Что такое тест-кейс?

Тест-кейс — подробный сценарий проверки.

Название: Авторизация с корректными данными.

Шаги:

1. Открыть страницу входа.

2. Ввести существующий email.

3. Ввести правильный пароль.

4. Нажать «Войти».

Ожидаемый результат: пользователь попадает в личный кабинет.

По сути это инструкция: «Сделай вот это → должно произойти вот это».

Что такое чек-лист?

Чек-лист обычно короче. Например, проверяем форму авторизации:

• вход с корректными данными;

• неправильный пароль;

• несуществующий email;

• пустой email;

• пустой пароль;

• слишком длинные значения;

• восстановление пароля.

Без огромного описания каждого шага.

Что такое баг-репорт?

Нашёл ошибку — мало написать: «Логин не работает».

Разработчик после такого превращается в детектива.

Нормальный баг-репорт обычно содержит:

• название проблемы;

• окружение;

• шаги воспроизведения;

• фактический результат;

• ожидаемый результат;

• скриншот или видео;

• дополнительную информацию.

Пример:

После авторизации пользователь получает ошибку 500.

Шаги:

1. Открыть страницу /login.

2. Ввести корректный email.

3. Ввести корректный пароль.

4. Нажать «Войти».

Фактически: появляется страница с ошибкой 500.

Ожидаемо: открывается личный кабинет.

Уже намного полезнее.

🔍 Шаг 2. Изучи основные виды тестирования

Функциональное тестирование

Проверяем: работает ли функция вообще?

Кнопка отправляет форму? Фильтр фильтрует? Корзина считает товары?

Регрессионное тестирование

Разработчик исправил одну функцию. QA проверяет: а не сломалось ли после этого ещё пять?

Это называется регресс.

И именно поэтому фраза:

«Я там всего одну строчку поменял»

никого особенно не успокаивает. 😅

Smoke-тестирование

Быстрая проверка основных функций:

• приложение запускается;

• авторизация работает;

• основные страницы открываются;

• ключевые функции не умерли.

Если уже здесь всё горит — продолжать подробное тестирование иногда нет смысла.

UI-тестирование

Проверяем интерфейс:

• элементы не съехали;

• текст не вылез за кнопку;

• модальное окно не оказалось под меню;

• мобильная версия не превратилась в современное искусство.

Кроссбраузерное тестирование

Chrome говорит: «Всё идеально».

Safari: «Не сегодня».

Поэтому веб-приложения проверяют в разных браузерах и на разных устройствах.

🛠️ Шаг 3. Освой DevTools

Вот здесь новичок начинает выглядеть немного более опасно.

В браузере нажми F12 или Ctrl + Shift + I.

Перед тобой откроются DevTools.

На старте особенно полезны две вкладки.

Console

Здесь можно увидеть JavaScript-ошибки.

Uncaught TypeError

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

Network

Здесь отображаются запросы между браузером и сервером.

GET /api/profile → 200
POST /api/login → 500

Код 500 уже намекает, что серверу стало плохо.

Начинающему QA не обязательно сразу понимать каждую деталь HTTP. Но видеть что отправили → куда отправили → какой получили ответ очень полезно.

🌐 Шаг 4. Разберись, как работает веб

Если планируешь тестировать сайты и веб-приложения, базовое понимание веба сильно облегчит жизнь.

Не нужно становиться frontend-разработчиком.

Но желательно понимать клиент-серверную архитектуру.

Пользователь нажал «Войти»
↓
Frontend отправил логин и пароль
↓
Backend проверил данные
↓
Backend вернул результат
↓
Frontend показал личный кабинет

Понимая эту цепочку, гораздо проще определить, на каком этапе всё сломалось.

📡 Шаг 5. Выучи основы HTTP и API

Вот здесь многие новички внезапно пугаются.

API?! Мне же сказали РУЧНОЕ тестирование!

Спокойно. 😄

Современному QA хотя бы базово понимать API очень полезно.

Начни с HTTP-методов:

• GET — получить данные;

• POST — создать;

• PUT/PATCH — изменить;

• DELETE — удалить.

И статус-кодов:

• 200 — всё хорошо;

• 201 — создано;

• 400 — неправильный запрос;

• 401 — нужна авторизация;

• 403 — доступ запрещён;

• 404 — не найдено;

• 500 — сервер решил добавить немного драмы.

Не обязательно зубрить весь список. Главное — понимать логику.

📬 Шаг 6. Попробуй Postman

Postman позволяет отправлять запросы к API вручную.

Например:

GET /api/users/42

Ты можешь отправить запрос напрямую и получить:

{
  "id": 42,
  "name": "Alex"
}

А затем попробовать:

GET /api/users/999999

и посмотреть, что произойдёт.

Тестирование API хорошо прокачивает понимание того, как приложения работают внутри.

🗄️ Шаг 7. Освой основы SQL

Нет, огромные запросы на 38 строк пока писать не нужно.

Начни с:

SELECT
FROM
WHERE
ORDER BY
JOIN

Например:

SELECT * FROM users WHERE email = 'test@example.com';

Если после регистрации пользователь должен появиться в базе, SQL помогает проверить, произошло ли это.

Для Junior QA базовый SQL — очень полезный навык.

📝 Шаг 8. Научись нормально описывать баги

Можно найти невероятно редкую критическую ошибку.

Но если оформить её так:

«Короче что-то сломалось, сами посмотрите»

тебя вряд ли будут носить по офису на руках.

Хороший баг должен быть воспроизводимым.

Другой человек должен прочитать описание и повторить проблему без телепатии.

Поэтому всегда спрашивай себя:

«Если разработчик ничего не знает об этом баге, сможет ли он повторить его по моему описанию?»

Если да — отлично.

🧩 Шаг 9. Учись составлять тесты

Допустим, есть поле:

Возраст: от 18 до 60 лет.

Новичок проверяет:

25

Работает. Готово.

Опытный тестировщик приходит с компанией:

17
18
19
59
60
61
0
-1
999999
"кот"
пустое значение

Это проверка граничных значений и классов эквивалентности.

Баги очень любят жить именно возле границ.

🚀 Нужно ли тестировщику знать программирование?

Для старта в ручном тестировании — не обязательно уметь программировать как разработчик.

Но понимать код очень полезно.

Потому что дальше появляются:

• автоматизация тестирования;

• API;

• базы данных;

• скрипты;

• CI/CD;

• автотесты.

💙 Где изучать программирование с практикой?

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

В Кодике обучение построено вокруг практики: проходишь тему → выполняешь упражнения → постепенно закрепляешь материал.

Это особенно полезно будущим QA-инженерам: даже если ты начинаешь с ручного тестирования, понимание HTML, SQL, Git, JavaScript, Python и устройства программ серьёзно поможет дальше развиваться в тестировании и автоматизации.

А ещё у Кодика есть Telegram-сообщество, где выходят полезные материалы по разработке, тестированию, технологиям и программированию. Удобный вариант регулярно повторять материал без ощущения, что ты снова открыл учебник размером с холодильник. 📚