Меня зовут Максим Белопросов, я QA Team Lead в компании 1221Systems и один из ответственных за направление автоматизированного тестирования. Использование ИИ в работе — одна из самых обсуждаемых тем последнего года. Моя жена активно применяет его в своих задачах, и когда мы что-то обсуждаем, она удивлённо спрашивает: «А ты-то почему до сих пор не используешь ИИ?» И в какой-то момент я и сам задумался — а правда, почему?
Я разобрался в теме, чтобы вам не пришлось. В этой статье поделюсь, как использовать ИИ с умом и пользой на примерах из мира тестирования (QA). Но фишки, о которых пойдёт речь, вполне подойдут и для других профессий.
Дисклеймер!
Сегодня использование ИИ в бизнесе, особенно в небольших компаниях, пока ещё слабо регламентировано. Важно помнить: не передавайте ИИ персональные и NDA данные и внутренние документы — информация из публичных сервисов может стать доступна посторонним. Перед активным использованием ИИ обязательно согласуйте это с отделом информационной безопасности, чтобы избежать проблем.
Промпт: как заставить ИИ работать
Если вы читаете Habr, скорее всего, слово промпт вам уже знакомо. Но на всякий случай коротко объясню, особенно для тех, кто только начинает разбираться.
Промпт - это запрос, команда или инструкция, которую вы отправляете искусственному интеллекту (например, ChatGPT), чтобы получить текст, изображение, ответ или решение. Чем точнее и грамотнее сформулирован промпт, тем лучше результат вы получите на выходе.
Важно! Любой ИИ продолжает учиться прямо во время общения. Если вы работаете над одной темой в одном чате, ИИ «запоминает» контекст и даёт более точные ответы. Но если уйти в другой чат с той же темой, контекст сбросится. Поэтому лучше вести каждую тему в отдельном чате.
Самый частый запрос к ChatGPT в сфере тестирования (по мнению самого ChatGPT) — написание тест-кейсов. Для примера возьмём простую задачу: создать тест-кейс для валидации поля email. Сначала проверим, что выдаст базовый промпт, потом добавим разные ограничения и сравним результаты с исходным.
Промпт-эксперимент: проверяем запросы
Итак, обычный стартовый запрос может выглядеть так:
Напиши тест-кейс для проверки поля email при авторизации.
Ответ ИИ
Название тест-кейса: Проверка поля Email при авторизации
Идентификатор: TC_AUTH_EMAIL_001
Предусловия:
Открыта страница авторизации, пользователь не авторизован.
Шаги:
Ввести значение в поле "Email"
Ввести корректный пароль в поле "Пароль"
Нажать кнопку "Войти"
Тестируемые значения и ожидаемый результат:
Ввести корректный email в формате user@example.com — система должна авторизовать пользователя (при правильном пароле).
Ввести email без символа @, например userexample.com — должно появиться сообщение об ошибке: "Неверный формат email".
Ввести email с только доменом, например user@ — сообщение об ошибке: "Неверный формат email".
Ввести email без имени пользователя, например @example.com — сообщение об ошибке: "Неверный формат email".
Ввести email с недопустимым доменом, например user@.com или user@com — сообщение об ошибке: "Неверный формат email".
Ввести email с двумя символами @, например user@@example.com — сообщение об ошибке.
Ввести email с доменной зоной менее двух символов, например user@example.c — сообщение об ошибке, если такое не допускается.
Оставить поле пустым — сообщение об ошибке: "Email обязателен".
Ввести пробел в поле email — сообщение об ошибке: "Email обязателен" или "Неверный формат email".
Ввести email на кириллице, например user@пример.рф — результат зависит от поддержки IDN-доменов: либо успешная авторизация, либо ошибка.
Ввести слишком длинный домен, например user@verylongdomainnamethatexceedsallowedlength.com — система должна отреагировать ошибкой, если длина домена превышает допустимый лимит.
Ожидаемый результат:
Поле "Email" должно принимать только корректные адреса электронной почты в формате имя@домен.зона. При некорректном вводе должно отображаться соответствующее сообщение об ошибке. Кнопка "Войти" может быть неактивна до ввода валидного email, если реализована валидация в реальном времени.
В целом — неплохо, но можно и лучше. Давайте добавим ограничения в промпт, чтобы получить ещё более релевантный и точный ответ.
Эксперимент первый: добавляем роль
Когда вы даёте задание сотруднику, вы же учитываете, новичок он или профи? От этого зависит подход к задаче и её результат. С искусственным интеллектом — то же самое. Ему нужно понять, какого уровня специалист должен выполнять задание.
Если хотите получить действительно качественный ответ, лучше сразу указать, что это должен быть senior. Идеально — добавить конкретику, например: Представь, что ты senior-тестировщик из Google. Так вы направляете ИИ не просто выполнять задачу, а «думать» как опытный эксперт. Это поможет ему настроиться на нужный уровень экспертизы и подход.
Итак, улучшенный промпт:
Представь, что ты senior-тестировщик из Google и напиши мне тест кейс для проверки поля email при авторизации.
Ответ ИИ
Название тест-кейса: Проверка валидации поля Email на экране авторизации
Цель:
Убедиться, что поле для ввода email корректно обрабатывает как валидные, так и невалидные значения, а также обеспечивает информативную обратную связь пользователю.
Предусловия:
Пользователь находится на экране авторизации. Форма активна. Поле email доступно для ввода.
Позитивный сценарий:
Ввести корректный email-адрес, например user@example.com, и нажать кнопку «Войти».
Ожидаемый результат: поле принимает значение, происходит переход к следующему шагу (например, запрос пароля или вход в систему).Ввести email с плюсом и поддоменом, например user.name+tag@example.ru.
Ожидаемый результат: email считается валидным, переход к следующему шагу.Вставить email с помощью буфера обмена (ctrl+v) или автозаполнения браузера.
Ожидаемый результат: email подставляется корректно, проходит валидацию.
Негативные сценарии:
Оставить поле пустым и нажать кнопку «Войти».
Ожидаемый результат: появится сообщение об ошибке «Email обязателен» или аналогичное.Ввести строку без символа @, например testgmail.com.
Ожидаемый результат: отображается ошибка: «Некорректный email».Ввести email без домена, например test@.
Ожидаемый результат: система сообщает об ошибке, не даёт продолжить авторизацию.Ввести только домен, например @gmail.com.
Ожидаемый результат: поле считается невалидным, появляется сообщение об ошибке.Ввести email с недопустимыми символами, например test@exa!mple.com.
Ожидаемый результат: ошибка «Некорректный email».Ввести email с пробелами в начале или в конце, например test@example.com.
Ожидаемый результат: пробелы автоматически обрезаются (trim) или показывается ошибка.Ввести email с двойной точкой, например test..email@example.com.
Ожидаемый результат: email не проходит валидацию.Ввести email с кириллическими символами, например тест@пример.рф.
Ожидаемый результат: зависит от требований — либо принимается (если поддерживается), либо отклоняется с понятной ошибкой.Превысить допустимую длину email (например, ввести слишком длинный email, который превышает максимально разрешённое количество символов).
Ожидаемый результат: либо ввод блокируется по длине, либо отображается сообщение о недопустимой длине email.Попробовать ввести JavaScript-код или HTML-теги, например <script>alert(1)</script>@test.com.
Ожидаемый результат: система нейтрализует потенциально опасный ввод, никаких скриптов не исполняется, ввод не проходит валидацию.
Дополнительные проверки:
Поле email не должно принимать только пробелы.
Все ошибки должны отображаться рядом с полем, быть понятными и не мешать пользовательскому интерфейсу.
Ошибки должны исчезать после корректного ввода.
Проверка должна выполняться как на клиентской, так и на серверной стороне.
API-запрос с невалидным email должен возвращать корректный код ошибки (например, 400 Bad Request) и сообщение.
Ожидаемый результат:
Система обрабатывает все сценарии корректно: валидные email-адреса принимаются, невалидные — отклоняются с понятной обратной связью, безопасность соблюдается, UX не нарушается.
Смотрим, оцениваем, делаем выводы!
В новом варианте появились важные улучшения:
Чёткая структура: шаги, входные данные, ожидаемые результаты — всё по полочкам. Это упрощает понимание и автоматизацию.
Расширенный набор тестов: добавлены проверки на безопасность (XSS), способы ввода (копипаст, автозаполнение), граничные значения по длине.
Учёт разных окружений: Web, Mobile, API, а также клиентская и серверная валидация.
Более детальная проверка пробелов и некорректных символов.
Почему это круто? Такой подход даёт более полное покрытие сценариев, облегчает автоматизацию и поддержку тестов, а заодно повышает качество и безопасность проверки поля email.
Эксперимент второй: подчёркиваем важность задачи
Если задача действительно важна, скажите об этом прямо в промпте. Например: Этот тест-кейс критически важен для бизнеса, постарайся выдать максимально качественный результат. Так ИИ поймёт, что нужно не спешить, а копнуть глубже и дать максимально точный результат.
Обновлённый промпт может выглядеть так:
Напиши мне тест-кейс для проверки поля email при авторизации. Помни, что авторизация — один из ключевых элементов, ведь это первая точка входа для пользователя.
Ответ ИИ
Тест-кейс: Проверка поля Email при входе в систему
ID: TC_AUTH_001
Название: Проверка корректности и валидации поля Email при входе в систему
Предусловия: Пользователь находится на странице входа в систему.
Шаги:
Ввести корректный email и корректный пароль, нажать кнопку "Войти".
Ввести email с неправильным форматом (например, без символа "@"), ввести пароль, нажать "Войти".
Ввести пустое значение в поле email, ввести пароль, нажать "Войти".
Ввести email с пробелами в начале/конце, ввести пароль, нажать "Войти".
Ввести email с допустимым максимальным количеством символов, ввести пароль, нажать "Войти".
Ввести email с недопустимыми символами (например, !, #, %), ввести пароль, нажать "Войти".
Ввести email, который не зарегистрирован в системе, ввести пароль, нажать "Войти".
Ожидаемый результат:
Пользователь успешно входит в систему.
Отображается ошибка с сообщением о некорректном формате email.
Отображается сообщение об обязательном заполнении поля email.
Пробелы автоматически удаляются, пользователь входит при корректном email и пароле.
Пользователь успешно входит в систему (если email корректен и зарегистрирован).
Отображается ошибка с сообщением о недопустимых символах в email.
Отображается сообщение о том, что пользователь с таким email не найден.
По сравнению со стандартным, в новом варианте добавлены важные проверки:
наличие email в системе (то есть зарегистрирован ли пользователь);
обработка пробелов в начале и конце email с автоматическим удалением.
Также фокус сместился с формальной валидации формата на реальные сценарии входа пользователя. Это важно, так как тест становится более прикладным: он проверяет не только корректность ввода, но и логику аутентификации. А значит — повышается надёжность и качество проверки.
Эксперимент третий: заставляем ИИ найти лучшее решение
Когда вы формулируете запрос, бывает полезно дать ИИ понять, как подойти к задаче: пойти «в лоб» или остановиться, оценить контекст и взглянуть шире. С этим отлично справляется простая установка — Хорошо подумай. Она даёт сигнал: не спеши, задача важная, стоит продумать подход, учесть нюансы и рассмотреть альтернативы.
ИИ может быстро выдать ответ, но по-настоящему продуманные решения требуют не скорости, а стратегии. Фразы вроде: Хорошо подумай, прежде чем ответить — задача непростая и требует нестандартного подхода, помогает получить не просто первую идею, а взвешенный, обоснованный а, возможно, даже креативный ответ.
Тестируем новый промпт:
Напиши мне тест-кейс для проверки поля email при авторизации. Хорошо подумай, прежде чем ответить.
Ответ ИИ
ID: TC-AUTH-EMAIL-001
Название: Проверка валидности и поведения поля Email при авторизации
Цель: убедиться, что поле email обрабатывает ввод корректно, в соответствии с форматом, UX-требованиями и бизнес-логикой
Предусловия:
Пользователь находится на экране авторизации
Доступ к интернету обеспечен
Система доступна и работает стабильно
Шаги и ожидаемые результаты:
Оставить поле email пустым и нажать "Войти"
Ожидаемый результат: появляется сообщение об ошибке: «Поле обязательно для заполнения».Ввести email без символа "@", например userexample.com, и нажать "Войти"
Ожидаемый результат: появляется сообщение об ошибке: «Неверный формат email».Ввести email без домена, например user@, и нажать "Войти"
Ожидаемый результат: появляется сообщение об ошибке: «Неверный формат email».Ввести email с двумя символами "@", например user@@example.com, и нажать "Войти"
Ожидаемый результат: появляется сообщение об ошибке: «Неверный формат email».Ввести email с пробелами, например user @example.com, и нажать "Войти"
Ожидаемый результат: появляется сообщение об ошибке: «Email не может содержать пробелы».Ввести email с недопустимыми символами, например user!#%&@example.com, и нажать "Войти"
Ожидаемый результат: появляется сообщение об ошибке: «Неверный формат email» (если такие символы не разрешены политикой системы).Ввести валидный email, например user@example.com, и нажать "Войти"
Ожидаемый результат: Ошибок нет, поле считается валидным, происходит попытка авторизации.Ввести слишком длинный email, который превышает максимально разрешённое количество символов и нажать "Войти"
Ожидаемый результат: Ввод блокируется или появляется сообщение об ошибке: «Превышена допустимая длина».Ввести email с заглавными буквами, например User@Example.Com, и нажать "Войти"
Ожидаемый результат: Email принимается, так как адреса электронной почты нечувствительны к регистру.Вставить email из буфера обмена, например скопировать user@example.com и вставить в поле
Ожидаемый результат: Вставка успешна, проверка формата работает как обычно.Ввести корректный, но незарегистрированный в системе email, например notfound@example.com, и нажать "Войти"
Ожидаемый результат: после отправки появляется сообщение: «Пользователь не найден».Ввести HTML или JavaScript-код, например <script>alert(1)</script>, и нажать "Войти"
Ожидаемый результат: Скрипт не исполняется, поле обрабатывает ввод безопасно. Система устойчива к XSS-атакам.Отключить JavaScript в браузере, ввести email и нажать "Войти"
Ожидаемый результат: Серверная валидация все равно проводится, и в случае ошибки отображается корректное сообщение.
Дополнительные сведения:
Поле должно иметь тип email (если это HTML-форма).
Максимальная допустимая длина email по стандарту — 320/254 символов.
Поле должно быть защищено от XSS, HTML-инъекций и SQL-инъекций.
Валидация должна проходить как на клиенте (если возможно), так и на сервере.
Смотрим на новый результат:
Тест-кейс получился гораздо более комплексным. Он проверяет не только формат email, но и безопасность, удобство для пользователя, технические ограничения и бизнес-логику.
Такой подход повышает надёжность, усиливает защиту, учитывает реальный пользовательский опыт и разные условия работы. А ещё — приносит реальную пользу и разработке, и команде QA.
Эксперимент четвёртый: указываем формат выдачи
Чтобы не тратить время на уточнения и повторные запросы, лучше сразу указать, в каком формате вы хотите получить ответ: в виде таблицы, структурировано по пунктам или текстом с акцентом на ключевые моменты — например, с выделением важного жирным шрифтом.
Это особенно полезно, если планируете сразу использовать результат — например, импортировать его в систему хранения тест-кейсов.
Тестируем обновлённый промпт:
Напиши мне тест-кейс для проверки поля email при авторизации. Сформируй результат в файл .XLSX, чтобы его можно было импортировать в систему тестовой документации.
Ответ ИИ
Готов файл с тест кейсами для проверки поля email при авторизации:
? Скачать test_cases_email_auth.xlsx — тут должен был быть файл, но Habr не фанат вложений (файлы загружать нельзя). Не будем его за это ругать и просто приведём данные из .xlsx в виде таблицы ниже.
TC_EMAIL_001 |
Пустое поле email |
Открыта форма авторизации |
1. Оставить поле email пустым |
Отображается сообщение об ошибке: 'Email обязателен' |
TC_EMAIL_002 |
Неверный формат email (без @) |
Открыта форма авторизации |
1. Ввести 'userexample.com' в поле email |
Отображается сообщение об ошибке: 'Некорректный формат email' |
TC_EMAIL_003 |
Неверный формат email (без домена) |
Открыта форма авторизации |
1. Ввести 'user@' в поле email |
Отображается сообщение об ошибке: 'Некорректный формат email' |
TC_EMAIL_004 |
Корректный email |
Открыта форма авторизации |
1. Ввести 'user@example.com' в поле email |
Пользователь успешно авторизован |
TC_EMAIL_005 |
Email с пробелами в начале и в конце |
Открыта форма авторизации |
1. Ввести ' user@example.com ' в поле email |
Пробелы удаляются, пользователь успешно авторизован |
TC_EMAIL_006 |
Email с верхним регистром |
Открыта форма авторизации |
1. Ввести 'USER@EXAMPLE.COM' в поле email |
Email обрабатывается без учета регистра, пользователь успешно авторизован |
Формат таблицы совместим с системами хранения тестовой документации (например, TestRail, Zephyr и др.). Если нужно — могу дополнить другими кейсами (например, с SQL-инъекциями, XSS и т.п.).
Думаю, выводы здесь не нужны. Удобно.
Эксперимент пятый: запрашиваем ссылки на источники
Может быть полезно прямо указать ИИ, что ответ должен базироваться только на проверенных источниках, а также попросить включить ссылки на эти источники в ответ. Например: Приведи, пожалуйста, ссылки на официальные источники или свежие статьи по теме. Так вы получите не просто ответ, а информацию, подкреплённую данными.
Разумеется, ИИ не всезнающий — его ответы всё равно стоит перепроверять, ведь он может ошибаться, использовать устаревшие данные или даже «галлюцинировать» (хотя в последнее время это случается всё реже). Но если заранее уточнить: Важно, чтобы данные были точными и ссылались только на проверенные источники, качество и надёжность результата заметно повышаются.
В итоге вы получаете не просто ответ, а надёжную основу для собственных выводов.
Новый промпт может выглядеть так:
Напиши мне тест кейс для проверки поля email при авторизации. Приведи ссылки на официальные источники или свежие статьи по теме, почему мы используем те или иные проверки.
Ответ ИИ
Тест-кейс: Проверка поля Email при авторизации
ID: TC_AUTH_01
Название: Проверка корректности ввода email при авторизации
Предусловие: Пользователь находится на форме авторизации
Приоритет: Высокий
Область тестирования: Проверка frontend и backend валидации поля email
Шаги и ожидаемый результат:
Оставить поле email пустым и нажать кнопку "Войти".
Ожидаемый результат: отображается сообщение об ошибке: «Поле email обязательно для заполнения».Ввести email без символа @, например: userexample.com, и нажать "Войти".
Ожидаемый результат: отображается сообщение об ошибке: «Неверный формат email».Ввести email без доменной части, например: user@, и нажать "Войти".
Ожидаемый результат: отображается сообщение об ошибке: «Неверный формат email».Ввести email с несколькими символами @, например: user@@example.com, и нажать "Войти".
Ожидаемый результат: отображается сообщение об ошибке: «Неверный формат email».Ввести email с пробелами, например: user @example.com, и нажать "Войти".
Ожидаемый результат: отображается сообщение об ошибке: «Неверный формат email».Ввести валидный email, например: user@example.com, и нажать "Войти".
Ожидаемый результат: Поле email проходит валидацию, запрос уходит на сервер без ошибок (проверка пароля продолжается отдельно).
? Почему такая проверка важна
Безопасность: неправильная валидация может привести к уязвимостям (например, email-инъекциям).
Юзабилити: пользователь получает мгновенную обратную связь при ошибке ввода.
Корректность данных: неверно введённые email-адреса могут привести к ошибкам при авторизации, восстановлении пароля и отправке писем.
? Полезные официальные материалы и статьи
OWASP: Input Validation — объяснение, почему валидация данных (включая email) критически важна с точки зрения безопасности.
HTML Living Standard — Email Type — спецификация HTML-поля типа email и его встроенная валидация.
MDN Web Docs: <input type="email"> — как работает HTML-валидация поля email.
RFC 5322 Official Email Format — формальное определение синтаксиса email-адреса.
В новом варианте появились ссылки на официальные источники, которые подтверждают описанные правила и поведение поля email (хоть они и «вшиты» в текст и не видны напрямую — просто поверьте, что они там есть ?).
Это важно, потому что любую информацию, особенно от ИИ, стоит обязательно перепроверять. Ссылки помогают быстро убедиться, что всё соответствует реальным стандартам и рекомендациям.
Плюс, это отличный способ узнать что-то новое и расширить свои знания.
Эксперимент шестой: вводим ограничения
В промпте можно указывать не только то, что обязательно нужно включить в ответ, но и что точно не нужно. Например: Не используй информацию из соцсетей или Не нужно делать таблицу, просто перечисли пункты.
Так ИИ лучше поймёт, как оформить ответ, чтобы он был максимально удобен именно для вас.
Давайте протестируем новый промпт:
Напиши мне тест-кейс для проверки поля email при авторизации. Не нужно делать таблицу, просто перечисли пункты и не используй технические термины.
Ответ ИИ
Ввести корректный email и пароль, проверить, что вход успешен.
Оставить поле email пустым и попробовать войти, проверить, что появляется сообщение об ошибке.Ввести email без символа «@» и проверить, что система показывает ошибку.
Ввести email без точки после символа «@» и проверить, что появляется сообщение об ошибке.
Ввести email с пробелами в середине и проверить, что вход не разрешён.
Ввести email с недопустимыми символами (например, %, #) и проверить, что система отклоняет.
Ввести очень длинный email и проверить, как система реагирует.
Ввести email с правильным форматом, но который не зарегистрирован, проверить, что появляется ошибка о неверных данных.
Попробовать ввести email с заглавными буквами и убедиться, что система воспринимает его корректно.
Ввести email с разными доменами (.com, .ru, .net) и проверить, что все корректные варианты принимаются.
В новом варианте ответ получился именно таким, как надо — без таблиц и сложных терминов. Это делает его понятным и удобным: можно сразу перейти к проверкам и быстро найти нужную информацию.
Эксперимент финальный: мастер-промпт
Мы с вами рассмотрели шесть основных приёмов, которые помогают улучшить ответы ИИ. Но ещё эффективнее и быстрее будет, если применять их не по отдельности, а все вместе. Проверим?
Предлагаю вам сделать мастер-промпт по проверке поля email, объединив все советы, которые мы обсуждали в статье. Либо придумайте свой вариант! Поделитесь вашим промптом в комментариях и расскажите, насколько удачным получился результат от ИИ. Также буду рад новым экспериментам и промптам – делитесь!
Выводы
Чем точнее сформулирован запрос, тем точнее и лучше будет результат (база).
Рассматривайте ответ ИИ как основу, которую нужно проверить и доработать с учётом своих требований и правил безопасности.
Хороший запрос - это не просто вопрос, а чёткая инструкция с пояснениями и ограничениями.
Если в запросе указать роль, уровень эксперта, приоритеты и формат ответа, качество результата значительно повышается.
Тесты, созданные ИИ, подходят как черновик, но их нужно адаптировать под проект и обязательно проверять вручную.
Чем подробнее описана задача, особенно если важны безопасность и удобство, тем выше шанс сразу получить полезный ответ.
Важно помнить: ИИ - не волшебство, а инструмент, эффективность которого зависит от того, как его используют.
Если вам интересен рост в тестировании, советую свою статью Куда расти QA-инженеру на каждом грейде: подробный гид
А если хотите пообщаться – всегда рад видеть коллег в своём профиле на LinkedIn.
maaGames
вот хотелось бы знать, сколько всего ушло времени, чтобы до финального запроса добраться и получить этот список из 9 пунктов. И, главное, сколько времени вам нужно, чтобы самому эти 9 пунктов написать?
А ведь тут задача элементарная и сразу можно оценить, чего ИИ недосказал или чего лишнего выдал. А вот будет более реалистичная задача, на несколько порядков сложнее и там не просто запрос надо суметь придумать, но ещё и суметь проанализировать ответ и догадаться, наврал ИИ или не наврал или недосказал или насочинял...
Хотелось бы про реальное испоьзование в боевых условиях узнать, а не на элементарых примерах, которые самому быстрее описать.
BelMaxS Автор
Я специально выбрал простой пример (хотя это действительно самый частый запрос со стороны QA) и разделил на шаги, чтобы объяснить, как это работает, и как подходить к работе с ИИ в целом. В реальных задачах, конечно же, я сразу использую сложносоставные промпты, которые как раз позволяют минимизировать ошибки и сократить время.
Если у вас есть сложная задача, попробуйте думать так, как описано в статье и сразу собрать промпт, подходящий под ваш случай.
maaGames
Кстати, приведённые 9 пунктов неточные в своих формулировках и, если следовать именно этим формулировкам, то не хватает ещё парочки тестов. Например п.4 тетсирует только наличие пробела внутри адреса. А что насчёт теста, когда пробелы в самом начале или в самом конце или и в начале и в конце? Если адрес не вводится, а копируется откуда-то из теста, то обрамляющие пробелы будут часто попадаться. Тут же можно придраться к формулировке "пробел", потому что есть ещё табуляция и другие пробельные символы, но я согласен отнести это всё к пункту 5. Почему нет списка допустимых/недопустимых символов? Как проверять что-то на что-то, что неизвестно? п.6 "очень длинный" это сколько? Это не абстрактная величина, она конкретно ограничена либо почтовым сервером, либо самой формой. п.7 совпадает с п.1, потому что в п.1 не сказано, что почтовый адрес дожен существовать. "корректный емэйл" и "зарегистрированный емэйл" - не слова синонимы. Но это придирка, по наличию пароля можно догадаться, что речь про уже зарегистрированный в системе емэйл.
п.1 это два разный кейса. И там дожен быть третий кейс с емейлом, но пустым паролем, а то как-то недотетсировали сообщения об ошибке.
Нет кейса с неправильным паролем.
То есть для меня это выглядит так, что ИИ сильно недоработанные кейсы вернул даже для простог ослучая. У меня одних придирок больше, чем он написал. Для сложной задачи, по моему, опять же получается проще сразу самому написать, чем за ИИ переписывать и дополнять и удалять лишнее. И это же речь про совершенно типовую задачу, которую он точно где-то уже на гитхабе списывал. А если запросить что-то не типовое и на что сам ответа толком не знаешь, то как потом понять, обманул тебя Ии или нет, нужно ли что-то дополнять или же ответ избыточен и содержит ненужное?
Для меня это замкнутый круг. Либо я и сам знаю и могу написать, либо я слепо доверяю ответу и гори оно всё синим пламенем, если ИИ что-то не учёл или соврал.
BelMaxS Автор
Конечно, ответы ИИ нужно критически рассматривать и дополнять, никто не говорит, что нужно брать их в изначальном варианте, не подвергая критическому анализу. Один из выводов статьи: ответ ИИ — это только база, которая ускоряет процесс, но которую нужно проверять и дорабатывать под свои задачи и правила безопасности. Этого принципа стоит придерживаться.
Цель статьи — показать, что продуманные промпты дают больше пользы, чем простые. Разница в ответах заметна, и, если это так, почему бы не использовать эти советы?
maaGames
Разумеется, разница в ответах заметна.
Я как раз всеми силами пытаюсь заставить себя использовать ИИ (Граждане СССР, заставляйте себя есть чёрную икру!), но не могу ничего реально полезного забабахать. Либо слишком примитивные задачи, которые и сам могу сделать, либо слишком сложные, что написание правильного промпта, анализ и исправление ответа займёт больше времени, чем самостоятельное решение.