IT для неайтишников: Какими бывают IT-шники? Часть 4

Периодически мне задают вопрос: "Кто есть кто в мире ИТ?". Вопрос этот интересный и объёмный. Чтобы не рассказывать всё по много раз, я напишу несколько статей и буду на них ссылаться. Четвёртая часть статьи посвящена QC (quality control) и QA (quality assurance). Это созвучные, но не очень похожие вещи. Кроме того, мы ещё успеем рассмотреть DevOps специалистов.

Меня зовут Константин Митин. 15 лет занимаюсь коммерческой IT-разработкой, прошёл путь от простого программиста до сооснователя и руководителя группы IT-компаний (АйТи Мегастар/АйТи Мегагруп). Успел побыть тим-лидом, руководителем филиала разработки крупной федеральной IT-компании. Являюсь одним из идеологов концепции IT~BP (партнёрство между IT и бизнесом).

Я не пишу продающие тексты и не являюсь копирайтером, в конце статьи не будет коммерческого предложения и призыва к действию. Мне более интересно делиться знаниями и опытом. Некоторым людям мои статьи кажутся слишком длинными, если вам более привычен формат небольших сообщений, то обратите внимание на telegram-канал Записки ITBP.

В первой части мы составили примерный список IT-специалистов, который хотим рассмотреть. Список получился длинным, объёмным, но на полноту не претендующим. В предыдущих статьях мы рассмотрели: эникейщиков; специалистов технической поддержки второй и третьей линии; системных администраторов (первая часть); программистов; поняли, чем младшие (junior), средние (middle) и старшие (senior) специалисты отличаются друг от друга (вторая часть); руководителей технической поддержки; технических лидеров и лидеров команд разработки (третья часть).

В четвёртой части мы рассмотрим специалистов по тестированию (QC), специалистов по обеспечению качества (QA) и DevOps-специалистов (development & operations). Видеть DevOps рядом с QA и QC несколько неожиданно, хотя между QA и DevOps очень много общего. Кроме того, и то, и другое — это культуры. Сейчас разберёмся что к чему.

Если мы возьмём ГОСТ ISO 9000-2011 «Системы менеджмента качества. Основные положения и словарь» (некий перевод ISO 9000:2005, IDT), то найдём там весьма сомнительный перевод. Собственно уже в заголовке у нас стоит англицизм, который иногда используют как синоним управлению, руководству, администрированию и контролю. И дело даже не в том, что администрирование и контроль — это тоже заимствованные слова, как не сложно заметить. Дело в том, что это 4 разных процесса.

Как получилась такая ошибка. В исходном документе есть термины:

Открываем исходник, видим там: «3.2.10 quality control part of quality management (3.2.8) focused on fulfilling quality requirements». В переводе получаем, что quality control это часть quality management, нацеленная на выполнение требований к качеству. Для лучшего понимания переведём следующим образом: «Надзор за качеством (quality control) - это часть процесса управления качеством (quality management), нацеленная на выполнение требований к качеству».

Давайте ещё немного исходник посмотрим: «3.2.11 quality assurance part of quality management (3.2.8) focused on providing confidence that quality requirements will be fulfilled». Получим: «Обеспечение качества (quality assurance) - это часть процесса управления качеством (quality management), нацеленная на обеспечение уверенности, что требования по качеству будут выполнены».

Ожидаемо было бы увидеть QC (quality control) как часть QA (quality control), но есть такая вещь, как «Абсолютное качество», при его достижении процессы QC (надзор за качеством) перестают работать, а процессы QA (обеспечения качества) работают на полную мощность. Иными словами, чем более качественную продукцию вы выпускаете, чем глубже на ваше производство проникло «Всеобщее управление качеством» (TQM - Total Quality Management), тем меньше операций проверки качества вы используете.

Абсолютное качество практически достигается, например, на некоторых производственных линиях РосАтома. Они автоматизированы в высокой степени и практически не могут произвести продукцию с браком. За отлаженностью их работы следят специальные инженеры, которые и выполняют работу QA (quality assurance). Если линия выявит отклонение в процессе производства, то она остановится вся. И её не запустят, пока не выяснят и не устранят причины сбоя.

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

Ну и помним, что разработка программного обеспечения — это не процесс тиражирования какой-то продукции, это как работа опытного цеха, который может выпускать уникальную продукцию, сделанную, в том числе и с применением ручного труда (вплоть до доводки надфилем). Процессы проверки качества можно сократить, но полностью уйти от них не получится.

Иногда можно услышать «тестировщик». Это тот человек, который проводит тестирование уже разработанного технического обеспечения, то есть проводит проверку соответствия реализации ожиданиям. Здесь сразу же придётся коснуться нескольких вопросов.

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

Почему в мире информационных технологий появилась необходимость в тестировщиках? Разработчики программного обеспечения обладают психологией созидателя. Хороший разработчик при отладке проведёт тестирование всех основных сценариев работы, проверит самые частые ошибки пользователей и ошибки кодирования.

Однако в руках хорошего разработчика будет работать то, что не может работать ни у кого другого, даже если это код написанный другим разработчиком. Человек при работе с чем-то инстинктивно будет обходить все проблемные места. В отличии от рядовых пользователей.

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

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

