![]() Главная страница Случайная страница КАТЕГОРИИ: АвтомобилиАстрономияБиологияГеографияДом и садДругие языкиДругоеИнформатикаИсторияКультураЛитератураЛогикаМатематикаМедицинаМеталлургияМеханикаОбразованиеОхрана трудаПедагогикаПолитикаПравоПсихологияРелигияРиторикаСоциологияСпортСтроительствоТехнологияТуризмФизикаФилософияФинансыХимияЧерчениеЭкологияЭкономикаЭлектроника |
Часть I. Процесс быстрого тестирования. • Должен уметь разрушать программные продукты, не чувствуя при этом никаких угрызений совести
• Должен уметь разрушать программные продукты, не чувствуя при этом никаких угрызений совести. Поскольку тестирование выполняется с целью обнаруже ния дефектов, тестировщик не должен испытывать дискомфорта, обнаруживая ошибки в работе другого исполнителя. • Должен уметь разрабатывать и выполнять пошаговые процедуры.
• Должен уметь описывать последовательность событий и конфигурацию систе мы, которые приводят к возникновению проблемы. Это включает способность четко документировать процедуры и результаты, умение устно передать ин формацию разработчикам, другим тестировщикам и руководству.
• Уметь критиковать и корректно воспринимать критику (например, умение так объяснить разработчикам суть дефектов, что с его слов их можно устранить).
• Обладать способностью приносить разработчикам и руководству плохие ново сти. Если в одиннадцать вечера выясняется, что не удается достичь готовности выпуска программного продукта, тестировщик должен быть готов сообщить руководству эту печальную новость.
• Уметь противостоять неослабевающему давлению (тестирование всегда явля ется завершающей стадией любого процесса разработки и, как правило, проте кает в стрессовых обстоятельствах).
• Обладать незаурядными умственными способностями, т.е. легко и быстро ос ваивать новые технологии.
• Быть терпеливым — быть готовым выполнять прогоны тестов столько раз, сколько нужно для того, чтобы снять проблему, после чего повторно выпол нить тесты, чтобы убедиться в корректном устранении проблемы. (Между про чим, существенную помощь в этом случае оказывает именно автоматизация!)
• Обладать гибким мышлением — быть способным быстро переключиться на тес тирование нового программного продукта или даже отказаться от испытания одного продукта в пользу другого, обладающего более высоким приоритетом.
• Обладать способностью одновременно видеть общую панораму и уметь при не обходимости сосредоточиться на деталях; иметь широкий и динамичный кру гозор.
• Быть экспертом в нескольких областях — группе тестирования могут потребо ваться специалисты по базам данных, по коммуникациям, по сетевым техноло гиям, по тестированию GUI-интерфейсов, по инструментальным средствам тестирования, по сценариям автоматизации, а также специалисты из других областей.
Этот перечень достоинств высококвалифицированного тестировщика может с пользой применяться при приеме людей на работу и при оценке кандидатов на ту или иную должность. Если вы формируете коллектив для работы над новым проектом, рекомендуется подбирать людей таким образом, чтобы они соответствовали, по воз можности, максимальному числу требований, фигурирующих в приведенном выше списке. Более подробную информацию о создании производственных коллективов можно найти в [14] и [33]. Глава 6. Вопросы объединения процессов тестирования......................... 145
Характерные ошибки
Если бы все группы тестирования проявляли качества, упомянутые в предыдущем разделе, проблем при проведении испытаний было бы значительно меньше. Однако лишь немногие коллективы тестировщиков в той или иной мере приближаются к идеалу, в связи с чем имеет смысл проанализировать наиболее распространенные ошибки, которые допускают тестировщики и которые ведут к снижению эффектив ности усилий, затрачиваемых на тестирование. Иногда достаточно простого предос тережения в адрес партнеров по работе (или самому себе) о возможности таких оши бок и формирования стратегии совместного устранения последствий этих ошибок.
Вот список некоторых классических ошибок, допускаемых тестировщиками:
• Предположение, что программа работает корректно. Тестировщик всегдадолжен предполагать, что программа работает некорректно. Его обязанности за ключаются в том, чтобы отыскать те моменты, которые программа выполняет неправильно, а не то, что она делает правильно. Любое отклонение от ожидаемого результата, вне зависимости от его значимости, должно рассматриваться как потенциальный признак дефекта. Независимо от того, насколько преду предительным и компетентным может быть программист, вы не должны отда вать свои симпатии этому программисту в ситуации, когда возникают подозре ния о наличии дефекта. • Нежелание регистрировать каждую обнаруженную проблему. Подобные ситуации часто возникают во время прогона продолжительного теста. Вы сталки ваетесь с некоторой незначительной проблемой, однако двигаетесь дальше, надеясь на то, что запомнили достаточно сведений, дабы зафиксировать их позже. Когда это " позже" наступает, вы либо забываете об этой проблеме, либо не можете воспроизвести действия, которые к ней приводят. Хороший способ не допускать такие ошибки состоит в ведении специального журнала записей, в котором фиксируются незначительные отклонения от нормы, даже те, кото рые на первый взгляд не имеют отношения к тестированию. Если вести точные записи, то в конце теста можно вернуться к обнаруженной проблеме и провес ти специальные исследования с целью определить, дефект ли это на самом деле. • Игнорирование или даже сокрытие проблемы. Эта ошибка является частнымслучаем двух первых видов ошибок. Она чревата весьма пагубными последст виями. В этом случае известно, что программный продукт содержит дефект, однако почему-то принимается решение игнорировать его. Возможно, что в следующей сборке этого дефекта не будет. Возможно, что он не играет никакой роли. Возможно, по причине ограничений во времени проведение исследова ний дефекта невозможно. Такая ошибка может привести к тяжким последстви ям, в том числе и вызвать просачивание дефекта в среду заказчика. Всегда сле дует помнить, что любой обнаруженный дефект может скрывать за собой це лый ряд других, скрытых дефектов, если только последовательно не бороться с теми из них, которые находятся на виду. • Вы позволяете разработчикам уговорить себя не составлять сообщений о дефектах или игнорировать имеющиеся сообщения о дефектах, не имея на то достаточных оснований. Нет ничего предосудительного в том, чтобы пого-
|