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

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

• Должен уметь разрабатывать и выполнять пошаговые процедуры.

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

• Уметь критиковать и корректно воспринимать критику (например, умение так объяснить разработчикам суть дефектов, что с его слов их можно устранить).

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

• Уметь противостоять неослабевающему давлению (тестирование всегда явля­ ется завершающей стадией любого процесса разработки и, как правило, проте­ кает в стрессовых обстоятельствах).

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

• Быть терпеливым — быть готовым выполнять прогоны тестов столько раз, сколько нужно для того, чтобы снять проблему, после чего повторно выпол­ нить тесты, чтобы убедиться в корректном устранении проблемы. (Между про­ чим, существенную помощь в этом случае оказывает именно автоматизация!)

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

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

• Быть экспертом в нескольких областях — группе тестирования могут потребо­ ваться специалисты по базам данных, по коммуникациям, по сетевым техноло­ гиям, по тестированию GUI-интерфейсов, по инструментальным средствам тестирования, по сценариям автоматизации, а также специалисты из других областей.

Этот перечень достоинств высококвалифицированного тестировщика может с пользой применяться при приеме людей на работу и при оценке кандидатов на ту или иную должность. Если вы формируете коллектив для работы над новым проектом, рекомендуется подбирать людей таким образом, чтобы они соответствовали, по воз­ можности, максимальному числу требований, фигурирующих в приведенном выше списке. Более подробную информацию о создании производственных коллективов можно найти в [14] и [33].

Глава 6. Вопросы объединения процессов тестирования......................... 145

Характерные ошибки

Если бы все группы тестирования проявляли качества, упомянутые в предыдущем разделе, проблем при проведении испытаний было бы значительно меньше. Однако лишь немногие коллективы тестировщиков в той или иной мере приближаются к идеалу, в связи с чем имеет смысл проанализировать наиболее распространенные ошибки, которые допускают тестировщики и которые ведут к снижению эффектив­ ности усилий, затрачиваемых на тестирование. Иногда достаточно простого предос­ тережения в адрес партнеров по работе (или самому себе) о возможности таких оши­ бок и формирования стратегии совместного устранения последствий этих ошибок.

Вот список некоторых классических ошибок, допускаемых тестировщиками:

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

• Нежелание регистрировать каждую обнаруженную проблему. Подобные си­туации часто возникают во время прогона продолжительного теста. Вы сталки­ ваетесь с некоторой незначительной проблемой, однако двигаетесь дальше, надеясь на то, что запомнили достаточно сведений, дабы зафиксировать их позже. Когда это " позже" наступает, вы либо забываете об этой проблеме, либо не можете воспроизвести действия, которые к ней приводят. Хороший способ не допускать такие ошибки состоит в ведении специального журнала записей, в котором фиксируются незначительные отклонения от нормы, даже те, кото­ рые на первый взгляд не имеют отношения к тестированию. Если вести точные записи, то в конце теста можно вернуться к обнаруженной проблеме и провес­ ти специальные исследования с целью определить, дефект ли это на самом деле.

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

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