что нужно знать тестировщику автоматизатору
Путь тестировщика: с чего начинать изучение автоматизации
Шесть лет назад Роман Печерский из Ижевска прошёл курсы для функциональных тестировщиков и начал работать QA-инженером. Спустя несколько месяцев он впервые столкнулся с автоматизацией тестирования и понял, что хочет развиваться в эту сторону.
Сейчас Роман руководит командой автоматизаторов, а также учебным центром по автоматизированному тестированию в ижевском EPAM. Он рассказал, с чего начинал изучать автоматизацию, как развивался, с какими проблемами имел дело и какими лайфхаками пользовался.
Как я познакомился с автоматизацией
Я впервые столкнулся с автоматизацией, когда техлид нашего проекта предложил мне покрыть автотестами проверки, чтобы их можно было запускать после любого изменения и быстро получать обратную связь. К тому времени я не проработал в тестировании и года, поэтому чувствовал себя не особо комфортно. Несмотря на это, задача показалась мне интересной, и я решил попробовать её выполнить – правда, даже не представлял, с чего начать.
Кто-то из коллег по проекту рассказал мне про Selenium IDE – инструмент для автоматизации действий Firefox-браузера. Помню, как написал свой первый автотест с помощью метода Record and Play: включил запись, начал нажимать кнопки, вводить текст в поисковую строку и кликать по ссылкам. Получился набор сохранённых действий, который можно было запускать и сразу видеть результат.
Знакомства с Selenium IDE и этих лекций мне вполне хватило, чтобы решить ту проектную задачу и начать делать первые шаги в сторону в автоматизации.
Как я учился автоматизации
Вскоре я начал самостоятельно изучать Java – один из самых популярных языков для автоматизации тестирования – и пробовать писать несложные автотесты в Eclipse, например, для тестирования login-формы приложений.
Однажды мы с моим менеджером обсуждали моё дальнейшее развитие. Я сказал, что планирую двигаться в сторону автоматизации, и попросился на курсы по автоматизированному тестированию для сотрудников.
Следующие шесть месяцев я работал и учился – по вечерам, выходным, праздникам. Всё усложнялось тем, что первые три месяца я находился в командировке на новом проекте. После работы я возвращался в гостиницу с мыслями о том, что если вовремя не сдам домашнее задание, то накоплю долги, за которые меня могут отчислить. Для меня это был ужасный стресс, и я даже похудел на несколько килограммов.
Вот что помогало мне преодолевать трудности:
• Понимание, зачем это нужно
Несмотря на то что учёба была сложной и временами даже скучной, я чётко осознавал, какие возможности она мне откроет. Именно поэтому всё свободное время я посвящал автоматизации. Вместо прогулок по городу – автоматизация, вместо посиделок в баре с коллегами – автоматизация, вместо вечернего сериала – автоматизация.
• Поддержка коллег
Всегда приятно, когда тебя кто-то подбадривает – особенно люди, которые уже прошли тот же путь.
• Чувство соперничества
Ощущение, что я могу стать самым отстающим студентом в группе, также подстёгивало меня двигаться вперёд.
Когда курсы закончились, я начал работать на проекте, чередуя обязанности функционального тестировщика и автоматизатора. Через несколько месяцев присоединился к новому проекту – уже в роли тимлида. QA-команда состояла всего из двух человек – меня и функционального тестировщика, которому я объяснял основы автоматизации.
Как я начал обучать автоматизации
Мой коллега по проекту – первый человек, которого я начал обучать автоматизации. Сначала моих знаний не всегда хватало, чтобы отвечать на его вопросы и помогать решать проектные задачи. Но когда я не мог ему что-то объяснить, то понимал, что сам недостаточно развиваюсь в теме и подтягивал знания. Обычно я искал ответы на Stack Overflow или обращался за помощью к разработчикам.
Постепенно моя команда выросла до 10 автоматизаторов. К тому времени я полностью отошёл от ручного тестирования и занимался комплексным системным автотестированием веб-приложений. Затем начал помогать команде с созданием архитектурных решений для тестов и стал проектным координатором.
Полгода назад мы с коллегами организовали в офисе собственный учебный центр по автотестированию. Стали брать на обучение студентов последних курсов и людей, которые решили сменить сферу деятельности.
Недавно я сам прошёл небольшой курс – по JavaScript – и подключился к новому проекту. Раньше я никогда не сталкивался с JS. Мне потребовалось около месяца, чтобы начать более-менее уверенно чувствовать себя в работе с новым языком.
Резюмируя свой опыт, я могу дать несколько советов новичкам, которые делают первые шаги в автоматизации.
• Начните с практики – создайте собственный автотест
Многие думают, что прежде чем писать автотесты, нужно сначала разобраться с теорией тестирования и выучить Java или другой язык программирования. Обычно энтузиазма у таких людей хватает ненадолго, потому что это долгий и сложный процесс.
Я считаю, что начинать нужно с простых вещей. Создайте несложный автотест сами. Чтобы было интереснее, попробуйте решить какую-нибудь жизненную задачу. Например, напишите скрипт, автоматизирующий передачу показаний счётчиков воды на сайт водоканала. Сегодня это можно сделать с помощью Katalon Studio, который пришёл на смену Selenium IDE. Такие задания подогревают интерес к изучению автоматизации. Затем можно будет переходить к изучению теории и специфики автоматизации, а также начать осваивать язык программирования в связке с Selenium WebDriver.
Допустим, вы поняли, что хотите развиваться как тестировщик-автоматизатор и готовы потратить время на учёбу. Если вы планируете полностью погрузиться в обучение и не растягивать его на долгие месяцы, нужно либо оставить текущую работу, либо попросить у начальства длительный отпуск.
Можно последовать моему примеру и попытаться совместить учёбу с работой. Так вы сохраните зарплату, но на несколько месяцев полностью забудете о существовании свободного времени.
• Начните учиться самостоятельно или пройдите курсы
Курсы – хороший вариант для тех, кто вообще не имеет представления о том, с чего начать, или хочет систематизировать свои знания. Онлайн-курсы можно найти на Otus, Stepik, GeekBrains, Lynda, JavaRush. Если говорить об офлайн-обучении, его могут организовывать разные IT-компании вашего города: учебный центр EPAM, например, работает в шести российских городах.
Обычно программа любого курса по автоматизации разделена на три модуля:
1. Введение в теорию автоматизации;
2. Изучение основ языка программирования (например, Java);
3. Написание собственных автотестов.
Это, на мой взгляд, универсальный алгоритм для изучения автоматизации тестирования. Его также можно брать за основу, если у вас есть технический бэкграунд и вы решили самостоятельно постигнуть азы автоматизации.
Вот минимальный набор знаний, которые вы должны освоить, чтобы начать работать на реальных проектах:
• Понимание основных понятий тестирования: тест-кейсы, дефекты и т.д.;
• Понимание, что можно автоматизировать, а что нет;
• Знание основ языка программирования (Java, JavaScript, Python, C#);
• Умение работать с Selenium WebDriver;
• Умение писать локаторы для элементов;
• Знание одного-двух юнит-фреймворков.
• Как можно больше интересуйтесь
Новичков в автоматизации чаще всего отпугивают ошибки в коде. Они запускают код, видят, как что-то идёт не так, и впадают в ступор. Что делать в такой ситуации? Попробовать найти решение в интернете, например, на том же Stack Overflow. Ещё один вариант – попросить помощи у более опытных коллег. Они тоже когда-то были на вашем месте и делали такие же ошибки. Обсуждая какую-либо задачу с опытными автоматизаторами, вы расширяете свой профессиональный кругозор.
• Не стойте на месте
Чтобы поддерживать себя в форме, нужно постоянно находиться на технологическом острие. Вводите в работу новые фреймворки и библиотеки, разберитесь с Continuous Integration, углубите знания языка программирования или освойте новый, читайте тематические статьи и блоги:
За пять с половиной лет, что я работаю с автоматизацией, я ни разу не пожалел, что выбрал это направление. Мне нравилось выполнять и задачи ручного тестирования, но я понимал, что рано или поздно упрусь в потолок. Потолок для мануальщика наступает, когда он тестирует разные виды приложений – веб, десктопные, мобильные – настолько профессионально, что работа перестает подбрасывать новые вызовы и превращается в рутину. Чтобы не стоять на месте и развиваться дальше, необходимо получить какой-то новый навык. Можно заняться автоматизацией функционального или нагрузочного тестирования, можно переключиться на тестирование безопасности или, например, разобраться в базах данных. Ещё можно посмотреть в сторону DevOps, бизнес-анализа или проектного менеджмента.
Я своего потолка как мануальный тестировщик достичь не успел – автоматизация увлекла меня раньше. При этом бэкграунд мануальщика сильно помогает мне в работе все эти годы. Я не только реализовываю тест-кейсы, но и обычно сам пишу для них сценарии. Так я понимаю, что именно тестирую, какой функционал покрываю и какого жду результата.
ТОП-5 вопросов начинающего автоматизатора про автотесты
Всем привет! Я Оля, тестировщик мобильных приложений в hh.ru. Сегодня мы завершаем серию ответов на самые популярные вопросы про автоматизацию тестирования. Ранее мы уже ответили на вопросы ручного тестировщика, менеджера и технического директора. Пришло время ответить на пять самых интересных вопросов начинающих автоматизаторов — про флакования и баги с прода, нашу борьбу за стабильность и как не терять всеобщее доверие к автотестам.
Видеоверсию моих ответов можно посмотреть и послушать тут.
А пока мы не перешли к торжественной части, было бы круто, если бы вы помогли нам в нашем исследовании:
Каждый год мы изучаем технобренд крупных и не очень игроков российского IT-рынка. Выясняем, кого знают меньше или больше, куда пойдут работать охотнее и почему. Результатами обычно делимся прямо здесь, на Хабре.
Пожалуйста, пройдите этот опрос и помогите изучить рынок IT в 2021 году.
Вопрос 1. Мы пишем и прогоняем автотесты, а баги с прода все равно прилетают.
Начнем с того, что баги с прода продолжат прилетать в любом случае, и это совершенно нормально.
Пользователи могут совершать с вашим приложением невообразимые действия и проходить невероятные, непредсказуемые сценарии — открыли, перешли в другое приложение, заблокировали телефон, получили пуши, где-то полистали новости и решили вернуться в наше приложение. И вот тут-то баг его и поджидает. Частично такие кейсы можно автоматизировать — с помощью нагрузки, прерываний и выгрузки в фон и т.п. Но все возможные уникальные сценарии покрывать автотестами точно не стоит. Как минимум потому что ни один CI не выдержит такой загрузки, а время тестового прогона не будет того стоить.
Также могут быть девайс-зависимые баги, которые невозможно отловить автотестами, если вам не повезло тестировать именно на этом устройстве. Можно, конечно, попробовать настроить CI так, чтобы он создавал разные эмуляторы, или гонять автотесты на разных реальных девайсах, но это значительно увеличит сложность поддержки таких автотестов и скорее всего снизит их стабильность. И, опять же, это не будет стоить увеличенного времени на поддержку и прогоны, особенно с учетом, что находимые баги будут минорными.
Вопрос 2. Как сделать так, чтобы автотесты не заставляли всех страдать?
Чтобы автотесты не заставляли страдать всех вокруг, достаточно следовать некоторым правилам:
Правило 1. Писать понятный читаемый код, настроить отчеты.
Тесты должны быть понятны не только вам, но и другим тестировщикам и разработчикам. Если ваш тест упал, то человек не должен сидеть над ним полдня или сразу идти к автору автотеста с “помоги, посмотри почему он упал”, а должен сам понимать место и причину падения. Еще лучше, если у вас настроены человекочитаемые отчеты, в которых также видны шаги и место, где и почему упал тест.
Никому не хочется тратить время на то, чтобы понять, как автотест работает и что он там вообще проверяет — всё должно быть прозрачно.
Правило 2. Обязательное ревью.
Чтобы убедиться в том, что ваш тест действительно полезен и идеален, нужно, чтобы кто-то еще это подтвердил, и тогда можете спать спокойно.
У нас в hh для всех задач предусмотрено обязательное ревью. Для всех задач с автотестами предусмотрено обязательное ревью от QA. Это крайне важно, так как ревьювер может найти не только неправильный отступ, но и ошибки в логике, посоветовать добавить какие-либо дополнительные проверки, или указать на то, что вы запросто могли пропустить.
Правило 3. Сразу внедрять автотесты в ваш CI/CD
Очень важно, чтобы автотесты сразу приносили пользу, а не ждали лучших времен где-то в недрах кода. Чем быстрее все начнут привыкать, что их код теперь тестируется, тем проще всем станет жить. При этом важно не забывать, что выпускать автотесты нужно максимально стабильными. Перед тем, как вмержить свои тесты, лучше в прямом смысле 100 раз прогнать их на CI. И только убедившись на 100%, что тест не флакует, не падает неожиданно в разных местах, работает и работает как надо — сразу вперед!
Вопрос 3. Из-за чего тесты постоянно падают? Как можно им доверять?
Начнем с того, что какие-то автотесты в любом случае будут падать. Это совершенно нормально, так как если они в 100% случаев всегда зеленые, стоит задуматься — а проверяют ли они вообще что-то?
Но со своей стороны мы обязательно должны сделать максимум для того, чтобы падали они как можно реже. Для этого нужно научиться быстро понимать и устранять причины падений и улучшать слабые места.
За время работы с автотестами я выявила свой личный ТОП-4 проблем с автотестами:
1 — Кто-то что-то выкатил и все упало
Тут все просто — изменения в функционале должны идти рука об руку с правкой автотестов. На такие правки мы закладываем время при оценке и декомпозиции задачи. Когда разработчик изменяет что-то в функционале, который уже был покрыт автотестами, перед тем как вмержить свою ветку, он должен поправить автотесты, чтобы они продолжали проверять этот функционал. Очень важно наладить этот процесс, не игнорить тесты, а всегда поддерживать их актуальность.
2 — Тесты начали падать, но мы ничего не меняли
Тут интереснее. Разработчик ничего не менял, но в какой-то момент тесты начали падать. Возможно, что-то поменяли на бэке.
Почему наши UI-автотесты зависят от бэкенда?
Наши автотесты гоняются на тестовых стендах — это копия продового бэкенда (без продовой базы данных). Мы поддерживаем их актуальность — каждый день автотесты запускаются на актуальном бэкенде. Соответственно, если кто-то зарелизил что-то новое, наши автотесты об этом узнают и, как следствие, могут упасть. Мы в срочном порядке бежим смотреть: баг это или наша новая реальность, которую следует поддержать. И далее либо сообщаем команде о баге, либо правим тесты.
Тут важно заметить, что это случается не при каждом изменении на бэке. Всё-таки в основном, мы синхронизируемся командами по всем изменениям. Но реальность такова, что иногда какие-то моменты упускаются — кто-то не подумал, что может зааффектить мобильные приложения, например. Наши автотесты к такому чувствительны.
Каждый раз, когда такое случается, мы задумываемся о моках. Моки — это классно, если ими не злоупотреблять. Но всё-таки я думаю, что такая чувствительность автотестов к изменениям — это нормально, потому что там мы остаемся в курсе новых фич, которые влияют на наше приложение со стороны других команд. Плюс на моки тоже нужно выделять время на поддержку и актуализацию. Тут каждый сам выбирает, что ему больше хочется поддерживать.
3 — Баги
Моя любимая причина падения автотестов. Тут можно и без комментариев. Если ваш автотест нашел баг, то это очень хороший автотест, а вы — большой молодец.
4 — Флакование
А это самая нелюбимая причина. О ней поговорим далее.
Вопрос 4. Почему мои тесты флакуют?
Флакование как эмоциональные качели — ваши тесты то зеленые, то красные, всем то грустно, то радостно, и как с этим жить никто не знает. Чтобы отношения вашего приложения и автотестов были максимально здоровыми, советуем придерживаться нескольких правил о том, как избежать флакований и писать изначально более стабильные автотесты:
1. Уникальные тестовые данные
Для каждого автотеста должны создаваться новые уникальные тестовые данные, с которыми будет работать только этот тест. Нельзя надеяться на то, что на каком-то экране точно будет что-то, что мы сможем проверить и нам ок. Предсказуемость очень важна.
2. Не забывать дожидаться элементов на экране
Вы написали логичный тест, все четко по шагам, но тест не проходит и постоянно падает в разных местах. Скорее всего где-то он не успевает дождаться нужного элемента и тапает не туда, куда бы вам хотелось. Усугубляют ситуацию различные анимации, лоудеры загрузки и внезапные алерты.
Чтобы такого не случалось, перед каждым действием над элементом (тапы, свайпы и т.д.) или ассертом (проверкой, чеком) нужно дождаться, пока этот элемент точно появится на экране и будет доступен.
У Kaspresso для android есть встроенный механизм, который перед каждым действием под капотом дожидается элемент, делая ретраи на isVisible, и только потом совершает это действие. Благодаря этому, проблем с “тапами не туда” или “тапами раньше, чем нужно” в ваших автотестах больше не будет. Также этот вейтер можно настроить на нужное/необходимое вам количество времени, так как возможно дожидаться какой-то элемент по 10 секунд на экране — это уже баг.
В XCUITest на iOS также есть вейтеры из коробки, но проставлять их нужно вручную перед каждым действием. Либо стоит самим написать механизм, подобный каспрессовскому.
Главное не оставлять в коде вейты на конкретное количество секунд, так как это сильно увеличит время прохождения тестов. И взять за правило — прежде, чем что-то сделать с элементом, — убедитесь, что он есть на экране.
3. Настроить стабильную инфраструктуру
Если инфраструктура, на которой гоняются тесты, постоянно подводит, то стоит решать эту проблему как можно быстрее. Зависающие и тормозящие эмуляторы, падающие тестовые стенды — в такой атмосфере ваши прогоны тестов вряд ли будут зелеными, да и всем довольно быстро надоест разбирать причины их падений. Поэтому нужно обязательно выделить время и ресурсы команды на стабилизацию инфраструктуры. Если все оптимизировано по-максимуму, но все равно остаются проблемы, возможно вам стало не хватать существующего железа и пора лезть в бюджет за новым.
Вопрос 5. Что делать, когда тестов стало очень много?
В самом начале вы писали коротенькие простые автотесты — открой в приложении такой-то экран и проверь, что он отобразился. Затем вы начинаете автоматизировать более сложные сценарии, более сложные проверки. Количество тестов растет. Время прогона увеличивается. А когда что-то ломается, вместо одного теста у вас падает целых десять, и все с одинаковой ошибкой. При этом время упавшей сборки увеличилось в несколько раз, так как упавшие тесты еще и ретраились.
В такой ситуации важно не держаться за свои старые, пусть даже стабильные, тесты и уметь их отпускать. Удаляйте их, если такие же проверки появились в новом. Железо не резиновое, а тратить х2 времени на запуск приложения для каждого нового теста контрпродуктивно и не экономично.
Чтобы не закапываться в будущие объемные рефакторинги, может помочь правило — актуализируй старое прежде, чем писать новое. Если вы сразу начинаете этому правилу следовать, то такой проблемы у вас возникнуть не должно.
Вместо заключения:
Эта статья — заключительная из серии ответов на вопросы про автоматизацию. Но мы продолжим рассказывать про тестирование и автоматизацию в hh.ru, о том, как проходят наши релизы и еще много о чем полезном и интересном.
А чтобы не пропустить новые видео, статьи и прочие новости, подписывайтесь на наш новостной канал в телеге и канал с охэхэнными историями на youtube. Также вы можете задать вопросы нашим инженерам по любым темам в комментариях, в телеграм-чате с разработчиками hh или в личку.
Ищем тестировщиков в четыре разных направления:
Какие вопросы ожидать на позицию автоматизатора и причем тут сортировка?
Само собой, если вы проходите собеседование на позицию junior, от вас не будут требовать опыта и знаний по всем вопросам. Будет круто, если вы разбираетесь хотя бы в
30% всего этого. От позиции middle я бы ожидал примерно
50%-60% знаний перечисленных мною тем. Ну и далее по восходящей.
Кто такой автоматизатор?
Чтобы понять, какие вопросы вас ждут на позицию автоматизатора, прежде всего стоит определиться с повседневными задачами автоматизатора. Ведь именно на их основе хороший интервьюер готовит вопросы. Какой смысл спрашивать о том, с чем автоматизатор работать не будет? Хотя бывают и исключения, но об этом чуть ниже.
Разбираться в тестировании. Иначе не получится писать хорошие тесты, проверяющие именно то, что необходимо.
Уметь программировать. Конечно, на первый взгляд тесты кажутся очень простыми. Последовательно вызываешь методы кликов, ввода значения и так далее. Но это неплохо работает только на небольшом количестве тестов, да и то если сам продукт меняется не слишком часто и работает стабильно. Чем больше тестов и сложнее продукт, тем больше опыта в программировании потребуется от автоматизатора для эффективной работы.
Итак, я предлагаю исходить из того, что именно по этим темам нас с вами и будут “гонять” на собеседованиях. Давайте поговорим про каждую из них подробнее и определимся с основными вопросами, к которым стоит быть готовыми.
Тестирование
Обычные вопросы по тестированию чаще всего затрагивают теорию и практику.
В теоретической части любят спрашивать про техники тестирования и тест-дизайн. Например, могут спросить о том, как бы вы составили тест-кейсы для какого-то функционала или целой программы.
Скорее всего спросят про знание устройства самого продукта, который вы будете тестировать. Например, если вам предстоит работать с Web, надо понимать как он работает: разбираться в протоколе HTTP, знать о связке HTML / CSS / JavaScript, понимать смысл кросс-браузерного тестирования и так далее.
Для тестирования мобильных приложений надо понимать основное отличие операционных систем iOS и Android, особенности тестирования на симуляторах, эмуляторах и реальных девайсах и многое другое.
Само собой, поскольку все это нам предстоит автоматизировать, еще необходимо разбираться в стеках автоматизации. Для автоматизации тестирования Web необходимо понимать как настроить Selenium или Selenoid, как подбирать CSS или XPath-локаторы для элементов, какие браузеры выбрать для тестов.
Для мобильной автоматизации пригодится знание драйверов (Espresso или XCUITest) или опыт работы с Appium. Умение настраивать ферму девайсов или устанавливать необходимые эмуляторы и симуляторы.
Для автоматизации API необходимо знать про методы HTTP-запросов (GET, POST, PUT, DELETE и т.д.) и их отличия, коды ответа сервера и их основные форматы (JSON, XML).
На практической части могут дать проверить работу какого-нибудь приложения, попросить составить список тест-кейсов и рассказать про особенности тестирования подобных продуктов.
Недавно, к слову, я писал автоматическую песочницу, имитирующую подобную задачу на собеседовании. Кому интересно, потыкать ее можно тут.
Программирование
В самом начале статьи я упомянул, что на собеседовании не всегда есть возможность задавать вопросы по тем задачам, с которыми предстоит работать. Я говорил как раз про эту часть.
Очень многие кандидаты не любят, когда на собеседовании их просят писать код. Особенно когда это код какой-нибудь алгоритмической задачи. Той же сортировки, например.
Я думаю, что ответ довольно простой. Потому что заставить писать кандидата полноценный тест долго и сложно. Во-первых, у всех кандидатов разный опыт работы с фреймворками. Кто-то пишет на Selenide, кто-то написал свою обертку, а кто-то на голом фреймворке Selenium. И это только Java. На других языках программирования свои фреймворки и их тоже может быть несколько.
Следовательно, велика вероятность, что кандидат не знает того фреймворка, на котором ему предложат писать тест. В таких условиях оценить его опыт не получится. А заставлять кандидата прямо на собеседовании собирать проект с нуля через тот же Gradle с его любимыми библиотеками довольно долго.
Конечно, можно дать задачу на дом, чтобы кандидат потом прислал ссылку на репозиторий. Некоторые компании так делают, но надо понимать, что не все готовы тратить свое время на решение этих задач в свое свободное время. Из-за этого часть кандидатов тоже могут отпасть. Причем как раз тех, кто уже имеет неплохой опыт и уверенно ощущает себя на рынке. Они с большой вероятностью откажутся и пойдут общаться с той компанией, где процесс интервью проще и проходит быстрее, без “домашних заданий”.
Чаще всего человек, который действительно пишет много кода, справится с подобными задачами. Особенно если немного попрактикуется решать именно такие специфичные задачи. Для этого существуют такие ресурсы, как leetcode, codewars и прочие.
Еще на собеседовании могут поспрашивать немного про паттерны программирования. Тут хорошо знать про Singleton, Factory, PageObject, PageFactory, Builder и так далее. Можно еще почитать про принципы разработки SOLID, KISS, DRY, SRP.
Девопс
Помимо этого спросят про опыт работы с bash: команды cd, ls, ps, mv, cp и так далее. Просто, чтобы убедиться, что вы не растеряетесь, зайдя на какой-нибудь сервер на основе linux по ssh.
Скорее всего попросят решить какую-нибудь задачку на SQL-запрос. Он тоже довольно популярен и с ним приходится работать, например, при тестировании серверной части: баз данных, сервисов или API.
Само собой, это не полный список возможных тем на собеседовании. Всегда стоит ожидать совершенно любого вопроса на самые разнообразные темы.
Но есть и те, кто только недавно начал проводить собеседования. Такие ребята еще не до конца набили руку и могут попадаться вопросы, не всегда имеющие отношения непосредственно к задачам их будущего коллеги. Или даже не до конца сформулированные вопросы. К этому тоже стоит быть готовыми и не стесняться уточнять и задавать дополнительные вопросы. Не всегда, когда что-то непонятно, проблема может быть в вашем незнании темы. Порой еще и в неопытности того, кто эти вопросы задает.
Также, за рамками этой статьи остались всевозможные вопросы по софт-скиллам. От безобидных: какую музыку предпочитаете, чем в свободное время занимаетесь. До более сложных. Например, как бы вы решали ту или иную конфликтную ситуацию.
Я думаю, про это я напишу как-нибудь в следующий раз.