Home

Автор: Джефф Найман (Jeff Nyman)

Оригинал статьи: http://testerstories.com/2016/07/modern-testing-and-resilient-strategy/

Перевод: Ольга Алифанова

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

Эластичность и давление

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

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

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

Ряд ключевых моментов, которые вытекают из вышеописанного, и о которых тест-командам стоит задуматься:

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

Что касается первых двух пунктов – хоть я и не стою на жесткой позиции Джеймса Баха, я согласен, что тест-кейсы – это не тестирование (см. одноименную статью Джеймса).

По третьему пункту – под "проверкой" я подразумеваю чисто алгоритмическое действие.

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

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

Стратегия эластичности

Теперь поговорим о стратегии.

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

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

На каком уровне тестировать?

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

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

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

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

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

Взаимосвязанная деятельность

Все вышесказанное ведет к главному вопросу, на который команде нужно найти ответ: насколько взаимосвязанными должны быть разработка и тестирование?

С моей точки зрения, чем больше они взаимосвязаны, тем выше ваша эластичность.

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

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

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

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

Будьте гибкими и вдумчивыми

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

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

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

Когда вы тестируете, вы не создаете артефакты тестирования, вы создаете артефакты проверок.

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

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

Важные вопросы

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

Заметьте, что вопросы "что такое документация/спецификация" остаются открытыми. На первый взгляд вопрос кажется простым, но над ним стоит задуматься. Мои статьи – это попытка сделать именно это.

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

Это означает, что нам нужно минимизировать потери, чтобы снизить издержки. Что считается потерями? Как минимум, время на исправление багов, на переговоры, на ручной труд.

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

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

От классики к модерну

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

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

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