– Ты ж программист?
– Да.
– Значит, в электрике разбираешься.
– Эээ, чо?
– Короче, нужно траншею под кабель прокопать отсюда и до вон того забора, бери лопату, действуй.
Вчера я написал про деление айтишников, так сказать, по вертикали. А сегодня хочу написать про деление по горизонтали. Какие они бывают.
Сразу отмечу – деление в этой категории не ультимативное, вполне возможно иметь опыт в нескольких категориях. Некоторые категории по методологии не совместимы в одном человеке в рамках одного продукта (скажем, разработчик и тестировщик – что не означает, будто бы разработчик не занимается тестированием вообще), другие не только совместимы, но и в ряде случаев в некоторых методиках рекомендуются к совмещению (скажем, тестировщик и аналитик).
Опять же, могу в чём-то допустить косяк, потому как могу не видеть всей картины, нельзя объять необъятное.
Итак, какие бывают айтишники.
Во-первых, разработчики. Разработчик – это тот, кто непосредственно создаёт код самого продукта. Искушение сказать, что это, собственно, то, что программист – но это не означает, что другие айтишники кода не пишут, ещё как пишут. Разработчики могут быть: разработчики микропрограмм (то, что создаётся на ассемблере или голом С и вшивается в кристалл), разработчики десктоп-приложений (то, что ставится на комп и с компа работает), веб-разработчики (то, что работает через браузер), разработчики мобильных приложений и т.д. Практически в каждой из этих подкатегорий (кроме, быть может, разработчиков микропрограмм, и то не факт) в отдельную подподкатегорию выделяются разработчики игр – потому что там требуются достаточно особые навыки, и потому что там есть свой отдельный инструментарий, т.н. игровые движки. Веб-разработчики (иногда и десктопные и мобильные) подразделяются на фронтендеров (те, которые разрабатывают ту часть, которая непосредственно видна в браузере, все вот эти вот кнопочки, контролчики, их взаимодействие между собой, корректное обращение к бэкенду и т.д.) и бэкендеров (те, которые разрабатывают ту часть, которая исполняется на сервере – подгрузить нужные данные, сформировать отчёт, проверить изменения на корректность и записать их, и т.д.). Если разработчик совмещает в себе фронтенд и бэкенд, его называют фуллстэк-разработчиком, или разработчиком полного цикла. Бывает, что человек в принципе работает как фуллстэкарь, но тяготеет к какой-то одной из сторон (скажем, мне, как шизоиду, внутренняя логика интереснее, а удобство использования, скажем так, не то, чтобы вторично, но то, что я расцениваю как удобное, может быть неудобно конечному пользователю – поэтому я, хотя, в принципе, во многих проектах отметился как фуллстэкарь, в душе больше бэкендер). В некоторых компаниях и на некоторых проектах из бэкендеров отдельно выделяют специалистов по слою баз данных, но, как правило, это входит в обязанности бэкендеров. В некоторых предметных областях бывает, что нужны более узкие специалисты: специалист по машинному обучению, специалист по блокчейну, дата-сайентист (это не то же самое, что специалист по базам данных – дата-сайентист владеет технологиями, примерно соответствующими функциям КРИ у Стругацких, в то время, как специалист по базам данных занимается более ординарными задачами, оптимизируя их, например, по времени выполнения) и т.д. Среди фронтендеров иногда отдельно выделяют (а иногда выделяют настолько, что вообще не считают их разработчиками – но мне это кажется неправильным) веб-верстальщиков. Верстальщик – это тот, кто, получив от дизайнера макет в виде картинки в какой-нибудь, скажем, Фигме, реализует его в виде кода на HTML и CSS. Многие инструменты дизайна умеют генерировать код и самостоятельно, но хорошему верстальщику и тут есть, чем заняться. Однако, зачастую одни и те же фронтендеры пишут и выполняемые на стороне браузера скрипты, и код вёрстки, и даже и дизайн сами рисуют (ну разве что, быть может, картинки на кнопках им отдельные дизайнеры дают).
Во-вторых, это специалисты по QA, или специалисты по контролю качества, или тестировщики. Аналог ОТК в советское время в докомпьютерную эпоху. Нельзя сказать, что разработчик не занимается тестированием. Разработчик проводит т.н. смоук-тест (тест, что «не дымится» – запустил проект и убедился, что он вроде как сохранил работоспособность после правок, и что новые фичи, если они были, работают, как ожидалось). Разработчик также (там, где применяется) пишет модульные тесты (то, что, будучи запущенным, автоматически подсовывает различным модулям различные данные и проверяет, что результат работы модуля соответствует ожидаемому). Тестировщик же осуществляет всестороннее полное насилие над тестируемым продуктом: проверяет работоспособность на разных видах корректных данных, некорректных данных, стойкость к попыткам взлома, нештатные ситуации, ситуации работы с максимальной загрузкой. Тестировщик зачастую тоже пишет код – но это не код, который непосредственно билдится в готовый продукт, а это код скриптов для систем автоматического тестирования (там, где таковые применяются). Без подтверждения пригодности текущей версии кода отделом контроля качества версия в прод не пойдёт (ну как... в идеале не пойдёт. На практике – мы сами видим, что иногда происходит «тестирование на конечном пользователе»). Артефакты, вырабатываемые тестировщиком – это чеклисты, тесткейсы и багрепорты. Чеклист – это список проверок, которые обязательно должны быть проведены при одобрении каждой новой версии. Проход по чеклисту – это примерно как читка карты в авиации. Ну... фильм «Экипаж», который старый ещё, помните?
– РУ-19.
– Есть.
– Высотомер.
– Есть.
– РВ.
– Есть.
– Авиагоризонт.
– Совмещён.
– Закрылки.
– Пятнадцать.
– Управление.
– Есть, свободно.
Ну и т.д.
Вот это самое и есть чеклист. Если джун QA может пробежать по готовому чеклисту и выполнить все указанные в нём проверки, то мид QA должен уметь составить чеклист сам.
Тесткейс – это конкретная методика проверки. В нём должны быть: заголовок (то, что тестируется в кейсе), шаги воспроизведения (конкретно и максимально подробно и однозначно, чтобы, буквально, джун мог сделать), ожидаемый результат.
Например.
Тест-кейс: запрет овербукинга.
Шаги воспроизведения:
1. На ВМ "Оклахома" зайти в систему как тестовый пользователь "Вася Пупкин".
2. На ВМ "Мичиган" зайти в систему как тестовый пользователь "Миша Кукушкинд".
3. На "Оклахома" открыть схему кинозала.
4. На "Мичиган" открыть схему кинозала.
5. На "Оклахома" выбрать для бронирования свободное место.
6. На "Мичиган" выбрать для бронирования то же самое место.
7. На "Оклахома" подтвердить бронирование.
8. На "Мичиган" подтвердить бронирование.
Ожидаемый результат: на "Оклахома" бронирование осуществлено успешно, на "Мичиган" появилось сообщение о том, что данное место уже забронировано.
Багрепорт: сообщение о замеченном недочёте. Оно может быть разного уровня критичности, от тривиального (например, опечатка в тексте сообщения) до шоустоппера (функциональность приложения нарушена критически, «взлёт невозможен»). Багрепорт также обязательно должен содержать шаги воспроизведения (полностью, включая стенд, на котором осуществлена проверка, если их несколько, и полный набор тестовых данных, включая, например, пользователя, под логином которого осуществлена проверка), ожидаемый результат и фактически полученный результат.
Следующие (не по важности, а по порядку перечисления) – инженер по инфраструктуре, или системный администратор (или сисадмин). Это тот, кто отвечает за то, чтобы сервера работали, пароли менялись, сети не притаскивали мертвецов, тестовые и продуктовые кластеры фигачили и т.д. И да, сисадмин тоже, бывает, очень даже пишет код. Это, например, скрипты, позволяющие автоматизировать установку и настройку рабочего софта на всех станциях офиса. Иногда из сисадминов выделяют отдельно администраторов виртуальных машин и администраторов систем баз данных.
Далее – инженер по внедрению, иногда девопс (хотя вообще-то DevOps – это, скорее, методика внедрения, чем отдельная специальность). Если девопс – то он отвечает за автоматизацию того, что происходит между тем, как нажата кнопка, условно, "версия готова к внедрению", и появлением новой версии на продуктовом стенде, и решение возникающих в этом процессе сбоев. Если просто инженер по внедрению – то же самое, но без автоматизации.
Далее – инженер по информационной безопасности. Иногда совмещается с сисадмином, но вообще это отдельная специальность с отдельными знаниями и навыками и отдельным инструментарием. Он следит за тем, чтобы луй с горы не мог получить доступ, которого ему не давали, чтобы всякие атаки, от DDoS до я уж и не знаю чего, успешно отражались, ну и т.д. Слышал шутку, что инженер по инфраструктуре отличается от инженера по безопасности тем, что сисадмин следит, чтобы доступ имели все, кому надо, а безопасник – чтобы доступ не имел никто, кому не надо.
Далее – техподдержка или саппорт. Обычно бывает эшелонированной: на первой линии проверяют банальные вещи (меня это рефлекторно выбешивает, конечно, когда приходится через них продираться, но увы, да, основная масса пользователей такова, что это зачастую бывает нужно: «Не печатает? А принтер какой? "В рот хер?" А, Brother! Да-да-да. Проверьте, не отошло ли подключение к компьютеру. В каком смысле "а что, ему ещё и компьютер нужен?"»), и эту самую первую линию сейчас уже полным ходом замещают боты (ну потому что реально же кожаные на первой линии всё равно по скриптам работают, шаг влево, шаг вправо – не, не умеем), на второй линии уже профессионально пытаются решить проблему, при обнаружении бага пишут багрепорт.
Ну и, наконец (если никого не забыл) техники (иногда тоже совмещаемые с сисадминами). Работают, собственно, руками – тянут провода, обжимают концы, устраняют проблемы по электрике, вот это вот всё.
Кажется, всех перечислил. Но не факт.
p.S. Ну так и знал же, что кого-то забуду!
Очень заслуженные две категории: аналитик и дизайнер.
Ну, раз уж так получилось, то коротко.
Аналитик – тот, кто превращает ХЗ в ТЗ. На входе аналитика – невнятное мычание заказчика категории «короче, надо сделать, как хорошо, а как не хорошо, делать не надо». На выходе аналитика – чётко поставленные задачи в трекере задач. Работа аналитика также может быть эшелонированной. Бизнес-аналитик из ХЗ создаёт ТЗ в виде так называемых юзер-стори. Юзер-стори – это тоже описание того, что заказчик хочет, но уже на более или менее чётком языке, так, чтобы осталось только понять, что это означает в чисто техническом плане, и декомпозировать. Системный аналитик дальше берёт юзер-стори и превращает в конкретные пункты в трекере задач.
Дизайнер – тот, кто отвечает за то, как будет выглядеть то, что будет видеть пользователь. Что будет нарисовано на кнопочках, где они будут расположены для широких экранов, для узких, для вертикальных, как будут выглядеть отчёты, ну и т.д. Может быть совмещён с верстальщиком и с фронтендером, а может и не быть – дизайнеру чисто дизайнеру не обязательно уметь писать код, но ему обязательно надо уметь в эргономику.
– Ты ж программист?
– Да.
– Значит, в электрике разбираешься.
– Эээ, чо?
– Короче, нужно траншею под кабель прокопать отсюда и до вон того забора, бери лопату, действуй.
Вчера я написал про деление айтишников, так сказать, по вертикали. А сегодня хочу написать про деление по горизонтали. Какие они бывают.
Сразу отмечу – деление в этой категории не ультимативное, вполне возможно иметь опыт в нескольких категориях. Некоторые категории по методологии не совместимы в одном человеке в рамках одного продукта (скажем, разработчик и тестировщик – что не означает, будто бы разработчик не занимается тестированием вообще), другие не только совместимы, но и в ряде случаев в некоторых методиках рекомендуются к совмещению (скажем, тестировщик и аналитик).
Опять же, могу в чём-то допустить косяк, потому как могу не видеть всей картины, нельзя объять необъятное.
Итак, какие бывают айтишники.
Во-первых, разработчики. Разработчик – это тот, кто непосредственно создаёт код самого продукта. Искушение ска