Я часто сталкиваюсь с подходом «ну вот пусть специалисты тестят безопасность/удобство/доступность, а я обычный QA, инструментам не обучен», но думаю, что и без супер инструментов можно учитывать действительно важные детали для бизнеса и пользователей.
Давайте на примере безопасности и регистрации: без специализированных инструментов и навыков, QA может тестировать безопасность регистрации, фокусируясь на "злонамеренном" вводе данных и проверке ограничений, например:
1. Некорректный ввод данных:
Пустые поля: Попробуйте оставить логин, пароль, email пустыми. Должны быть внятные сообщения об ошибках.
Неправильный формат: Введите email без символа
@, пароль, не соответствующий требованиям (слишком короткий, без цифр/спецсимволов), или логин с запрещенными символами. Система должна корректно отказать в регистрации.Очень длинные данные: Введите очень длинную строку (сотни, тысячи символов) в поля логина, имени, email. Система не должна "упасть" или зависнуть.
Специальные символы: Введите в поля регистрации символы типа
' " < > %. Убедитесь, что они корректно обрабатываются (экранируются) при сохранении и отображении, а не ломают страницу или код.2. Попытки регистрации с существующими данными:
Попробуйте зарегистрироваться с email или логином, который уже есть в системе. Сообщение об ошибке не должно выдавать лишней информации.
3. Ограничения и защиты:
Слабые пароли: Попробуйте создать аккаунт с очень простым паролем (например,
123456, password). Система должна его отклонить или предупредить. Если нет - прекрасный повод обсудить это с коллегами.Множественные попытки: Попробуйте быстро зарегистрировать несколько аккаунтов подряд. Появляется ли CAPTCHA или другое ограничение для предотвращения автоматической регистрации ботами?
4. Сообщения об ошибках:
Намеренно вызывайте ошибки при регистрации. Убедитесь, что сообщения об ошибках являются общими и не раскрывают внутренние детали системы (например, номера строк кода, названия баз данных).
Конечно, вариантов может быть еще много, это только то, что первое вспомнилось, но эти примеры - то, о чем обычно не пишут в ТЗ, но значит ли это, что проверять такое не надо, если есть возможность?