Автор: Рауль Парваль (Rahul Parwal)
Оригинал статьи
Перевод: Ольга Алифанова

В прошлом году я и Сандип Гарг работали над электронной книгой TestFlix, зачастую откровенно обсуждая качество, тестирование и жизнь в целом. В ходе такого разговора Сандип рассказал мне про Джерри Вайнберга. Я впервые услышал про него и начал изучать его высказывания, а затем – популярные книги вроде «Секретов консалтинга» и «General system design thinking».

Недавно я наткнулся на его книгу о тестировании в ходе сессии читательского клуба Happy Book – это была «Perfect Software and other illusions about testing», выпущенная в 2008 году. Поначалу я думал, что она устарела, так как в нашу технологичную эпоху все устаревает за месяцы. Имея опыт чтения книг Вайнберга, я знал, что в книге могут быть неплохие моменты, и решил прочитать ее, дабы насладиться рассказами о старине и понять, как тестировали в древние времена.

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

Я написал об этом в LinkedIn и лег спать.

Когда я проснулся, телефон разрывался от уведомлений LinkedIn (спасибо Майклу Болтону, поделившемуся постом и увеличившим его охват), и я понял, что то, на что откликнулся я, вызывает такой же отклик у множества других тестировщиков. Пост растиражировали 100 раз, и его прочитало огромное количество тестировщиков, разработчиков, менеджеров, консультантов. Комментарии подтвердили, что эти ошибки все еще крайне распространены и очень важны.

За последние 20-30 лет мы увидели, как развиваются инструменты, процесс, методологии тестирования, как и многое другое. Однако если за более чем тридцать лет развития тестирования как отрасли ошибки остаются все теми же, перед нами встает серьезный вопрос – действительно ли мы развивались? Если нет, то почему? Мне кажется, потому что мы продолжаем спотыкаться о старые ловушки и игнорируем реальность.

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

1. Идея, что искать ошибки можно по расписанию

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

Ловушки:

• Идея, что тестирование – механическая, а не когнитивная деятельность.
• Идея, что CI/CD/CT устраняют нужду в распределении времени на тестирование.
• Идея, что зеленые прогоны автоматизированных тестов равняются качественному продукту.
• Идея, что автоматизация решит все наши проблемы.

Реальность:

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

2. Игнорирование потраченного на переключения времени

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

Ловушки:

• Идея, что мультизадачность – это продуктивно.
• Идея, что тестирование – пассивная деятельность, которую можно совмещать с какой-либо еще.
• Прием задач в работу и начало деятельности, как только задача появляется.
• Отсутствие планирования в работе.

Реальность:

• Если вы прибегаете к многозадачности, то рано или поздно об этом пожалеете.
• Ответственное тестирование требует концентрации усилий.
• Разработка ПО – это систематическое применение инженерных подходов к разработке.
• Провал в планировании – это планирование провала!

3. Отношение к тестированию, как к низкоприоритетной задаче, которую можно прервать в любой момент

Надежное тестирование требует концентрации.

Ловушки:

• Идея, что тестировать может кто угодно.
• Идея, что тестирование – это проверки.
• Измерение прогресса тестирования через количество багов.
• Идея, что тестирование – это ТОЛЬКО верификация.

Реальность:

• Да, как и в случае с кулинарией, кто угодно может тестировать до определенных пределов. Но не все могут заниматься ответственным тестированием.
• У качества множество измерений.
• Ценность одного бага может с лихвой превышать ценность 50 других багов. Количество багов НИ О ЧЕМ не говорит.
• Тестирование – это НЕ верификация, тестирование включает верификацию!

4. Требование, чтобы тестировщики точно локализовали все баги

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

Ловушки:

• Идея, что тестировщики должны стать разработчиками и локализовывать каждый баг.
• Идея, что проблемы однозначны (скажем, Истина или Ложь).
• Идея, что тестировщики в основном ничем не заняты, помимо проведения тестов.

Реальность:

