“Техническая база” для менеджеров продукта — часть 10— Тестирование
Записи из курса по 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 варификация;
Другие части
- “Техническая база” для менеджеров продукта — часть 1 — общие понятия;
- “Техническая база” для менеджеров продукта — часть 2 — frontend;
- “Техническая база” для менеджеров продукта — часть 3 — backend;
- “Техническая база” для менеджеров продукта — часть 4 — базы данных;
- “Техническая база” для менеджеров продукта — часть 5 — архитектура продукта;
- “Техническая база” для менеджеров продукта — часть 6 — сеть, информационная безопасность и СI/CD;
- “Техническая база” для менеджеров продукта — часть 7 — GIT, системы контроля версий;
- “Техническая база” для менеджеров продукта — часть 8 — Документация (техн, прод);
- “Техническая база” для менеджеров продукта — часть 9 — Аналитика;
- тут
- “Техническая база” для менеджеров продукта — часть 10 — Mobile;