Привет, коллеги 👋
У многих в голове тестирование начинается с момента, когда уже есть кнопка, база данных или хотя бы что-то, что можно потыкать.
А потом приходит глава 3 ISTQB и говорит:
нет, баги можно ловить ещё раньше 😅
Глава 3 посвящена СТАТИЧЕСКОМУ ТЕСТИРОВАНИЮ
Статическое тестирование это когда мы проверяем рабочие продукты без выполнения кода.
Представьте стройку. Если вы заметили ошибку в чертеже до заливки фундамента, вы красавчик.
Здесь та же логика.
📄 Статически мы можем проверять:
• требования
• дизайн
• код
• тест-кейсы
• документацию
То есть статическое тестирование, это не только ревью кода. Это вообще про любые артефакты, где можно найти косяк до запуска системы.
🤔 Чем оно отличается от динамического?
Динамическое тестирование это когда система уже работает и мы проверяем её в действии.
Статическое, это когда ещё ничего не запустили, но уже можем найти:
• противоречия в требованиях
• дыры в логике
• странные условия
• кривые тест-кейсы
• подозрительный код
И вот в этом главная польза главы.
Отдельно в экзамене ISTQB есть вопросы про процесс рецензирования: какие там роли, какие бывают виды review и от чего зависит его успех.
Глава небольшая, но очень практичная. Эту тему и остальные я описал в своем конспекте, приложу в комментариях к этому посту
Если упростить главу до одной мысли:
лучший баг, это тот, который нашли до запуска.
⚡️ Подписаться
#ISTQB