“Техническая база” для менеджеров продукта — часть 10— Тестирование

9 min readAug 5, 2021

Записи из курса по technical product manager; позиционируют как: “Говори с разработчиками на одном языка”.

Это 10я часть из серии, в ней собраны: термины, процесс тестирования, классификация тестов, дизайн тестов, и всякое другое. Получилось очень много и сочно.

Тестирование

Тестирование — проверка на соотв. продукта требованиям (ТЗ) и валидация. Имеет 2 компонента:
верификация: ориентация на процесс, проверка по чек-лист (документации), объективность в оценке (да/нет).
валидация: продуктовый подход (это нужно рынку? пользователями удобно? решает потребности?), сопоставление с ожиданиями бизнеса, субъективность в оценке (ок или мимо кассы).

Отличный QA: помнит о бизнесе и фокусируется на валидации (ньюансы продукта, где бизнес ценность, решает ли продукт проблемы заказчика и клиента).

Quality assurance vs. Quality control vs. Testing

QA (проверка): обеспечение качества всего процесса тестирования; от начала работы над задачей до фиксов и изменения требований по результатам тестов (если нужно);

QC (контроль): проверка качества для определенного продукта; тест кейсы полностью покрывают требования;

Testing (тестирование): проход по чек-листу тестов, проверка базовых тест кейсов;

Процесс тестирований включает оформление документации по тестам, уровень покрытия тестами продукта и метрики.

Что ждать (требовать) от QA команды?

Надёжно проверены все наиболее важные для бизнеса флоу;
Найденные проблемы качественно задокументированы;
Для покрытия имеющегося функционала разработаны релевантные тест-кейсы;
Тестовая документация приведена в соответствие с актуальным
состоянием продукта.

Метрики QA: defect density = кол-во дефектов / кол-во модулей
помогает оценить самые проблемные места в продукте.

Баг — реализованная в коде ошибка, которая приводит к отклонению фактического поведения системы от ожидаемого; реальность vs. ожидание.

Причины возникновения: некорректные требования, ошибки проектирования системы, низкое качество кода, сложная бизнес-логика, горящие сроки (пушим).
Главная — частые изменения требований (оч сильно страдаю этим).

Что мы делаем с багами?
Оцениваем их Severity — влияние бага на систему и Priority — приоритет в разработке; есть удобная матрица для оценки.

SDLC процесс

Обычный процесс выглядит так:
Требования — Дизайн — Разработка — Тестирование — Запуск.

Но в эту схему нужно добавить Идею (Vision) вначале и Поддержку в конце, т.к. (весомый аргумент).

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

Чем раньше подключить QA — тем ниже цена ошибки:(поправить на уровне ТЗ легче, чем после написания кода, и тем более выливки на прод).

В чем задача тестирования?
Найти баги в продукте или подтвердить отсутствие багов?
Таки найти максимум багов и грязи!

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

Из чего состоит работа QA?

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

Как понимать, что тестировщики справились?

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

Классификация тестирования:

Подходы:

статическое — без выполнения программы (например интерфейс, на уровне кода, ещё как-то);
динамическое — в ходе работы с программой (функц. и не функц.);
негативное — заведомо не валидные данные; проверка отказоустойчивости системы и ошибок;
позитивное — берем валидные значения/данные; проверка правильности работи функций;
ручное — наши ребята, основной сквад;
автоматизированное — дорого, но не всегда себя окупает; нужно делать кейсы, которые дают максимум выхлопа. Критерий целесообразности автоматизации — функционал важный (например процессинг платежей, вход )и меняется редко (чтобы не переписывать кейсы) и/или тратит много времени живых QA.

Уровни тестирования:

Unit тесты — пишут программисты на свой код; в процессе разработки фичи;
Integration тесты — на связь с другими модулями;
System тесты — тестирование всей системы по функциям;
Acceptance тесты — принимаем функции в продакшн или нет;

Color box: по доступу QA к коду.
white — может узнать, какая реализация в коде (методы, классы, и тд); как разработчик;
black — ничего не знаем о системе внутри; как пользователь;
grey —что-то по средине;

Alpha — на сторона разработки (внутри команды);
Beta — с привлечением пользователей, на их стороне; окончательные тесты (на рынке).

По степени готовности документации: тестирование по документации (всё описано, есть чек-листы) или интуитивное (на лету).

Виды тестирования:

smoke — базовая проверка, что система работает;
sanity — чуть глубже проверяем некоторые элементы системы;
integration — проверка взаимодействия модулей (платежи и тд);
regression — опишу отдельно;
acceptance — прием по требованиям;
perfomance — нагрузка, стресс, безопасность, локализация и тд.

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

Когда какой применять?

Smoke — после выхода новой версии сразу;
Sanity — после выхода стабильной версии сразу;
Integration — после Санити;
Regression — перед аксептансом задачи, убедиться что ничего не поломали;
Acceptance — перед релизом — все новое работает и можно на прод;
Performance Testing: Load; Stress; Volume — параллельно интеграции;
Security Testing — параллельно регрессии;
Compatibility Testing — параллельно интеграции;
Localization Testing — параллельно интеграции;

