Какими должны быть тест-кейсы для передачи в AutoQA?
Не так давно в области ML и ИИ говорили о том, что мир переводит свой сценарий взаимодействия в плоскость ИИ-агента. Это правильно и действительно нужное решение. Пусть он создает, делает что-то, а вы на пульсе держите его выполнение, пока не убедитесь, что работает так, как надо!
Всем мануальщикам в будущем придется научиться работать с ИИ-агентами и проверять свою гипотезу по техникам дизайна и покрытию функционала более тщательно и придумывать любопытные сценария!
А пока что надо привести ум и сознание мануальщика к тому, чтоб уже на этапе проектирования тест-кейсов писать данные в атрибуты кейса таким образом, чтоб можно было сразу передавать в автоматизацию или нагрузку!
Человеческий кейс (ничего не понятно, но очень понятно): Кейс: Проверить вход в систему Шаги: Открыть сайт, ввести логин и пароль, нажать "Войти", убедиться, что вход выполнен успешно.
Какие боли данного кейса? 1) Что значит "логин и пароль" — какие именно данные? Валидный пользователь, а какой? 2) Что значит "вход выполнен успешно" — по какому конкретному признаку это проверяется? 3) Кейс называется "проверить вход", но не сказано, что делать, если введён неверный пароль — это отдельный кейс или тот же?
Следовательно, нужно определить, какими качествами должен обладать правильно оформленный кейс, он должен быть: - атомарным — одна проверка, один повод для падения (иначе непонятно, что автоматизировать отдельно); - детерминированным — без "проверить, что всё ок", а с конкретным ожидаемым результатом; - с явными предусловиями и тестовыми данными — то, что человек может домыслить, автоматизация обязана получить в явном виде.
Теперь попробуем переделать и порадовать автоматизатора, которому не придется показывать, переписывать и ждать, когда тесты будут готовы к автоматизации.
Кейс: Успешный вход в систему с валидными учётными данными Предусловия: 1) Пользователь зарегистрирован в системе, учётные данные: login: test_user@shop.com, password: Test1234! 2) Пользователь не авторизован (на странице логина)
Тестовые данные: валидная пара логин/пароль (см. предусловия)
Шаги: 1) Открыть страницу /login 2) Ввести test_user@shop.com в поле "Email" 3) Ввести Test1234! в поле "Password" 4) Нажать кнопку "Войти"
Ожидаемый результат: 1) Пользователь перенаправлен на страницу /account (или главную — зависит от системы) 2) В шапке сайта отображается имя пользователя или email 3) HTTP-статус ответа на запрос логина — 200
Дополнительно можно указать, надо ли удалять пользователя после прохождения кейса или нет, чтоб автотест мог выполнять данный кейс непрерывно!
Теперь, когда определились с состоянием тест-кейса, можно было продумать, как можно нагенерировать кейсы с помощью RAG-настройки ИИ-модели и как понять, что функционал покрыть и готов быть оценен "можно переводить в автотесты"...
С нашей ж стороны, мы будем адаптироваться и давать общие шаги кода или фреймоворка отдавать на откуп ИИ и потом проверять, что получилось в качестве автотестов и безопасно ли их выполнение? Хотя я лично не считаю рутиной написание автотестов :)
· 02.09
Все же логин/пароль в явном виде - скорее редкость для автоматизации, чем правило. Чтобы эффекта пестицида не было, обычно отдельно под каждый тест (или набор тестов) создается рандомный юзер средствами автоматизации. Есть конечно исключения, какой-нибудь очень специфичный пользователь/бэк-офис/админ, если он и в проде существует в неизменном виде. Так что указать в предусловии "ранее зарегистрированный"/"ранее не зарегистрированный" может быть уместно, у автоматизатора (или llm) это будет сигналом "до начала шагов в бд уже создали юзера и используем его данные"/"берем рандомные данные, в бд такого нет". Про очищение данных после тестов хороший момент)
0
ответить
коммент скрыт — часть юзеров считает его токсичным или некорректным
коммент удалён
· 02.09
Да, ты права, я просто в качестве примера привёл простейший тест, однако, главное, чтоб можно было понять, а какие тесты готовы быть переданными в автоматизацию. Мне часто приходилось объяснять и писать примеры в TMS, как мы любим. И вообще такой подход однажды мне помог избавиться от необходимости читать документацию по продукту, чтоб понять, как он работает. По сути можно такие кейсы использовать для погружения в продукт в качестве документации для QA и AQA. Однако, при таких кейсах надо учесть их атомарность в TMS, то есть стоит ссылаться на оригинал в предусловиях.
0
ответить
коммент скрыт — часть юзеров считает его токсичным или некорректным
ответ удалён
· 02.09
Про замену документации - согласна, я по такому же принципу обычно заводила тест-кейсы: и в пир, и в мир, и автоматизаторам (если есть), и это самая актуальная версия документации по итогу обычно (учитывает последнюю актуальную версию продукта в идеале). Хотя онбордиться в проект по тест-кейсам не очень весело😁
0
ответить
коммент скрыт — часть юзеров считает его токсичным или некорректным
ответ удалён
· 02.09
Ну, по идее, можно было показать на видео основные кейсы - и вот хороший онбординг ☺️ если кейсы понятно расписаны, то ведущий мог бы без проблем продемонстрировать продукт на основных кейсах
0
ответить
коммент скрыт — часть юзеров считает его токсичным или некорректным
ответ удалён