Понятия Quality Assurance, Quality Control, Testing.

QA — это процесс управления, направленный на предотвращение дефектов и улучшение процессов разработки продукта для обеспечения высокого уровня качества. Цель QA — не допустить появления дефектов на всех этапах разработки.

Задачи QA: Разработка стандартов, процедур, и методологий для того, чтобы продукт соответствовал требованиям. QA включает такие методы, как аудит процессов, создание документации, а также контроль за выполнением стандартов.
Пример: Внедрение agile-подходов или автоматизированного тестирования, чтобы снизить количество ошибок на стадии разработки.

QC — это процесс проверки, направленный на выявление дефектов в готовом продукте. QC занимается проверкой того, что продукт соответствует стандартам качества и требованиям.

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

Тестирование — это часть QC, которая включает в себя практическую проверку программного обеспечения для выявления багов, дефектов или ошибок.

Задачи тестирования: Проверка всех функциональных и нефункциональных аспектов ПО.
Пример: Ручное тестирование интерфейса пользователя или автоматизированное тестирование API.

Отличия:

QA фокусируется на процессах создания продукта и предотвращении дефектов на ранних этапах.
QC концентрируется на проверке готового продукта и исправлении найденных проблем.
Тестирование — это инструмент QC для выявления дефектов в продукте.

Таким образом, QA работает с процессами, QC проверяет результаты, а тестирование — это один из методов контроля качества продукта.

Тестирование на основе моделей.

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

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

Что такое тестовые модели.

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

Аналогично другим моделям, они должны быть в меру точны, адекватны (соответствовать реальности), универсальны (могут быть использованы неоднократно и для разных задач) и целесообразно экономно. Последнее очень важно: не стоит применять MBT ради галочки: важно понимать цель и ожидаемый результат такого подхода. Если создание и поддержание модели занимает больше времени, чем нахождение и исправление проблем без нее, а сам продукт не планируется поддерживать в долгосрочной перспективе, лучше сконцентрироваться на более доступных методах обеспечения качества.

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

Плюсы и минусы тестовых моделей.

Как и любой подход, MBT (Model Based Testing) имеет преимущества и недостатки.

Плюсы MBT.

Использование тестовых моделей развивает аналитическое мышление за счет постоянного анализа тестируемой системы. Лучший способ развить этот тип мышления — применять его для решения задач, например, для создания абстрактной схемы продукта или его компонента.
Моделирование улучшает понимание системы как у того, кто модель создает, так и у команды, которая ревьюит и использует ее. Приятный бонус: спустя некоторое время благодаря модели можно научиться предугадывать поведение системы в тех или иных обстоятельствах.
Тестовую модель поддерживать легче, чем много тест-кейсов (за счет абстрактности и того, что кейсов много, а модель одна).
MBT позволяет взглянуть на систему (или ее часть) в целом и увидеть неочевидные зависимости.
Создание и поддержание тестовой модели способствует синхронизации понимания работы системы внутри команды. Это очень полезно для избегания неоднозначных ситуаций и решения спорных вопросов «на берегу» до начала разработки.
Благодаря математической подоплеке наличие модели позволяет автоматизировать нахождение оптимального пути, пути с задействованием всех состояний и т.д. Кроме того, тестовую модель можно использовать как основу для проектирования автотестов.
Несомненно, модель делает процесс адаптации новичка в проект более эффективным. «Лучше один раз увидеть, чем сто раз услышать» тут как раз работает. Кроме того, у нового члена команды могут возникнуть вопросы, которые не пришли в голову команде, или другие участники процесса разработки могут вспомнить что-то важное, презентуя модель новичку.
Тестирование на основе моделей прекрасно подходит для долгосрочных проектов, где большое число тест-кейсов затруднит понимание принципов работы системы, а простая и наглядная схема, наоборот, упростит его.

Минусы MBT.

