Какие бывают программы обеспечения качества

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

Различают технические и организационные методы обеспечения качества ПО.

К техническим можно отнести следующие методы обеспечения качества ПО:

— использование систем управления дефектами (bug tracking system);

— внедрение автоматизированного тестирования;

— внедрение модульного (unit) тестирования;

— использование современных интегрированных сред разработки;

— использование валидаторов кода;

— внедрение систем версионного контроля;

К организационным методам обеспечения качества ПО относятся:

— планирование работ и затрат;

— оценка проектных рисков;

— проведение статусных митингов;

— проведение сессий Lessons Learnt;

— проведение Casual Analysis;

Качество программного обеспечения

2. Тестирование ПО. Цели тестирования. Виды тестирования: функциональное, практичности, безопасности, производительности. [вверх]

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

Цель тестирования – поиск дефектов в программе. Дефект – это некорректная логика, некорректная или неадекватная инструкция, выполнение которой приводит к отказу. Другими словами, дефект – это источник отказов, а отказы – это выполнение части программного кода, содержащего дефект.

В зависимости от объекта тестирования выделяют следующие виды:

— функциональное тестирование (functional testing);

— тестирование практичности (usability testing);

— тестирование безопасности (security testing);

— тестирование производительности (performance testing);

— глобализационное тестирование (globalization testing);

— тестирование локализации (localization testing);

— тестирование доступности (accessibility testing).

Функциональное тестирование (functional testing) – это тестирование заявленных (задокументированных) функциональных возможностей программы. Цель данного тестирования – поиск дефектов, связанных с выполнением непосредственных функций программы. К функциональным дефектам можно отнести, например, неправильное взятие программой-калькулятором корня от числа.

Тестирование практичности (usability testing) – это тестирование, направленное на поиск возможных проблем при использовании программы и относящихся к удобству пользования и предоставления заявленных функциональных возможностей. К дефектам практичности можно отнести, например, близко расположенные маленькие кнопки программы-калькулятора, расположение которых приводит к тому, что часто нажимается не та цифра.

Тестирование безопасности (security testing) – это тестирование программы, направленное на выявление уязвимостей, которые могут приводить к неправомерному или нецелевому использованию программы. К дефектам такого рода можно отнести уязвимости в интернет-браузерах, позволяющие злоумышленникам получать контроль над компьютером пользователя.

Режим Бога на windows 7.

Тестирование производительности (performance testing) ­– тестирование, направленное на выявление проблем производительности программы. Данное тестирование оценивает затраты программы на выполнение заявленных функций, а также проверяет поведение программы при работе с верхними пределами входных значений. Примером дефекта производительности может служить стократное увеличение времени вычислений при выполнении операции взятия корня над двузначными числами в программе-калькуляторе.

3. Тестирование ПО. Цели тестирования. Виды тестирования: нагрузочное, глобализационное, локализационное, доступности. Поколения тестирования. [вверх]

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

Цель тестирования – поиск дефектов в программе. Дефект – это некорректная логика, некорректная или неадекватная инструкция, выполнение которой приводит к отказу. Другими словами, дефект – это источник отказов, а отказы – это выполнение части программного кода, содержащего дефект.

В зависимости от объекта тестирования выделяют следующие виды:

— функциональное тестирование (functional testing);

— тестирование практичности (usability testing);

— тестирование безопасности (security testing);

— тестирование производительности (performance testing);

— глобализационное тестирование (globalization testing);

— тестирование локализации (localization testing);

— тестирование доступности (accessibility testing).

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

Глобализационное тестирование (globalization testing) – цель данного тестирования выявление дефектов, связанных с региональными отличиями в программном обеспечении. Например, как будет вести себя программа при использовании на компьютере с американскими региональными настройками (форматами времени и даты, денежных единиц и прочее). Примером дефекта подобного рода может служить дефект, связанный с некорректной обработкой чисел с плавающей запятой: в России в качестве разделительного знака используется запятая, а, например, в США – точка.

