0: Всем привет, сейчас вы будете лицезреть собеседование на позицию мануального ручного начинающего тестировщика, поэтому приятного просмотра все вот эти вопросы, которые будут видео я взял из реального собеседования, поэтому

1: Можете не спрашивать, а что действительно так происходит на собесах? Да, происходит это все правда. Приятного вам просмотра. Подписывайтесь на мой канал, а мы начинаем. Лиза, привет. Ты откликнулась на нашу вакансию. Айти панка, я твоё резюме просмотрел.

2: И сейчас ты будешь собеседоваться, собственно, на вакансию, которую я вам предлагаю. Эта вакансия насчитывает оффер 70 000 ₽. Как hr тебе уже рассказывала? Вот позиция junior. Кьюэй, давай начнём вообще с твоего опыта, да, вообще, почему?

3: Решила, что тебе надо в тестирование. Какая причина? Тому последствовало, что ты решила прийти к нам. Привет. Получается, я работаю в компании сейчас, на текущий момент, которая называется вот это

4: Многофункциональный сервис. И основной функцией этого сервиса является предоставление услуг мобильной связи. Сервис включает в себя микросервисную архитектуру с различными интеграциями. Вот пришла я в тестирование получа

5: Так что на последних курсах института от знакомого узнала про данную сферу, она мне стала как бы очень интересна, мы с ним разговорились, я начала у него как бы расспрашивать а что, а как вот и

6: И он мне все рассказал, мне стало очень интересно. Я начала изучать, получается, все начала изучать теорию, все программы, вот все, что касается данной сферы, меня там

7: Очень заинтересовало, и я прошла, получается, в прошла собеседование. Вот. И сейчас работаю вот на своём текущем проекте. Вот мне. А подскажи,

8: Вот ты говорила про вышку, у тебя получается профильное образование или что-то другое? Нет, оно немножечко другое, оно касается системного аналитика. Вот. Но все равно получилось так, то, что все равно оно

9: Затрагивает это все темы очень близкие на самом деле, поэтому как-то так. Угу. Окей, понял. Получается, попала в свою компанию на стажировку, да, как я понимаю. Да, да, да. Попала на стажировку, как бы это было, это заодно и как

10: За практику считалась и стажировка. Угу. Можешь рассказать вообще, вот о своём опыте на текущем проекте. Я как понимаю, ты ещё работаешь, вот, что вообще приходилось тестировать, какие там задачи возможно выполнять. Вот что считаешь важным рассказать про свой опыт, да, того, что я не видел в резюм.

11: Вот, то можешь рассказывать. Угу. Хорошо. Получается. Тестирую я и веб, и фронт, и мобильные приложения. Вот постепенно углубляюсь в различные виды тестирования. Api. Тестирую также.

12: Вот работаю с эскьюэль, вот у меня есть понимание микросервисной архитектуры, вот команда у нас состоит из продукт менеджера системных аналитиков бэкэнд, разработчиков ios.

13: Разработчиков android, тестировщиков, техлид, разработчиков наш техлит и дизайнеры вот работаем мы сейчас по классическому спринту двухнедельному вот.

14: Получается, у нас планирование следующего спринта идёт обычно в конце предыдущего. Вот каждый день у нас дейлики с общей командой, с командой тестировщиков. Дальше у нас начина

15: Вот в начале спринта анализ требований, после анализа требований идёт уже функциональное тестирование, где мы создаём тест кейсы, пишем задачки. Вот. Потом у нас уходят дни на регресс, в регрессе.

16: Регресс у нас примерно длится 5, 6 дней в сумме. Ну вот как-то так. Если есть вопросы, могу что-то раскрыть подробнее. Окей? Да, ты сказала, что получается и с мобилками, и sam, и с бэкендом, да, взаимодействуешь, да, что тебе интереснее всего? Вот из того.

17: То перечислено, что тебе больше нравится тестировать. Больше всего. Мне нравится тестировать веб, потому что backend именно потому, что это такая более техническая часть, там более широкий какой-то спектр.

18: Которая есть каких-либо ошибок. В общем, там есть над чем подумать, есть где покопаться, протестировать. Вот. Угу. Супер. Хорошо. У нас по багану тоже будут вопросы вообще. Мы начнём с теории, с такой прям базы базовой.

19: То есть, что такое тестирование можешь рассказать своими словами, как ты это понимаешь. Для меня получается тестирование это как обеспечение уверенности клиента в качестве продукта. То есть для меня тестирование, оно не сводится к

20: Прям поиску багов. Задача тестировщика. Я считаю то, что это собрать информацию о продукте, вот понять, насколько этот продукт соответствует заложенным требованиям. Это

21: Оценка, готов ли продукт к релизу. Также тестировщик должен минимизировать какие-то риски и ошибки на продакшене. Вот. Ну то есть тестировщик, он не просто ищет ошибки, а управляет