Если в модели есть ошибка, это может привести к фундаментальному недопониманию внутри команды. Именно поэтому важен следующий пункт.
Желательно, чтобы в моделировании (или ревью модели) участвовала вся команда. Во-первых, это позволяет исключить недопонимания, во-вторых, активирует силу коллективного разума.
Как и в случае с тестовой документацией, надо не лениться, поддерживать и регулярно обновлять модель. Если на это нет времени и / или недостаточно знаний, стоит поставить под сомнение целесообразность использования тестовых моделей в проекте.
Иногда создание модели занимает больше времени, чем написание простого чек-листа. Особенно это актуально для больших и многокомпонентных систем: если модель начинают создавать после того, как внутри системы уже существует куча не до конца понятных зависимостей, это может стать довольно долгим процессом.
Использование тестовых моделей требует определенных навыков абстрактного мышления вкупе с внимательностью к мелочам. Не стоит отключать критическое мышление даже по отношению к собственным трудам.

Как начать использовать тестовые модели.

Определить наиболее удобный для восприятия (собой, командой или бизнес-оунерами) вид схемы (таблица, диаграмма, граф и тд.). Важно, чтобы те, для кого делается модель, легко «читали» ее — это основная задача.
Декомпозировать систему, которую собираемся описать, на модули (руководствуясь приоритетами, функциональностью, логикой или другими критериями). Скорее всего, система многокомпонентная. Не стоит пытаться описать все и сразу.
Определить для отдельно взятого модуля возможные состояния системы, действия пользователя, переходы между состояниями, а также начальные и конечные точки взаимодействия (т.н. точку входа и точку выхода).
Схематично нарисовать «золотой путь», то есть идеальный вариант взаимодействия пользователя и системы.
Расширить этот путь для модуля так, чтобы помимо идеальных случаев модель включала и иные варианты: что может пойти не так на каждом шаге.
Не забыть о влиянии каждого состояния и перехода на другие части системы. Это особенно актуально, если создается не первая модель для тестируемого продукта.
Решить, будут ли объединяться модули в одну схему или хранить их по отдельности.
Поделиться полученной моделью с командой. Можно презентовать, отдать на ревью или пригласить коллег на ограниченную по времени сессию мозгового штурма, чтобы дополнить то, что можно забыть или упустить.
Поддерживать! Не забывать актуализировать и обновлять модель, — особенно когда добавляются новые компоненты, связи или даже новые модели.

Метрики тестирования.

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

Предназначение.

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

Для чего нужны метрики?

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

Метрики: как выбрать и внедрить.

Если по написанному выше ещё не стало понятно, что цифры ради цифров не нужны, придётся повториться: не следует пытаться внедрить какую-то метрику просто потому, что кажется логичной или полезной. Всегда стоит идти от задачи, например:

Согласовать ожидания руководства, зафиксировать, а потом уже думать: какими показателями можно оценить именно эту цель?
Когда хочется что-то улучшить в своей работе. Что именно? Определить, какого результата нужно достигнуть, подумать о его измерении:

Как оценивать прогресс в достижении этого показателя?
Как измерить достижения на уровне процесса, пока ключевой показатель, возможно, не меняется?

Если нужно решить какую-то проблему, непосредственно в команде тестирования или на проекте в целом:

Как оценивать эту проблему, в чём её можно измерить?
Какие могут быть предпосылки для этой проблемы, очевидные или кажущиеся совсем нелогичными?
Как можно обнаружить корень этой проблемы, или «узкое горлышко»?

Если нужно обосновать что-то своему руководству, и уже исчерпаны все аргументы:

Как проиллюстрировать наличие проблемы?
Как показать пользу от предлагаемого решения? Максимально осознанно пройтись по этому списку вопросов. Подключить коллег через совместный брейншторм или опросы. Определить, что нужно измерять, не доходя до уровня конкретных чисел и метрик. Сначала нужны обобщённые названия метрик, например:
Срывы сроков (для обработки жалобы от РМа).
Причины срыва сроков (чтобы найти решения проблеме).
Низкое качество тестирования (для решения жалоб от техподдержки).
Низкое качество кода (чтобы конструктивно пожаловаться руководителю разработки).
Отчетность для РМа по качеству продукта (по которой он сможет принимать взвешенные решения).

Только когда появится список неуточненных метрик, можно задуматься, как их измерять. Сначала — цели, потом — инструменты!