Локализационное тестирование (localization testing) направлено на поиск дефектов, возникших при локализации программного продукта. Это могут быть как ошибки, допущенные во время перевода, так и проблемы, связанные с отображением национальных символов и т.п.

Тестирование доступности (accessibility testing) проводится для определения проблем в работе людей с ограниченными возможностями с программой. Дефектом, обнаруженном при данном виде тестирования являются некорректные цвета интерфейса, приводящие к тому, что человек, страдающий дальтонизмом, не в состоянии прочитать текст.

Источник: studopedia.su

Что такое обеспечение качества ПО (SQA)?

Что такое обеспечение качества программного обеспечения?

Обеспечение качества программного обеспечения (SQA, Software Quality Assurance) – это процесс, который гарантирует, что все процессы, методы и подходы программной инженерии контролируются и соответствуют установленным стандартам. Эти установленные стандарты могут быть одним или комбинацией любых стандартов, таких как ISO 9000, модель CMMI, ISO15504 и т. д.

SQA включает в себя все процессы разработки ПО, начиная с определения требований и заканчивая кодированием и выпуском продукта в эксплуатацию. Его главная цель – обеспечить качество.

План обеспечения качества ПО

Сокращенно называемый SQAP (Software Quality Assurance Plan), план обеспечения качества ПО включает в себя процедуры, методы и инструменты, которые используются для того, чтобы убедиться, что продукт или услуга соответствуют требованиям, определенным в SRS (Software Requirements Specification, спецификация требований к ПО).

План определяет обязанности QA команды и перечисляет компоненты, которые необходимо тестировать и для которых проводить аудит. Он также определяет артефакты SQA.

Документ плана SQA состоит из следующих разделов:

• Раздел с целями
• Раздел со ссылками
• Раздел управления конфигурацией ПО
• Раздел с отчетами о дефектах и корректирующих действиях
• Раздел с описанием инструментов, технологий и методологий
• Раздел с подходами контроля кода
• Документы и артефакты: Сбор, ведение и хранение
• Методология тестирования

Мероприятия SQA

Ниже приведен список мероприятий SQA:

1. Создание плана SQA менеджмента :

Самое важное мероприятие включает в себя составление надлежащего плана относительно того, как именно будет осуществляться контроль качества в вашем проекте.

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

2. Согласование контрольных точек:

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

3. Применение методов программной инженерии:

Применение некоторых методов программной инженерии помогает разработчику ПО в достижении высокого качества реализации требований спецификаций. Для сбора информации дизайнер может использовать такие методы, как интервью с клиентами или FAST (Functional Analysis System Technique, системный метод функционального анализа).

Позже, основываясь на собранной информации, разработчик ПО может подготовить оценку проекта, используя такие методы, как WBS (Work Breakdown Structure, иерархическая структура работ), SLOC (Source Lines of Code, количество строк кода) и FP.

4. Проведение технических ревью:

Технические ревью проводятся для оценки качества и дизайна прототипа.

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

5. Наличие стратегии мультитестирования:

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

6. Обеспечение соблюдения процессов:

Этот вид деятельности настаивает на необходимости соблюдения процессов в процессе разработки ПО. Процесс разработки также должен придерживаться определенных процедур.

Эта деятельность представляет собой сочетание двух поддеятельностей, которые подробно описаны ниже:

(i) Оценка продукта:

Эта деятельность подтверждает, что программный продукт соответствует требованиям, которые были определены в плане управления проектом. Она гарантирует, что установленные стандарты для проекта соблюдаются правильно.

(ii) Мониторинг процесса:

Эта деятельность проверяет, были ли предприняты правильные шаги во время разработки программного обеспечения. Это делается путем сопоставления фактически выполненных шагов с задокументированными шагами.

7. Контроль изменений:

В этой деятельности мы используем сочетание ручных задач и автоматизированных инструментов для создания механизма контроля изменений.

Проверяя запросы на изменения, оценивая характер изменений и контролируя их влияние, мы обеспечиваем поддержание качества ПО на этапах разработки и сопровождения.