22: Информация о качестве. Окей, хорошо, можешь рассказать вообще, как вот ты ищешь, собственно, эти ошибки и как ты вот контролируешь качество на своём проекте, что тебе с чем приходится больше всего взаимодействовать, касаемо каких-то инструментов. Но если это касается

23: Beck то я работаю с postman вот мы там дёргаем запросы, смотрим ответы от сервера, кидаем на сервер какие-то запросы, чтобы посмотреть, как он будет на них реагировать, какие ответы он будет приходить статус, коды.

24: Смотрим, чтобы в основном это было как бы двухсотые коды. Вот если это мобилки, то мобилки тестируются через в основном чарз прокси, перехват и анализ трафика. Вот для того, чтобы также посмотреть, какие будут

25: Это ответы ошибки, что будет возвращать сервер в случае ошибок, например. Угу. Хорошо, супер. Вот ты рассказала про инструментарий, а можешь рассказать, вот виды тестирования, которые ты используешь в работе. Виды основные это функциональные, не

26: Функциональное тестирование в функциональное себя включает такие самые распространённые. Это юнит тестирование, модульное тестирование, интеграционное тестирование, системное и приёмочное тестирование.

27: Вот, также функциональным тестированием может являться тестирование безопасности в том случае, если, например, безопасность это является как основной функцией продукта, как, например, какие-то антивирусы. Вот не

28: Функциональное тестирование это кросс браузерное тестирование, кросс, платформенное локализации, тестирование ui ux, тестирование. Окей. А вот, допустим, ты говоришь про безопасность, да, что это зависит там от контекста некого, допустим, юай, тестирование.

29: Ты отнесла к функциональному, оно разве не соответствует тоже к функциональному и к нефункциональному? В зависимости тоже от контекста? Да, получается, в зависимости от контекста оно может тоже также относиться и к функциональному, и к нефункциональному. А в каком случае вот оно функциональное будет?

30: Ui тестирование само, наверное, в случае, если основная цель приложения это какие-то, ну окей, окей. Это в принципе, как раз таки какая-то загрузка некая это там.

31: Интерфейс, как он выглядит, как там переходы идут, это все не функциональное, а касаемо функционального, это именно само взаимодействие с той кнопкой, как она именно нажимается, да, то есть её интерфейс ui, да, ты нажимаешь и как бы переходишь, а то, что связано с какой-то визуальной частью,

32: С какой-то, ну, больше не основной функцией. Вот можешь прям делить себе. Вот основная функция не основная. Ну, окей, да, в принципе, я понял. Хорошо. А знаешь, вот что-то про ящики тестирования, да, получается, есть метод тести.

33: Чёрный ящик, белый ящик и серый ящик, чёрный ящик это про то, что тестировщик тестирует со стороны как бы глазами пользователя, то есть у него нету доступа ни к коду, ни какой-либо документации.

34: Белый ящик это есть и доступ к коду, и к различным документациям, и к логам, и как бы ко всему. Вот. А серый ящик это такое некое смешение чёрного с белым, то есть в сером ящике доступа к коду у тебя нету, но зато могут быть

35: Доступы к чему-либо другому. Ну, например, к чему другому может быть доступ, например, к логам приложения документация. А у тебя вот на проекте больше какой ящик, как ты считаешь, в основном это серый ящик бывает чёрный?

36: Но в большинстве все-таки серый, окей, супер. Какие техники дизайна, ты знаешь, техника, граничные значения. Вот эквивалентное разбиение. Получается, вот эти вот 2 техники, они тесно связаны, потому что они обычно тестирую

37: Как-то вместе в связке, то есть, например, эквивалентное разбиение это такая техника, при которой разбивается какие-то значения на определённые классы и вот в этой группе, вот в этом определённом классе они разбивают

38: По тому критерию, что программа работает в этих классах одинаково, то есть она должна давать одинаковый ответ, а ограниченные значения это обычно вот тестируется, например, пользователь до 18 лет не может зарегистрироваться

39: Соответственно, тебе нужно проверить границы возле 18 и саму границу, потому что это самые уязвимые места и часто могут быть какие-то недопонимания в плане того, что включено, не включено. То есть

40: Кто-то может там разработчик и тестировщик по разному это понять. Или разработчик где-то ошибиться. Например. Окей, окей. А вот какая вообще основная функция техники дизайна? Зачем тестировщики их используют для того, чтобы как бы разнообразить количество

41: Проверок не то, нет, не то чтобы разнообразить, а наоборот, для того, чтобы сократить количество этих проверок, чтобы оставить максимально как бы такие продуктивные. Окей часто приходится использовать на проект.

42: Техники, да, постоянно супер. Ну и как бы тоже не услышал про документацию. То есть они как бы для документации пишут, чтоб ты не писала там тест кейсы, допустим, на всем проекте, или вы прям про все пишите тест кейсы по всем проверкам, которые вы делаете.

