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

Часть 1

Часть 2

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

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

Снижение рисков через дизайн

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

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

(Примечание: эта модель не отображает модель водопада. Виды деятельности в жизненном цикле разработки неизбежно ведутся параллельно, так как мы одновременно работаем над небольшими участками, если используется Agile).

В первой половине жизненного цикла мы занимаемся исследовательским тестированием-расследованием – оно проводится еще до создания кода, поэтому мы не можем проверить ПО на предмет соответствия ожиданиям от его работы). Схожим с исследовательским тестированием реального продукта образом, тестирование идей, артефактов, UX/UI дизайна, дизайна кода и архитектуры, и т. д. имеет целью выявление информации. Выявленная информация принимает форму известных рисков, а наши тест-заметки – это карты рисков.

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

Предотвращение багов и обнаружение багов (проактивное и реактивное качество)

Можно отметить довольно четкую разницу между тестированием с целью идентифицировать риски (иными словами, проблемы с нашими идеями, артефактами, дизайном, мышлением…) и тестирование ПО, движимое выявленными рисками, дабы выявить проблемы в продукте.

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

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

В книге “Ignorance: How it drives science” Стюарт Файрштейн использует очень полезную аналогию, сравнивая неведение с "кругами по воде". Он говорит следующее: "По мере роста знания растет и неведение. Суть не в том, что неведение превращается в знание – более важный процесс идет в противоположном направлении. Знание приводит к неведению более высокого качества, пытаясь задавать вопросы все лучше и лучше".

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

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

Чем мы рискуем, не думая о рисках

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

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

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

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

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

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

Как работали с рисками продукта вы?

Думаете ли вы о рисках таким образом? Если нет, знакомы ли вам проблемы, вытекающие из-за отсутствия таких размышлений?

Надеюсь, что вы попробуете попрактиковаться в таком тестировании. Всегда рад услышать истории о вашем опыте!

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