Lesson 48

Уже часть третья.

Слово Канеру:

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



Главная цель этой части - показать систему классификации техник тестирования. Мы называем это пятью измерениями тестирования. Любой вид тестирования описывается в терминах пяти измерений:

- Тестировщики. Те, кто занимается теcтированием. Например, пользовательское тестирование фокусируется на тестировании силами целевой аудитории, теми, кто обычно использует продукт.
- Покрытие. То, что тестируется. Например, в функциональном тестировании мы тестируем каждую функцию.
- Потенциальные проблемы. Почему мы тестируем (какие риски мы проверяем). Например, тестирование на ошибку с максимальными значениями.
- Активности. Как вы тестируете. Например, исследовательское тестирование.
- Оценка. Как определить, что тест прошел или сработал. Например, сравнение с известным правильным результатом.

Также мы детально описали несколько техник в этой части и понимание того, как использовать еще несколько других, но наша главная цель - объяснить систему классификации.

Во всех тестах есть все пять измерений. Техника тестирования фокусирует ваше внимание на одном из пяти измерений, обходя другие. Вы могли бы комбинировать технику, которая сфокусирована на одном измерении с техникой, которая сфокусирована на другом для достижения требуемого результата. Вы могли бы назвать результат этого действия новой техникой тестирования (некоторые так и делают), но мы думаем, что процесс мышления более полезен, чем добавление новых имен в постоянно расширяющийся перечень непоследовательно определенных техник, используемый в нашей области. Наша схема классификации поможет комбинировать сознательно и вдумчиво.

Задачи тестирования часто концентрируются на одном измерении, но мы работаем во всех пяти. Например:

- Кто-то может попросить вас сделать функциональное тестирование (тщательно поверить все функции). Это говорит вам, что тестировать. Вы все еще должны решить, кто будет тестировать, какие типы багов вы будете искать, как тестировать каждую функцию, и как вы будете определять, что в программе есть ошибка.

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

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

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

Вот пример того, как техника может быть многомерной: если кто-то вас просит провести тестирование основанное на требованиях, он говорит тебе о комбинации трех идей:

- Покрытие: мы тестируем все, что описано в требованиях.
- Потенциальные проблемы: тестировать в направлениях, на которых эти требования могут быть не выполнены.
- Оценка: тесты будут спроектированы так, что спецификация будет определять ожидаемое поведение программы.

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

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

Сохраняя во время тестирования в голове все пять измерений, вы можете подобрать лучший выбор комбинаций. Например, в бета-тестировании вы могли бы жестко не оговаривать одно или несколько измерений. Вы могли бы не определять способ оценки результатов или последовательности действий. Однако мы предлагаем, чтоб вы сознательно сделали этот выбор, приняв саму технику, а не сосредотачиваясь на каком-либо из аспектов.

Ремарка: неоднозначное понимание тестирования по требованиям дает нам пример главной проблемы в разработке ПО.