43: Нет, если это какая-нибудь такая быстрая фича, так сказать, которая не будет потом как-то взаимодействовать с провер, с проектом и, ну, реализована вот разово, то под неё можно писать.

44: Уже не тест кейс, а чек лист. Ну и, например, в условиях нехватки времени тоже можно. Угу. Чек листом покрыть. Окей, окей, давай поговорим про такие очень важные виды тестирования. Смог.

45: Вот когда ты используешь смок тест, для чего он тебе вообще нужен? Смок тест, например, можно использовать в случае, когда разработчик скинул на тестирование какой-либо модуль или интеграцию.

46: В общем продукт и ты должен это как бы базово пробежаться по продукту, проверить вообще его на работоспособность это как критерий, можно ли тестировать это дальше, потому что если smoke test не про.

47: Прошёл, то дальше нет смысла вообще тестировать продукт. Угу. Окей. Санитарное тестирование. Санитарное тестирование это тестирование какой-то небольшой маленькой части функционала, которая подвергается какой-то, которая была подвергнута.

48: Изменению. Ну, например, там был баг, вот тебе это вернули, и ты прям это тестируешь, чтобы проверить, что оно реально работает. Окей? А вот чем тогда отличается от ретеста санитарное? Ну, ретест, он не

49: Затрагивает. Ну, это, в общем, более глобально. Угу. Ну, окей. Этот нюанс тоже ещё повторишь. А регрессионное тестирование это что такое? Регрессионным тестированием? Мы тестируем тот функционал, который был задет каким

50: Либо изменением. То есть, например, вышла, вышла у нас новая фича. Вот, и мы должны протестить все, чего она коснулась, все интеграции, чтобы проверить, не сломался ли старый функционал. Хорошо. Вот можешь на примере рассказать.

51: Тестирование, допустим, у нас есть сайт. Вот какое-то изменение, скажи. И, собственно, какие модули бы ты в регистронной тестировании бы тестировала. Угу. Например, при регистрации пользователя у нас добавилась какая-нибудь, какой-нибудь

52: Новое поле, то есть теперь нужно будет обязательно вписывать, допустим, номер телефона, и мы должны протестировать все остальные поля и также протестировать кнопку регистрации, чтобы проверить, чтобы она корректно работала.

53: Все поля тоже корректно заполнялись и отдавали корректный результат. Угу. Окей, расскажи вообще про документацию. Какую на проекте вы пишите. Мы пишем тест кейсы, чек, листы, багрепорты у нас есть на проект.

54: Отчёт о тестировании тест план матрица тестаили есть, а ты сама как-то test плана касалась или не ты пишешь его в команде нет тест планов я не касалась у нас тест планы пишет кэлли угу. Супер.

55: Супер. Расскажи вообще, вот с документом, который ты взаимодействуешь, допустим, тест кейсы и чек листы. Вот как выглядит твой чек, лист, который ты пишешь, как выглядит твой тест, кейс, какие там поля, какие там проверки ставишь. Угу. Так получается?

56: Если это тест кейс, то там мы пишем, ну, допустим, номер тест кейса. Вот заголовок обязательно какое-нибудь предусловие, то есть

57: Что должно быть выполнено на момент тестирования. Дальше там должны быть описаны шаги проверок. Вот ожидаемый результат, что мы хотим увидеть статус также

58: Там должен быть, например, создан, пройдён, не пройдён, провален, ещё запущен. Вроде такие. Приоритет можно ука.

59: Казать модуль, который мы тестируем. И ещё также там можно указать пост условия. Окей, чек, лист, чек, лист, он более та.

60: Такой высокоуровневый, то есть там можно указать меньше критериев каких-то. Ну, например, в чек листе можно указать заголовок шаги и приоритет. Угу.

61: То есть вы в чек листе ещё пишите шаги. Вот просто обычно, ну, в чек листе как бы только заголовок идёт в большинстве случаев и как бы дальше расписывается, собственно, какие-то другие проверки, а вы прям шаги пишите для чек листа, да, но они как бы такие.

62: Не полные, а чтобы передать кратко суть. Угу. Окей, хорошо, я понял. Вот какие, как тебе кажется, атрибуты. Вот в тест кейсе невозможно убрать. Если уберёшь, то не получится. Тогда тест кейс в тест кейсе.

63: Я считаю, что шаги воспроизведения, наверное, это будет 1 из главных атрибутов. Угу. Ну, да, 1 из главных. Так, ещё, наверное, приоритизированная, этих, этого тест кейса. То есть тоже, чтобы для более

64: Конкретного и детального понимания, что будет более важным в том случае, если вдруг на регресс осталось очень мало времени и нужно вот срочно что-то пробежать, чтобы проще было выбрать необходимые чек листы. Угу. Окей.

