Вопросы объединения процессов тестирования и кадрового обеспечения 142 Часть П. Технологии быстрого тестирования и советы 159
 Скачать 4.53 Mb.
|
|
Глава 5. Системные испытания 141 • Составление сообщений о дефектах • Анализ дефектов м Прогон системных тестов • Вход в системные испытания • Циклы тестирования • Регистрация результатов прогона тестов • Отчетность по результатам тестирования • Отчет о ходе выполнения тестовых работ • Отчет по результатам тестирования • Критерии выхода из испытаний и оценка готовности Необходимыми условиями для проведения системных испытаний являются план проведения испытаний в его окончательном виде, набор готовых к прогону тестовых случаев и отлаженный испытательный комплекс в требуемой конфигурации. Резуль тат выполнения тестовых работ представляет собой совокупность результатов тести рования, которые позволяют руководству проекта и коллективу разработчиков выра ботать оценку готовности программного продукта к выпуску. В первых пяти главах книги даны определения множества процессов, которые ох ватывают тестирование программного обеспечения от этапа выявления требований до завершения системных испытаний. Если вы впервые сталкиваетесь с тестирова нием или пытаетесь открыть новую испытательную лабораторию, трудно будет реа лизовать все эти процессы сразу; их необходимо разворачивать постепенно, как часть долгосрочной программы совершенствования процессов. В следующей главе будет показано, как построить интегрированный процесс тестирования, воспользовавшись подходом долгосрочного совершенствования. Вопросы объединения процессов тестирования и кадрового обеспечения Темы, рассматриваемые в главе: • Человеческий фактор и тестирование • Совершенствование процесса тестирования • Что дальше В главе 1 мы говорили о быстром тестировании как о структуре, построенной на ос нове следующих факторов: • Исполнители • Интегрированный процесс тестирования • Статическое тестирование • Динамическое тестирование. До сих пор основное внимание уделялось второму строительному блоку структу ры, а именно, процессу комплексных испытаний. Одна из причин повышенного вни мания этому процессу связана с тем, что независимо от квалификации исполнителей, если они не имеют в своем распоряжении систематической, упорядоченной методи ки тестирования, то не смогут работать с максимальной отдачей. В первой части дан ной главы мы перенесем акцент на изучение человеческого фактора при тестирова нии. Следует отметить, что исследованию проблем, привносимым человеческим фактором в разработку программного обеспечения, посвящено немало книг, одной из которых является [41]. В своей книге Peopleware (Кадровое обеспечение) [14], которая стала классикой, Демарко (DeMarco) и Листер (Lister) рассматривают проблему че ловеческого фактора с точки зрения его влияния на разработку программных про дуктов. В первой части данной главы будут обозначены наиболее важные аспекты этой темы, которые могут содействовать успеху тестовых работ, но в равной степени могут стать основной причиной их неудачи. Несмотря на то что многие аспекты процесса отладки уже были обсуждены, при дется затронуть еще один вопрос. В конце главы 5 отмечалось, что весь процесс тес тирования нельзя кардинально перестроить. Совершенствование процесса тестиро- Глава 6. Вопросы объединения процессов тестирования... 143 вания должно быть планомерным процессом, разбитым на отдельные этапы. Вторая часть этой главы представляет собой обзор мероприятий, направленных на совер шенствование процесса отладки. Статическое и динамическое тестирование образуют третий и четвертый строи тельные блоки рациональной и эффективной методики тестирования. Эти две тех нологии тестирования основательно обсуждались во второй и третьей главах, а более подробное их исследование будет продолжено в главах 9 и 10. Человеческий фактор и тестирование Барри Боем (Barry Boehm) в [21] утверждает, что личные качества исполнителей и отношения, установившиеся в коллективе, представляют собой резерв для повыше ния эффективности программного обеспечения. Другими словами, человеческий фактор оказывает гораздо большее влияние на эффективность программного обес печения, чем любой другой отдельно взятый фактор. Боем доказывает это утвержде ние, применяя инструментальное средство СОСОМО для оценки трудозатрат сис темного аналитика и программиста, при этом производительность каждого из них изменялась в 4 раза. Как показывает опыт, накопленный авторами, именно такой разброс производительности возможен во время выполнения тестовых работ, при разработке тестов и даже при прогоне тестов (т.е. при обнаружении дефектов). Если есть намерения выявить фактор, оказывающий максимальное влияние на способ ность вашего коллектива выполнять тестирование программных продуктов быстро и эффективно, в этом плане потребуется подвергнуть исследованиям в первую очередь деловые и личные качества членов группы тестирования. В этом разделе мы покажем, какими качествами должен обладать тестировщик, дабы успешно справляться со своими обязанностями, Затем мы составим список ошибок, приводящих к снижению эффективности работ по тестированию, которые могут допускать тестировщики. Кроме того, будет рассмотрен ряд технологий опро са, ориентированных на специалистов по тестированию. Качества, которыми должен обладать специалист по тестированию, чтобы успешно справляться со своими обязанностями Среди тестировщиков есть яркие представители, которые могут служить истинными примерами специалиста по тестированию программного обеспечения. Однако более привычным является вариант высококвалифицированной группы, которую состав ляют специалисты, обладающие различными навыками. В этом разделе будет состав лен список качеств, которыми должен обладать идеальный тестировщик. Следует отдавать себе отчет, что в то время, как ни один человек не может быть носителем всех необходимых качеств, группа тестирования, будучи единым целым, может во площать максимально возможное количество требуемых качеств. В основу этого спи ска положен опыт и наблюдения, но отнюдь не достоверные данные научных иссле дований; возможно, возникнет желание нарисовать собственный портрет идеального тестировщика, воспользовавшись предлагаемым списком в качестве отправной точ ки. На наш взгляд, идеальный тестировщик: 144 Часть I. Процесс быстрого тестирования • Должен уметь разрушать программные продукты, не чувствуя при этом никаких угрызений совести. Поскольку тестирование выполняется с целью обнаруже ния дефектов, тестировщик не должен испытывать дискомфорта, обнаруживая ошибки в работе другого исполнителя. • Должен уметь разрабатывать и выполнять пошаговые процедуры. • Должен уметь описывать последовательность событий и конфигурацию систе мы, которые приводят к возникновению проблемы. Это включает способность четко документировать процедуры и результаты, умение устно передать ин формацию разработчикам, другим тестировщикам и руководству. • Уметь критиковать и корректно воспринимать критику (например, умение так объяснить разработчикам суть дефектов, что с его слов их можно устранить). • Обладать способностью приносить разработчикам и руководству плохие ново сти. Если в одиннадцать вечера выясняется, что не удается достичь готовности выпуска программного продукта, тестировщик должен быть готов сообщить руководству эту печальную новость. • Уметь противостоять неослабевающему давлению (тестирование всегда явля ется завершающей стадией любого процесса разработки и, как правило, проте кает в стрессовых обстоятельствах). • Обладать незаурядными умственными способностями, т.е. легко и быстро ос ваивать новые технологии. • Быть терпеливым — быть готовым выполнять прогоны тестов столько раз, сколько нужно для того, чтобы снять проблему, после чего повторно выпол нить тесты, чтобы убедиться в корректном устранении проблемы. (Между про чим, существенную помощь в этом случае оказывает именно автоматизация!) • Обладать гибким мышлением — быть способным быстро переключиться на тес тирование нового программного продукта или даже отказаться от испытания одного продукта в пользу другого, обладающего более высоким приоритетом. • Обладать способностью одновременно видеть общую панораму и уметь при не обходимости сосредоточиться на деталях; иметь широкий и динамичный кру гозор. • Быть экспертом в нескольких областях — группе тестирования могут потребо ваться специалисты по базам данных, по коммуникациям, по сетевым техноло гиям, по тестированию GUI-интерфейсов, по инструментальным средствам тестирования, по сценариям автоматизации, а также специалисты из других областей. Этот перечень достоинств высококвалифицированного тестировщика может с пользой применяться при приеме людей на работу и при оценке кандидатов на ту или иную должность. Если вы формируете коллектив для работы над новым проектом, рекомендуется подбирать людей таким образом, чтобы они соответствовали, по воз можности, максимальному числу требований, фигурирующих в приведенном выше списке. Более подробную информацию о создании производственных коллективов можно найти в [14] и [33]. Глава 6. Вопросы объединения процессов тестирования... 145 Характерные ошибки Если бы все группы тестирования проявляли качества, упомянутые в предыдущем разделе, проблем при проведении испытаний было бы значительно меньше. Однако лишь немногие коллективы тестировщиков в т о й или иной мере приближаются к идеалу, в связи с чем имеет смысл проанализировать наиболее распространенные ошибки, которые допускают тестировщики и которые ведут к снижению эффектив ности усилий, затрачиваемых на тестирование. Иногда достаточно простого предос тережения в адрес партнеров по работе (или самому себе) о возможности таких оши бок и формирования стратегии совместного устранения последствий этих ошибок. Вот список некоторых классических ошибок, допускаемых тестировщиками: • Предположение, что программа работает корректно. Тестировщик всегда должен предполагать, что программа работает некорректно. Его обязанности за ключаются в том, чтобы отыскать те моменты, которые программа выполняет неправильно, а не то, что она делает правильно. Любое отклонение от ожидае мого результата, вне зависимости от его значимости, должно рассматриваться как потенциальный признак дефекта. Независимо от того, насколько преду предительным и компетентным может быть программист, вы не должны отда вать свои симпатии этому программисту в ситуации, когда возникают подозре ния о наличии дефекта. • Нежелание регистрировать каждую обнаруженную проблему. Подобные си туации часто возникают во время прогона продолжительного теста. Вы сталки ваетесь с некоторой незначительной проблемой, однако двигаетесь дальше, надеясь на то, что запомнили достаточно сведений, дабы зафиксировать их позже. Когда это "позже" наступает, вы либо забываете об этой проблеме, либо не можете воспроизвести действия, которые к ней приводят. Хороший способ не допускать такие ошибки состоит в ведении специального журнала записей, в котором фиксируются незначительные отклонения от нормы, даже те, кото рые на первый взгляд не имеют отношения к тестированию. Если вести точные записи, то в конце теста можно вернуться к обнаруженной проблеме и провес ти специальные исследования с целью определить, дефект ли это на самом деле. • Игнорирование или даже сокрытие проблемы. Эта ошибка является частным случаем двух первых видов ошибок. Она чревата весьма пагубными последст виями. В этом случае известно, что программный продукт содержит дефект, однако почему-то принимается решение игнорировать его. Возможно, что в следующей сборке этого дефекта не будет. Возможно, что он не играет никакой роли. Возможно, по причине ограничений во времени проведение исследова ний дефекта невозможно. Такая ошибка может привести к тяжким последстви ям, в том числе и вызвать просачивание дефекта в среду заказчика. Всегда сле дует помнить, что любой обнаруженный дефект может скрывать за собой це лый ряд других, скрытых дефектов, если только последовательно не бороться с теми из них, которые находятся на виду. • Вы позволяете разработчикам уговорить с е б я не составлять сообщений о дефектах или игнорировать имеющиеся сообщения о дефектах, не имея на то достаточных оснований. Н е т ничего предосудительного в том, чтобы пого- 146 Часть I. Процесс быстрого тестирования ворить с разработчиком и позволить ему убедить себя в том, что дефект при сутствует в самом тесте, или же в том, что конфигурация тестовых средств не соответствует вероятной среде заказчика. Однако прежде чем принимать ре шение игнорировать тот или иной дефект, следует быть уверенным в правиль ности этого решения. В случае малейших сомнений относительно желания разработчика отказаться от регистрации дефекта или игнорировать то или иное сообщение о дефекте, нужно обсудить логику его рассуждений с коллегой- тестировщиком или с другим разработчиком. • Стремление не обострять отношения с разработчиком. Этот вид ошибки имеет отношение к предыдущему типу, в то же время формы ее проявления мо гут быть другими. Если вы находите ошибку в чьей-то работе, это значит, что дефект засел в программном продукте, выпускаемом вашей компанией, и вся группа тестирования только выигрывает от того, что об этом ей стало извест но, ибо чем раньше дефект будет устранен, тем лучше. Одним из достоинств э ф ф е к т и в н о й системы отслеживания дефектов и еженедельных анализов де фектов является то, что они позволяют избегать конфликтов между людьми. Личные обиды, которые возникают, когда кто-то находит недостатки в чужой работе, можно сгладить, если профессионально применять соответствующие инструментальные средства и процедуры анализа дефектов. • Недостаточное внимание, которое уделяется планированию испытаний. Ес ли ваш процесс не поддерживается планированием испытаний, то элементарно может случиться так, что у вас останется слишком мало времени на подготовку к тестированию следующей сборки. Может также иметь место спешка при оценке затрат времени и ресурсов, необходимых для выполнения конкретной тестовой задачи. Планы, составляемые в спешке, обычно приводят к возникно вению больших проблем при проведении испытаний. • Написание пространных отчетов о несуществующих проблемах. Подобный вид бездарной траты времени находится на противоположном конце спектра по отношению к большинству рассмотренных выше ошибок. Вам спустили сверху квоту на отлов дефектов? Оценка вашего труда как-то связана с количе ством обнаруженных дефектов? Если это так, то иногда трудно устоять перед искушением представить в качестве дефектов несуществующие проблемы. По иск дефекта в программе, которая работает в соответствии с замыслом, требует больших непроизводительных затрата времени. Вы не только понапрасну тра тите время на формулирование проблемы, вы отнимете время разработчиков и руководства проектом, которое они вынуждены будут отдать отслеживанию не существующего дефекта и попыткам воспроизвести проблему. Тестировщики должны неукоснительно фиксировать каждую реальную проблему, с которой они сталкиваются, но ни а коем случае не поддаваться соблазну фиксировать те проблемы, которые, по их убеждению, будут проигнорированы. Если более 10% дефектов, обнаруженных конкретным тестировщиком, попадают в число несуществующих и будут игнорироваться, то этот тестировщик либо намеренно купился на эту уловку, либо ему явно не хватает знания деталей тестируемой программной системы. Глава 6. Вопросы объединения процессов тестирования... 147 Как проводить опросы претендентов Одним из способов формирования дееспособной группы тестирования является на ем квалифицированных тестировщиков. И хотя подробное обсуждение стратегий и технологий опроса выходит за рамки данной книги, мы дадим краткую характери стику технологий опроса, ориентированных на специалистов по тестированию, ко торые, по мнению авторов данной книги, обеспечивают неплохие результаты. Все они представляют собой простые идеи, основанные на здравом смысле, однако если ранее ими пользоваться не доводилось, возможно, информация, полученная благода ря применению этих технологий, вызовет некоторое удивление. • Выясните, каким опытом работы в тестировании обладает кандидат. Участ вовал ли он когда-либо в составлении планов проведения испытаний? Если это так, то какая информация учитывалась в этом плане? Приходилось ли ему ото бражать тестовые случаи на технические требования? Пользовался ли они формальной системой отслеживания дефектов? Несколько вопросов с после дующим их обсуждением позволяют достаточно быстро дать оценку опыта ра боты кандидата с процессами тестирования. • Если кандидат претендует на квалификацию в некоторой предметной об ласти, спросите его, как он применял знания этой предметной области во время тестирования программного продукта. Легко освоить технический сленг и рассуждать о предметных областях, однако толковое объяснение того, как кандидат разрабатывал сценарии автоматизации или конфигурировал ло кальную сеть или как использовал различные инструментальные средства, по зволяют дать оценку его знаниям конкретных технологий. • Задайте вопросы, которые могут продемонстрировать, обладает ли канди дат перечисленными выше качествами, которые необходимы для того, что бы успешно справиться со своими обязанностями. Обычно вопросы, подоб ные "Достаточно ли вы умны для выполнения такой-то работы?" или "Доста точно ли вы терпеливы, чтобы выполнять обязанности, на которые претендуе те?", едва ли дадут нужную информацию. Разумеется, можно предложить кан дидату рассказать о предыдущей работе в других местах; такой рассказ может пролить свет на некоторые из этих качеств. Например, можно поинтересо ваться: "Приходилось ли вам менять проектные приоритеты в тех случаях, ко гда требовалось немедленно перейти от тестирования продукта А к тестирова нию продукта В? Если да, то как это все происходило? Были ли у вас какие-либо затруднения при изучении технологии, связанной с продуктом В? С учетом приобретенного опыта, что у вас получилось хорошо? Что бы вы хотели изме нить?" Если для формирующейся группы тестирования подыскивается работ ник, обладающий одним или несколькими из перечисленных выше качеств, стоит заблаговременно подготовить набор вопросов для выяснения области интересов кандидата. • Если вы хотите напять работника, отвечающего конкретным требованиям, можно предложить ему составить план действий в гипотетической ситуа ции и проанализировать предложенное им решение. Например, если требу ется исполнитель, умеющий составлять планы проведения испытаний и тесто вые случаи для некоторого специального вида программного продукта, можно 148 Часть I. Процесс быстрого тестирования разработать простой набор технических требований и спросить кандидата, ка кими видами тестов он воспользуется. Пребывая в поисках нужного решения вместе с кандидатом и делая при необходимости наброски на бумаге или устно обсуждая различные детали проблемы, следует получить представление о том, насколько хорошо кандидат справляется с задачей написания тестов. • Дайте оценку того, насколько кандидат склонен совершать перечисленные выше классические ошибки, создав ему соответствующие ситуации и про анализировав его ответы. Например, можно поставить кандидата в ситуацию, когда на группу тестирования оказывается давление с целью сокращения сро ков тестирования. Далее неплохо было бы задать ему приблизительно такие вопросы. Откажетесь ли вы от плана проведения испытаний в пользу проведе ния специализированного тестирования? Будете ли регистрировать проблемы, с которыми столкнетесь в процессе прогона тестов, или же только факты ус пешного или неудачного исхода? Удосужитесь ли вы потратить некоторое вре мя на составление плана, указывающего, прогон каких тестов будет выполнять ся на завершающей сборке программного продукта, либо же сломя голову при ступите к прогону тестов в надежде все завершить до того, как прозвенит за вершающий звонок? Какие решения принимались в прошлом в аналогичных ситуациях?.. Можно предложить и другие ситуации, которые предполагают конфликт с разработчиками, или в которых требуется принять решение, если вдруг возникает подозрение, что коллега сообщает о несуществующих дефектах и проблемах. В этом разделе затрагивается лишь несколько аспектов, имеющих отношение к кадровому обеспечению процесса тестирования. В то же время, несмотря на крат кость изложения, нам удалось коснуться трех из пяти базовых принципов кадрового обеспечения, сформулированных Боемом (Boehm) [21]: • Профессиональная пригодность • Распределение работ в соответствии с квалификацией • Продвижение по службе • Пропорциональное распределение ресурсов внутри группы тестирования • Постепенное сворачивание работ (с устранением несоответствий). Принцип подбора кадров по профессиональной пригодности отражен в приве денном выше списке качеств идеального специалиста по тестированию. В этом спи ске также отражаются вопросы распределения работ в соответствии с квалификаци ей и пропорционального распределения ресурсов внутри группы тестирования. Не следует забывать о том, что ни один исполнитель не может обладать всеми профес сиональными качествами, которые требуются от группы тестировщиков, в связи с чем кадровый состав группы тестирования должен быть сбалансирован так, чтобы покрывать все требования, предъявляемые к квалификации кадрового состава группы. Принцип постепенного сворачивания работ предусматривает освобождение от обязанностей исполнителей, не способных внести положительный личный вклад в деятельность группы тестирования. Примером отрицательного вклада может слу жить ситуация, когда исполнитель своими действиями вносит такой беспорядок в |