В учебных программах по дисциплине "Обеспечение качества и тестирование программ" есть темы "Место тестирования в процессах обеспечения качества", "Соотношение тестирования, контроля качества и обеспечения качества (quality assurance)" и "Процессы обеспечения качества: SQA, V&V, Тестирование". В программе обучения базового уровня International Software Testing Qualifications Board "Сертифицированный тестировщик" тема детализируется пунктом «Описать, почему тестирование — это часть обеспечения качества и привести примеры, как тестирование способствует повышению качества».

«Тестирование программного обеспечения. Фундаментальные концепции менеджмента бизнес-приложений», Сэм Канер, Джек Фолк и Енг Кек Нгуен, Москва, ДиаСофт, 2001. 431-434 страницы:

• Существует четыре основных типа тестовых групп. У каждой из них своя роль в компании и свои задачи. (1) Группа контроля качества следит за соблюдением стандартов. (2) Группа обеспечения качества пытается тем или иным способом га­рантировать соблюдение стандартов. (3) Служба тестирования ищет и документирует ошибки. (4) Служба поддержки разработки выполняет ряд технических задач, и в том числе тестирование.
• Группа контроля качества. Теоретически это очень влиятельное подразделение. Инспектор группы контроля качества (Quality Control) может задержать выпуск продукта до тех пор, пока не будут соблюдены все стандарты и процедуры и исправлены все ошибки. Какой заманчивой кажется сотрудникам служб тестирования и разработки такая власть! Но ничто не дается даром. Инспектор группы контроля качества не просто снимает с конвейера пару бракованных банок консервов. Он останавливает всю линию, возмож­но, единственную линию компании, и делает это не на пару минут, а на несколько дней, недель или месяцев. Руководство компании реагирует на такие события немедленно и может запросто отменить решение группы контроля качества и распорядиться выпускать продукт, каким бы ни было его качество.
• Группа тестирования помогает руководству компании, предоставляя информацию о текущих проблемах разработки и степени их серьезности. Однако предоставление информации — это одно, а принятие решений — совсем другое. Здесь группа контроля качества обладает несколько более высокими полномочиями, чем обычная группа тестирования, поскольку может задержать выпуск продукта, не удовлетворяющего определенным требованиям. Однако сделать это она может только на некоторое время — пока руководство не проанализирует ситуацию, чтобы принять окончательное решение.
• Группа обеспечения качества. Группа обеспечения качества (Quality Assurance) делает то, чего не может сделать обыкновенная группа тестирования, — она обеспечивает качество продукта. Для этого группа обеспечения качества участвует в разработке от первого до последнего дня, устанавливая стандарты, определяя процедуры контроля и обучая людей тому, как лучше проектировать и разрабатывать программные продукты. Таким образом, недостатки программ не просто устраняются, а предотвращаются. Группа обеспечения качества занимается также и тестированием, но это далеко не единственная ее работа.
• Чтобы справиться со своей задачей, группа обеспечения качества должна обладать огромными полномочиями, а ее сотрудники — высочайшей квалификацией в целом ряде профессий. Они должны быть высококлассными программистами, техническими писателями, руководителями, проектировщиками и аналитиками. Иначе им просто не будут доверять.В любой компании имеется группа, отвечающая за определение стандартов, обучение персонала, управление работой и повышение ее эффективности, — это руководство компании. Именно оно обеспечивает качество выпускаемых продуктов.
• Служба тестирования. В задачи службы тестирования (Testing Services) входит поиск ошибок и недостатков программы, их описание и предоставление этой информации всем, кому она необходима. Решений относительно выпуска продукта руководитель службы тестирования не принимает, он только предоставляет руководству информацию о том, насколько продукт протестирован и каково его качество.
• Роль службы тестирования в разработке продукта может быть различной. В некоторых компаниях основными тестировщиками считаются сами программисты, а служба тестирования им только помогает. Как бы там ни было, служба тестирования отвечает за техническую сторону этой работы: анализ объекта тестирования, проектирование и подготовку тестов, их выполнение и документирование... Она отвечает за качественное тестирование, интерпретацию его результатов и их своевременное предоставление руководству, документирование своей работы. Но ни контролирующей, ни руководящей роли у нее нет. Участие службы тестирования в управлении проектом скорее косвенное, чем непосредственное. Ее сила заключается в собираемых данных и умении правильно их представить. И сила эта немалая. Переговорами и убеждением нередко удается достичь гораздо большего, чем просто отменой выпуска продукта или вводом новых процедур и стандартов.
• Служба поддержки разработки. Концепция службы поддержки разработки (Developing Services) является расширением концепции службы тестирования. Обе они являются службами, а значит, предоставляют чисто технические услуги — это не административные, не контролирующие и, как правило, аполитичные группы. Они помогают улучшить продукт, созданный другими сотрудниками (программистами), используя для этого профессиональные навыки, которых у программистов нет. Если служба тестирования только тестирует продукт, то у службы поддержки разработки есть и другие задачи... Основной задачей службы поддержки разработки остается тестирование, но в зависимости от нужд конкретной компании могут выполняться следующие задачи. (1) Отладка. (2) Техническая поддержка пользователей, особенно в первые недели после выпуска продукта. (3) Редактирование копии руководства пользователя. (4) Техническое редактирование руководства (с правом вносить изменения, которого обычные тестировщики не имеют). (5) Анализ эксплуатационных характеристик продукта. (6) Сравнительная оценка продукта. (7) Изучение пользовательского удовлетворения продуктом.