• Менталитет тестирования и разработки кардинально отличается. Тестировщики хорошо размышляют о гипотетических ситуациях (что, если?), а не об императивных (делай это!)
• Большинство проблем выходят за рамки границ «Да» и «Нет». Они требуют человеческой оценки и глубокого изучения. Одно наблюдение можно интерпретировать множеством способов.
• Тестирование НЕ РАВНЯЕТСЯ проведению тестов. Это множество иных задач – проектирование тестов, подготовка тестовых данных, изучение и понимание требований, фиксация багов, их отслеживание, оценка проблем пользователей, и т. д.

5. Требование, чтобы тестировщики нашли все баги

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

Ловушки:

• Идея, что все проблемы очевидны.
• Ряд компаний делает подобные ложные заявления пользователям, проводя тестировщиков как Full Stack, T-форму, Star Testers.

Реальность:

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

6. Починка без ретеста

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

Ловушки:

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

Реальность:

• Большинство сделанных в последний момент исправлений приводит к побочным эффектам для системы.
• Излишний оптимизм разбивается о реальность!
• Юнит-тесты – просто проверки небольших фактов, ничего более.
• Тестирование никогда ничего не ломает – кроме иллюзий излишней уверенности.

7. Игнорирование кросс-связей

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

Ловушки:

• Идея, что тестирование независимо.
• Идея, что тестирование фиксировано и четко определено.
• Игнорирование издержек на анализ багов, их исследование, отстаивание и повторное тестирование.

Реальность:

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

8. Недостаточное внимание к тестируемости

Код, который проектировался и строился с учетом тестируемости, может значительно снизить затраты времени и сил на тестирование.

Ловушки:

• Идея, что магический фреймворк решит все проблемы тестирования.
• Идея, что инструменты улучшат тестируемость ПО.

Реальность:

• Секретный ингредиент хорошего тест-решения – это тестируемый код.
• Если тестируемость отсутствует, инструменты только ухудшат дело.

9. Требование «воспроизводимости» всех багов

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

Ловушки:

• Идея, что любая проблема – это результат контролируемых параметров или настроек.
• Идея, что тест-система и сравниваемая система одинаково настроены.

Реальность:

• В ходе тестирования мы контролируем лишь немногие данные и наблюдаем лишь за несколькими результатами.
• Зачастую кажущиеся неважными детали, вроде платформы, времени выполнения, версий поддерживаемых библиотек, не упоминаются или игнорируются. Действительно ли вы знаете абсолютно все о своей тест-системе? А если подумать?

10. Идея, что тестирование – это «создание и выполнение тест-кейсов»

Большая часть работы тестировщика выходит за рамки конкретного идентифицируемого тест-кейса. Лучше думайте в терминах видов тест-деятельности.

Ловушки:

• Идея, что тестирование = создание и выполнение тест-кейсов.
• Идея, что тестирование крутится вокруг тест-кейсов.

Реальность:

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

11. Требование пересмотра процессов компании

Если вы работаете в компании, уверенной, что единственная задача тестировщика – найти и выявить баги или приносить кофе и пончики разработчикам, то так и подмывает отправиться к руководству и совершить дерзкий переворот. Даже если вы заинтересованы в более уважительном отношении к тестировщикам внутри компании, вы ничего не добьетесь грубыми требованиями. Вы можете сказать начальству: «Я читал, что тестировщик – это человек, пробующий различные методы, чтобы заставить все работать. Подозреваю, наши тестировщики будут лучше работать, если мы что-то изменим. Я бы хотел обсудить это с вами».

Ловушки:

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

Реальность:

• Первый Великий Секрет Марвина: девяносто процентов всех болезней излечивается самостоятельно без всякого вмешательства докторов. Нежно обращайтесь с системами, способными на самолечение.
• Большинство людей легко справятся с 10% чего угодно, отнеся это в категорию «нет проблем». Все, что этот процент превышает, вызовет стыд, если вы преуспеете.
• Неважно, что или как они говорят – проблема всегда в людях.
• Если бы логика всегда работала, ни консультанты, ни консультации никому бы не понадобились. Консультанты зачастую помогают справиться с противоречиями.