Меня зовут Константин Митин. 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 разных процесса.
Как получилась такая ошибка. В исходном документе есть термины:
- Quality control, который перевели, как «управление качеством»;
- Quality assurance, который перевели, как «обеспечение качеством»;
- Quality management, который следовало переводить, как «управление качеством», но термин уже был занят. Приехали.
Открываем исходник, видим там: «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). Если линия выявит отклонение в процессе производства, то она остановится вся. И её не запустят, пока не выяснят и не устранят причины сбоя.
Бесспорно, я сейчас ничего нового не сказал тем людям, которые понимают, что такое 6-сигм, Кайдзен и другие подходы к обеспечению качества на производствах, которые успешно существуют уже многие десятки лет.
Просто имейте в виду, что придётся сталкиваться с ошибками перевода, которые вызывают искажённое понимание процессов управления качеством. С таким эффектом можно столкнуться и в сфере информационных технологий.
Ну и помним, что разработка программного обеспечения — это не процесс тиражирования какой-то продукции, это как работа опытного цеха, который может выпускать уникальную продукцию, сделанную, в том числе, и с применением ручного труда (вплоть до доводки надфилем). Процессы проверки качества можно сократить, но полностью уйти от них не получится.
Инженер по тестированию (QC — quality control)
Иногда можно услышать «тестировщик». Это тот человек, который проводит тестирование уже разработанного технического обеспечения, то есть проводит проверку соответствия реализации ожиданиям. Здесь сразу же придётся коснуться нескольких вопросов.
Чтобы лучше ощутить разницу между контролем и управлением, представьте, что вы едете на автомобиле по трассе на высокой скорости, перед вами приборная панель, вы видите и контролируете их показания. Но пока у вас нет доступа к органам управления (рулю, педалям тормоза и газа, коробке передач), автомобилем вы не управляете.
Почему в мире информационных технологий появилась необходимость в тестировщиках? Разработчики программного обеспечения обладают психологией созидателя. Хороший разработчик при отладке проведёт тестирование всех основных сценариев работы, проверит самые частые ошибки пользователей и ошибки кодирования.
Однако в руках хорошего разработчика будет работать то, что не может работать ни у кого другого, даже если это код написанный другим разработчиком. Человек при работе с чем-то инстинктивно будет обходить все проблемные места. В отличии от рядовых пользователей.
Поэтому появились люди, которые производят тестирование после того, как разработчик посчитает свою работу законченной. Часто это люди с критическим (не негативным, нельзя путать) мышлением, которые могут все сломать одним движением/действием, так как видят многие уязвимости.
Чем критическое мышление отличается от негативного? Люди с негативным мышлением токсичны, они радуются чужим ошибкам, найдя чужой промах они самоутверждаются. Люди с критическим мышлением чаще всего доброжелательны, они показывают уязвимости и подсказывают, как их устранить.
Существует множество технологий тестирования, в зависимости от того, что нам известно о тестируемом функционале (например, документации может не быть от слова «совсем») и того качества, которого нужно добиться. Есть различные подходы к дизайну (разработке) тест-кейсов (создания сценариев проверки), чек-листов (списка проверяемого функционала) и покрытию тестами (минимальной комбинации сценариев проверки).
Инженер по тестированию именно потому и инженер, что применяет для проверки работоспособности функционала инженерные методики. Их много, это целая наука.
Задача инженера по тестированию это «Не найти как можно больше ошибок», это «Не пропустить на продуктив более, чем запланированное количество ошибок заданной критичности». Ошибки в программном обеспечении всегда будут. Вопрос лишь в стоимости владения ошибкой и стоимости её устранения.
Если ошибка случается лишь раз в год у одного пользователя из тысячи, причём не несёт никакого вреда, а её исправление стоит один миллион рублей, то её спокойно выпустят на продуктив. Стоимость владения ошибкой много меньше, чем её устранение. Инженер по тестированию должен хорошо понимать термин «целесообразность».
Хороший инженер по тестированию, после того, как разработает «тест-кейсы», скорее всего поделится ими с разработчиками, чтобы те могли осуществить самопроверку. Так инженер по тестированию сможет сократить объёмы своей работы и одновременно вести больше задач.
Автоматическое тестирование, зачастую, это тоже область quality control. Инженеры по тестированию любят автоматизировать свой ручной труд, поэтому могут написать программный код, который будет тестировать за них.
Но всегда нужно помнить, что если человек плохо выполняет дизайн тест-кейсов, но хорошо их автоматизирует, то толку от такой автоматизации очень немного.
Практика показывает, что в команде разработки должен быть кто-то на роли QC. Даже если вы скажете, что на продуктиве тестировщиков много, то есть соберётесь тестировать на живых пользователях, то вспомните, что:
- Из-за ошибок пользователь не сможет выполнить какие-то действия, что нанесёт какой-то экономический ущерб.
- На службу технической поддержки будет повышенная нагрузка, их время тоже стоит денег.
Найм инженера по тестированию, обычно, это выгодное финансовое приобретение.
Инженер по качеству (QA — quality assurance)
Честно говоря это редкая специализация. Очень часто QC-специалистов зачем-то называют QA-специалистами. Если работа QC направлена на то, чтобы остановить поток ошибок на продуктив, то работа QA направлена на то, чтобы не давать ошибкам возникать вообще.
Инженер по качеству будет пытаться устранить места потенциального возникновения ошибок. Такую работу начинают проводить ещё на этапе сбора и формирования требований к программному продукту. Продолжают на этапе проектирования, проработки архитектуры и составления технического задания. Не прекращают, когда идёт реализация программного продукта. И завершается только после внедрения продукта, когда процесс обеспечения качества трансформируется в процесс управления инцидентами и процесс управления проблемами.
То есть настоящий QA начинает работать с бизнес-аналитиком, а заканчивает свою работу с руководителем технической поддержки. При этом это всегда человек, который очень хорошо понимает разработку программного обеспечения, вплоть до того, что сам может работать, как старший программист.
При работе QA будет сосредоточен на создании внутренних границ продукта. На разделении его на модули, сервисы ещё что-то. Не важно, лишь бы запереть регрессионные ошибки в пределах модуля, сервиса либо ещё чего-то. Большое внимание будет обращено на интерфейсы модулей, API (Application Programming Interface — интерфейс приложения для программ) сервисов либо ещё чего-то, что выполняет функцию стандартизации и контроля обмена информации между элементами системы.
После того, как систему удастся разбить на компактные модули, сервисы и прочие элементы, заранее будет продуманно, как тестировать каждый элемент по отдельности, и как тестировать их совместную работу. Сразу же будут созданы требования к системе логирования, чтобы дефекты кодирования было легче замечать и локализовать.
В работе QA очень много от работы наставника. Именно этот человек учит всех членов команды, как меньше ошибаться. И он помогает разработчикам научиться вести отладку таким образом, чтобы после неё почти не оставалось ошибок. То есть сокращает затраты всей команды на багфикс.
В какой-то момент встанет вопрос об автоматизации тестирования. Но только не автоматизации тестирования на тестовом стенде, а о CI/CD (непрерывная интеграция и непрерывное развёртывание). То есть автоматической проверке любого нового фрагмента кода, который разработчик попробует добавить в кодовую базу программного обеспечения. Если фрагмент не пройдёт проверку, то его добавление будет отклонено автоматически.
Нельзя забывать и об ошибках переноса. Разработчики обычно работают на локальных стендах, чтобы их процесс отладки ошибок никому не мешал. При переносе изменений с локального стенда на общий стенд разработчиков могут возникать ошибки, например, что-то не перенеслось либо окружение локального стенда отличается от окружения стенда разработки. Окружение — это то что находится вокруг разрабатываемого приложения, иные сервисы и приложения, операционная система, доступные аппаратные ресурсы и иное.
То, что прекрасно работало на стенде разработки, где находятся незаконченные изменения от множества разработчиков, при переносе на тестовый стенд может перестать работать вообще. Например, потому, что связанные изменения от другого разработчика не были перенесены. Именно здесь начинает проявляться необходимость релизной политики. Релиз — это пакет изменений, которые переносятся на тестовый стенд все вместе и тестируются все вместе, так как нужно проверять и совместное влияние изменений друг на друга и на уже существующий функционал.
Даже если что-то хорошо работало на тестовом стенде, то не факт, что оно будет так же хорошо работать на демонстрационном и предпродуктовым стендом (продуктив — среда, на котором работает приложение, доступное конечным пользователям). Причиной может быть, например, наличие на тестовом стенде тестовых данных, которые будут отсутствовать на других стендах. Кроме того, иногда нужна конвертация старых данных в новые форматы, её тоже нужно проверять, для этого в том числе и нужен каскад стендов.
Ну и главное, то, что было перенесено на предпродуктовый стенд и показало свою работоспособность на копии данных с продуктива, должно ровно таким же образом попасть на продуктив. Чтобы не появились новые и неисследованные ошибки, уже на продуктиве.
Чтобы не тратить много времени на перенос изменений с одного стенда на другой, появилась автоматизация разворота приложений. В идеале процесс разворота должен происходить вообще без участия человека.
DevOps инженер
Достаточно новая специализация на стыке системного администрирования, разработки и тестирования программного обеспечения. Специалисты этого вида обеспечивают автоматизацию сборки, настройки и развёртывания программного обеспечения.
В целом, раньше этим занимались разработчики с навыками администрирования и системные администраторы с навыками программирования. Сейчас это отдельная специализация.
Особую актуальность данная специализация приобретает вместе с технологиями виртуализации и облачными технологиями. Попробуем понять, что это такое на пальцах. Представьте, что ваш бизнес владеет высоконагруженным сервисом. Иногда на него приходит много пользователей и нагрузка становится очень большой, иногда пользователей мало. Держать большие серверные мощности все время — очень дорого.
В результате вы приходите в облако (внешнее либо частное). Облако представляет собой ЦОД (центр обработки данных) из железных серверов, например, их у нас N штук. На базе железных серверов развёрнуто M штук виртуальных серверов, для простоты допустим M в разы больше N. И вы арендуете в этом облаке какое-то количество виртуальных серверов.
Ваш сервис представляет собой балансировщик, который принимает запросы пользователей и перераспределяет их по серверам обработки. Все сервера обработки однообразные и на них развёрнуто одно и то же приложение. Чем больше серверов обработки, тем большую нагрузку держит ваш сервис, и тем больше денег вы платите за аренду.
Благодаря автоматизации сборки и разворота у вас появляется возможность в динамике горизонтально масштабировать производительность сервиса. Начался наплыв пользователей — автоматически начали разворачиваться дополнительные сервера обработки. Пользователи ушли — дополнительные сервера обработки свернулись и вы за них не платите. А ещё, если ваши разработчики написали какое-то обновление, оно автоматически дойдёт до всех серверов обработчиков и само туда установится.
Обеспечением всего этого счастья, дающего новые возможности для бизнеса, и занимаются DevOps инженеры. То есть автоматизация процессов разворота приложений и доставки изменений (тот самый CI/CD) не только экономит ресурсы на разработку (разработчики больше не настраивают сами свои стенды) и тестирования приложений (перенос изменений между стендами), но и открывают новые возможности при эксплуатации приложения.
Кроме этого, в ведении DevOps инженеров находятся системы автоматизированного мониторинга и системы централизованного логирования (сборка и обработка логов в одном месте).
Подводя промежуточные итоги
В четвёртой части мы разобрали семантические ошибки перевода, которые могут негативно влиять на понимание процесса управления качеством в области информационных технологий, познакомились с QC и QA специалистами, поняли, чем они отличаются друг от друга и немного затронули область DevOps.
Зачастую хорошие QA специалисты совмещают в себе навыки разработчика, архитектора, бизнес-аналитика, руководителя проектов, руководителя службы технической поддержки. Именно поэтому настоящих специалистов по QA очень немного, в основном на рынке представлены специалисты по QC.
DevOps — это тоже инженерная культура, смежная и взаимопроникающая с культурой QA. В рамках этой культуры работают программисты, системные администраторы, QA (очень активно), руководители службы технической поддержки, руководители проектов. При хорошей работе DevOps инженеров затраты на разработку информационных систем и владение инфраструктурой заметно снижается, а у бизнеса появляются интересные возможности для масштабирования.
Если вы дочитали до конца, и написанное было для вас полезным, то спасибо вам.