«Ключевые процессы тестирования. Планирование, подготовка, проведение, совершенствование», Рекс Блэк, Москва, Лори, 2006, 531/545 страница:

Оценка качества (в отличие от тестирования) (Quality Assurance contrasted with Testing). В соответствии со стандартом IEEE 610.12-1990 стандартный глоссарий терминологии по программированию ("IEEE Standard Glossary of Software Engineering Terminology") говорит: оценка качества (QA) включает в себя "всякую деятельность, необходимую для обеспечения достаточной уверенности "в качестве системы и оценку" процесса, с помощью которого [система] разрабатывалась", тогда как тестирование состоит из действий, необходимых для "обнуражения различий между существующими и требуемыми условиями (ошибок) и оценки... свойств". Другими словами, оценка качества фокусируется на корректности процесса, а тестирование - на установлении качества.

Качество (Quality). 1. Пригодность для использования. Наличие свойств, атрибутов и функций, удовлетворяющий ожиданиям заказчиков и пользователей, и отсутствие свойств, атрибутов и функций, неудовлетворяющих ожиданиям заказчиков и пользователей. 2. Соответствие требованиям. Наличие свойств, атрибутов и функций, удовлетворяющих всем уставленным требованиям, и отсутствие свойств, атрибутов и функций, отклоняющихся от требование. (Данное определение применимо в конкретном контексте, в особенности для проектов, выполняемых по контракту.)

«Основы инженерии качества программных систем», Филипп Андон, Галина Коваль, Татьяна Коротун, Екатерина Лаврищева, В. Суслов, Академпериодика, 2007. 39, 41, 42, 303 страница:

