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

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

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

Я в индустрии уже под 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 страниц.

Удачи.

отличный набор требований! Очень надеюсь, что человеку с таким набором знаний и умений вы платите достойную зарплату, соответствующую набору требований. Хотя… тестировщику Эндпоинта АПИ или кнопки 70% указанных требований не нужны.

Я просто даже боюсь представить стоимость такого специалиста. А это точно тестировщик, может ошибка в названии статьи? Предлагаю изменить название и контекст статьи. «Что должен знать T-Shape инженер бекенда?» Как посмотрю последнее время необоснованно растут требования к инженерам, но не растут зарплаты. А вообще это уже вопрос перекладывания ответственности за архитектуру и процессы разработки с (Тим, тех, арх и прочих лидов) на линейных специалистов. Мы вам скажем на словах что нужно, а вы уж сами там принимайте решения и думайте как лучше сделать. Вот с таких предпосылок и растут ноги у подобных «что должен знать дворник Палыч о свойствах пыли».
С таким подходом и лиды не нужны. Ведь Тшейпы всё уже сами знают, смогут договориться в виду своей разносторонней подкованности. Да и к чему такие лиды, которые не знают о процессах производства и не способны использовать узкие специализации в разработке ПО. Такие лиды будут искать дешевых сотрудников знающих всё и тратить на это уйму времени. С одной стороны можно методически подойти к процессу разработки, выдать каждому сотруднику свой фронт работы, заложить бюджет на изучение необходимой спецификации или опять же самому подготовить методику работы с той или иной технологией (коли семь пядей во лбу) и т.д. но ведь это сложно, проще ждать «необходимого сотрудника». Но вот с другой стороны такой необходимый сотрудник тратит своё время на изучение каждой технологии, держит свои знания в актуальном состоянии, тратит на это ресурсы (кстати время это тоже ресурс) и для чего? Что-бы кто-то «условно бесплатно» это получил просто прицепом к должности «тестировщик». А тестировщик должен знать, как раз то чему выделен жалкий абзац в этой статье, а именно теорию тестирования и соответственно навыки владения языком в контексте которого тестируется система. Всё остальное уже как раз тот прицеп за который компания должна либо доплачивать, либо обучать.

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

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

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

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

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

Автору — спасибо за статью :)

azakharenko посмотрел на ваш профиль в LinkedIn www.linkedin.com/in/azakharenko/?originalSubdomain=ru и не нашел там информации о ваших сертификатах по ISTQB. Вы действительно считаете что эта сертификация нужна для тестировщика backend? И вообще для тестировщиков в целом. Сколько человек в вашей команде сертифицированы?

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

Это вопрос, зачем мне учить Git/GitHub если у работодателя может быть Bitbucket… Инструменты могут быть разные, но концепция и практики использования очень похожи. Поэтому вопрос не совсем актуален.