Home

Автор: Майкл Болтон (Michael Bolton)
Оригинал статьи
Перевод: Ольга Алифанова

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

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

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

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

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

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

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

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

Подумайте вот о чем: взвешивание не заставляет вас терять вес. Анализ крови не делает вас здоровее. Стандартизированные школьные тесты не делают детей умнее, и, конечно, не улучшают качества обучения.

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

Переформулирую: тестирование – это допрос продукта с целью его оценки. Ни вопросы, ни ответы не делают продукт лучше. Люди, действующие на основании ответов, могут сделать продукт лучше.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Потенциальные возражения:

Если тестирование не выявляет нужду для улучшений, улучшения не произойдет.

Это не так. Тестирование проливает свет на то, что нуждается в улучшении, однако улучшения могут произойти и без тестирования.

Тестирование также может проходить без улучшений. Например:

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

В каждом из этих случаев 1) был ли продукт протестирован? (Да) 2) улучшился ли продукт? (Нет).

Утверждение, что тестирование не улучшает продукт, снижает воспринимаемую ценность тестирования.

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

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

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

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

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