65: Допустим, ожидаемый результат. Думаешь, стоит его без него как бы писать? Нет, конечно, ожидаемый результат тоже важен. Угу. Да. Ну, соответственно, нам надо понимать вообще, к чему нас эти шаги. Да, да. К чему они должны привести. Окей.

66: Вот багрепорт по любому писала, да, пишешь на проекте, вот можешь сказать, какие у вас там атрибуты в этом багрепорте. Угу. Так, получается, в багрепорте 1 атрибутом будет. Это заголовок в заголовке. Мы должны кратко, но че

67: Описать, что произошло, где произошло, при каких условиях это произошло. Также мы там должны прописать окружение. То есть в какой тестовой среде это, этот баг выявился.

68: На каком устройстве? Какой платформе? Вот или в каком браузере это произошло. Модель телефона, например, если это было мобильное тестирование. Далее пишется, мы пишем северити и приорити.

69: Критичность, потом шаги воспроизведения, шаги воспроизведения тоже должны как бы чётко быть, чётко быть последовательными, то есть 1 шаг это 1 действие i. Шаги должны привести тебя точно к

70: Получается, тому результату, который произошёл, соответственно, к Багу, ожидаемый результат фактический результат. И дальше можно приложить какие-нибудь логи, скриншоты, записи экрана. При необходимости. Окей, вы выставляете

71: Серьёзность багрепортов, да? Окей. А в чем отличие серьёзности от приоритета? Так, получается, серьёзность это влияние на техническую часть продукта. То есть, насколько сложно это будет исп.

72: Править приоритет, это да, приорити, он, получается, влияет на бизнес часть продукта. То есть, например, в названии компании на главной странице будет какая-то ошибка. То есть это легко исправить. То есть здесь будет

73: Низкая серьёзность, но тут будет высокий приоритет, потому что это нужно исправить срочно и сейчас, потому что пользователей будет падать доверие к компании, к бизнесу. То есть это касается вот таких вот бизнеса уже, окей.

74: Вот ты привела пример, допустим, с высоким паритетом, низкой серьёзностью, а можешь, наоборот, привести пример с высокой серьёзностью и низким паритетом, да, например, если у нас это, этот баг затрагивает

75: Какой-то функционал, которым пользуется маленькое количество людей. То есть, например, интеграция приложения. Сейчас, вот сейчас стало достаточно распространённое приложение с telegram ботом каким-нибудь. То есть, допустим, если мы понимаем, что на нашем проект

76: Только 1% пользователей пользуется вот этим вот чат чат ботом, то, соответственно, это будет для нас не так срочно в исправлении. Угу. Хорошо, я понял. Расскажи, с какими типами баз данных ты работала?

77: Революционные, в основном, ну, с революционными. Окей, какие запросы писала вообще, как взаимодействуешь с базами данных? Получается, запросы. Я писала, это селекты, джойны, вот агрегатные, различные функции, функции.

78: В having группировка сортировка. Это необходимо для того, чтобы проверить, правильно ли записываются, например, пользователи при регистрации. Вот не будет ли

79: Там каких-то ошибок, ошибок при записи или, может быть какое-нибудь поле может быть не записано. Угу. Окей, давай выполним небольшое такое задание. Я скину его сейчас в чатик. Вот по эскьюэль. Можешь его уже открывать, я его отправил. Угу.

80: Ознакомься, вот можешь вслух, как тебе удобно, можешь просто в чат написать ответ, ну, как бы можешь показать ход своих мыслей, если считаешь нужным. Вот. То есть у тебя, Таня, из, получается, 3 пунктов написать запрос, который выведет всех по

81: Пользователи старше старше 25 лет. 2 момент посчитать количество пользователей из города Москва, вывести список уникальных городов, в которых живут пользователи. 3. Вот, то есть пример таблички у тебя есть. Вот можешь написать эти запросы.

82: Прям в чатик так, всех пользователей старше 25 лет. Нам нужно имена пользователей именно вывести. Да, да. То есть вывести имена, которые старше 25 лет. Так, ну вроде так, 1. Так, 1 задание.

83: Давай посмотрим, что у нас есть. Можешь как-то прокомментировать? Вот что конкретно происходит. Угу. Получается, мы селектом выводим имена пользователей из таблицы. User, с условием в где эйч.

84: Возраст больше, ой, 25, 20, да, только 24 написала. Ну да. Окей, как думаешь, вот чего тут не хватает? Есть такая вроде бы небольшая тут ошибочка. Возможно, ошибка. Вот где в эйч.

85: Больше 25. Так, а ты не исправила, да? 24. Сейчас, сейчас, давай я перепишу исправить, да, на 25. Так, ну, это, да, все. Ну, в принципе, теперь ошибки нет. Вот, да, то есть 25, вот, по тз, потому что очень

