Home

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

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

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

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

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

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

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

Дисциплина, говорит Чемберс, это "1. Тренировка, рассчитанная на развитие самоконтроля и упорядоченный образ жизни, 2. Состояние самоконтроля, приобретенное путем такой тренировки". Идея самоконтроля предполагает идею агентности, которая очень важна для исследовательской работы – которая, в свою очередь, важна для инженерной работы.

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

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

• Когда на носу изменение или новая фича, группы людей пересматривали и обсуждали идеи, чтобы понять изменение и причины для него. Разговор концентрировался на улучшении системы и проблемах, которые решало изменение. Но этот фокус смягчался и заострялся, приближался и отдалялся, и передвигался, чтобы люди могли увидеть все возможное, включая проблемы. Участники часто не соглашались друг с другом, но они были готовы на небольшие эксперименты, чтобы разобраться с этими несогласиями.
• Я видел, как люди консультируются с коллегами и пользователями, дабы узнавать о разнообразных идеях о дизайне, внедрении и рисках. Разговоры шли за рабочими столами и в конференц-залах, но также и вне офиса – в ресторанах, за едой, питьем, шутками, прогулками, играми, хождением по магазинам… Дисциплина иногда расслабляется. Социальная жизнь продуцирует доверие и ответственность, и это помогает людям стремиться к дисциплине.
• Я видел, как люди использовали разговоры, текст, таблицы, наброски, диаграммы, истории, ментальные карты, игрушки и имитаторы, чтобы доступнее объяснять – как для анализа, так и для запоминания. Дисциплинированная работа зачастую также ассоциируется с аккуратным ведением заметок.
• В дисциплинированных организациях порядок необязательно наступает сразу же – иногда ему надо придать ускорения. Все начинается с сумбура и постепенно делается чище, если это необходимо; если все становится чересчур формальным раньше времени, то идеи начинают теряться. Разработка – это тоже стиль жизни, а упорядоченный и основанный на самоконтроле стиль жизни часто начинается с бесконтрольности и беспорядка, когда мы затеваем создание чего-то нового. Порядок возникает постепенно.
• В некоторых дисциплинированных местах все были тихими и сконцентрированными, но в других была масса фоновой болтовни. В центре этой болтовни были истории о том, как люди решали проблемы – и создавали новые по дороге. Такие рассказы помогали ярко представлять себе риски, и побуждали задуматься о дисциплине.
• Я слышал открытое и честное несогласие, если что-то стоило того, чтобы не соглашаться. Я видел, как люди расстраиваются… и берут на себя ответственность за то, чтобы разобраться. Дисциплина – это не всегда гладко.
• Я видел, как авторы обращали внимание на тестируемость – включая простоту, чистоту кода, модулярность, видимость и контролируемость – и позднее это облегчало и удешевляло глубокое тестирование.
• В дисциплинированных командах разработчики старались не вносить чересчур много перемен одновременно. Они вносили неторопливые изменения внимательно, осторожно, с умом, и сами смотрели, что получилось. Когда они чувствовали, что готовы показать свою работу коллегам, они делали ее легко доступной, просили о моментальной обратной связи и получали ее.
• В ходе разработки и тестирования разработчики старались предусмотреть потенциальные исключения и условия для ошибки, и обычно преуспевали в этом. Затем они давали продукт на тестирование, и после этого узнавали что-то упущенное ими.
• Действительно хорошие дебаггеры внимательно пробовали вносить специальные мелкие изменения, работая над решением проблемы.
• Дисциплинированные разработчики обычно предпочитали надежные, широко применяемые, проверенные опытом компоненты, а не бежали волосы назад внедрять что-то новое, разработанное с нуля. В результате появлялось меньше неожиданных багов.
• Я видел разработчиков, работающих в стиле "сначала тесты" или TDD – и им давали на это время. И я работал с дисциплинированными разработчиками, которые не заморачивались с TDD, проявляя дисциплину иначе.
• Я видел код, содержащий ассерты в дебаг-билдах. Я видел обработку ошибок, встроенную в продукт, и логи, сообщающие о его статусе. (Время от времени я вижу продуманные, полезные сообщения об ошибках).
• Я видел, как разработчики проверяют свою работу при помощи конфигурационных проверок, детекторов нежелательных изменений и юнит-тестов, включая запрограммированные проверки результатов.
• Я видел, как люди проводят часы и дни в офисах коллег, занимаясь парным программированием и получая немедленное ревью.
• Я видел формализованные ревью-сессии, в ходе которых новенькие учились у более опытных разработчиков – и, что интересно, наоборот.
• Я видел, как разработчики используют множество инструментов для того, чтобы увидеть то, что скрыто – или увидеть явное в новом свете (к примеру, IDE-проверка синтаксиса в ходе создания кода; внимательность к предупреждениям компилятора; диаграммы схемы базы данных; проверка зависимостей; профайлинг производительности, и т. д.)
• Я видел систематический рефакторинг с целью повысить читабельность, поддерживаемость и портируемость; как говорится, выплата технического долга.
• Я слушал разговоры о проработке общего стиля программирования, что также помогало с читабельностью.
• Я видел, как разработчики ведут подробные заметки о процедурах настройки и настройках конфигурации.
• Я видел, как вся команда постоянно трудится совместно – множество глаз и умов заметят, когда что-то пойдет не так.
• Я видел, как люди налаживают хорошие отношения с техподдержкой.
• Я видел дисциплинированных людей, которые всегда уходили домой вовремя, а также дисциплинированных людей, которые время от времени задерживались.
• В дисциплинированных командах я видел общий скептицизм по поводу полноты, точности или релевантности требований, критериев приемки, или критериев готовности. Среди оптимистов я видел железобетонную уверенность, если что-то было действительно готово.
• Дисциплинированные команды часто проводят краткие, поверхностные, ничего не затрагивающие сессии интерактивного тестирования "из первых рук", чтобы помочь убедиться, что то, что делает разработка, близко к тому, что команда планировала сделать.
• Я видел, как проектные менеджеры зовут на помощь сотрудников поддержки (включая настройщиков тест-систем), чтобы помочь следить за бэк-логом, и администратора группы, который помогает менеджеру в приобретении ресурсов.
• Я видел частые билды, чтобы билд для глубокого тестирования и баг-фиксов можно было получить за долю секунды. Но я видал и сравнительно нечастые, однако все равно надежные билды.

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

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

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

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

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

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

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

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

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

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

Если кто-то чувствует, что не справляется – это знак, что, возможно, происходит нечто такое, с чем справиться нельзя.

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

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

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

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

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

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

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

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