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