86: Важно, да, нам именно вот этот момент касаемо возраста. Вот, потому что если ты ввела бы 24, вот у тебя бы че то не то вывелось. Вот. Окей. Давай попробуем тогда следующую задачку, да, 2 посчитать количество пользователей из города Москва. Угу.

87: Так, получается, сейчас я могу спросить. Угу. Количество пользователей это аккаунт или авг? Так, это, значит, мы 2, да, делаем, да, там, ну, аккаунт должно быть, аккаунт. Все, тогда вот так, так, хорошо.

88: Давай посмотрим 2 задачу. Да, нейм, вер сити, Москва тут как будто бы, ну ладно, пробелы это нормально. Ну, все, да, в принципе, остальное верно, хорошо.

89: А вот можешь 3 задачу, вот 2 тоже у нас правильная. Можешь 3 задачу вот рассказать. Просто, ну, там, по идее, небольшой будет запрос, да, у нас состоит задача в том, что вывести список уникальных городов, как бы ты вывела этот список уникальных городов, в принцип,

90: Кстати его можно не писать можно не писать ну получается будет select distinct так, города сити то есть дистинкт у нас даёт как раз уникальные ну города вот from.

91: Users from users в ct равно Москва ой, из уникальных городов нет нет нет, сейчас, сейчас селекта, дистинкт там просто from users все.

92: В принципе, этого достаточно там, да, from user. Ну, тут ещё просто можно ордер бай сделать. Ага. Окей. Часто приходится писать запросы вот на проекте или в основном, как бы, базово.

93: Можно в интерфейсе посмотреть. Вообще, в основном базу можно в интерфейсе построить, но все равно бывают такие случаи, когда написать необходимо. Окей. Хорошо, в принципе про базу данных у нас все. Вот давай поговорим про api. У вас же

94: По любому есть на проекте, да, в какой-то мере, что у вас за фишка рест или там что-то другое по ресту. Угу. Окей. Какие аштипи методы вообще, ты знаешь, Гетта пост пут делит.

95: Options. Основные вот такие вот. Угу. Патч. Метод не используете на проекте патч. Дааа. Используем. Хорошо, что делает метод options options. Получается, выдаёт. Так.

96: Сказать, как такой перечень доступных методов, вот в реализованной для сервера, реализованный для сервера. Угу. Хорошо. Можешь сказать вот про каждый метод, что

97: Вообще, какую функцию он выполняет? Угу. Получается, get on это как запрос на сервер. То есть, когда нужно получить какую-то информацию с сервера. Пост это когда необходимо создать на сервере.

98: Какую-то сущность пут это когда нужно эту сущность обновить полностью патч, это когда нужно эту сущность обновить, частично делит это удаление чего-то с сервера. Угу. Да.

99: Вроде все назвала. Окей. Можно ли менять, вот, допустим, гет запросом что-то отправлять на сервер? Да, можно, но только желательно, чтобы это были не какие-то чувствительные данные к безопасности, потому

100: Это будет как-то, ну, то, что get это передаётся он в урле, и это будет открыто и всем видно. То есть это будет небезопасно. А почему в урле передаётся? Потому что у get запроса нет тела. Угу, хорошо, хорошо.

101: Давай тоже выполним такое задание. В принципе, я сейчас тоже скину в чат, тут просто надо протестировать, ничего писать не нужно. Вот на слух как бы тестировал вот эту апишку. Вот я скинул это задание, можешь зайти посмотреть, то есть у нас есть

102: Пользователь с такими методами, которые там предоставлены, пост get put и delete, и как бы тебе надо 4 задачи выполнить, точнее ответить на эти вопросы как ты будешь проверять работу, пост метода и какие проверки ты?

103: Будешь делать в нём. Давай сначала с него. Угу. Так, нужно проверить работу метода post. Какие проверки нужно сделать. Так, ну, соответственно, я сначала попробую сделать. Поззи.

104: Активную проверку, вот внесу корректно все данные для создания пользователя, то есть, которые необходимы. Вот, ну, давай, допустим, представим то, что там для регистрации нужно. Фамилия, имя, mail.

105: И номер телефона. Угу. Вот сначала отправлю корректный запрос, проверю, что сущность создалась, что пользователь зарегистрировался. А как проверить, что пользователь

106: Сдался, допустим, ты отправляешь этот запрос, да, в посмоне, как я понимаю, допустим. Угу. Вот как ты поймёшь, что он создался. А, ну, то есть мне должен прийти 200 ответ, а потом можно гитом по айди. То есть, допустим, мне, я зарегистрировалась, мне выдался там, трёт.

107: Id и гитом, проверить, вернуть данные сервера, проверить, есть ли они там. Угу. Окей. Допустим, 200 код. Это, по идее, успешный ответ от сервера. Он разве не даёт тебе гарантию, что значит уже