Задача инженера по тестированию - это не «Найти как можно больше ошибок», это «Не пропустить на продуктив более, чем запланированное количество ошибок заданной критичности». Ошибки в программном обеспечении всегда будут. Вопрос лишь в стоимости владения ошибкой и стоимости её устранения.

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

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

Зачастую, автоматическое тестирование - это тоже область quality control. Инженеры по тестированию любят автоматизировать свой ручной труд, поэтому могут написать программный код, который будет тестировать за них.

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

Практика показывает, что в команде разработки должен быть кто-то на роли QC. Даже если вы скажете, что на продуктиве тестировщиков много, то есть соберётесь тестировать на живых пользователях, то вспомните, что:

Найм инженера по тестированию, обычно, - это выгодное финансовое приобретение.

Честно говоря, это редкая специализация. Очень часто QC-специалистов зачем-то называют QA-специалистами. Если работа QC направлена на то, чтобы остановить поток ошибок на продуктив, то работа QA направлена на то, чтобы не давать ошибкам возникать вообще.

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

При работе QA будет сосредоточен на создании внутренних границ продукта. На разделении его на модули, сервисы, ещё что-то. Не важно, лишь бы запереть регрессионные ошибки в пределах модуля, сервиса либо ещё чего-то. Большое внимание будет обращено на интерфейсы модулей, API (Application Programming Interface — интерфейс приложения для программ) сервисов либо ещё что-то, что выполняет функцию стандартизации и контроля обмена информации между элементами системы.

После того, как систему удастся разбить на компактные модули, сервисы и прочие элементы, заранее будет продуманно, как тестировать каждый элемент по отдельности, и как тестировать их совместную работу. Сразу же будут созданы требования к системе логирования, чтобы дефекты кодирования было легче заметить и локализовать.

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

В какой-то момент встанет вопрос об автоматизации тестирования. Но только не автоматизации тестирования на тестовом стенде, а о CI/CD (непрерывная интеграция и непрерывное развёртывание). То есть автоматической проверки любого нового фрагмента кода, который разработчик попробует добавить в кодовую базу программного обеспечения. Если фрагмент не пройдёт проверку, то его добавление будет отклонено автоматически.

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

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

Даже если что-то хорошо работало на тестовом стенде, то не факт, что оно будет так же хорошо работать на демонстрационном и предпродуктовом стендах (продуктив — среда, на котором работает приложение, доступное конечным пользователям). Причиной может быть, например, наличие на тестовом стенде тестовых данных, которые будут отсутствовать на других стендах. Кроме того, иногда нужна конвертация старых данных в новые форматы, её тоже нужно проверять, для этого в том числе и нужен каскад стендов.

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

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

Достаточно новая специализация на стыке системного администрирования, разработки и тестирования программного обеспечения. Специалисты этого вида обеспечивают автоматизацию сборки, настройки и развёртывания программного обеспечения.

В целом, раньше этим занимались разработчики с навыками администрирования и системные администраторы с навыками программирования. Сейчас это отдельная специализация.

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

В результате вы приходите в облако (внешнее либо частное). Облако представляет собой ЦОД (центр обработки данных) из железных серверов, например, их у нас N штук. На базе железных серверов развёрнуто M штук виртуальных серверов, для простоты допустим M в разы больше N. И вы арендуете в этом облаке какое-то количество виртуальных серверов.

Ваш сервис представляет собой балансировщик, который принимает запросы пользователей и перераспределяет их по серверам обработки. Все сервера обработки однообразные и на них развёрнуто одно и то же приложение. Чем больше серверов обработки, тем большую нагрузку держит ваш сервис, и тем больше денег вы платите за аренду.

Благодаря автоматизации сборки и разворота у вас появляется возможность в динамике горизонтально масштабировать производительность сервиса. Начался наплыв пользователей — автоматически начали разворачиваться дополнительные сервера обработки. Пользователи ушли — дополнительные сервера обработки свернулись и вы за них не платите. А ещё, если ваши разработчики написали какое-то обновление, оно автоматически дойдёт до всех серверов обработчиков и само туда установится.

Обеспечением всего этого счастья, дающего новые возможности для бизнеса, и занимаются DevOps инженеры. То есть автоматизация процессов разворота приложений и доставки изменений (тот самый CI/CD) не только экономит ресурсы на разработку (разработчики больше не настраивают сами свои стенды) и тестирование приложений (перенос изменений между стендами), но и открывают новые возможности при эксплуатации приложения.

Кроме этого, в ведении DevOps инженеров находятся системы автоматизированного мониторинга и системы централизованного логирования (сборка и обработка логов в одном месте).

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

Остаётся только добавить, что на самом деле QA — это культура управления качеством и обеспечения качества. В рамках этой культуры могут работать программисты, системные администраторы, специалисты по тестированию, архитекторы и руководители проектов. Зачастую хорошие QA специалисты совмещают в себе навыки разработчика, архитектора, бизнес-аналитика, руководителя проектов, руководителя службы технической поддержки. Именно поэтому настоящих специалистов по QA очень мало, в основном на рынке представлены специалисты по QC.

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

Если вы дочитали до конца и написанное было для вас полезным, то спасибо вам.

Полезные материалы по теме: