Home

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

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

Предпосылка 6 в Rapid Software Testing относится к издержкам и ценности.

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

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

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

В этой статье я поговорю о первом, что нам нужно для глубокого тестирования: о решительности.

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

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

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

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

Проблемы:

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

Эвристические обходные пути:

• Убедитесь, что в команде есть как минимум один человек, берущий на себя роль Ответственного Тестировщика, как мы это называем в Rapid Software Testing. Ответственный тестировщик – это тестировщик, который берет на себя личную ответственность за тестирование определенной части определенным образом в определенном проекте. Ответственный тестировщик – это человек, занимающийся тестированием, следящий, чтобы тестирование выполнялось, и, при необходимости, призывающий на помощь вспомогательных тестировщиков.
• Держите всю команду – дизайнеров, разработчиков, менеджеров и тестировщиков – в курсе о рисках, вскрывая продуктовые проблемы, рассказывая о проблемах, обнаруженных в других проектах, и прорабатывая и донося до них последствия таких проблем.
• Поверхностные баги прерывают глубокое тестирование. Обнаружение ошибок требует фиксации и отчетности, а затем возврата к ним и повторного тестирования после того, как они будут исправлены. Для тестировщиков это может ощущаться как бессмысленная задача, если эти ошибки легко найти, и если их легко можно было избежать. Это, в свою очередь, снижает мотивацию тестировщиков.
• В то же время разработчики полагают, что глубокое тестирование требует перемен в образе мыслей и подходах, и мешает их работе по созданию продукта. Много ли вы знаете разработчиков, утверждающих "Я обожаю тратить кучу времени на тестирование"? Когда у людей нет мотивации для действия, они, скорее всего, будут не очень хорошо или не очень тщательно работать. Следовательно, дайте разработчикам время, ресурсы и ответственность за проверку ошибок на поверхности их работы, чтобы поверхностные баги не мешали глубокому тестированию. В то же время поставьте тестировщикам задачу заниматься глубоким тестированием, чтобы оно не прерывало полет разработчиков.
• Никто не хочет, чтобы в проекте сидели сложные баги, но их нахождение может вызывать восторг и ощущение своей полезности. Миссия по их поиску может повысить мотивацию тестировщиков.
• Глубокое тестирование – это необязательно формальное процедурное тестирование. Формализация – до той степени, до которой тестирование может быть формализовано – тут больше в тщательном проектировании и выполнении интересных экспериментов, а не приверженность механическим, процедурным, строго заскриптованным, подтверждающим тест-кейсам. Тест-кейсы могут помочь тестированию, но тестирование – это не тест-кейсы, а тест-кейсы – это не тестирование.
• Суть тестирования – в оценке продукта путем его изучения; опыта работы с ним; исследования продукта; экспериментирования. Признайте, что глубина тестирования – это не про формальность, а про содержательное изучение, исследование и экспериментирование.
• Устраните все, что делает тестирование нудным, скучным, монотонным и ужасным. Не допускайте превращения людей в тест-роботов. Дайте ответственным и вспомогательным тестировщикам свободу и ответственность для исследования, открытий, расследований и описания продукта - и избегайте излишнего структурирования отчетности о работе, если формальность – не абсолютная необходимость.
• Помогите людям вспомнить, что намеренное обнаружение проблем до релиза – это, как правило, лучше, чем их внезапное обнаружение на проде. Да, нахождение бага – как правило, в какой-то степени плохая новость, но то, что мы нашли его сейчас, дает нам шанс разобраться с ним до того, как станет слишком поздно. Хвалите и награждайте людей, задействованных в его обнаружении. Тестированию не нужно замедлять проект, но благоразумие может потребовать замедлиться, чтобы ускоряться.

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

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