• Первый шаг к повышению качества ПС состоит во внедрении в повседневную практику организаций-разработчиков специально предназначенных для этого поддерживающих процессов жизненного цикла программной системы, регламентируемых стандартом ISO/IEC 12207:1995 "Information technologies. Software life cycle processes" (или ДСТУ 3918) по процессам жизненного цикла программной системе, а именно процессов гарантирования качества, верификации, валидации, совместного просмотра и аудита. Применение этих процессов обеспечивает руководство организации и проекта методами и средствами контроля за соблюдением требований к процессам разработки и качеству рабочих продуктов на каждой стадии жизненного цикла проекта.
• Применяемый далее термин «гарантирование качества» соответствует обычно используемому за рубежом термину «Software Quality Assurance» (SQA), получившему в издаваемой у нас переводной литературе по программной инженерии и отечественных стандартах разные варианты перевода, например, «обеспечение качества», «контроль качества». Однако существующие переводы не в полной мере отражают суть деятельности по SQA.
• Может сложиться впечатление, что именно (и только) процесс SQA должен обеспечивать качество программных продуктов или контролировать качество, что неверно. Неверно также все задачи обеспечения качества возлагать на одноименную группу – SQA. Без вовлечения в контроль качества других процессов жизненного цикла достижение целей качества было бы невозможным.
• Процесс SQA обеспечивает гарантии (от assurance – давать заверения, гарантировать), что программные продукты и процессы в жизненном цикле проекта соответствуют предъявляемым к ним требованиям. Эти гарантии основаны на том, что SQA планирует и осуществляет контроль и оказание помощи в той деятельности по проекту, которая непосредственно связана со «встраиванием» в программные продукты свойств, обеспечивающих качество. SQA устанавливает стандарты, отвечающие передовой практике программной инженерии (нормы, правила, требования - как к процессам, так и к их продуктам) и контролирует их соблюдение в ходе жизненного цикла. SQA гарантирует, что проблемы, неизбежно возникающие в любой комплексной деятельности (каковой является совместное выполнение процессов жизненного цикла), своевременно идентифицируются и устраняются, что запланированные процессы пригодны для применения и надлежащим образом выполняются в соответствии с планом и что результаты выполняемых в проекте измерений могут быть использованы для регулирования деятельности в процессах жизненного цикла. Цель SQA – установить, почему допускаются ошибки и как они могут быть устранены. Таким образом, объектом исследований SQA являются в основном процессы жизненного цикла программной системы, а не программные продукты (в том числе рабочие продукты), качество которых должно быть обеспечено.
• Для контроля качества программных продуктов (включая все рабочие продукты) предназначены процессы верификации и валидации.
• Процессы верификации и валидации определяют, действительно ли продукты определенного этапа процесса разработки и сопровождения ПС соответствуют виду и потребностям данного шага и отвечают требованиям, предъявляемым к ним в начале этапа, а также в начале процесса. Задача верификации и валидации – проверить и подтвердить, что конечный программный продукт будет отвечать своему назначению и удовлетворять пользователей. Эти процессы контролируют качество путем выявления ошибок в продуктах процессов ЖЦ, не исследуя коренных причин появления этих ошибок.
• Цель верификации – исследуя трансформации одних (входных) рабочих продуктов в другие (выходные) рабочие продукты проверить, правильно ли разрабатывается программный продукт (например, правильный ли код программного модуля по отношению к спецификации проекта этого модуля).
• Цель валидации – исследуя совокупность рабочих продуктов, полученных на определенном этапе процесса разработки, убедиться в том, что они разработаны правильно, то есть отвечают назначению и специфицированным исходным требованиям к программному продукту (например, совокупность программных модулей действительно представляет требуемый программный продукт, совокупность выполненных тестов действительно достаточна для проверки всех функций ПС и т.п.).
• И процесс верификации, и процесс валидации должны выполняться, начиная с самых ранних стадий ЖЦ ПС и применительно ко всем рабочим продуктам разработки (включая, например, планы). Эти процессы тесно взаимосвязаны и обычно определяются одним термином «верификация и валидация», которому соответствует термин «Verification and Validation» (V&V), используемый в зарубежной литературе.
• Нужно отметить, что контроль процессов SQA и V&V осуществляет руководство проекта или организации (для независимого SQA или независимой верификации и валидации), а сами процессы координируют свои действия по проверке рабочих продуктов и других процессов.
• Существует множество методов, пригодных для применения как в целях SQA, так и в целях V&V. Один из видов их классификации – деление на статические и динамические, не связанные и связанные с выполнением программ на компьютере, соответственно.
• Статические методы касаются исследования документации по проекту (процессам, рабочим продуктам и пр.) одним лицом или группой лиц (коллективно), возможно с применением инструментальных средств поддержки.
• К методам коллективной работы относятся инспекции, ревизии, сквозной контроль и др. Они могут также определяться и выполняться как самостоятельные поддерживающие процессы жизненного цикла.
• Методы индивидуальной работы предполагают проведение аналитических исследований (например, анализ потоков данных, причинно-следственный анализ, анализ деревьев событий и деревьев отказов, анализ сложности алгоритмов, формальное доказательство корректности и др.).
• К динамическим методам обычно относят тестирование, имитационное моделирование и символическое выполнение.
• Примечательно, что тестированию, с одной стороны, отводится место среди основных процессов жизненного цикла программной системы, а с другой - его принято считать ключевым методом V&V (Коротун Т.М. Верификация и валидация ППО автоматизированных систем организационного управления / Сб. материалов конференции. УкрПРОГ’98, 2-4 сентября 1998 г. -Киев. - 1998. - С. 362 - 367). На наш взгляд тестирование, как процесс, недостаточно четко определено в действующих стандартах, поскольку эффективное осуществление процесса тестирования требует выполнения определенных действий практически на всех стадиях жизненного цикла проекта и во многих процессах, например, в процессах определения требований, SQA и V&V...
• Тестирование имеет много общего с процессами верификации и валидации (V&V), рассмотренными в главе 6 "Процессы и методики проверки". Общность процесса тестирования с процессами V&V заключается в единстве состава и структуры планов, рекомендуемых IEEE Std 829:1998 "Standard for Software Test Documentation" (52 страница), а также объектов и применяемых методов. Отличие этих процессов состоит в условиях их применения. Тестирование – основной процесс в жизненного цикла, выполняемый всегда, для всех объектов ПО системы независимо от ее критичности. Процессы V&V, в современной трактовке стандартов . IEEE Std. 1012:1998 "IEEE Standard for Software Verification and Validation" и ISO/IEC 12207:1995 "Information technologies. Software life cycle processes" (61 страница) – поддерживающие процессы, которые могут применяться к выбранным объектам тестирования для проверки планов их тестирования и подтверждения того, что выполненное тестирование адекватно уровню критичности ПС. По отношению к процессу тестирования V&V выполняет контрольную функцию и подтверждает соответствие объектов установленным требованиям.
• Тестирование ПС тесно связано с отладкой и собственно программированием, но охватывает гораздо более широкий круг проблем и участников – программистов, тестировщиков, аналитиков и инженеров по качеству.

«Тестирование Дот Ком, или Пособие по жестокому обращению с багами в интернет-стартапах», Роман Савин, Москва, Дело, 2007. 32 страница:

• QA (Quality Assurance — буквально "обеспечение качества", произносится "кью-эй") — это забота о качестве в виде превентирования появления багов, тестирование — это забота о качестве в виде обнаружения багов до того, как их найдут пользователи. Общее в QA и тестировании заключается в том, что они призваны улучшить ПО, различие между ними — в том, что: QA призвано улучшить ПО через улучшение процесса разработки ПО; тестирование — через обнаружение багов.

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

28.05.2017