Три термина, которые в вакансиях и статьях путают как синонимы, хотя по ISTQB они описывают разный масштаб работы. На собеседовании разницу спрашивают чаще, чем кажется.
Определение по ISTQB, что это значит на практике, пример из мобильного приложения.
Определение. Процесс в рамках жизненного цикла разработки, который оценивает качество компонента или системы и связанных с ними рабочих продуктов - через статические и динамические методы.
Что это меняет. Тестирование - это не только "покликать интерфейс". Чтение требований на предмет противоречий, статический анализ кода - тоже тестирование, просто без запуска программы.
Пример. Перед тем как открыть баг-трекер, тестировщик читает пользовательскую историю и находит противоречие: в одном пункте "email обязателен", в другом - "можно зарегистрироваться по номеру телефона без email". Это тоже тестирование, хотя код ещё не написан.
Определение. Процесс поиска, анализа и устранения причины отказа. Отладку выполняет разработчик - тестирование только находит отказ и передаёт его дальше.
Что это меняет. Если тестировщик "чинит баг сам", он не занимается отладкой в терминах роли - максимум подсказывает разработчику направление поиска. Разграничение важно для отчётности: кто нашёл дефект и кто его исправил - разные метрики и разная зона ответственности.
Пример. Тестировщик воспроизводит падение приложения при добавлении десятого товара в корзину и прикладывает стектрейс. Разработчик по стектрейсу находит переполнение буфера фиксированного размера и переписывает логику на динамический массив - это отладка.
Определение. Набор действий для оценивания качества компонента или системы. QC направлен на продукт, реактивен - находит и блокирует уже возникшие несоответствия. Тестирование - основной инструмент QC, наряду со статическими методами вроде формальных ревью.
Что это меняет. Вопрос QC - можно ли выпускать именно эту сборку. Решение принимается по фактическому состоянию продукта: сколько открыто дефектов, какой у них severity, какие тесты прошли.
Пример. Релиз-менеджер смотрит на отчёт: два открытых minor-бага, все критичные закрыты, регресс зелёный - принимает решение выпустить билд. Это QC-решение, привязанное к конкретному продукту здесь и сейчас.
Определение. Активности, направленные на уверенность в том, что требования к качеству будут выполнены. QA ориентирован на процесс и проактивен - предотвращает появление дефектов заранее, а не ловит уже случившиеся.
Что это меняет. QA не спрашивает "сколько багов в этом билде", а спрашивает "почему у нас вообще появляются баги такого типа - и что поменять в процессе". Правильная метрика QA - не число открытых дефектов, а тренд: их стало больше или меньше от релиза к релизу.
Пример. После третьего релиза подряд с багами в интеграции с внешней платёжной системой QA-инженер вводит обязательный контракт-тест API перед мержем. Это не чинит текущие баги - это снижает вероятность таких же в будущем.
Определение. Подтверждённое объективными свидетельствами доказательство того, что заданные требования выполнены. Чаще всего это статические методы без запуска кода: ревью требований, дизайна, кода.
Вопрос. Правильно ли мы делаем продукт - соответствует ли он документации и договорённостям.
Пример. Два разработчика проводят код-ревью друг у друга на соответствие принятому в команде стилю и архитектуре. Само приложение при этом ещё не запущено.
Определение. Подтверждение экспертизой того, что рабочий продукт соответствует потребностям заинтересованных сторон. Включает динамические проверки - запуск и тестирование готового продукта.
Вопрос. Тот ли продукт мы делаем - нужен ли он пользователю, решает ли его задачу.
Пример. Бета-версию приложения отдают фокус-группе. Технически всё работает по спецификации, но пользователи жалуются, что оформление заказа занимает семь экранов вместо ожидаемых двух-трёх - продукт технически верен, но неудобен.
Определение. Скоординированные действия по руководству и контролю организации в области качества - самый верхний уровень, объединяет QA, QC, планирование и постоянное улучшение.
Что это меняет. Если в компании есть только QC - проверка перед релизом - и нет QA, число багов от релиза к релизу не падает: гасятся симптомы, а не причина. Управление качеством связывает оба уровня в один цикл.
Пример. Руководство ставит цель снизить число критичных багов в проде на 50% за квартал. Одновременно меняют процесс код-ревью и обучение команды (QA) и ужесточают критерии приёмки релиза (QC) - обе меры работают на одну метрику.
Правильно ли мы делаем продукт?
Статические проверки: ревью требований, дизайна, кода - без запуска системы.
Тот ли продукт мы делаем?
Динамические проверки: запуск и тестирование готового продукта, обратная связь пользователей.
QA охватывает весь процесс. QC внутри него оценивает готовый продукт. Тестирование - главный, но не единственный инструмент QC.
| Уровень | Что делает | Пример действия |
|---|---|---|
| QA | Выстраивает процесс, чтобы дефектов было меньше | Обязательное ревью требований перед разработкой |
| QC | Оценивает, соответствует ли конкретный продукт критериям качества | Решение, можно ли релизить билд с открытыми minor-багами |
| Testing | Основной инструмент QC - находит несоответствия, запуская систему | Прогон регресса перед релизом |
Читаешь описание действия, определяешь, к какому уровню оно относится.
Команда вводит обязательный код-ревью перед мержем любого пул-реквеста.
Это QA. Правило меняет процесс для всех будущих изменений, а не оценивает конкретный уже готовый продукт - это проактивная мера.
Перед релизом менеджер смотрит на количество открытых критичных багов и решает, отправлять билд в прод или нет.
Это QC. Решение принимается по фактическому состоянию конкретной сборки здесь и сейчас - реактивная оценка продукта.
В компании вводят единый обязательный шаблон тест-кейса для всех проектов.
Это QA. Единый шаблон - изменение процесса на будущее, направленное на то, чтобы тест-кейсы в принципе были полнее и понятнее.
Тестировщик прогоняет регресс новой версии приложения и находит пять дефектов.
Это QC. Тестирование - основной инструмент контроля качества: оно оценивает конкретный, уже собранный продукт.
После серии похожих багов отдел качества проводит тренинг для разработчиков по написанию юнит-тестов.
Это QA. Тренинг снижает вероятность появления похожих дефектов в будущем - это работа с процессом, а не с конкретным багом.
Перед сдачей билда в тестирование инженер сверяет сборку с чек-листом критериев готовности.
Это QC. Проверка конкретной сборки на соответствие критериям - оценка готового продукта перед следующим этапом.
Определяешь, на каком звене цепочки находится описанная ситуация.
Разработчик неправильно понял требование и по невнимательности написал условие "if age > 18" вместо "if age >= 18".
Это ошибка. Само действие человека - неверное понимание требования и невнимательность при письме кода - источник всей цепочки.
В коде метода авторизации осталось условие "if age > 18" вместо ">=", но никто из пользователей 18 лет ещё не пытался зарегистрироваться.
Это дефект. Неверное условие уже сидит в коде, но пока никто с граничным значением не столкнулся - дефект спящий, отказа ещё не было.
Пользователь 18 лет попытался зарегистрироваться и получил отказ в доступе, хотя должен был пройти проверку.
Это отказ. Дефект проявился при выполнении - конкретный пользователь увидел неверное поведение системы вживую.
Тестировщик по невнимательности скопировал старый тестовый сценарий и забыл поменять в нём ожидаемый результат.
Это ошибка. Источник цепочки - человеческое действие, и ошибиться может не только разработчик, но и тестировщик при подготовке сценария.
После обновления библиотеки платежей приложение крашится при попытке оплаты картой "Мир".
Это отказ. Приложение уже наблюдаемо ведёт себя неправильно во время выполнения - крашится вместо того, чтобы провести оплату.
В требованиях осталась старая формулировка комиссии, которую забыли обновить после смены тарифа - код по этой формулировке ещё не писали.
Это дефект. По ISTQB дефект - это несоответствие в любом рабочем продукте, не только в коде: устаревшая формулировка в требованиях - тоже дефект, просто в другом артефакте.