108: Пользователь создался. Ну, я считаю то, что нет, он может не дать, потому что, может быть, как-то неправильно реализована функция создания пользователя на сервере. Может быть для него 200. Это успех. Чего?

109: Другого. Угу. Да, да, в принципе, так и есть, может быть, разные истории. Вот. То есть с двухсоткой или какой-то вообще скотт, он нам не гарантирует, что именно что-то произошло действительно успешное, либо наоборот, плохое. И также надо, конечно, данные проверят.

110: Который мы создали, тот же пароль, да, емейл и так далее. Вот хорошо получается. Get запросом ты получаешь, да, какие-то данные. Ну вот мы, в принципе, пока про post говорим, что ееще протестируешь в этом методе. Угу. Я, получается, попробую отправить.

111: Джейсон, вот как раз с этой информацией. И, например, я неверно введу, допустим, имя, буду использовать какие-нибудь символы, если эти символы у нас запрещены. Вот попро.

112: Поставить пробел спереди с начала слова в конце слова ну, то есть отправлю какой-то невалидный json, чтобы убедиться, что мне сервер не даст создать.

113: Такую не даст создать такого пользователя с неправильными данными. И он должен мне вернуть 400 ответ, где будет requests. Угу. Хорошо, хорошо. В принципе. Давай ещё.

114: Какую проверку можно сделать в этом методе? Попробую создать пользователя с такими же данными повторно. То есть он должен вернуть, не помню какой код он должен вернуть, но, в общем, он не должен мне дать зарегистрироваться повторно с теми

115: Же данными. Угу. Окей. Вообще, отличная проверка, да, такое вообще обязательно даже проверять. Хорошо, давай get запросу перейдём. Нам нужно получить просто данные пользователя. Как бы ты проверяла вот такой запрос, просто получить данные о пользова.

116: Ну, для начала опять попробую существующего пользователя, который у нас есть. Реально записан, зарегистрирован, вернуть, чтобы он мне вернул все его данные двухсотые.

117: Ответ также, чтобы данные, которые он вернёт, проверю, чтоб они были корректные. Вот. Потом попробую ещё запросить какого-нибудь пользователя с несуществующим айди. Угу.

118: Чтобы посмотреть, что он вернёт. Также можно попробовать отправить кет запрос в хедерах, например. Ну, что-нибудь попробовать поменять в хедерах, чтобы были неверные. Угу.

119: Окей, а почему мы вот в пост запросе ничего в хедерах не ставили? Как ты думаешь вообще вот что вот при пост запросе, да, на создание пользователя обычно бывает. А что бывает в пост запросе при создании пользователя, да, в заголовках токен должен быть?

120: Да, токен. То есть мы ж какую-то манипуляцию проводим, я же могу тебе дать апишку, и ты насоздаешь мне там, да, на сервере в базу данных очень много всего what, естественно. Ну, чаще всего токен какой-то хотя бы стоит. Вот. Окей. Также, давай ещё.

121: Позапросу тому вернуся, допустим, отправила запрос успешный, да, смог. Тест провела. Какой статус? Код ты ждёшь от этого метода? При успешном, да, при успешном 200. Угу. А почему не 201? А, да.

122: Кстати, 201, 201, 201. Это как раз говорит о том, что пользователь успешно создан. Да? Ну, тут тоже, конечно, в зависимости от проекта можно настроить 200 и не париться, там 201 ставить это как бы в зависимости, да, они по разному бывают. Где-то он может вернуть 200, где-то 200.

123: Как проверить вообще, что метод delete отработал у нас? Какой процесс? Вот тебе надо протестировать этот метод. Вот, да, удаление юзера. Вот как бы ты его проверяла. Угу. Получается, для начала я попробовала бы удалить нашего.

124: Существующего юзера. Ну вот, допустим, мы уже создали юзер с 3 айди. Вот посмотрю опять ответ, чтобы мне вернулся 200, что пользователь успешно удалён. Дальше я попробую отправить ещё 1.

125: Запрос с таким же пользователем, который мы только что удалили. Гет запрос. Вот. И что мне должно вернуться? То, что такого пользователя не существует. Угу. Хорошо. При удале.

126: Какая ошибка будет, точнее, при удалении успешном удалении. Какая вот статус, код у нас появится. Ну, по идее, наверное, должен 500 вернуться. Нет, то, что на сервере нету этих данных при успешном, я имел ввиду.

127: То есть ты удаляешь вот юзера, который существует, какой код мы ожидаем от delete 404 нот. Фаунд, наверное, а ресурс не найден. Ну, ещё раз успешно. То есть пользователь у нас существует, ты просто хочешь удалить, то есть позитивная проверка.

128: Если уже позитивно, то 200 то что запрос выполнен успешно. А вот если уже, а если вот пользователь, допустим, удалён, и ты отправляешь делит, то тогда по логике 404. Угу. Ну да, то есть, может быть и такой.

