Comments 25
поэтому знать в общих чертах о сетевой модели OSI, безусловно, надо.
А каким образом вместо TCP/IP записалась OSI?
А зачем нужны коды ответов HTTP? Мне кажется, они давно уже умерли, и используются максимум 10 из них.
Я бы ещё добавил популярные трекеры задач.
А каким образом вместо TCP/IP записалась OSI?
Как нечто более общее, чем TCP/IP. Опять же, это не значит, что нужно знать все эти протоколы, но просто надо знать, что они есть.
Ну и да, это всё субъективно + зависит от требований конкретной вакансии.
А зачем нужны коды ответов HTTP?Да в любом случае лишним не будет. Я простой фронт и то знаю виды разделения. К примеру: 300-е — всякие редиректы, 400-е — клиентские ошибки, 500-е серверные и тд. Ну и конкретные, которые часто приходят.
Я в индустрии уже под 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 страниц.
Удачи.
И я не имею ни малейшего представления как работает TCP. Кто-то кому-то присылает syn, syn-ack, дальше они там договариваются про окна, расширения, улучшения, rfc 800 какого-то по 8000 какой-то. А да, ещё там в конце FIN.
А как это противоречит статье? Я как раз и написал, что очень круто, если кандидат знает про 3-way handshake, про скользящее окно и про флаги.
Если кратко и только необходимые:
Shell.Каких? Такой список пойдёт? сам наверно четверть дай бог использую
Знание базовых команд
Сетевые протоколы более низкого уровняЗачем? Действительно интересно.
Кандидат должен знать, что существуют протоколы TCP, UDP и IP и понимать их суть.
Базы данныхМожет просто SQL или его уже недостаточно?
Основные запросы в MySQL (всеми любимый JOIN).
ООПИм оно нужно?
Знание основных принципов ООП.
ИМХО но лишнее
тестировщик должен обладать пытливым умом и умеренной любопытностьюэто свойственно многим людям, только оно может совершено в другом выражаться. И даже наверно хорошо если не в работе.
Вообщем-то статье не хватает подробно описанных кейсов работы тестировщика. Иначе смотрится как сферическая должность в вакууме. Даже приведённые тестовые задания с минимальными требованиями коррелируют довольно слабо. Shell я так понимаю легко заменяется на Python, Go, Java… или на набор тулзов.
И сколько стоит такой необходимый минимум?
Не совсем понял вопрос. По времени изучения: на базовом уровне всё довольно быстро познаётся.
Про shell: всё субъективно, скорее надо знать на уровне уверенного пользователя + знать инструменты дебага (strace, tcpdump, gdb и прочее).
Про SQL: спасибо за замечание, именно MySQL и правда ни к чему, исправил на просто SQL-запросы.
Про ООП: зависит от компании, лично меня не раз спрашивали про принципы ООП и пару раз про пару паттернов.
Кейсы работы бывают разнообразные, именно поэтому хорошо иметь широкий кругозор. В частности, если не знать основ архитектуры распределенных систем, то на задаче с формочкой ты не сможешь придумать кейс «а вдруг данные из формы идут на несколько серверов, надо как-то проверить, что работает фоллбэк». А дальше уже раскручиваешь это: посмотрим tcpdump'ом, что трафик действительно есть на нескольких серверах. А теперь зафаерволлим один с помощью iptables. Проверим, что форма до сих пор работает и т.п. И это самый простой пример. Согласитесь, будет здорово, если кандидат что-то подобное скажет вам на интервью? :) И это явно будет дополнительный плюсик кандидату.
С таким подходом и лиды не нужны. Ведь Тшейпы всё уже сами знают, смогут договориться в виду своей разносторонней подкованности. Да и к чему такие лиды, которые не знают о процессах производства и не способны использовать узкие специализации в разработке ПО. Такие лиды будут искать дешевых сотрудников знающих всё и тратить на это уйму времени. С одной стороны можно методически подойти к процессу разработки, выдать каждому сотруднику свой фронт работы, заложить бюджет на изучение необходимой спецификации или опять же самому подготовить методику работы с той или иной технологией (коли семь пядей во лбу) и т.д. но ведь это сложно, проще ждать «необходимого сотрудника». Но вот с другой стороны такой необходимый сотрудник тратит своё время на изучение каждой технологии, держит свои знания в актуальном состоянии, тратит на это ресурсы (кстати время это тоже ресурс) и для чего? Что-бы кто-то «условно бесплатно» это получил просто прицепом к должности «тестировщик». А тестировщик должен знать, как раз то чему выделен жалкий абзац в этой статье, а именно теорию тестирования и соответственно навыки владения языком в контексте которого тестируется система. Всё остальное уже как раз тот прицеп за который компания должна либо доплачивать, либо обучать.
Уважаемые HR'ы, если вы ищете кого-то с навыками:
- Java, Python, PHP
- React, Angular
- PostgreSQL, Redis, MongoDB
- AWS, S3, EC2, ECS, EKS
- *nix администрирование
- Git
- Docker, k8s
Запомните, это не фуллстек разработчик, это целый IT-отдел.
Как правило работодатель не разграничивает тестирование эндпоинта C++ приложение или эндпоинта python приложения. Они могут быть очень схожи, для конечного потребителя: передай данные — получи данные. Но под капотом может быть очень разная реализация и QA специалист с широким кругозором сможет очень четко диагностировать проблемы как в том, так и в другом случае.
Понятно что все привыкли к вакансиям типа «C++ программист», но сейчас рынок не предлагает «C++ тестировщик» (разумеется, если речь не об автоматизации).
Поддержу также тех, кто высказывается, что знание, как правило, нужно поверхностное, типа «слышал о ...» и «знаю как найти», но более глубокие знания — обычно выделяют кандидата при собеседовании. Это воспринимается, как то, что раз человек уже изучил материал достаточно глубоко (но не слишком глубоко), то он сможет освоить и другие сложные и нужные темы.
Автору — спасибо за статью :)
Лично моё мнение: эта сертификация не особо полезна людям, имеющим опыт в этой сфере. Для начинающих специалистов она может быть полезна, потому что позволяет ознакомиться с предметной областью в целом и познать основную суть тестирования (но, как мне кажется, это можно сделать более быстро: например, посмотрев пару видео или почитав пару статей, а не вычитывая кучу страниц сухой теории).
Но если есть желание в будущем уехать за границу, то надо иметь ввиду, что у многих вакансий в описании написано «желательно иметь сертификат ISTQB», а процентов для 5 вакансий (по моим наблюдениям, вакансии в Европе) эта сертификация обязательна.
Фигассе, я по точно такому же списку собеседую qa к себе в команду, сублимировал этот же набор минимальных знаний параллельно с вами, похоже тут как армейский устав — написан кровью, так набор вопросов к qa — опытным путем)
Я может глупость скажу, но зачем человеку с такими знаниями работать тестировщиком, а не сисадмином / девопсом / да просто девом?
Что должен знать тестировщик бэкенда