Автор: Дэн Эшби (Dan Ashby)
Оригинал статьи
Перевод: Ольга Алифанова

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

Типы тестирования или типы рисков?

Когда вы описываете свое тестирование кому-то, кто не знаком с профессией (да даже если знаком), говорите ли вы о типах тестирования, которое проводите? Или же вы рассказываете о рисках? И о том, и об этом? Ни о чем из перечисленного? В чем тут разница?

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

Типы тестирования

Люди довольно часто обсуждают типы тестирования. К примеру, функциональное, регрессионное, тестирование производительности, юзабилити, доступности, безопасности, интеграции, и так далее, и тому подобное.

Все эти типы тестирования описывают тестирование по отношению к определенным интересующим нас областям. Но если задуматься, то эти типы просто описывают тестирование, особо концентрирующееся на тест-типах продуктовых рисков.

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

"Исследовательское тестирование" и "Скриптовое тестирование" – это подходы к тестированию, а "черноящичное" или "белоящичное" – техники тестирования, поэтому их я сюда не включаю.

Типы рисков

Представьте, что вы что-то тестируете. Подумайте о единице тестирования – тест-идее, которая у вас, вероятно, есть. Что движет этой идеей?

Тестируя ПО, мы связываем наши тесты с каким-то типом продуктового риска.

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

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

"XYZ-тестирование" – это тестирование, сконцентрированное на рисках XYZ. Как я уже говорил выше, рассказывая о типах тестирования, тип тестирования – это тестирование, сконцентрированное на определенном типе риска.

Но вот в чем подвох…

Знаете ли вы, что существует более сотни различных типов продуктовых рисков? Некоторые из них мы и не подумаем называть "типами тестирования".

Если бы я попросил вас назвать максимальное количество типов тестирования, вы бы отлично справились, назвав 15-20. Я пробовал просить об этом команды в разных компаниях и внутри тест-сообщества, и обычно люди сходу называют около 15. Однако если бы я попросил вас назвать различные типы продуктовых рисков, то точно знаю, что вы назвали бы больше. Спрашивая о типах продуктовых рисков те же самые группы людей, вспомнивших о 15 типах тестирования, я получал около 50-60 ответов, прежде чем заканчивалось отведенное время. Они бы и больше назвали.

Вот ряд примеров:

• Допустим, мы работаем над мобильным приложением. Тогда мы бы тестировали, насколько сильно оно нагружает батарею устройства. Слышали ли вы о "тестировании на расход батареи" как о типе тестирования? Нет… Однако это тип продуктового риска, который непременно нужно исследовать! Другой приме риска связан с изменениями в типе мобильной связи, а еще – риск интеграции с определенными настройками мобильной операционной системы… Кто-нибудь слышал, чтобы люди говорили об этих рисках как о "типах тестирования"? В мобильных приложениях множество рисков, которые нуждаются в тестировании, но о которых не говорят, как о неких отдельных "типах тестирования".
• Возьмем другой распространенный контекст – подумаем о данных. Большая часть приложений использует данные тем или иным образом. Существует около 20 различных рисков, связанных с данными. Например, это правильность данных, количество данных (для одной транзакции), количество транзакций (с точки зрения мультитранзакционной нагрузки), тип данных, использование данных (где используются введенные данные), полнота данных, создание, чтение, обновление и редактирование, удаление, обработка ошибок в данных, обработка ошибок в передаче данных, тип ввода данных, и так далее. Множество типов рисков, связанных с данными. Возьмите любой из вышеперечисленных – слышали ли вы, чтобы кто-либо называл его "типом тестирования"? "О, привет! Нам нужно провести тестирование метода ввода данных!" Нет. А если даже и слышали, то это точно малораспространенное определение типа тестирования, и сказавший такое все равно имел в виду тестирование этого конкретного риска.

Почему нужно говорить о типах рисков, а не о типах тестирования

Вы немедленно увидите ряд преимуществ, если переключите свои рассуждения с типов тестирования на типы рисков:

1. Вы отойдете от явного обсуждения фаз тестирования. Типы тестирования, как правило, подсознательно подталкивают наши размышления по пути "нам нужно провести этот тип тестирования, а затем этот, а затем еще этот…" Это негибкий подход. Представьте вместо этого следующее – "ага, надо протестировать эту фичу, и эти потенциальные риски нам известны – тогда у меня есть вот такой набор тест-идей, и часть из них я могу скомбинировать в одном тесте, покрыв несколько рисков этим единственным тестом! Эгегей!"
2. Вы будете лучше рассказывать свою тест-историю – то есть "этот тест был нацелен на исследование этого риска. Вот что я узнал об этом риске. Мне нужно больше времени на тестирование этой фичи, потому что этот риск очень важно изучить".
3. Вы будете быстрее замечать пробелы в своем тестировании: "мы проверили риски, связанные с большим объемом данных в транзакции (то есть риски нагрузки данными), но это заставило меня задуматься о нагрузке транзакциями – что будет, если множество транзакций произойдет одновременно?"
4. Это добавляет структурирования вашим тест-чартерам исследовательского тестирования. Если вы знакомы с изумительным образом тест-чартера от Элизабет Хендриксон – "Исследуйте (цель), с (ресурсами), для обнаружения (информации)" – его можно слегка изменить, чтобы структурировать информацию, которую хотим найти. "Исследуйте (цель), с (ресурсами), для обнаружения (информации об определенных рисках)".
5. Это помогает расширить ваши навыки латерального и критического мышления в плане того, как именно тестировать конкретный риск. Всегда существует более одного решения этого вопроса, поэтому если вы знаете о риске, который нуждается в тестировании – вы можете начать думать о множестве различных возможных способов тестирования того, является ли этот риск проблемой или нет.
6. Вы также будете лучше выявлять риски, о которых вы раньше не думали. Вы будете чаще спрашивать, о каких рисках мы еще не задумывались.

Осторожно, ловушки!

У этого подхода есть ряд ловушек, о которых нужно знать.

1. Исследовательское тестирование и автоматизация – это не типы тестирования, это подходы к нему.
2. Некоторые риски не имеют значения, поэтому всегда нужно спрашивать, важен ли этот риск, прежде чем тратить время на тестирование, если ответ – "нет". Мы не можем проверить все – поэтому очень важно приоритезировать наши тесты.
3. Тестирование не заканчивается на тестировании рисков. К примеру, первичное тестирование нацелено на выявление рисков.
4. Риски делятся на различные категории. Люди часто путают бизнес-риски с продуктовыми, проектными или человеческими. Некоторые риски могут быть связаны с рисками из других категорий. К примеру, в процессе тестирования нет смысла заявлять "мне нужно проверить риск того, что бизнес потеряет пользователей из-за плохих отзывов" – если только вы не тестируете бизнес-стратегию и цели. Тестируя, лучше размышлять о продуктовых рисках.

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