Функциональное тестирование: чек-листы для джуниора

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

Почему чек-листы - твой главный инструмент

Тест-кейсы - это когда ты пишешь по 20 шагов на каждую функцию. Чек-лист - это когда ты держишь в голове 5-7 пунктов, которые должны работать в любом случае. Для джуниора это идеальный баланс: не перегружает, но не оставляет ничего важного в тени.

Чек-листы работают, потому что они:

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

Это не замена тест-кейсам. Это твой ежедневный помощник - как напоминание на телефоне, только для тестирования.

Что проверять: структура чек-листа для джуниора

Не надо писать 50 пунктов. Начни с этих 6 групп. Они покрывают 90% всех проблем, с которыми сталкиваются новые тестировщики.

1. Основные пользовательские сценарии

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

• Регистрация - можно ли создать аккаунт? Проверь, что письмо приходит, а пароль сохраняется.
• Авторизация - залогинился, вышел, снова зашел - всё работает?
• Добавление в корзину - товар появился? Цена верная? Количество можно менять?
• Оформление заказа - прошла ли оплата? Пришло ли подтверждение?

Запомни: если пользователь не может сделать это за 30 секунд - это баг. Не важно, как ты его назвал.

2. Ввод данных и валидация

Люди вводят всё, что угодно. Ты должен быть готов.

• Почта: введи test@ - система должна сказать, что это неверно.
• Телефон: введи 123456789 - если это не 10 цифр, должна быть ошибка.
• Пароль: попробуй ввести 3 символа - система должна отказать.
• Числа: введи -1000 в поле «количество» - должно быть ограничение.
• Спецсимволы: введи !@#$%^&* в поле «имя» - система не должна сломаться.

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

3. Навигация и интерфейс

Если кнопка не работает - это не «мелочь». Это то, что пользователь запомнит навсегда.

• Все ссылки ведут туда, где должны? Проверь хотя бы 5 самых важных.
• Кнопки «Назад» и «Вперёд» в браузере работают без потери данных?
• Меню на мобильном открывается и закрывается без зависаний?
• Появляются ли подсказки, когда пользователь что-то делает не так?

Тестировщик, который не проверяет навигацию, похож на повара, который не пробует блюдо - он просто делает вид, что всё в порядке.

4. Интеграции и внешние системы

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

• Если есть оплата - попробуй оплатить с картой, которая отклоняется. Система должна показать ошибку, а не зависнуть.
• Если есть API - проверь, что данные приходят и уходят без искажений. Например, если ты регистрируешься через Google - приходит ли твой email?
• Если данные сохраняются в БД - зайди в базу (если есть доступ) и убедись, что там нет лишних символов, пробелов или пустых значений.

Тут часто ловят баги: всё работает в интерфейсе, а в базе - мусор. Это редко видят джуниоры, но это одна из самых частых причин утечек данных.

5. Ошибки и исключения

Ты не тестируешь, как приложение работает, когда всё идеально. Ты тестируешь, как оно ведёт себя, когда всё ломается.

• Отключи интернет - что покажет приложение?
• Загрузи файл размером 10 ГБ - система должна отказать, а не упасть.
• Введи 10000 символов в поле «Комментарий» - что происходит?
• Быстро нажми кнопку «Отправить» 10 раз подряд - не должно быть 10 заказов.

Если ты не проверяешь ошибки - ты не тестируешь. Ты просто проходишь по списку.

6. Роли и доступ

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

• Гость может зайти в профиль? Он не должен.
• Пользователь может удалить чужой заказ? Он не должен.
• Админ может заблокировать самого себя? Тогда это баг.
• Если ты вышел из аккаунта - можешь ли ты получить доступ к личным данным через URL? Проверь.

Это не «дополнительно». Это основа безопасности. И если ты пропустишь это - тебя попросят перепроверить всё сначала.

Как создавать чек-листы

Не копируй чужие. Создавай свои. Вот как:

1. Прочитай требования - не «всё», а только то, что связано с тем, что ты тестируешь.
2. Выпиши 3-5 основных сценариев, которые пользователь сделает в первый час.
3. Добавь 3-5 «что, если» - что, если сеть отключится? Что, если данные не в формате?
4. Проверь, что ты не забыл про мобильную версию - 70% пользователей заходят с телефона.
5. Обновляй чек-лист каждый раз, когда меняется функция - даже если это «мелочь».

Твой чек-лист - это живой документ. Он не должен быть идеальным. Он должен быть актуальным.

Чего не стоит делать

После двух месяцев тестирования я видел, как джуниоры делают одну и ту же ошибку.

• Не проверяй всё сразу. Ты не должен проверять всё приложение за раз. Начни с одного модуля - например, регистрация. Потом - корзина. Потом - оплата.
• Не пиши «Проверить, что всё работает». Это не чек-лист. Это отмазка. Каждый пункт должен быть конкретным: «Проверить, что после входа с неверным паролем появляется сообщение «Неверный логин или пароль»».
• Не игнорируй браузеры. Chrome - не единственный браузер. Проверь хотя бы Firefox и Safari. Мобильные браузеры - отдельная история.
• Не жди, пока тебе скажут, что проверять. Если ты не понимаешь, как работает функция - спроси. Лучше задать вопрос, чем пропустить баг.

Как проверить, что чек-лист хороший

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

Если он говорит: «А что, если...?» - значит, ты что-то упустил. Добавь это. Потом перепроверь. Потом снова добавь.

Чек-листы не делают тебя экспертом. Они делают тебя надёжным. И именно надёжность - то, что ценят в QA больше всего.

Что дальше

Когда ты освоишь чек-листы - начни изучать тест-кейсы. Но не забывай: даже самые сложные тест-кейсы начинаются с простого списка. Ты не должен знать всё. Ты должен не забывать самое важное.

Тестирование - это не про память. Это про систему. И чек-листы - твой первый шаг к ней.