8. Измерение влияния изменений:

Если команда QA сообщает о каком-либо дефекте, то соответствующая команда разработчиков устраняет его.

После этого команда QA должна определить влияние изменения, которое принесло это исправление дефекта. Они должны проверить не только то, что изменение устранило дефект, но и то, совместимо ли это изменение со всем проектом.

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

9. Проведение SQA-аудитов:

Аудит SQA проверяет весь фактический процесс жизненного цикла разработки проекта и сравнивает его с установленным процессом.

Он также проверяет, было ли на самом деле выполнено то, о чем команда сообщала в отчетах о статусе. Эта деятельность также выявляет любые проблемы, связанные с несоответствием требованиям.

10. Ведение записей и отчетов:

Очень важно вести необходимую документацию, связанную с SQA, и делиться необходимой информацией о контроле качества с заинтересованными сторонами. Результаты тестирования, аудитов, отчеты о проверках, документация по запросам на изменения и т.д. должны храниться для будущих справок.

11. Поддерживайте хорошие отношения:

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

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

Стандарты обеспечения качества ПО

В целом, SQA может требовать соответствия одному или нескольким стандартам.

Некоторые из наиболее популярных стандартов рассмотрены ниже:

ISO 9000: Этот стандарт основан на семи принципах управления качеством, которые помогают организациям гарантировать, что их продукция или услуги соответствуют потребностям клиентов.

7 принципов ISO 9000 представлены на рисунке ниже:

Уровень CMMI: CMMI расшифровывается как Capability maturity model Integration. Эта модель возникла в программной инженерии. Она может быть использована для улучшения процессов в рамках проекта, отдела или всей организации.

5 уровней CMMI и их характеристики описаны на рисунке ниже:

Организация оценивается и получает рейтинг уровня зрелости (1-5) в зависимости от типа оценки.

Интеграция модели зрелости тестирования (TMMi, Test Maturity Model integration): Основанная на CMMi, эта модель фокусируется на уровнях зрелости в управлении качеством ПО и тестировании.

5 уровней TMMi показаны на рисунке ниже:

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

Элементы обеспечения качества ПО

Существует 10 основных элементов SQA, которые перечислены ниже для справки:

1. Стандарты программной инженерии
2. Технические обзоры и аудиты
3. Тестирование ПО для контроля качества
4. Сбор и анализ ошибок
5. Управление изменениями
6. Образовательные программы
7. Управление поставщиками
8. Управление безопасностью
9. Управление рисками
10. Метрики

Методы контроля качества ПО

Существует несколько методов контроля качества ПО. Аудит является основным методом, который широко распространен. Однако есть и несколько других значимых подходов. К различным методам SQA относятся:

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

• Общие требования и дизайн
• Функциональные и интерфейсные спецификации
• Конвенции
• Прослеживаемость требований
• Структуры и интерфейсы
• Логика
• Производительность
• Обработка ошибок
• Тестируемость, расширяемость
• Связность

Заключение

SQA – это комплексная деятельность, которая применяется на протяжении всего жизненного цикла ПО.

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

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

Надеемся, вы получили четкое представление о концепции обеспечения качества ПО благодаря этой статье!

Похожие записи:

1. Полное руководство по тестированию баз данных
2. Руководство по тестированию безопасности веб-приложений
3. Как проводить тестирование Backend
4. Анализ тестирования

Источник: qarocks.ru

Что такое качество. Разбираемся в иерархии терминов «QA», «QC» и «тестирование»

Дискуссии вокруг терминологии в 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 может оказаться совершенно устаревшим. Одни стандарты сменяются другими, значения терминов изменяются со временем. Нам остаётся это только принять.

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

• Качество программного обеспечения
• software quality
• гост
• качество по
• обеспечение качества
• quality assurance
• управление качеством
• quality control
• тестирование по
• software testing

• Блог компании Ростелеком
• Тестирование IT-систем
• Терминология IT

Источник: habr.com