Автор: Джеймс Бах (James Bach)
Оригинал статьи
Перевод: Ольга Алифанова

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

Интересная динамика тестируемости

Изменение продукта или повышение стандарта качества снижает эпистемологическую тестируемость. Разница между тем, что мы знаем, и что нам нужно узнать – это первопричина тестирования в принципе. Продукт легче тестировать, если мы уже много знаем о его качестве, или же в случае, когда стандарты качества низки – дел для тестирования остается немного. Это эпистемологическая тестируемость. Следовательно, продукт, который часто меняется, или не допускает ни малейшей ошибки, по определению имеет меньшую тестируемость.

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

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

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

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

Улучшение практической тестируемости также улучшает разработку и поддержку. Если продукт легче тестировать, то его легче поддерживать, дебажить и развивать. На волнах удобства наблюдения и контроля помчит любой корабль.

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

Ключевые слова для анализа тестируемости

Эпистемологическая тестируемость

• Предыдущие знания о качестве. Если мы уже много знаем о продукте, нам потребуется меньше тестирования.
• Толерантность к отказам. Чем более низкий уровень качества требуется, чем больше рисков мы можем себе позволить, тем меньше тестирования необходимо.

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

• Доступность оракулов. Нам нужны способы, чтобы определять все типы проблем, которые имеет смысл искать. Хорошо написанная спецификация – один из примеров таких оракулов, но он не единственный – типов оракулов, которые могут вам помочь, включая людей и инструменты, очень много.
• Значимость оракула. Мы получаем выгоду от оракулов, идентифицирующих важные проблемы.
• Надежность оракула. Мы получаем выгоду от оракулов, которым можно верить длительное время и при множестве условий.
• Точность оракула. Мы получаем выгоду от оракулов, которые упрощают идентификацию специфических проблем.
• Дешевизна оракула. Мы получаем выгоду от оракулов, которые не требуют больших затрат и усилий для приобретения или работы с ними.
• Стабильность и единство пользователей. Чем меньше меняются пользователи, чем меньше среди них разнообразия и разнобоя, тем проще тестировать.
• Осведомленность пользователя. Чем больше мы понимаем о пользователях, чем больше мы идентифицируем себя с ними, тем проще для них тестировать.
• Доступность пользователя. Чем больше мы можем говорить с пользователями и наблюдать за ними, тем легче для них тестировать.
• Доступность пользовательских данных. Чем больше у нас доступа к естественным данным, тем проще тестировать.
• Доступность пользовательского окружения. Доступ к естественным окружениям использования улучшает тестирование.
• Стабильность и единство пользовательских окружений. Чем меньше меняются пользовательские окружения и платформы, и чем их меньше, тем легче тестировать.

Субъективная тестируемость

• Продуктовые знания. Если мы много знаем о продукте, включая его внутреннюю кухню – это сильно улучшает нашу способность его тестировать. Если мы ничего не знаем о продукте, тестирование исследовательским путем позволяет нам быстро обучаться.
• Технические знания. Умение программировать, знание технологии и применимых инструментов, понимание динамики разработки ПО в целом (но не во всех аспектах) упрощает тестирование.
• Доменные знания. Чем больше мы знаем о пользователе и его проблемах, тем лучше мы тестируем.
• Навык тестирования. Наша способность тестировать в целом, очевидно, упрощает тестирование. Релевантные аспекты навыков тестировщика включают экспериментальный дизайн, моделирование, учет элементов продукта, критическое мышление, и тест-фрейминг.
• Вовлеченность. Тестировать проще, когда тестировщик находится ближе к процессу разработки, общаясь и сотрудничая с командой. Если тестировщиков держат вдалеке от разработки, эффективность тестирования серьезно страдает.
• Помощники. Тестировать проще, если нам есть кому помочь. Помощник – это тот, кто не считает себя ответственным за тестирование продукта, но все-таки тестирует или выполняет какую-то полезную для ответственных тестировщиков работу.
• Тест-стратегия. Хорошо спроектированная тест-стратегия может серьезно снизить затраты сил и времени на тестирование.

• Удобство наблюдения. Чтобы тестировать, мы должны быть способны видеть продукт. В идеале мы бы хотели полностью прозрачного продукта, когда любой факт о его состояниях и поведении, а также история этих фактов, нам доступны.
• Удобство контроля. Чтобы тестировать, нам нужна возможность контролировать поведение продукта. в идеале мы можем ввести любые возможные данные и вызывать любое возможное состояние, их комбинацию, или последовательность легко и быстро, если у нас есть такая необходимость.
• Алгоритмическая простота. Для тестирования нам нужна возможность наблюдать и оценивать взаимоотношения между входом и выходом. Чем сложнее и чувствительнее поведение продукта, тем больше связей нам нужно рассмотреть.
• Незабагованность. Баги замедляют тестирование, потому что нам приходится останавливаться и отчитываться о них, или искать обходные пути, или, в случае блокеров, ждать, пока их исправят. Тестировать проще, когда багов нет.
• Небольшой размер. Чем меньше продукт, тем меньше нам надо в нем изучить, и тем меньше риск возникновения багов из-за взаимодействия продуктовых компонентов.
• Делимость. Если различные части продукта можно отделить друг от друга, нам проще концентрироваться на тестировании, исследовании багов, и ретесте после изменений.
• Схожесть (с известной и заслуживающей доверия технологией). Чем больше продукт похож на другие продукты, уже известные нам – тем легче его тестировать. Если продукт использует значительное количество кода другого, доверенного продукта, или основан на заслуживающем доверия фреймворке – это особенно хорошо.

Читать статью полностью