Требования к тестированию:

Тут тоже может быть много вариантов классификации, по разным критериям. Но важно помнить, что есть требования к требованиям:

Трассируемость — соотвествие бизнес требований к технической реализации; последоватлеьный переход от бизнеса до дев и тестирования.

Software Requirements Specification (SRS)

Целое казино требований (не отстреливаю в чем разницу, най буде)

PRD — Product Requirements Document
BRD — Business Requirements Document
MRD — Market Requirements Document
SRS — Software Requirements Specification

Декомпозиция требований: делим SRS на эпики -> фичи -> user story
-> задачи (в формате user story).

User story — это короткая формулировка намерения, описывающая что-то, что система должна делать для пользователя (было уже). Тут есть апгрейд, требования к story (INVEST схема):

I независимая — атомарный объект разработки и теста, не зависит от других;
N обсуждаемая — команда должна придти к решению к каждой стори (на митинге);
V полезная — добавляет ценность для бизнеса / пользователя;
E оценимая — с оценкой команды (по времени);
S небольшая — содержит одну функцию или элемент;
T тестируемая — можно протестировать;

Регрессия (regression test)

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

Это бывает нужно когда:

баг фикс: в общем любой изменение;
добавилась новая фича: которая может зацепить другие функции;
поменялись настройки конфигурации: обновили версию библиотеки или API;
большие изменения в проекте;
фиксы в производительности или рефакторинг кода;

Когда оно реально нужно?

Внесены существенные изменения функционала;
Было исправлено большое кол-во дефектов (и вылили сразу);
Конфигурация системы была каким-то образом изменена.
В ходе подготовки к релизу.

Структура Test Case:

Дизайн тест кейсов:

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

Техники тест-дизайна применяются для:

системного подхода к тестированию;
оптимизации затраченных усилий, времени, ресурсов;
для формирования необходимого и достаточного
тестового покрытия;

(ECP) Разбиение на классы эквивалентности: разбиваем зону тестирования на группы, с схожими элементами. Внутри классов, система ведёт себя одинаково.

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

(BVA) Граничные значения: на основе предпосылки, что баги водятся на границах. Граничные значения — это значения на границах классов эквивалентности.В этих местах резко увеличивается возможность обнаружения ошибок, т.к. меняется поведение системы.

В этом методе не нужен полный перебор значений (комбинаторная сложность), только выбранные значения, которые реально могут вызвать баги.

Причина — Следствие: когда, при добавлении новых функций в программу, что-то перестает работать и нужно узнать почему, стоит использовать fish диаграмму, чтобы разложить в причины.

Таблица решений: строить таблицу соотв. между условием и результатам (типа булева матрица, с true и false), где есть все варианты поведения системы.

Диаграмма переходных состояний: отражает переходы в системе. Она описывает:

возможные состояния обрабатываемые системой;
переход из одного состояния в другое (transition);
события, которые порождают переход между состояниями;
действие возникающее в результате перехода (result);

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

Пример: АТМ акак банкомат.

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

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

матрица пересечения параметров / упрощение

Use Case Testing: на основе сценариев использования продукта.

Use Case (вариант использования, прецедент) — это сценарная техника описания взаимодействия. С помощью Use Case могут быть описаны требования к взаимодействию между пользователями и системой, либо к взаимодействию систем между собой; (Покупатель-Продавец, Адресант-Почтовый клиент, Браузер — Web-сервер).

Use Case — описывает случай использования системы.

Test Case — описывает случай тестирования системы.

(EG) Предугадывание ошибки:

Примеры: деление на ноль, ввод пробела в текстовые поля, не вводя
каких-либо символов, нажатие на кнопку «Submit» без заполнения
обязательных полей, загрузка файла превышающего максимально
допустимый размер, загрузка пустого файла.

Исследовательское тестирование: похоже на HADI циклы, когда эмпирически ищем ошибки. Для более опытных QA.

(ISTQB) Тестирование на основе чек-листов: при тестировании по чек-листам тестировщик проектирует, реализует и выполняет тесты, покрывающие тестовые условия, указанные в чек-листе.

Чек-лист пишут на основе: опыта, знаний системы, приоритеты.

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

7 (священных) принципов тестирования

Тестирование показывает наличие дефектов, а не их отсутствие (находит баги, они есть всегда, чем эффективнее qa — тем больше багов найдено);
Исчерпывающие тестирование невозможно;
Раннее тестирование: чем раньше нашли баг, тем дешевле его исправить (от планирования задач с QA, до самой разработки);
Скопление дефектов (приницп Паретто): 20% функций (кода), содержат 80% багов;
Парадокс пестицида: со временем глаз замыливается, перестаем видеть баги;
Тестирование зависит от контекста: лендинг и банк/ракету тестируют по разному;
Заблуждение об отсутсвии ошибок: валидация vs варификация;