Home

Оригинал статьи: http://www.developsense.com/blog/2011/09/testing-problems-are-test-results/

Автор: Майкл Болтон (Michael Bolton)

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

В курсе Rapid Software Testing я даю студентам такое упражнение: я прошу их перечислить все, что, с их точки зрения, усложняет или замедляет тестирование. Их ответы, как правило, однотипны – я регулярно слышу одни и те же вариации (пример таких ответов можно посмотреть, к примеру, в обсуждении на Stack Exchange). Обычно это примерно следующий перечень:

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

И, в плюс к вышеперечисленному,

• Компания, в которой я работаю, утверждает, что работает по Agile
• Помимо двухнедельных итераций, на самом деле мы применяем максимум пару практик, относящихся к Agile-подходу – как правило, ежедневные scrum-встречи или канбан-доски.

И вишенка на торте:

• Приходящие на тестирование билды очень нестабильны. Система падает при самых базовых smoke-тестах, и мне приходится ждать и/или пересобирать билд вместо того, чтобы заниматься своим прямым делом.

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

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

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

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

Джерри Вайнберг в своей книге "Perfect Software and other illusions about testing" отмечает, что то, что мы получаем в качестве результата – это прежде всего информация. Если тестирование, по словам Джерри – это сбор информации с целью ее передачи лицам, принимающим решения, то нельзя оставлять за бортом потенциально значимые наблюдения.

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

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

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

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

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

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

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

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

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

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