собеседование qa лайфхаки и скрипты успеха
Как QA-инженеру получить зарплату выше рынка? Высняем у Head of QA
Что нужно, чтобы ваше резюме читали внимательно, а не по диагонали? Какие вопросы будут на интервью и о чём стоит спросить работодателя? Как вести переговоры о зарплате? Про подготовку к собеседованию Алексей Петров, Head of QA Сбермаркета, рассказал у нас на вебинаре очень подробно. Все основные рекомендации — в статье!
На чтение одного резюме у интервьюера в среднем уходит 1–1,5 минуты, лист смотрят по диагонали. Если эти атрибуты выполнены, резюме прочитают чуть внимательнее. Чтобы «продать» себя, есть одна минута: поэтому важно подчеркнуть самые интересные случаи из опыта.
Пользуюсь этим рецептом, когда сам собеседую кандидатов.
Количество интервью зависит от специфики работы и этапов найма в конкретной компании. Если есть возможность, стараюсь уложиться в одно собеседование, больше двух очень не люблю.
Открытием для QA этот кейс не станет: тестирование простейшей формочки, формы поиска или авторизации/регистрации. Практика показывает, что очень многие специалисты не могут решить эту задачу в полной мере, сообразно тому, что ожидают IT-компании.
Тестировщики подходят к ней с точки зрения теории тестирования, классов эквивалентности, анализа граничных значений, строят графы переходы состояний. При этом забывают о продуктовом тестировании, когда фокус идёт не на комбинаторику и техники типа pairwise, а на сценарии, с которыми сталкивается реальный пользователь.
Наверное, теперь придётся исключить из собеседований этот вопрос, но приведу пример. Форма авторизации: логин-пароль, всё просто. Логин по маске либо телефон, либо имейл, пароль имеет какое-то ограничение.
Большинство кандидатов начинают перебирать комбинаторные варианты: введу много пробелов, ещё что-то такое. А для пользователя важны другие кейсы: при существующем аккаунте, пускай при корректной связке логин-пароль (имейл+пароль, номер телефона+пароль) пускает, по несуществующей связке — не пускает. Дробить тут можно бесконечно. Почему-то забывают про кейс с восстановлением пароля. По старому тебя не должно пускать, а по новому — должно. Именно по таким кейсам можно посмотреть, как кандидат владеет техниками тест-дизайна, может ли он от них абстрагироваться и думать о продукте не как о наборе кнопочек и формочек, а как о пользовательском сценарии, с которым сталкивается самый обычный пользователь.
В тестировании безусловно играет роль и product vision. Сейчас есть такая модная штука: shift-left testing. Тестирование подключается как можно раньше, включается в процедуру планирования, проработки требований. Такой подход всё популярнее во многих крупных компаниях, и разумеется, что QA-инженер понимает, какое есть продуктовое видение.
Пусть в бэклоге заложено 15–20 задач: зачем мы их делаем, какую пользу приносим пользователю — в зависимости от этого строятся кейсы. Например, хотим повысить ретеншн у мобильного приложения. Значит всё, что связано с реактивирующими пушами — для нас в высоком приоритете. Поэтому они должны работать идеально, как часы: приходить ровно, таргетировать человека в то место, куда должны, и так далее. Безусловно, QA должен понимать, зачем и как это происходит.
Есть альтернативный подход: shift-right testing. QA-инженер не начинает работу, когда тикет приходит в состоянии ready for test — подключается раньше, и не бросает её, когда тикет перешел в tested. Инженер помогает зарелизиться, помогает сопровождать в продакшене.
Речь и про регрессионные тесты, которые в будущем повторяются и говорят о том, что данный функционал не деградировал. Речь и про продуктовые метрики. Нередко, глядя на них, можно сделать предположение, что что-то пошло не так: смотрим на тот же DAU, а он резко просел после последнего релиза. Может, по техническим метрикам мы это не уловили, на регрессах проблемы нет, но всё равно это сигнал разобраться, что пошло не так, что повлияло на эти события. Плюс не надо забывать А/В-тестирование, feature toggling и так далее. Многие компании выпускают фичи на часть аудитории, QA вместе с продуктовыми аналитиками оценивают, оправдывает ли фича возложенные на неё надежды, если да — занимаются раскаткой дальше. QA не должны бросать фичу, протестировал — не значит, что работа закончена.
Позволю себе отойти в сторону: 50-60% кандидатов фейлится на вопросе про свой самый большой провал. Очень многие комплексуют признаваться в неудачах. Ощущение, что они начитались книг про успешный успех и думают, будто все истории построены на череде исключительно успешных кейсов. Это не так: не ошибается только тот, кто ничего не делает.
Я призываю всех искренне и прямо рассказывать о собственных неудачах. Не пытаться увиливать, спихивать ответственность на коллег, обстоятельства, фазы луны. Если человек хорошо рассказывает про собственные фейлы, например, как проанализировал их с помощью техники «Пять почему» или Диаграммы Исикавы, разобрался в причинах ошибок и устранил их, что сделал для того, чтобы проблема не повторялась — это очень подкупает. Если вам задают такой вопрос — будьте искренними, это ключ к успеху.
Если говорить про то, что спрашивать интервьюеров — советую задавать вопросы, применимые на практике, не абстрактные. Например, человек собеседуется на позицию специалиста по ручному тестированию, а спрашивает, что в компании с автоматизацией, нагрузочным тестированием, какие перспективы стать тимлидом — хотя сам — джуниор.
Спрашивайте то, что максимально релевантно функциональной нагрузке в будущей компании: как будет проходить испытательный срок, какие будут задачи, как понять, прошли ли вы испытательный срок или нет, есть ли kpi. Можно сразу задать встречный вопрос о негативных аспектах в работе в компании, о факапах — это актуальный вопрос для обеих сторон. Я предельно искренне рассказываю, если есть проблемы, неотлаженный процесс или мало автоматизации — прямо говорю и не преследую цели любыми способами заманить к себе специалиста. Люди ошибаются, и в компании тоже есть ошибки.
Центральный навык — самообучаемость. Часто кандидат рассказывает, как хочет погрузиться в специфику мобильного тестирования или автоматизацию, хочет стать тимлидом — а злой и коварный работодатель не даёт ему это сделать. Поэтому он ищет работу, где сможет себя проявить, и ждёт, что его, как в «Волшебнике из страны Оз», возьмут за ручку и по дороге из желтого кирпича поведут в мир новых знаний и компетенций.
Всё-таки хочется, чтобы человек был сам заинтересован в собственном обучении. Конечно, работодатели предоставляют возможности для роста внутри компании: конференции, митапы, посещение профильных мероприятий, бюджеты на обучение и прочее. Но важно, чтобы человек сам делал шаги в этом направлении: пет-проект по автоматизации, ссылка на Github, а там — да, может быть, «карманные» тесты, на основе роликов в Ютубе или курсов Udemy. Но уже это показывает, что инженер не стоит на месте, а обозначил себе цель и идёт ей навстречу, не ждёт чуда.
Второе: важно, чтобы человек излучал уверенность. Иногда встречаешь кандидатов, просишь рассказать, какие http-методы он знает. Неуверенным голосом он говорит: «get, post, кажется, patch, put… delete… options…». Спрашиваешь, в чём отличия get и post, а в ответ: «ну, я не уверен… по-моему, один получает, другой создаёт объект, или что-то такое…». Если видно, что человек выдаёт правильные ответы на собеседовании, но делает это очень неуверенно — в реальной работе его съедят.
Модная концепция, набирающая обороты в продуктовых командах: есть закреплённый тестировщик, и он единственный и самый компетентный QA в команде. Если на планировании он будет точно так же говорить: «ой, ну не знаю, может, не стоить брать, я могу не успеть» — это не прокатит. Человек должен излучать уверенность: такая черта характера не позволит проскочить багам на уровне «и так сойдет». QA должен убедить коллег, привести аргументы, что так делать не стоит.
Ещё — автономность в работе. Всё чаще в продуктовых командах QA работают в одиночку или в паре. В сервисной модели есть большой отдел тестирования, есть тимлиды — можно забиться в уголок и отсидеться, а проблемы решит старший товарищ, ведущий инженер, тимлид, руководитель группы. В продуктовых так не получится, и компаний с похожим подходом компаний всё больше. Поэтому надо прокачивать уверенность и автономность.
А отсюда — и инициативность. Нужно её прокачивать, не бояться выражать мнение, подсвечивать проблемы. Может, попросить добавить новый статус? А может, начать делать код-ревью? Сопротивление и легкая конструктивная оппозиция. Для всего этого, безусловно, должна быть инициативность.И всё равно — на одних софт скиллах далеко не уедешь, под ними должна быть техническая подложка. Опытный интервьюер быстро смекнёт, если человек умеет только рассуждать.
Сразу скажу, что рынок очень сильно поломался ковидом и удалёнкой. География присутствия расширилась, и у многих компаний поменялись установки.
Джуны — от 20 тыс. до 100 тыс. рублей. Найти работу с большой зарплатой сложно, одними курсами не обойдёшься, но устроиться можно. К тому же сильно зависит от региона.
У миддлов зарплаты тоже отличаются в зависимости от региона, компании, в каком секторе она работает. Финтех обычно платит больше всего — область специфичная. Для миддла — от 70–80 тыс. до 150–160 тыс. Тут ещё вопрос, кто какой уровень считает миддлом — в моём представлении, это сформировавшийся QA, который представляет, куда развиваться, чувствует почву под ногами, понимает, что хочет, может ответить на «пять почему».
Сеньоры: нижняя граница — от 100–120 тыс. рублей. Я видел ребят-сеньоров, не лидовых, кто на своей позиции получает 300 тысяч. Это даже не зарубежные компании, такие зарплаты существуют внутри российского рынка. Единственное, нужно отдавать отчёт, что если сфера — криптовалютный блокчейн и подобное, есть риск, что в понедельник вы проснётесь, а тимлид написал: извини, работы больше нет, зарплаты нет, ноутбук можешь оставить себе. Как ни печально, такие истории я слышал.
Тимлиды получают от 140 тыс. до 300 тыс., для хэдов я видел вакансии до 500 тысяч рублей. Все цифры называю с учётом налогов.
Лайфхак — давать вилку с небольшой «горкой», так, чтобы даже отступив от верхней планки, держать марку. Нормальная техника, если назвал: от 100 до 150, а по факту устроит и 130, к такому можно прибегать.
Ещё два пункта: честность, даже в таких базовых вещах, как назвать свой текущий уровень дохода. И аргументация — по опыту, если было 100 тыс., а хочу 150 тыс., но есть действительно понятные аргументы, та же ипотека — такой подход намного лучше сработает.
Важно быть честным, если вопрос финансов — определяющий. Неприятные ощущения остаются от беседы с человеком, который всё собеседование бьёт себя пяткой в грудь, говорит про развитие и интерес к продукту, желание работать в продуктовой команде, а потом называет цифру в 140 тыс., при текущей 95 тыс. Про таких невольно думаешь: и рыбку съесть, и косточкой не подавиться.
Здорово, если деньги становятся не самоцелью, а дополнительной наградой, плюс хочется соразмерности. Безусловно, ни для кого не секрет, что переход в другую компанию сопряжен с ростом з/п. Но если это не выпячивается — то вызывает симпатию. И, честно скажу, бывали случаи, когда я давал сверх ожиданий, как дополнительный мотиватор. В тех случаях я понимал, что человек стоит больше, к тому же эта история с Даннингом-Крюгером: часть людей себя недооценивает. Им важно показать, что они классные специалисты, в том числе в финансовом эквиваленте. Поэтому если у меня есть возможность и есть бюджет, я захеджирую свои собственные риски: что через полгода-год, почувствовав уверенность в себе, специалист не пойдет смотреть рынок. Дам ему хорошие деньги — и он будет работать не один год.
У меня и моих бывших коллег есть несколько статей типа «как подготовиться к собеседованию на тестирование бэкенда» или «какие есть требования/ожидания от QA». Они актуальные, очень рекомендую.
Есть пара ссылок про инвертированное собеседование: какие вопросы задавать и зачем. Это архиважно: когда перед тобой сидит кандидат, и на вопрос о компании или продукте не знает, что ответить — выглядит не очень. И наоборот, на моём опыте был человек, который погуглил наши статьи на Хабре, почитал, что пишут СМИ, установил продукт, сделал тестовый заказ, записал несколько баг-репортов, сопроводительное письмо — это подкупает.
Несмотря на то, что по многим позициям у нас кандидат диктует условия, так или иначе — компании выбирают сотрудников, и вовлечённость играет в этом роль. Поэтому помимо всех этих ссылок — рекомендую изучить, чем занимается компания, что за продукт и какая специфика.
Взгляд на процесс собеседования начинающего QA-специалиста
Вместо вступления
В первую очередь хочется отметить, что QA и тестирование в России идут довольно близко и разницы между ними очень мало, именно поэтому я обобщил эти термины.
В этой статье я бы хотел поделиться общими моментами процесса собеседования, как со стороны собеседоваемого, так и со стороны собеседующего. Тут приведен взгляд сразу с двух сторон. Так же хотелось бы сделать особый упор на техническую сторону данного процесса, так как, как правило, именно она и является решающей при выборе кандидата. Мне понравился вот этот топик, поэтому хотелось бы кое-что к нему добавить и увести в сторонy QA.
Сразу хочу отметить, что это лишь личные наблюдения и просто хотелось бы, чтобы процесс ревью был более понятен обоим сторонам. Везде своя специфика, но все равно можно выделить некоторые моменты. Все далее можно отнести к начинающему или уже имеющему опыт специалисту, но никак не к эксперту.
Чем занимались?
В большинстве случаев первым вопросом становится следующая фраза: «Чем сейчас занимаетесь?», и, опционально, «Почему хотите сменить работу?». Тут я советую просто рассказать тезисно, не пытаясь удивить, Ваш обычный рабочий день. Запомните, не пытайтесь «убить» Вашими знаниями, и тем более хитрыми аббревиатурами. Люди, сидящие напротив Вас вполне могли работать в Вашей нынешней (бывшей) компании. Расскажите процесс, по которому вы работаете, составление тест-планов, тестирование, верификация и т.п. Особенно хорошо, если вы скажете какую именно Вы играете роль в повышении качества продукта, и как именно вы помогли сделать процесс эффективней.
Технические знания
Как уже было описано в начале, именно эти знания играют важнейшую роль в процессе прохождение интервью. И тут сразу «голос из зала»: «А что если человек на самом деле умный и способный, но ему не давали развернуться и ничем заниматься? Он хороший, он всему научится!». Да, безусловно так всегда бывает, очень много разных факторов может быть не учтено в процессе оценки технических знаний, но нужно руководствоваться одним простым правилом — если человек, работая 2-3 года, например с тестированием firewall-систем, не знает чем отличается TCP трафик от UDP трафика, аргументируя это тем, что «Да как то не интересно было», то это «настораживает»
В зависимости от компании, текущего проекта, должности, области вопросов могут меняться, но все равно остаются, скажем так, столпы, которые спрашиваются в 80% случаев. Итак, вот они:
Тут необходимый минимум должен быть запрос следующего вида:
Select * from my_table where >
Да, для кого-то это все ерунда, для других это набор букв. Здесь стоит учесть только лишь один момент, если человеку не нужен был SQL для активного использования, то смысла гонять его по JOIN’ам и CONCAT’ам или чему-нибудь вроде функций нет. Тут я думаю, а точнее очень хотелось бы услышать фразу: «Гугл».
+ Тут будет если человек безошибочно назовет все предложенные команды, названия и основные отличия альтернативных баз данных, а так же не будет особо долго думать над ответом, даже если не знает его, а просто начнет рассуждение.
Linux
Network
Основные принципы процесса «Как все происходит». GET, POST, HTTP, FTP, SMTP — эти страшные сокращения не должны Вас пугать.
+ Знать как работает DNS, ARP, NAT, DHCP. Иметь опыт настройки «чего-нибудь» в «боевой обстановке», например дома. Это просто показывает, что вы не боитесь проблем и можете пользоваться документацией.
Programming
Тут самый больной вопрос. Крайне редко, а точнее ну очень редко, бывает что человек хорошо знающий программирование работает в QA. Тут нужны основные знания по любому языку программирования. Знания циклов, рекурсий, ООП. Вообщем, тут чем больше, тем лучше, даже HTML и XML, это уже показатель того, что вы можете работать напрямую с кодом. Для QA «замешанных» в автоматизации, а в основном это Python, JS, Java знание синтаксиса очень желательно, да и опыт написания собственных скриптов/программ очень приветствуется.
+ Четкое знания различий между ООП и функциональными языками. Опыт разработки/поддержки автоматических тестов.
Тестирование
Тут можно говорить долго и бестолково, к сожалению.
Тестирование лифта, ручки, самолета — полная банальность, особенно когда Вы, уже работали с различными способами, уровнями, моделями тестирования. Тут одним из самых лучших примеров, который мне попадался, было тестирование формы авторизации. Само по себе задание выглядит следующим образом:
У вас есть Логин, пароль, чекбокс, кнопочка: 
По сути здесь все просто, но нужно ведь протестировать систему на «выдержку» и пр. Самое главное — описать тестирование с двух сторон. Тестирование как пользователем — у вас есть мышка, браузер, клавиатура. Тестирование скриптом (специальными инструментами) — отправка 1000+ запросов подряд, ввод очень больших значений и пр. Главное уметь понять, какие из подходов здесь можно применить. Так же стоит отметить, что тестирование «ящиков» здесь тоже имеет место быть.
Английский язык
Так уж заведено, английский язык признан международным стандартом. В этом случае играет роль компания работодатель и ее конкретный процесс. Думаю лучшее мерило английскому языку — умение как перевести 80-90% текста на русский, так и рассказать, например, про Ваш обычный рабочий день на английском языке. Соответственно не стоит изображать нелепый акцент и думать над каждым словом по 5 минут. Как можно проще и понятнее, в этом и есть умение разговаривать на английском языке (имхо).
Вопросы на логику
Личностные качества
Всегда стоит спросить, ну или рассказать о своих увлечениях, интересах, времяпрепровождении. Особым моментом хотелось бы отметить желание кандидата расти и развиваться, как в профессиональном, так и в личностном плане. Спросите про желание изучать языки, как вербальные, так и программирования. Хороший специалист, опять же мое скромное мнение, всегда должен стремиться к изучению новых технологий и к совершенствованию уже имеющихся знаний. Так же могут быть заданы вопросы, которые требуют у Вас выбора: Коллеги или работа, Карьера или честность и т.д. Тут думаю правильного ответа нет…
«У Вас к нам есть вопросы?»
Тут все просто. Если Вы думаете что прошли собеседование хорошо, спросите про процесс, перспективы, коллектив, бонусы, возможность командировок. Только не спрашивайте слишком много, Всю нужную информацию Вы можете получить на официальном сайте организации. Спросите про медицинскую страховку, в “маленьких” компаниях Вы узнаете много “подводных камней”, но уже будет поздно. Обязательно поинтересуйтесь про график. Он должен Вас устраивать, спросите про «овертаймы», часто ли они бывают, по какой причине, как оплачиваются. Если Вы уверены, что плохо прошли собеседование, обязательно спросите, что Вам нужно знать, в каком направлении двигаться, какие области знаний наименее сильны именно у Вас и что нужно, чтобы работать в этой организации. Последнее, я уверен, самое важное, так как именно это дает Вам необходимый толчок к движению вперед.
Отдельным моментом тут идут человеческие, а точнее эмоциональные моменты. Так, например, Вас могут “заставить” подождать с 20-30 минут, после чего прийти, и, не извинившись, начать разговор. Опять же, этот разговор может иметь изначально негативный “оттенок”. Так же, могут в лицо оскорблять как Вас, так и Ваши знания. В этих случая проверяется стрессоустойчивость человека, ведь именно в этот момент, можно попытаться посмотреть “под маску” собеседоваемого. На моем опыте я старался держаться от подобных компаний как можно дальше. Тут компания находится в менее привлекательном положении, ведь именно ей надо нанять наиболее квалифицированных кадров, но почему-то об этом они зачастую забывают.
Спасибо за внимание. Надеюсь данный топик изменит, хотя бы немного, процессы ревью в некоторых компаниях. Прошу прощения за допущенные ошибки.
Чек-лист подготовки к собеседованию на позицию ручного web-тестировщика
Самые популярные вопросы:
Какие методики тестирования Вы знаете?
модульная/компонентная: проверяет функциональность и ищет дефекты в частях приложения, которые доступны и могут быть протестированы по отдельности;
интеграционная: предназначена для проверки связи между компонентами, а также взаимодействия с различными частями системы.
системная: высокоуровневая проверка функционала всей программы или системы в целом.
приемочная: проводится на этапе сдачи готового продукта заказчику.
Именно в этом порядке программное обеспечение подвергается испытанием.
Расскажите про виды тестирования?
Все виды тестирования программного обеспечения, можно условно разделить на следующие группы:
связанные с изменениями, то есть после исправления бага/дефекта необходимо повторное тестирование, с целью убедиться, что внесенные изменения действительно решили проблему.
Что такое нагрузочное тестирование и чем отличается от стресс тестированием?
Какие бывают подходы тестирования?
Всё зависит от доступа к коду программного обеспечения.
Что такое чек-лист и как его оформлять?
Литературы по тестированию множество и вам всё не перечитать, это и не нужно! Выбирайте книгу более современную и тоньше.
Что такое web приложение? Однозначно, это клиент-серверное приложение, в котором клиент взаимодействует с веб-сервером при помощи браузера. Поэтому не избежать вопросов про сетевые протоколы взаимодействия. Могут быть общие вопросы:
Какие интернет протоколы Вам известны?
На собеседование достаточно будет рассказать про основные протоколы, углубляться в эту тему не следует. Наиболее известные протоколы:
HTTP (Hyper Text Transfer Protocol)
FTP (File Transfer Protocol)
POP3 (Post Office Protocol)
SMTP (Simple Mail Transfer Protocol)
Но основная часть вопросов будет про http и https:
Расскажите какие между ними различие?
http — протокол прикладного уровня передачи данных, изначально — в виде гипертекстовых документов в формате HTML, в настоящее время используется для передачи произвольных данных.
https — расширение протокола HTTP для поддержки шифрования в целях повышения безопасности.
Как же ответить на вопрос «в чем отличия?», ответ кроется в их определении, а именно: https не является отдельным протоколом передачи данных, а представляет собой расширение протокола http с надстройкой шифрования; передаваемые по протоколу http данные не защищены, https обеспечивает конфиденциальность информации путем ее шифрования.
Какие Вам известны методы протокола http, расскажите вкратце о каждом?
HTTP определяет множество методов запроса, которые указывают, какое желаемое действие выполнится для данного ресурса.
Метода GET в HTTP используется для получения информации от сервера. Запросы клиентов, использующие метод GET должны получать только данные и не должны никак влиять на эти данные.
Метод HEAD работает точно так же, как GET, но в ответ сервер посылает только заголовки и статусную строку без тела HTTP сообщения.
Метод POST используется для отправки данных на сервер, например, из HTML форм, которые заполняет посетитель сайта.
Метод PUT заменяет все текущие представления ресурса данными запроса.
Метод DELETE удаляет указанный ресурс.
Метод CONNECT преобразует существующее соединение в тоннель.
Метод OPTIONS используется для получения параметров текущего HTTP соединения.
Метод TRACE создает петлю, благодаря которой клиент может увидеть, что происходит с сообщением на всех узлах передачи.
Метод PATCH используется для частичного изменения ресурса.
Отвечая на этот вопрос можете перечислить только основные методы.
Расскажите о структуре http-запроса и ответа?
Не пугайтесь этого вопроса, здесь следует упомянуть только про основные части http запроса: строка запроса, заголовки, тело сообщения. Нужно обратить внимание, что между заголовками и телом сообщения находится пустая строка (в качестве разделителя), она представляет собой символ перевода строки. При получении ответного запроса от сервера, тело сообщения обычно представляет собой содержимое веб-страницы.
Для расширения кругозора рекомендую прояснить понятия «Транспортный уровень», «Уровень сети интернет», «Канальный уровень».
Основы Web-программирования
Веб-приложение — клиент-серверное приложение, в котором клиент взаимодействует с веб-сервером при помощи браузера. Поэтому вопросы на собеседовании по этой теме обязательно будут!
Почему не открывается гиперссылка?
При ответе на вопрос необходимо уточнить, что у пользователя устойчивое интернет соединение. Даны следующие вводные: пользователь заходит на популярный ресурс с новостями, нажимает на «Срочная новость!», но страница не открывается. Самый простой способ разобраться в причине, это воспользоваться браузерной консолью. Открыли консоль, выбрали элемент с гиперссылкой, и анализируем какой веб-адрес указан. Самая популярная ошибка, которую находят тестировщики, это неверно указанный веб-адрес.
Почему не соответствует цвет кнопки дизайну?
Посмотреть цвет кнопки можно аналогичным способом через браузерную панель, и сравнить кодировки цвета.
Расскажите про браузерную консоль.
Панель Elements показывает разметку страницы точно так же, как она рендерится в браузере, так же можно посмотреть, как бы выглядела открытая страница на каком-нибудь девайсе с другим расширением экрана.
Панель Network. Основная функция данной вкладки – запись сетевого журнала. Она дает представление о запрашиваемых и загружаемых ресурсах в режиме реального времени.
Панель Performance. Данная вкладка используется при необходимости полного обзора затраченного времени.
Панель Memory. Данная панель дает возможность профилировать время исполнения и использование памяти веб приложением или страницей, таким образом помогая понять где именно тратится много ресурсов и как можно оптимизировать код.
Панель Application. Предназначена для исследования загруженных элементов.
Если у вас есть основы знаний HTML, CSS, JS это будет огромным плюсом, хотя бы следует развиваться в этом направлении, чтобы стать хорошим специалистом!
Что же именно входит в основы?
А что же с API?
Сложность тестирования API (программный интерфейс приложения) заключается в отсутствии пользовательского интерфейса. Поэтому нужно настроить с необходимым набором параметров среду тестирующую API, а затем проанализировать результаты теста. Какие же вопросы могут таиться:
Чем отличается REST от SOAP протокола?
REST — это архитектурный стиль. SOAP — это формат обмена сообщениям, имеет веб-сервис WSDL с прописанными методами, которые можно удаленно вызывать.
REST работает только по HTTP/HTTPS, SOAP с любым протоколом прикладного уровня: SMPT, FTP, HTTP, HTTPS, POP3.
REST более простой, гибкий и быстрый, SOAP типизированный, но в некоторых случаях лучше визуализируется за счет применения им синтаксиса похожего на HTML разметку.
Какой формат передачи информации используется в SOAP, а какой в REST?
REST использует Json и XML, SOAP только XML.
Какие инструменты вы знаете для тестирования API?
Отвечая на этот вопрос, опирайтесь на свой опыт. Список самых популярных инструментов: SoapUI, Postman, REST-Assured, Fiddler, Karate, JMeter.
Информации по API в свободном доступе огромное количество, поэтому вы сможете разобраться в этом разделе.
Как быть с автоматизацией?
Во многих компаниях активно используется автоматическое тестирование. Часто разбором результатов прогонов и анализом занимаются ручники. Поэтому нужно иметь небольшое представление, как строится процесс автоматизации и какие инструменты используются.
Если раньше в работе сталкивались с автоматизацией, то расскажите подробнее какой использовался технический стек, как происходил разбор тестов, и какой был алгоритм действий, если автотест падал с ошибкой.
Большим плюсом будет опыт работы с GIT и с базами данных.