- Что такое статическое тестирование?
- Практика статического тестирования
- Динамическое тестирование
- Что дает динамическое тестирование
- Разница между динамическим и статическим тестированием — таблица
- Размышления о деньгах и распределении сил
Допустим, у нас есть приложение на этапе минимально рабочего прототипа (MVP). После написания начальной документации, первых use-кейсов, и архитектурного плана, дальше есть два пути. Тестировать приложение сразу после создания первого работающего MVP-прототипа, или же потратить больше времени на тщательную QA-проверку документации, архитектурного плана, и первых версий кода. Эти два пути, собственно, описывают два подхода к тестированию — динамический и статический. Далее разберемся, где какой подходит, и как это все сочетается.
Что такое статическое тестирование?
Статическое тестирование — не требует выполнения кода; это его суть. При этом оно может быть ручным или автоматизированным (например автоматические чекеры синтаксиса).
Статические тесты начинаются на ранних этапах цикла разработки. Такие тесты незаменимы при проверке MVP. Иногда даже не нужен компьютер — просто вручную проверяются самые базовые функции.
Техники статического тестирования включают, например, “тестирование” базовой документации приложения; поверхностную проверку кода; также документации по дизайну; спецификации функций; и требований по основным функциям.
Помимо стандартного процесса визуальной проверки, где уже будут видны промахи в документации, в технических требованиях, и в архитектуре кода, проводится программный статический анализ кода.
Тестировщики делают статический анализ, чтобы найти:
- Так называемый мертвый код — выполнение которого никак не влияет на приложение
- Незадействованные переменные
- Некорректный синтаксис
- Переменные с неизвестными значениями
- Бесконечные циклы
Практика статического тестирования
Простая проверка, выполнены ли заданные цели, use-кейсы по архитектуре, и проверка самых важных частей кода.
Этапы статического тестирования:
- Проверка требований и написание скриптов. Описываются все действия пользователей (включая вводы и выводы). Чем лучше детализированы use-кейсы, тем лучше — надежнее тест-кейсы.
- Верификация функциональных требований. Проверяется, что требования “покрывают” все важные элементы. Особое внимание уделяется базам данных, интерфейсу, далее требованиям по аппаратной и программной части, и сети.
- Оценка архитектуры. Оценка всех процессов на бизнес-уровне. Особое внимание — правильности локации серверов, также сетевые диаграммы, протоколы, балансировка нагрузки, доступность баз данных; затем оценка тестового окружения.
- Верификация прототипов, и, особо в последнее время, пропорций экрана в мобильных приложениях. Проверяются требования и use-кейсы.
- Валидация т.н. “field dictionary”. Каждое поле ввода в интерфейсе пользователя подробно описывается, и генерируются соответствующие тест-кейсы.
Статическое тестирование — это о самых важных вещах в приложении, «опорных». Поэтому составляются пошаговые чек-листы, чтобы не упустить ничего важного.
Динамическое тестирование
Динамическое тестирование подразумевает выполнение кода при тестировании. Проверяется поведение приложения и функции, оценивается как задействованы память и процессор, и в целом производительность. QA-команда убеждается, что софт работает в соответствии с use-кейсами, ориентированными на бизнес-цели.
Динамическое тестирование выполняет код при выполнении — и сверяет результаты с ожидаемыми. Такое тестирование могут проводить на любом этапе жизненного цикла, и оно может быть как по типу черного ящика, так и белого ящика.
Существуют три способа динамического тестирования.
- Юнит-тестирование. Все модули тестируются QA-командой (хотя традиционно это задача разработчиков).
- Интеграционное тестирование. Оценка связности работы всех частей приложения.
- Системное тестирование. Тестируется вся система как целое — выполнены ли требования в спецификациях.
Разумеется, тестирование безопасности и производительности динамические.
Что дает динамическое тестирование
Динамическое тестирование имеет дело уже с полностью функциональным продуктом. QA-инженеры находят проблемы в логике и узкие места в инфраструктуре приложения, которые не были заметны на этапе написания проектной документации.
- Динамическое тестирование предполагает тщательное исследование всей функциональности приложения, что обеспечивает качественные результаты QA.
- Это, в идеале, хорошо структурированный процесс, рассматривающий приложение с точки зрения пользователя
- Динамическое тестирование находит сложные дефекты, невидимые при поверхностном анализе кода, во время статического тестирования
- Динамическое тестирование можно (и нужно) автоматизировать
Разница между динамическим и статическим тестированием — таблица
Итак, статическое тестирование анализирует код, требования, и дизайн, а динамическое — функциональность в целом, нагрузку на память и процессор, производительность в целом.
| Статическое тестирование | Динамическое тестирование |
| Без запуска приложения | На работающем приложении |
| Предназначено для предотвращения багов | Находит и фиксит баги |
| Проверяет код и документацию | Сообщает о найденных багах и узких местах |
| Составляется чек-лист и выполняется проверка | Выполняются стандартные тест-кейсы |
| До компиляции | После компиляции |
| Низкая стоимость поиска и устранения дефектов | Высокая стоимость |
| ROI (финансовая эффективность затрат на QA) высокая, потому что дефекты находят вовремя | ROI низкая, потому что дефекты находят уже после разработки |
| Нужно провести много митингов | Намного меньше митингов |
Размышления о деньгах и распределении сил
На вопросе финансовой эффективности возможно стОит остановиться подробнее. Бизнес-интересы превыше всего, как известно. Какова стоимость статического и динамического тестирования?
С точки зрения управления стоимостью, оценить работу QA-команды можно по:
- Количеству найденных дефектов
- % дефектов которые пофиксили
- % отклоненных дефектов
- Покрытию требований
- Автоматизации тестов
Исходя из этого задаются KPI для тестировщиков.
По статистике, больше всего тестовых сьютов — на этапе раннего статического тестирования. В небольших проектах хорошо структурированное статическое тестирование составляет примерно две трети объема QA-операций. Именно тогда устраняются почти все проблемы с кодом — не привлекая “сеньйоров” в большом количестве, что разумеется, удешевляет процессы. Хорошей практикой является “разделение“ процесса на многие простые этапы. Далее проводится проверка вводов/выводов. Это экономит затраты времени (и денег) для дальнейших, более “дорогих” этапов.
Остальной объем тестов, примерно треть (на небольших проектах) составляет динамическое тестирование, обычно автоматизированное. Если архитектура продуманная, а команда опытная, то особых проблем возникнуть не должно. Автоматизируются сперва стандартные пользовательские действия.
Статическое тестирование не влияет на user experience; проверка кода и документации не дает полного представления о дизайне приложения, и главное его юзабилити. При этом, самые критические дефекты (из практики небольших проектов) это именно дефекты дизайна, и они находятся только динамическим тестированием. Если у продукта лишь несколько функций, доля динамического тестирования будет больше.
