Home

Автор: Майкл Болтон (Michael Bolton)
Оригинальная публикация: Testing Problems Are Test Results
Перевод: Сергей Высоцкий и RA

Часто во время курса "Быстрое Тестирование ПО", я провожу упражнение, в ходе которого прошу людей записать те вещи, которые, по их мнению, замедляют тестирование и делают его сложней. Эти списки отлично ложатся на шаблон, который я снова и снова слышу от тестировщиков (вы можете посмотреть пример такого шаблона в этой беседе на Stack Exchange). Обычные пункты в этих списках выглядят так:

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

В добавок к этому:

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

Ах да, вот еще:

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

Как мы можем принять во внимание все эти наблюдения?

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

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

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

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

• Осознают ли люди риски (особенно риски вроде Черных Лебедей), которые обычно несет с собой усложнение?
• Если люди осознают эти риски, обращают ли они на них достаточно внимания? Паникуют ли они из-за этого? Или они игнорируют их, в надежде пролететь мимо кладбища? Или...
• Люди реагируют спокойно и прагматично? Знают ли они об этой сложности, пытаются ли с ней что-то сделать? Если они не могут сделать продукт или процесс, который данный продукт моделирует, менее сложным, пытаются ли они делать какие-нибудь шаги в сторону большего понимания продукта и упрощению его обработки?
• Может быть программисты создают и модифицируют код настолько быстро, что они не успевают понять, что в действительности происходит?
• Если кто-то чувствует что нужно больше тестировщиков, то что скрывается за этим ощущением? (я уже пытался ответить на этот вопрос несколько лет назад)

Как мы можем получить ответы на эти вопросы? Один из способов - присмотреться к результатам и мета-результатам тестов.

• Догадывается ли кто-нибудь, что тестирование очень сложное, и занимает много времени? Кто? Что является причиной таких догадок? Какие предположения лежат под ними?
• Правда ли исследование и описание багов перегружает тестировщика настолько, что ему трудно поддерживать хорошее покрытие тестами продукта? (я писал об этой проблеме тут)
• Показывает ли тестирование сложившиеся шаблоны ошибок в продукте?
• Постоянно ли программистов удивляют эти ошибки и шаблоны?
• Приводят ли небольшие изменения кода к непропорционально большим и труднообнаруживаемым проблемам?
• Хорошо ли программисты понимают все взаимозависимости? Нужны ли эти взаимозависимости или от них можно избавиться?
• Принимают ли программисты какие-нибудь шаги для того чтобы сократить или предотвратить проблемы с интерфейсами или взаимодействиями?
• Если автоматические проверки трудно разрабатывать и поддерживать, говорит ли это что-то о навыках тестировщика, о качестве интерфейсов для автоматизации или об области проверок? Или это говорит о чем-то другом?
• Являются ли нестабильные сборки преградой на пути более детального и глубокого тестирования? Или мы можем считать, что нестабильные сборки это признак того, что проблем настолько много и они настолько серьезные, что даже поверхностное тестирование легко демонстрирует их?
• Когда мы наконец получаем "стабильную" сборку после серии нестабильных, насколько она стабильна в действительности?

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

• Какие риски могут возникнуть из-за этих проблем на пути продукта к успеху? Долгосрочные это риски или краткосрочные?
• Если тестирование постоянно демонстрирует шаблонные ошибки и постоянно присутствующий риск, то что команда работающая над продуктом предпринимает по этому поводу?
• Должны ли программисты просто поставлять код? Или они должны поставлять код, который обязан делать то, что он должен делать (и не делать того, чего не должен делать) по мере их знаний? Предпочитают ли программисты последний вариант?
• Давит ли кто-нибудь на программистов, заставляя взять на себя дополнительные обязательства, или управиться в сроки, которые в реальности не достижимы?
• Могут ли программисты и тестировщики избавиться от давления и лишних обязательств в случае когда они ставят под угрозу продукт или проект?
• Прислушивается ли менеджмент к жалобам команды разработки? Насколько они в курсе проблем которые пытаются донести до них программисты и тестировщики? Когда команда разработки указывает на наличие риска, делает ли менеджмент что-нибудь по этому поводу?
• Работает ли команда в устойчивом темпе, или мы должны ожидать, что продукт и проект сокрушат сложности, взаимозависимости, хрупкости, проблемы, которые скрываются за пределами возможностей команды разработки и тестирования?
• Действительно ли команда Agile в тех терминах, что обозначены в Agile Manifesto? Или эта "гибкость" всего лишь культ карго, маскирующийся за артефактами и внешними атрибутами другой методологии?

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

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