Введение
Дискуссии вокруг терминологии в IT вечны, хотя по умолчанию считается, что термины отлиты в граните… Трактовка очень сильно зависит от того, кого спрашивать. А вокруг «качества» так много холиваров, что, если начать спрашивать коллег по цеху, что это такое, в ответ можно услышать разные версии: от довольных клиентов или отсутствия багов до абсолютной формальности. Но еще большая чехарда начинается, если спросить, как это качество обеспечить.
Если спросить коллег про обеспечение качества в энтерпрайзе, то с ними проблем обычно нет: тебя быстро посылают в группу обеспечения качества и дальше занимаются своими делами. А вот в не энтерпрайзе (например, в ритейле) начинается интересное. В зависимости от того, кого спрашивать, тебя будут посылать к разным людям, но в большинстве случаев всё сводится к «Не мешай работать, иди к тестировщикам, они вот как раз про качество». Не проблема, сходим.
Ниже результаты моего небольшого исследования, что же такое качество и как его обеспечить, чтобы не слушать в ответ: «Слушай, да что ты докопался, сходи на www.protesting.ru (далее – ПроТестинг), там специально для таких, как ты все написано». Поскольку про него (ПроТестинг) я слышу постоянно, я буду опираться на него.
Основные понятия и определения
Процитирую определения SQ с ПроТестинга:
Качество программного обеспечения (Software Quality) – это степень, в которой программное обеспечение обладает требуемой комбинацией свойств. [1061-1998 IEEE Standard for Software Quality Metrics Methodology]
Качество программного обеспечения (Software Quality) – это совокупность характеристик программного обеспечения, относящихся к его способности удовлетворять установленные и предполагаемые потребности. [ISO 8402:1994 Quality management and quality assurance]
Хочу обратить внимание на годы, которые я выделил жирным. Стандарты, откуда взяты определения были выпущены больше 20 (!) лет назад. А что есть сейчас?
Ответ: ГОСТ Р ИСО 9000-2015. Тут у многих возникает реакция «Эм, а номера-то стандартов не бьются!». Верно, рекомендую погуглить самостоятельно и потратить время на изучения того, как менялись номера стандартов и один стандарт поглощал другие.
Вернемся к «Качеству». ГОСТ нам говорит следующее:
Качество (Quality) – степень соответствия совокупности присущих характеристик объекта требованиям.
Если сравнить его с предыдущими версиями, то слов стало меньше, а смысл стал более кристаллизованным. Из этого определения вытекает важный вывод: если вы не выдвинули требования, то и разговор про качество не имеет под собой основания. Качество само собой не появляется, оно требует затрат. Об этом развернуто говорится в разделе «2.2.1 Качество».
Приведу абзац из этого раздела:
Организация, ориентированная на качество, поощряет культуру, отражающуюся в поведении, отношении, действиях и процессах, которые создают ценность посредством выполнения потребностей и ожиданий потребителей и других соответствующих заинтересованных сторон.
Культура ест стратегию на завтрак? Да, но не только. Она «ест» всё, включая качество. Если вы не будете вкладываться в культуру, поощряющее качество, то можете забыть про него. Качество не может жить в отрыве от организации как системы.
Качество продукции и услуг организации определяется способностью удовлетворять потребителей и преднамеренным или непреднамеренным влиянием на соответствующие заинтересованные стороны.
Качество не может жить в отрыве и от тех, кто пользуется продуктом. Если не удовлетворять требования, которые основаны на пожеланиях пользователей, то продукт будет восприниматься некачественным. С другой стороны, если вы не рассказываете о своем продукте и о его предназначении, то ваш продукт будет воспринят неправильно и будет считаться некачественным.
И еще один абзац. Очень важный абзац:
Качество продукции и услуг включает не только выполнение функций в соответствии с назначением и их характеристики, но также воспринимаемую ценность и выгоду для потребителя.
Если мы не транслируем свою видение качества, политику в отношении качества, то восприятие наших продуктов потребителями может не совпасть с тем, какой мы ожидаем видеть.
На мой взгляд в этих трех абзацах разработчики стандарта постарались отразить, что качество – это достаточно сложная и многогранная вещь, включающая в себя культуру производства, наше понимание клиентов и наше видение того, что есть наш продукт. Мне такой подход очень близок.
Пойдем дальше и обсудим, что изменилось в определении: Обеспечение качества (Quality Assurance)
С сайта ПроТестинг:
Обеспечение качества (Quality Assurance) - это совокупность мероприятий, охватывающих все технологические этапы разработки, выпуска и эксплуатации программного обеспечения (ПО) информационных систем, предпринимаемых на разных стадиях жизненного цикла ПО, для обеспечения требуемого уровня качества выпускаемого продукта.
Согласно ГОСТ Р ИСО 9000-2015:
Обеспечение качества (Quality Assurance): Часть менеджмента качества, направленная на создание уверенности, что требования к качеству будут выполнены.
Что мне нравится в определении ГОСТа: ушли от всей многословности про мероприятия, этапы и прочее, а сфокусировались на сути – на обеспечение уверенности. Если задуматься, то это единственное, что вы можете сделать. Гарантировать на 100% нельзя ничего. А как вы будете обеспечивать эту уверенность – напрямую зависит от корпоративной культуры и политики качества.
Где-то это четко выраженные критерии приемки фичи в работу, где-то специальные договорные отношения или множество политик и инструкций. Как реализовать обеспечение качества компания выбирает сама. Но одно очевидно – это очень дорого.
Quality Control – а вот тут начинается самое интересное! Смотрим и сравниваем, верхнее определение взято с ПроТестинга, нижнее из ГОСТа:
Контроль качества (Quality Control) – это совокупность действий, проводимых над продуктом в процессе разработки, для получения информации о его актуальном состоянии в разрезах: «готовность продукта к выпуску», «соответствие зафиксированным требованиям», «соответствие заявленному уровню качества продукта».
Управление качеством (Quality control) – часть менеджмента качества, направленная на выполнение требований к качеству.
Внимательные уже заметили, что поменялся перевод. Теперь это управление качеством!
Из нового определения также ушла многословность, и остался фокус на выполнение требований, что, на мой субъективный взгляд, сделало его сильно лучше, в старом варианте. В основном потому что в нем присутствовало «…для получения информации…».
Что потом со всей этой информацией делать не уточнялось… В новом определении четко прописано: надо выполнять требования. Опять же, как вы это будете делать зависит от корпоративной культуры.
Например, политика качества предписывает, что тест кейсы должны быть максимально полные – это обеспечение качества. А управление качеством это:
проверка, что эти тест кейсы полные и достаточные;
проверка, что тестирование по ним выполняется в полном объеме.
Если соотнести определения с циклом Деминга-Шухарта, то обеспечение качества = планирование, часть выполнения и часть корректировки. А управление качеством – это часть выполнения, проверка и часть корректировки.
Теперь мы поговорим о том, что такое тестирование. Ниже даны два определения, первое взято c ПроТестинга, ниже – из ISO/IEC TR 19759:2015, он же SWEBOK.
Тестирование программного обеспечения (Software Testing) – проверка соответствия между реальным и ожидаемым поведением программы, осуществляемая на конечном наборе тестов, выбранном определенным образом. [IEEE Guide to Software Engineering Body of Knowledge, SWEBOK, 2004].
В более широком смысле, тестирование – это одна из техник контроля качества, включающая в себя активности по планированию работ (Test Management), проектированию тестов (Test Design), выполнению тестирования (Test Execution) и анализу полученных результатов (Test Analysis).
Software testing consists of the dynamic verification that a program provides expected behaviors on a finite set of test cases, suitably selected from the usually infinite execution domain».
Официальный перевод отсутствует, поэтому ниже я приведу свой перевод. Альтернативные версии пишите в комменты под постом.
«Тестирование программного обеспечения это проверка того, что программа обеспечивает ожидаемое поведение на конечном наборе тестовых случаев, выбранных определенным образом из бесконечного набора тестовых случаев».
Определения если и изменились, то не сильно. В целом это уже проверка, и я полностью согласен с коллегами: это часть управления качеством.
А из всего вышесказанного получается вот такая картинка.
Пример
Про определения можно говорить много, долго и красиво. А как в жизни? Она же сложная, многогранная. Рассмотрим на простом примере, чем отличается тестирование от управления качеством и обеспечения качества.
Дисклеймер: пример, представленный ниже, является полностью вымышленным. Все совпадения случайны.
Знакомьтесь, компания Икс
Компания занимается продажей продуктов, дела у нее все хорошо. Сквозной процесс доставки ценности показан ниже:
Компания создавала ценность, потом проводила верификацию и валидацию, чтобы убедиться, что все хорошо и выполняла поставку, выходным артефактом был дистрибутив. Мы же помним, что это простой пример!
Компания заботилась о качестве выпускаемых продуктов и доносила до клиентов, что тестирование выполняется на самом высшем уровне. И действительно, продукты компании были классные и здорово решали проблемы клиентов. Клиенты подумали, раз продукты такие хорошие, то и тесты, с помощью которых их проверяют, тоже хорошие, и эти данные помогут помочь уже с проверкой собственных бизнес процессов. И компания получила заманчивое предложение «Продайте нам ваши тесты, вот договор с открытой суммой». Компания решила «А почему бы и нет!».
Процесс поставки ценности приобрел следующий вид:
Теперь на выходе два артефакта: дистрибутив и тесты. Но возник вопрос от коллеги из ИБ: что у нас с персональными данными? В дистрибутиве их понятно нет, а в тестах? Как мы соблюдаем 152-ФЗ? А вдруг кто-то использовал свои ФИО или ФИО коллег для тестирования?
Согласно закону фамилия, имя и отчество трактуются как персональные данные. Я понимаю, что юристы тут много что могут сказать, но помните – у нас упрощенный пример.
Понятно, что можно попросить сотрудников подписать документы на передачу ПД, но мы сейчас чуть про другое. Мы рассматриваем кейс как нам обеспечить уверенность в том, что персональных данных в тестах нет. В качестве ПД рассматриваем только фамилию имя и отчество, сильно упрощаем под формат статьи. Что это все означает? В политику качества компании добавлено требование «В поставляемых тестах отсутствуют персональные данные». Реализуем его.
Тестирование
Идем от частного к общему. Подход к тестированию очень простой: нужно проверить, что в наших тестах нет ФИО сотрудников. Хороший тестировщик скажет, что неплохо бы пропустить ФИО через морфер, чтобы получить их в различных падежах.
Встраиваем в наш процесс отдельный шаг, где мы проверяем наши тесты на отсутствие ПД. В результате процесс поставки бизнес ценности становиться таким.
Дешево и быстро. Если нашли ПД, то убрали их в выходном артефакте, и в тестах в системе управления тестированием. Кстати последнее уже больше про QC. Вопросов к такому подходу нет, проверили, молодцы, но выполняются ли требования к качеству? Нет. Например, в компанию устроился новый сотрудник, как он попадет в это список?
Здесь переходим на следующий уровень. Рассматриваем решение нашего кейса уже с точки зрения управления качеством.
Управлением качеством
На этом уровне мы уже встраиваем дополнительные шаги в процессы компании, а не только в основной процесс создания ценности. Для того чтобы обеспечить отсутствие ФИО сотрудников в тестах, мало проверить каждый из них. Нужно быть уверенным в том, что список, по которому мы ведем проверку, всегда актуальный.
В общем случае возможны два события, которые требуют добавления информации в список:
Сотрудник поменял ФИО. Всякое бывает;
В компанию пришел новый сотрудник.
Сразу возникает вопрос: почему не обновлять и когда информация удаляется из списка? Ответ на них один – никогда. Информация не удаляется и не обновляется, а только добавляется, таким образом мы гарантируем отсутствие ПД. Лучше, как говорится, перебдеть.
Процесс создания ценности становиться вот таким:
Уже хорошо, но нас будут постоянно преследовать две проблемы: ложноположительные и ложноотрицательные срабатывания. И сделать с ними ничего нельзя, ведь мы находимся в конце цепочки создания ценности, не влияем на предыдущие шаги. Более того, мы реагируем на уже свершившиеся события.
Задача обеспечения качества – исключить возможность в принципе возникновения таких событий. Переходим на этот уровень.
Обеспечение качества
Для того чтобы предотвратить попадание ФИО наших сотрудников в тестовые данные мы переходим на процедурную генерацию ФИО. Тестировщикам больше не надо придумывать ФИО для заполнения полей, за них это сделает процедура. Более того, тестировщикам запрещено использовать данные полученные не из процедуры. Процесс создания ценности становится следующим:
Какие плюсы мы получаем от такого подхода:
Обеспечиваем уверенность, что в созданных для тестирования данных не будет ФИО сотрудников. В самой процедуре реализованы проверки на то, что созданные ФИО отсутствуют в списке ФИО сотрудников;
Гарантируем, что они не будут похожи на «человеческие». Очень хорошая практика + еще одна ступень уверенности. Например, ФИО могут быть созданы в эльфийском стиле;
Гарантируем, что в них будут внедрены сигнатуры для быстрой скриптовой идентификации. Например, в начало и в конец вставлять букву «й»;
Обеспечиваем единую точку поставки тестовых данных;
Всё есть код! Обеспечивается прозрачный контроль над алгоритмом создания тестовых данных;
Приятный бонус: мы можем использовать наши процессы для обеспечения качества кода. Например, любые изменения возможно только после одобрения ИБ запроса на изменение.
Все эти меры обеспечивают нам уверенность в том, что требование «В поставляемых тестах отсутствуют персональные данные» будет выполнено. Но важно понимать, что это никак не отменяет тестирования выходных данных на наличие ПД.
Заключение
Определения не отлиты в граните, они меняются. То, что было справедливо в 1999 году, в 2022 может оказаться совершенно устаревшим. Одни стандарты сменяются другими, значения терминов изменяются со временем. Нам остаётся это только принять.
Пока готовил эту статью я понял один важный момент. Вести разговор о качестве в отрыве от требований неправильно. Только когда выдвинуты все требования следует запускать все механизмы по обеспечению качества. Выдвинутые требования – это гарантия осознания того, что необходимо сделать, и какие ресурсы нужно выделить. Иначе получить качественный продукт на выходе просто невозможно.
