company_banner

Что должен знать тестировщик бэкенда



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

    В FunCorp есть список тем с вопросами, которые мы задаём кандидатам. Я решил дополнить его, сделать более универсальным, разбить каждую тему по уровням (что нужно знать обязательно и что будет плюсом) и добавить ссылки на статьи и книги, которые можно почитать по этим темам.

    Какие проблемы помогает решить этот текст: кандидату — подготовиться к интервью, любому тестировщику бэкенда — освежить знания, тестировщику фронтенда или мобильных приложений — расширить кругозор. Работодатели могут использовать список для составления требований в вакансиях.

    Необходимые знания


    Сразу сделаю ремарку: необходимые знания и навыки  зависят от специфики вакансии. Если вакансия про тестирование API, где используется HTTP, то вам нужно очень хорошо знать HTTP и необязательно знать нюансы работы ОС. Если вы будете работать с Windows, то вам необязательно знать bash.

    Также хочу обратиться и к работодателям: не стоит спрашивать про управление памятью в Linux кандидата на позицию Mobile QA Engineer, это вряд ли пригодится ему в работе.
    Я не упоминаю языки программирования, потому что это сильно зависит от используемого стека. Но часто про них вообще ничего не спрашивают на собеседованиях тестировщиков (в противном случае указывают о необходимом уровне знания языка в описании вакансии).

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

    Теория тестирования


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

    Что ожидается от любого кандидата


    Знание основных терминов, техник тест-дизайна, умение написать качественный баг-репорт.

    Что говорит о том, что кандидат хорошо знает тему


    Формально это сертификаты ISTQB.

    Что почитать по теме


    Есть хорошая статья на Хабре со всей необходимой информацией. Если же хочется более детально разобраться в теории тестирования, то можно почитать материалы ISTQB.

    Shell


    В зависимости от ОС нужно знать либо bash (sh, zsh и т.п., но нюансы вряд ли будут играть существенную роль), либо CMD и PowerShell.

    Что ожидается от любого кандидата


    Знание базовых команд.

    Что говорит о том, что кандидат хорошо знает тему


    Кандидат знает много команд, различные опции для них, их преимущества и недостатки, различные способы использования, а также инструменты для дебага проблем, например, strace, tcpdump, gdb и прочие.

    Что почитать по теме


    Про основные команды в Linux можно почитать в одной из моих предыдущих статей, а также есть очень крутой репозиторий c кучей примеров на GitHub. Из книг я бы посоветовал «Операционная система UNIX» Робачевского, Немнюгина и Стесик — она не только про команды, а про систему в целом.
    Про команды CMD можно почитать здесь, а у PowerShell есть хорошая документация.

    HTTP (или протоколы, указанные в описании вакансии)


    Очень часто в качестве основного протокола для клиент-серверной архитектуры выбирают HTTP, поэтому часто спрашивают именно про этот протокол. Однако может понадобиться знать IMAP, POP3, SMTP (если будете тестировать почту), Protobuf или MessagePack или другие протоколы. 

    Что ожидается от любого кандидата


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

    Что говорит о том, что кандидат хорошо знает тему


    Кандидат может ответить на вопросы про кеширование, сжатие данных, cookies и использование различных заголовков в HTTP. Для других протоколов всё более субъективно.

    Что почитать по теме


    Про HTTP вся необходимая информация есть в «Википедии». Про другие протоколы советую читать их документации и спецификации. Также не стоит забывать про HTTPS. Ну и само собой, нужно всегда под рукой иметь ссылки на RFC 2616 и RFC 7540 (но есть и другие спецификации).

    Сетевые протоколы более низкого уровня


    Многие кандидаты не имеют представления о том, что находится под HTTP. Я считаю, что это не очень хорошо характеризует их, потому что тестировщик должен обладать пытливым умом и умеренной любопытностью, поэтому знать в общих чертах о сетевой модели OSI, безусловно, надо.

    Что ожидается от любого кандидата


    Кандидат должен знать, что существуют протоколы TCP, UDP и IP и понимать их суть.

    Что говорит о том, что кандидат хорошо знает тему


    Понимание механизма работы протокола TCP (three-way handshake, некоторые поля из заголовка, флаги, скользящее окно), кандидат может назвать недостатки и преимущества TCP и UDP, области их применения, общие знания IP. Будет круто, если кандидат расскажет в двух словах и про другие протоколы (например, ARP, ICMP, ICMPv6).

    Что почитать по теме


    Базовые знания можно получить из статей в «Википедии»: сетевая модель OSI, TCP, UDP, IP, IPv6, ICMP, ARP, ICMPv6. Если хочется погрузиться в эту тему, то можно почитать «Компьютерные сети» Таненбаума.

    Базы данных


    Что ожидается от любого кандидата


    Основные SQL-запросы (всеми любимый JOIN).

    Что говорит о том, что кандидат хорошо знает тему


    Общие знания о разных СУБД, репликации, шардировании, о внутреннем устройстве СУБД, общие знания о нереляционных БД.

    Что почитать по теме


    В общих чертах про базы данных можно почитать в документации конкретной СУБД. Если хочется разобраться с базами данных детально, то рекомендую соответствующие главы «Высоконагруженных приложений» Клеппмана.

    ООП


    Что ожидается от любого кандидата


    Знание основных принципов ООП.

    Что говорит о том, что кандидат хорошо знает тему


    Будет круто, если кандидат знает некоторые паттерны.

    Что почитать по теме


    Про принципы можно почитать, например, здесь, про паттерны — здесь. Также есть классная книга «Приёмы объектно-ориентированного программирования. Паттерны проектирования» «банды четырёх».

    Операционные системы


    Что ожидается от любого кандидата


    Для большинства вакансий тестировщиков знание нюансов работы операционных систем нерелевантно.

    Что говорит о том, что кандидат хорошо знает тему


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

    Что почитать по теме


    Вкратце можно прочитать в уже упомянутой книге «Операционная система UNIX» Робачевского, Немнюгина и Стесик. Если тема заинтересует, то можно углубиться в неё с помощью, например, «Современных операционных систем» Таненбаума. В общих чертах ознакомиться с темой можно с помощью «Википедии»: есть статьи про ядро Linux, виртуальную память, context switch и прочие.

    Архитектура ЭВМ


    Что ожидается от любого кандидата


    Для большинства вакансий тестировщиков знание нюансов работы процессоров, памяти и периферийных устройств нерелевантно.

    Что говорит о том, что кандидат хорошо знает тему


    Будет здорово, если кандидат знает в общих чертах про работу процессора, регистры, кеши, работу памяти и диска и прочее.

    Что почитать по теме


    Поверхностно ознакомиться с «железом» можно с помощью «Википедии»: ЦПУ, режим работы процессора, микроархитектура (в этой статье много ссылок на другие статьи по теме), кеш, АЛУ, конвейер, branch predictor, суперскалярность и т.д. Более целостно и глубоко эту тему можно изучить, например, с помощью книги «Архитектура компьютера» Таненбаума.

    Алгоритмы и структуры данных


    Вопросы по алгоритмам и структурам данных, скорее всего, не зададут (особенно если позиция не уровня Intern или Junior), но какие-то общие вещи знать всё равно надо. Лично меня только один раз на собеседовании спрашивали про двоичную кучу, сам я тоже не любитель спрашивать про это кандидатов. Поэтому никаких критериев вводить не буду и прикреплю лишь статью с хорошими картинками, можно распечатать их и положить на видном месте. Если захочется погрузиться в алгоритмы и структуры данных с головой, то смело начинайте читать «Алгоритмы. Руководство по разработке» Скиены или «Алгоритмы. Построение и анализ» Кормена.

    Прочее


    1. Много где используется Docker.
    2. Архитектура распределённых систем («Высоконагруженные приложения»).
    3. REST и SOAP.
    4. JSON и XML.
    5. Protocol Buffers, MessagePack и BSON.
    6. TLS.
    7. Git (или другие VCS).
    8. Nginx и Apache.
    9. Библиотеки.
    10. TeamCity и Jenkins (или другие CI-системы).


    Несколько примеров тестовых заданий


    Что будет, если ввести в адресную строку браузера google.com и нажать Enter?


    Классическая задача, с помощью которой можно проверить, насколько глубоко кандидат разбирается в веб-технологиях в целом. Есть подробный разбор этой задачи на Хабре, но я не рекомендую вчитываться в нюансы типа «небольшое количество тока отправляется по электросхеме клавиатуры».

    Тестирование формы с кнопкой


    Да, эту задачу часто задают и на собеседовании тестировщиков бэкенда. Задача классическая, поэтому будет круто, если кандидат немного пофантазирует и представит, что может быть за этой формочкой с кнопкой. Например, можно предположить, что из формы данные уходят на бэкенд, состоящий из нескольких серверов и базы данных, что бэкенд пишет логи и имеет конфиг — это сразу добавит много тест-кейсов более глубокого уровня, чем «введём слишком длинное значение в поле ввода». Например, можно с помощью tcpdump смотреть, точно ли трафик идёт на все сервера бэкенда; можно попробовать отправить SQL-инъекцию или битый JSON (естественно, если вдруг JSON вообще есть в контексте задачи); можно проверить, что будет, если логи займут всё свободное место на диске; можно проверить работу системы при зафайрволенном бэкенде, корректность добавления данных в базу и т.д. Таким образом кандидат покажет свой широкий кругозор, что, несомненно, пойдёт ему на пользу.

    Тестирование сервиса


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

    Тестирование эндпоинта REST API


    И опять всё то же, только с HTTP (скорее всего). Здесь можно продемонстрировать знание протокола HTTP: например, проверить работу сервиса при наличии различных заголовков в запросе.

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

    P.S. Также рекомендую ознакомиться со статьёй моего коллеги «Образ современного тестировщика. Что нужно знать и уметь», в ней в общих чертах описаны различные направления развития для тестировщиков.
    FunCorp
    Разработка развлекательных сервисов

    Комментарии 25

      0
      поэтому знать в общих чертах о сетевой модели OSI, безусловно, надо.

      А каким образом вместо TCP/IP записалась OSI?
      А зачем нужны коды ответов HTTP? Мне кажется, они давно уже умерли, и используются максимум 10 из них.
      Я бы ещё добавил популярные трекеры задач.
        +1
        А каким образом вместо TCP/IP записалась OSI?

        Как нечто более общее, чем TCP/IP. Опять же, это не значит, что нужно знать все эти протоколы, но просто надо знать, что они есть.
        Ну и да, это всё субъективно + зависит от требований конкретной вакансии.
          +1
          А зачем нужны коды ответов HTTP?
          Да в любом случае лишним не будет. Я простой фронт и то знаю виды разделения. К примеру: 300-е — всякие редиректы, 400-е — клиентские ошибки, 500-е серверные и тд. Ну и конкретные, которые часто приходят.
          +4

          Я в индустрии уже под 20 лет. Я писал код для гипервизоров, разбирался с кодом драйверов в linux, писал на С и питоне, пишу на Rust, с интересом читаю учебник по квантовой физике, разрабатывал систему оптимизации трафика по bgp, отлаживал проблемы переупорядочивания пакетов у сетевых карт с несколькими очередями при ребалансировке irq на другие ядра (по сравнению с приложением), разрабатывал сетевые архитектуры для cloud с минимальным blast radius.


          И я не имею ни малейшего представления как работает TCP. Кто-то кому-то присылает syn, syn-ack, дальше они там договариваются про окна, расширения, улучшения, rfc 800 какого-то по 8000 какой-то. А да, ещё там в конце FIN.


          Чёртова магия и бездна.


          curl https://tools.ietf.org/rfc/index | grep RFC | grep TCP | wc -l


          201


          Средний размер RFC по TCP — 80 страниц.


          Удачи.

            0
            И я не имею ни малейшего представления как работает TCP. Кто-то кому-то присылает syn, syn-ack, дальше они там договариваются про окна, расширения, улучшения, rfc 800 какого-то по 8000 какой-то. А да, ещё там в конце FIN.

            А как это противоречит статье? Я как раз и написал, что очень круто, если кандидат знает про 3-way handshake, про скользящее окно и про флаги.
            –1
            И сколько стоит такой необходимый минимум?
            Если кратко и только необходимые:
            Shell
            Знание базовых команд
            .Каких? Такой список пойдёт? сам наверно четверть дай бог использую

            Сетевые протоколы более низкого уровня
            Кандидат должен знать, что существуют протоколы TCP, UDP и IP и понимать их суть.
            Зачем? Действительно интересно.

            Базы данных
            Основные запросы в MySQL (всеми любимый JOIN).
            Может просто SQL или его уже недостаточно?

            ООП
            Знание основных принципов ООП.
            Им оно нужно?

            ИМХО но лишнее
            тестировщик должен обладать пытливым умом и умеренной любопытностью
            это свойственно многим людям, только оно может совершено в другом выражаться. И даже наверно хорошо если не в работе.

            Вообщем-то статье не хватает подробно описанных кейсов работы тестировщика. Иначе смотрится как сферическая должность в вакууме. Даже приведённые тестовые задания с минимальными требованиями коррелируют довольно слабо. Shell я так понимаю легко заменяется на Python, Go, Java… или на набор тулзов.
              +3
              И сколько стоит такой необходимый минимум?

              Не совсем понял вопрос. По времени изучения: на базовом уровне всё довольно быстро познаётся.

              Про shell: всё субъективно, скорее надо знать на уровне уверенного пользователя + знать инструменты дебага (strace, tcpdump, gdb и прочее).

              Про SQL: спасибо за замечание, именно MySQL и правда ни к чему, исправил на просто SQL-запросы.

              Про ООП: зависит от компании, лично меня не раз спрашивали про принципы ООП и пару раз про пару паттернов.

              Кейсы работы бывают разнообразные, именно поэтому хорошо иметь широкий кругозор. В частности, если не знать основ архитектуры распределенных систем, то на задаче с формочкой ты не сможешь придумать кейс «а вдруг данные из формы идут на несколько серверов, надо как-то проверить, что работает фоллбэк». А дальше уже раскручиваешь это: посмотрим tcpdump'ом, что трафик действительно есть на нескольких серверах. А теперь зафаерволлим один с помощью iptables. Проверим, что форма до сих пор работает и т.п. И это самый простой пример. Согласитесь, будет здорово, если кандидат что-то подобное скажет вам на интервью? :) И это явно будет дополнительный плюсик кандидату.
              0
              отличный набор требований! Очень надеюсь, что человеку с таким набором знаний и умений вы платите достойную зарплату, соответствующую набору требований. Хотя… тестировщику Эндпоинта АПИ или кнопки 70% указанных требований не нужны.
                +1
                Я просто даже боюсь представить стоимость такого специалиста. А это точно тестировщик, может ошибка в названии статьи? Предлагаю изменить название и контекст статьи. «Что должен знать T-Shape инженер бекенда?» Как посмотрю последнее время необоснованно растут требования к инженерам, но не растут зарплаты. А вообще это уже вопрос перекладывания ответственности за архитектуру и процессы разработки с (Тим, тех, арх и прочих лидов) на линейных специалистов. Мы вам скажем на словах что нужно, а вы уж сами там принимайте решения и думайте как лучше сделать. Вот с таких предпосылок и растут ноги у подобных «что должен знать дворник Палыч о свойствах пыли».
                С таким подходом и лиды не нужны. Ведь Тшейпы всё уже сами знают, смогут договориться в виду своей разносторонней подкованности. Да и к чему такие лиды, которые не знают о процессах производства и не способны использовать узкие специализации в разработке ПО. Такие лиды будут искать дешевых сотрудников знающих всё и тратить на это уйму времени. С одной стороны можно методически подойти к процессу разработки, выдать каждому сотруднику свой фронт работы, заложить бюджет на изучение необходимой спецификации или опять же самому подготовить методику работы с той или иной технологией (коли семь пядей во лбу) и т.д. но ведь это сложно, проще ждать «необходимого сотрудника». Но вот с другой стороны такой необходимый сотрудник тратит своё время на изучение каждой технологии, держит свои знания в актуальном состоянии, тратит на это ресурсы (кстати время это тоже ресурс) и для чего? Что-бы кто-то «условно бесплатно» это получил просто прицепом к должности «тестировщик». А тестировщик должен знать, как раз то чему выделен жалкий абзац в этой статье, а именно теорию тестирования и соответственно навыки владения языком в контексте которого тестируется система. Всё остальное уже как раз тот прицеп за который компания должна либо доплачивать, либо обучать.
                  0
                  тут у вас описан не тестировщик, а готовый системный администратор. причем очень недешевый. ну или вы просто под знанием всех этих штук имели ввиду «слышал про N». и да, интересно бы было знать — какую зарплатную вилку вы предполагаете для такого специалиста?
                    0
                    Уважаемые HR'ы, если вы ищете кого-то с навыками:
                    • Java, Python, PHP
                    • React, Angular
                    • PostgreSQL, Redis, MongoDB
                    • AWS, S3, EC2, ECS, EKS
                    • *nix администрирование
                    • Git
                    • Docker, k8s

                    Запомните, это не фуллстек разработчик, это целый IT-отдел.
                      0
                      У меня поначалу вообще возникло ощущение, что автор переписал требования из мема «работать в нашем банке — большая честь») Ну разве что 1С на докер поменял)
                      0
                      А я бы наоборот согласился с автором: конечно, перечень технологий весьма широк и едва ли специалисту на конкретной вакансии тестирующему определенный эндпоинт нужно знать все из этой статьи, но кругозор действительно должен быть достаточно широкий, что бы уметь решить любую задачу.

                      Как правило работодатель не разграничивает тестирование эндпоинта C++ приложение или эндпоинта python приложения. Они могут быть очень схожи, для конечного потребителя: передай данные — получи данные. Но под капотом может быть очень разная реализация и QA специалист с широким кругозором сможет очень четко диагностировать проблемы как в том, так и в другом случае.

                      Понятно что все привыкли к вакансиям типа «C++ программист», но сейчас рынок не предлагает «C++ тестировщик» (разумеется, если речь не об автоматизации).

                      Поддержу также тех, кто высказывается, что знание, как правило, нужно поверхностное, типа «слышал о ...» и «знаю как найти», но более глубокие знания — обычно выделяют кандидата при собеседовании. Это воспринимается, как то, что раз человек уже изучил материал достаточно глубоко (но не слишком глубоко), то он сможет освоить и другие сложные и нужные темы.

                      Автору — спасибо за статью :)
                        0
                        azakharenko посмотрел на ваш профиль в LinkedIn www.linkedin.com/in/azakharenko/?originalSubdomain=ru и не нашел там информации о ваших сертификатах по ISTQB. Вы действительно считаете что эта сертификация нужна для тестировщика backend? И вообще для тестировщиков в целом. Сколько человек в вашей команде сертифицированы?
                          +2
                          Добрый день! А вы прочитали про сертификаты ISTQB в пункте «Что ожидается от любого кандидата»?
                            0
                            А разве мой вопрос был в том почему ISTQB нету в ожиданиях для любых кандидатов? Мне просто интересно было ваше отношение к этой сертификации и считаете ли вы что они нужны для новичков и для тех кто уже работает в индустрии?
                              0
                              Просто вопросы были заданы так, будто я написал «сертификат нужен всем!» :)

                              Лично моё мнение: эта сертификация не особо полезна людям, имеющим опыт в этой сфере. Для начинающих специалистов она может быть полезна, потому что позволяет ознакомиться с предметной областью в целом и познать основную суть тестирования (но, как мне кажется, это можно сделать более быстро: например, посмотрев пару видео или почитав пару статей, а не вычитывая кучу страниц сухой теории).

                              Но если есть желание в будущем уехать за границу, то надо иметь ввиду, что у многих вакансий в описании написано «желательно иметь сертификат ISTQB», а процентов для 5 вакансий (по моим наблюдениям, вакансии в Европе) эта сертификация обязательна.
                                +1
                                Извините, за формулировку вопроса. В целом я согласен с вашей позицией — действительно сертификация может быть полезна в очень редких случаях. Хотя лично для меня компания которая требует обязательно эту сертификацию уже отмечается красным флагом и я туда точно идти работать не хотел бы.
                          +3

                          Фигассе, я по точно такому же списку собеседую qa к себе в команду, сублимировал этот же набор минимальных знаний параллельно с вами, похоже тут как армейский устав — написан кровью, так набор вопросов к qa — опытным путем)

                            0
                            >20 Лет в ИТ и наверное сходу на большинство вопросов не отвечу, нужно вспоминать, потому что просто не помню все и вся. Вы ищите студентов которые заучили и выперлись на экзамен? Был на таких собеседованиях, обычно такие собеседователи надергали вопросы из инета и на эти же вопросы ответить не могут. И с их работой мало что общего. Вот почему то не вcпомнили про elastic, memcache т. п. А почему для общего развития может еще вопросы из мира животных не позадавать?
                            0

                            Я может глупость скажу, но зачем человеку с такими знаниями работать тестировщиком, а не сисадмином / девопсом / да просто девом?

                              +1
                              Я конечно, сразу извиняюсь. После прочтения статьи хотел прокомментировать, что очень мало навыков и многого не хватает. Особенно когда мы говорим про тестирования backend. Но потом прочитал комментарии… «и вот что у меня есть вам сказать». Профессиональный инженер тестирования, должен знать очень много и перечисленное в статье, это только «верхушка айсберга». Я уже не говорю про «хотя бы» базовое использование автоматизации процессов (конфигурации) и работу с «автоматизацией» тестирования. Мониторинг и инструменты API тестирования, Jenkins и т.д. И нет, это не инженер DevOps или сисадмин, это знания и навыки хорошего тест/QA инженера.
                                –1
                                А если у меня не Jenkins? А сколько ос и сколько инструментов? Я должен знать все? чтоб один раз ответить глупому собеседователю?
                                  +1
                                  Я должен знать все? чтоб один раз ответить глупому собеседователю?


                                  Зависит от состояния рынка. 2008 год, Нью Йорк — на собеседовании надо было изображать 110% знания, иначе «мывамперезвоним». И есть у меня смутные ощущения, что скоро те годы и те рынки вернутся.
                                0
                                Это вопрос, зачем мне учить Git/GitHub если у работодателя может быть Bitbucket… Инструменты могут быть разные, но концепция и практики использования очень похожи. Поэтому вопрос не совсем актуален.

                                Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                                Самое читаемое