Классный разбор! Неясно одно: смысл отключать клиентскую валидацию? Подавляющее же большинство сайтов используют клиентский рендеринг. А серверную часть проверяем через Postman
Я бы уточнил на собеседовании такой момент: Обычно когда на такие формы редактирования заходим - в полях присутствуют данные. В требованиях об этом ничего нет. Можно добавить такой тест (допускаю что данные подтягиваются): 1) Входим на редактирование профиля - в полях подтянулись нужные поля 2) Меняем имя/возраст 3) Жмем отмену Проверяем что в UI отображаются старые данные. Что в БД данные не затерлись. Так же неплохо обозначить что проверки на разных браузерах и на разных платформах (десктоп и тач)
Видео просто находка! Спасибо за пошаговость и наглядность!!! Казалось бы, нужно проделать простые и очевидные вещи, но даже для этого нужен алгоритм - четкая инструкция, что, зачем и после чего. Большое спасибо за ясность в голове!
И еще хочу сказать - Вы делаете классную вещь. Разборов тестовых заданий очень мало по сравнению с другим контентом для тестировщиков - и будет классно, если продолжите. Вас приятно слушать, отличная скорость и ситемность.
Отключить js и отправить любое значение - было б здорово увидеть, как это сделать в девтулзе. И вопрос - напрашивается одна из важных проверок - отлетает ли POST запрос при нажатии кнопки "Сохранить"? Это учебный макет, понятно, но записать эту проверку надо бы.
Вот алгоритм для Chrome: 1. Открываем DevTools 2. Вызываем панель команд с помощью сочитания клавиш: Ctrl+Shift+P 3. В ней вводим "disable JavaScript" и выбираем соответствующую команду из выпадающего списка Включить js затем можно с помощью команды "enable JavaScript"
Про негативные кейсы всё же вопрос - разве они не являются частью проверок на логику программы? При отрицательном количестве дней, при дробном количестве дней - программа должна выдавать ошибку валидации, это ведь тоже важно. И тоже часть бизнес-логики.
В рамках этого тестового задания от нас хотят перечень входных значений, для которых мы будем проверять, описанную авторами логику расчета процентной ставки. На основе постановки задачи и отсутствия какой-либо информации о поведении программы в случае ввода невалидных значений, считаю что оптимальным будет определить входные значения только для позитивных кейсов. В случае же тестирования зтой фичи на реальном проекте, согласен с тем, что проектирование и выполнение негативных кейсов необходимо.
Есть вопрос - а надо ли проверять подробно валидацию поля name, например? Со всякими проверками типа " An na-Michael ", "127IvaЫыыЖЖn%&!@*!*@(*" и всякое такое? Если примет комбо-строку с цифрами, символами и кириллицей - ок, будет понятно, что валидация отсутствует, в поле name можно пихать все, что угодно. Или, что принмиает пробелы в начале и в конце, что не есть ОК. Длину больше нормы мы проверили, хорошо. А как насчет минимальной? Если принимает два символа, окей, бывают такие имена. А если принмиает и один символ? Таких имен нет. Ну и в этом духе, для каждого поля - нужно ли это делать в подобных заданиях?
Можете поставить расширение в браузер Google Chrome под названием Bug Magnet. По нажатию лкм там масса сценариев валидации, чтоб не придумывать вручную и тратить драгоценное время.
Спасибо! Решил не досматривая видео покрыть тестами поля ввода имени и возраста, используя комбинаторную технику. Так же использовал технику граничных значений и классов эквивалентности. Но возник вопрос: имеет ли смысл так глубоко использовать в данном контексте техники тест-дизайна?
Видео супер. Самая суть, то что и надо знать. хотя можно конечно некоторые моменты побольше показать) А то как не начнешь смотреть то все видео вода водой, дольше про установку самого постман расскажут))
HTTP заголовки используются для передачи дополнительной информации между клиентом и сервером во время обмена данными, обеспечивая эффективное управление и контроль за процессом общения. Примеры такой информации: - куки - токен, полученный при прохождении аутентификации - данные о хосте/сервере Информации в сети много, можете начать с википедии. Также попрактикуйтесь в отправке запросов, на ресурсах типа: apichallenges.herokuapp.com/ - для большего понимания работы с загаловками.
Спасибо. Хорошее видео. Субъективно не стоит обрезать моменты, когда Вы вводите условные хедеры, джейсон и прочее. Да, это существенно сокращает видео, но для людей, не очень хорошо знакомых с постменом, скорее всего, будет трудновато для восприятия, так как количество тех же хедеров меняется, но это не показано как часть выполнения тестового.
на работе тебе не будут каждый раз готовое показывать, а только некоторые принципы. в чем проблема курс по постману пройти и пересмотреть видео с базовыми знаниями?
@@ViktoriiaLesina у меня проблем с курсами по постмену нет, но люди без опыта или с маленьким опытом, заходя в видео с названием "разбор тестового", очевидно, хотят увидеть именно разбор, а не "некоторые принципы". А вообще - добрее надо быть.
Если вам возвращается тело ответа: { "code": 422, "meta": null, "data": [ { "field": "email", "message": "has already been taken" } ] } значит в теле запроса вы указали уже зарегистрированный в системе email. Попробуйте поменять его значение и выполнить запрос на создание нового пользователя снова.
Да, я собрал в виде списка идеи для проверок, которые можно дооформить в виде тест-кейсов. Но на мой взгляд лучше оставить чек-лист, дополнив его атрибутами типа: предусловий, тестовых данных, ожидаемого результата - так как в таком формате ответ будет лучше восприниматься проверяющей стороной.
