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

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

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

Как выявлять продуктовые риски

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

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

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

Для примера возьмем игрушечное пианино моего сына…

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

Мне тоже нравится играть на этом пианино. Хоть оно и невелико, я могу взять ряд аккордов и использовать обе руки, чтобы добавить гармонии детским песенкам, которые я умею играть. Итак, это еще одна задача игрушечного пианино – чтобы я играл Ангусу песенки. К тому же Ангус начал ходить, и он любит взбираться на пианино и использовать его, чтобы добраться до дивана (хоть мне и не нравится это – я беспокоюсь за его безопасность). Иногда ему нравится быстро включать и выключать его несколько раз – когда оно включается, то проигрывает короткую мелодию. Его также развлекает сам процесс нажатия на выключатель.

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

Существует также ряд состояний, о которых нужно подумать: состояние включенности и выключенности, возможность играть сидя на стуле, сидя на полу, стоя, играть локтями и пальцами ног. Ангус также клал пианино на спинку и играл на нем таким образом. Я играл на нем, держа пианино на коленях, и играл, когда Ангус тоже облокачивался на него. Мы играли на нем в разное время суток. Мы играли на нем, когда батарейки почти заканчивались, и затем сразу после того, как я заменял батарейки.

Надеюсь, вы уловили суть – у пианино множество различных переменных, и у каждой из вариаций переменных есть свои переменные. Я перечислил только некоторые из них в своем примере, но есть еще и неизвестные мне вещи, которые я упустил.

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

И вот что забавно, когда я играю на пианино, я слышу различные баги. Если одновременно нажать определенные клавиши, то пианино случайным образом добавляет странные ноты. Однако когда на нем играет Ангус, он никогда не вызывает к жизни эти проблемные звуки, потому что нажимает на единичные клавиши и не берет аккорды. Я даже не уверен, что заметил бы, если бы в его игру вмешались странные звуки – он все равно нажимает на клавиши как попало!

Если вам любопытно, как звучат эти странные звуки при нажатии трех клавиш одновременно, вот видео:

https://videopress.com/v/Nc2PBwJc

"ЗНАЧИМ ЛИ ЭТОТ РИСК?"

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

НО! (Всегда есть какое-то но…) Решение, значим риск или нет, должно совместно приниматься вами, командой, и представителем продукта. Возможно, с вашей точки зрения риск не имеет значения, но вы не учли иную перспективу, о которой знает кто-то еще в вашей команде.

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

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

В финальной части этого цикла статей я затрону тестирование с целью выявления рисков и тестирование рисков с целью выявления проблем – возможность снизить риски через тест-дизайн. А также поделюсь еще парочкой моделей.

Обсудить в форуме