129: Id не найден, да. Угу. Хорошо. В принципе, я понял. Вот с этой задачкой мы тоже разобрались. Только расскажи ещё, чем пут от патча отличается в итоге, да, как я уже сказала, получается пут это у нас полное обновле.

130: Уже существующий существующего, например, пользователя на сервере apache частичное, то есть, например, при отправке запроса, например, у нас есть пользователь с именем фамилией, отчеством, вот, и если хочешь.

131: Например, исправить только имя, то это нужно делать ну то патчем можно, например, отправить json только имя, вот соответственно он просто обновит имя и вернёт тебе полностью вот это вот.

132: Джейсон с именем фамилией, отчеством, емэйлом. А put, например, если ты отправишь ему только имя, то он только имя и оставит. Он обновит все, что там есть. Вот можешь рассказать, какие функции девтулс ты используешь в работе. Угу.

133: Так, ну получается, это основная нетворк для отслеживания запросов. Какие запросы отправляются на сервер? Также вкладка консоль, где

134: Можно посмотреть ошибки java script вот также на нетворке, например, можно на вкладке убрать кэширование, чтобы ресурсы не кэшировались, посмотреть, как это будет рабо.

135: Работать без кэширования также в дефузе есть такая функция, как троттлинг поведения сайта, например, при медленном интернете также дефуз можно имитировать экраны различных мобильных

136: Приложений имитировать, например, как это будет на маленьких экранах. На больших можно поставить какую-нибудь, можно поставить какую-нибудь свою разметку.

137: Вот, вот, смотри, ты говорила, допустим, про адаптивность, да, в детул. Почему, собственно, обычно тестируют все-таки адаптивность на реальном устройстве, либо какие-то инструменты для мобильного тестирования используют. Вот они все-таки в детул это делают телефону.

138: Потому что на мобильном телефоне будет выявлено больше багов, так как это все-таки реальное устройство там будет сказываться тоже какой-нибудь заряд батареи, например.

139: Различные прерывания в тузе это сделать нельзя. И также детом нельзя протестировать именно само мобильное приложение, так как это можно сделать через, например, чарльз в мобильном телефоне. Окей.

140: Расскажи, вот, а в чем отличие тогда мобильного тестирования от веб тестирования? Отличие мобильного тестирования от веб тестирования, например, заключается в том, что в мобильном тестировании очень много различных телефо

141: Моделей производителей. То есть это нужно учитывать. А браузеров как бы не такое большое количество. Также на телефоне есть различные функции, такие как работа камеры, работа с геолока.

142: На телефоне также есть различные прерывания. Это, например, резкое отключение телефона при низком заряде батареи, различные всплывающие уведомления. Вот тоже, например, связано с батареей, то, что низкий

143: Процент батареи. И вот, соответственно, когда это уведомление всплывает, то там работа прекращается. Нужно проверить, сохранится ли текущий момент страницы, на котором ты сейчас, если вот это вот уведомление закрыть также

144: Можно протестировать, если позвонят на телефон, если его заблокировать, разблокировать. Окей, какие инструменты использовал для мобильного тестирования? Основное это час прокси для тестирования. Андроид. Это андроид студио адб для

145: Тестирования ios это икс код угу, хорошо понятно расскажи какие у вас мероприятия были скрамов кие ты говорила, что у вас был скрам, вот что вообще проводилось а у нас были грумминги, например это как раз мы

146: Разбирали требования, анализировали, читали, обсуждали требования, были ретро в конце спринтов, где мы оценивали работу, что мы успели, что не успели, что сделали, вот какие.

147: Были ли выполнены поставленные цели? Делики были каждый день. Ну и все. Как ты считаешь, что удобнее для работы? Скрам или канбан? Это зависит, наверное, от

148: Приложение, насколько часто, ой, не от приложения от проекта, насколько часто будут релизы на проекте, выходят ли они с определённым интервалом, насколько гибкая модель. То есть, да, в зависимости

149: Приложение от проекта. Окей, понял. Давай представим такую ситуацию. Ты создала багрепорт, направила на разработчика разработчик тебе его вернул, говорит, что он не будет его фиксить, потому что он не считает это багом. Вот он считает, это что это

150: Просто не баг, вот какие твои действия будут. Угу. Ну, для начала я обсужу это с самим разработчиком, мы с ним посмотрим требования. Вот будет ли, если в требованиях, как бы.

151: Будет нам достаточно требований, то я думаю, что мы как-то сами решим этот вопрос. Вот если все-таки требования будут, например, для нас неясны, то мы обратимся к системному аналитику, чтобы он как бы разъяснил для нас

152: Нас вопрос, считается ли это багом или нет. Угу. Хорошо. Расскажи, почему уходишь с своего проекта? Почему вышла в поиск? Ну, получается, я считаю то, что на текущем проекте я достигла своего потолка. Вот мне хочется

