Переходя все границы... (Алексей Баранцев, SQADays-11) — различия между версиями

== Примечания и отзывы ==
<!-- <blockquote>[©]</blockquote> -->

<references/>



[[Категория:Тестирование]]
[[Категория:SQADays-11]]
{{stats|disqus_comments=0|refresh_time=2020-07-06T20:28:4207T23:16:19.316440780871|vimeo_comments=0|vimeo_plays=3334|youtube_comments=0|youtube_plays=489}}490}}

Версия 20:16, 7 июля 2020

Аннотация

Докладчик

Алексей Баранцев

Анализ границ — эту технику каждый тестировщик осваивает, наверное, самой первой. Прочитать спецификацию, отделить «хорошие» данные от «плохих», сделать тесты для тех и для других, а также проверить границы. Выделить классы эквивалетности, взять по одному представителю из каждого, а также проверить границы. Это знакомо каждому тестировщику.

Но в действительности применение этой техники вовсе не так просто, как может показаться на первый взгляд, потому что в реальном мире разных «границ» куда больше, чем описано в любой, даже самой хорошей спецификации. Причина этого в том, что в реальной программе существует множество *технологических* границ, о которых аналитик может даже не подозревать. Это максимальные и минимальные числа в различных представлениях, максимальные допустимые размеры строк или полей в базе данных, максимальная и минимальная представимая дата, точность вычислений и другие ограничения. Иногда они возникают из-за особенностей реализации — алгоритмов или архитектурных решений, которые выбрали ваши разработчики. Иногда они определяются внешними используемыми библиотеками и платформой (программной и/или аппаратной), на которой реализована ваша программа.

Что будет, если пользователь, случайно или намеренно, пересечёт такую *технологическую* границу — введёт слишком большое число или слишком длинную строку? Должен ли тестировщик пытаться это выяснить? Или может быть достаточно предупредить пользователей, чтобы они не вводили «плохие» данные, а кто ввёл — мы ответственности не несём? А если всё таки мы решили, что тестировщику следует пытаться всё это проверить — как искать эти границы, если они нигде не описаны? И можно ли попасть в область, находящуюся «за технологической границей»? А если можно — нет ли там, дальше, ещё каких-нибудь границ? Как далеко это может завести тестировщика?

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

Видео

Слайды

Примечания и отзывы

Plays:3824   Comments:0