153: Какого-то развития. Хочется более такой масштабный, интересный проект, чтобы я могла дальше развивать свои какие-то навыки, скилы, учиться может

154: Быть у каких-нибудь других, более опытных коллег. А что тебе на твоём месте работы больше всего не нравилось? Я честно, не могу выделить, что мне прям сильно не нравилось, потому что мне в целом нравится моя работа.

155: Вот, наверное, ну, больше всего так, наверное, какой-то дискомфорт доставляло это прохождение регрессов, потому что это некая такая постоянная рутина. Вот, вот 1 и тоже проходишь эти регрессы.

156: Вот, но все-таки, как бы я к этому отношусь совершенно спокойно, потому что от этого я понимаю, что от этого никуда не деться. Это часть моей работы. Окей, что ждёшь от своей будущей компании. Угу. Получается, от компании. Я жду, чтобы

157: Они были готовы идти навстречу мне в плане моего развития. Вот также, например, я хочу

158: Чтобы был достаточно такой хороший анбординг, чтобы меня погрузили в проект достаточно так плавно. Вот. Ну и в целом хочется, хо.

159: Хорошую позитивную команду, с которой будет комфортно работать. Окей, супер. В принципе, у нас собеседование уже потихоньку заканчивается. Давай я тебе выдам фидбэк сразу же, как крутой технический специалист, да, который тебя собеседует, что как бы плохо, что нормально. Вот.

160: В целом собеседование прошло хорошо. Вот, в принципе, давай пройдёмся по таким нюансам, которые я заметил, чуть чуть чуть запуталась в видах тестирования, да, там ui вот не ответила, но, в принципе нормально.

161: Насчёт документации, да, тоже было несколько моментов. Вот касаемо чек листов и тесткейсов я бы тоже ещё пересмотрел, да, то есть этот подход просто у вас он чуть необычный, наверное, да, в какой-то степени на проекте, вот посмотреть, как у других потом.

162: Потому что мало там, допустим, кто в чек листах шаги пишет. Вот, ну, как бы, посмотреть, как это у всех, да, а не только под свою компанию. Возможно, у вас какой-то локальный процесс, вот. И других он как бы немножко будет смущать также, также, что ещё посмотреть по базам данных, в принципе, хорошо.

163: Вот, ну, конечно, собеседующему мне хочется слышать какие-то размышления, да, потому что я там понимаю, что можно, допустим, где-то че то списать, да, или там подсмотреть. Вот хочется все-таки слышать, как человек размышляет. Вот, в принципе, задания для этого и делаются по

164: Вот в целом тоже я б посоветовал чуть чуть бы повторить, вот не забывать там, допустим, тот же патч, метод, да, вот, может в работе не используешь, но, во всяком случае, как бы это 1 из базовых вот методов и как бы в проверках твоих

165: В принципе, они хорошие. Вот мне понравилась проверка, особенно с повторным повторной регистрацией. Вот, но, как бы, мне, допустим, хочется видеть много фантазии, да, то есть какой-то негативной, позитивные проверки, как бы, ну, по сути, может, как бы, любой придумать, там, допустим, зарегистри,

166: Понятно, что надо зарегистрироваться, но надо как бы немножечко показывать, что ты как бы можешь где-то и сломать систему, где-то можешь интересную проверку придумать, так же, как ты с регистрацией повторного пользователя придумала и также забыла, что тоже такой является ошибкой. Это требование уточнять. Вот.

167: Допустим, в Эскель ты спросила, да, вот про юзеров, кажется. А вот в аппе че то вообще ничего не спросила, хотя тоже обязательно на собесе, как бы, да, и в целом в работе, я думаю, надо уточнять всегда. Вот у людей, чтобы было понимание потом, потом, потом, в целом, остальное.

168: Все окей. Вот такой как бы краткий, краткий фидбэк. Может, у тебя есть какие-то вопросы к нашей компании? Вот можешь их задавать, можешь прям подряд их сказать. Угу. Да, мне интересно, анбординг как проходит в вашей компании?

169: Они плавно ли погружают тестировщика или сразу же дают какие-то рабочие, прям задачи. Угу. Ещё какие-то вопросы? Может есть, есть ли какие-то метрики по закрытию испытательного срока? Угу.

170: Ещё какая команда на проекте, из кого она состоит? Какие задачи, как проходит, например, стандартный рабочий день у вас на проекте? Как часто различные встречи? Окей.

171: Супер, я на них отвечать не буду. Вот. Но, во всяком случае, спасибо. В принципе, на этом заканчиваем все, пока, пока. Ну что, как тебе это видео? Устроился бы на позицию ручного тестировщика, начинающего специалиста джуна кьюэй, или же нет?

172: Пиши в комментарии и ставь лайк этому видео, если действительно оно тебе зашло, а мы увидимся скоро.