Тестирование-книга. Ю. Н. Артеменко Научный редактор
 Скачать 6.27 Mb.
|
|
Глава 14: Управление группой тестирования 4 3 9 Советы по планированию Как руководитель группы тестирования вы отвечаете за часть работ по планированию проекта. Сроки тестовых работ оценивать очень сложно, поскольку они зависят от работы других сотрудников. Если программисты не будут укладываться в график, затянется и работа вашей группы. То же самое случится, если ошибок в программе будет больше, чем предполага лось, или если пользовательский интерфейс будет постоянно меняться. Хотя все эти трудности вполне объективны, прятаться за ними не следует. Обязанность руководителя — предусмотреть все возможные проблемы и составить план работ своей группы с их учетом. Вот каковы его цели. • Предоставить необходимую информацию руководителю проекта. Руководитель проекта должен знать, какие задачи стоят перед груп пой тестирования и сколько времени потребуется на их выполнение. • Продумать возможные экстренные меры для обеспечения своевре менного выпуска продукта и выявить ресурсы для его ускорения. Заранее выделите те задачи программистов и технических писателей, которые могут задержать другие части общей работы и поэтому обязательно должны быть выполнены вовремя. Определите те эта пы разработки, на которых дополнительные ресурсы могут значи тельно ускорить ее ход. Многие руководители проекта охотно идут на выделение этих ресурсов, особенно если речь идет о дополни тельных тестировщиках или программистах. Ведь в конечном счете, оплатив определенное количество человеко-дней и выпустив продукт на неделю раньше, компания сэкономит на оплате недельного тру да всех тех, кто работает над проектом. И при этом она раньше выйдет на рынок и раньше начнет получать прибыль. Так что подоб ные затраты окупаются с лихвой. • Быть честным со своими подчиненными. Руководитель проекта может попытаться ускорить выпуск продукта за счет сверхурочной неоплачиваемой работы персонала. Однако полученная при этом до полнительная прибыль может дорого обойтись для вас и вашей ком пании: вы теряете право называться порядочными людьми, ухудшаете психологический климат в коллективе, качество работы усталых сотрудников оставляет желать лучшего, а текучесть кадров сильно повышается. Зато руководитель, добившийся такой ценой ускорения выпуска продукта, становится героем. Одной из главных обязанностей руководителя группы тестирования является защита своих подчиненных. 4 4 0 Часть III: Управление проектами и группами • Повысить производительность труда. Люди с готовностью постара ются уложиться в жесткий, но выполнимый график. Однако, если плохое планирование приведет к необходимости постоянной сверху рочной работы, не ждите от них энтузиазма. Уставшие сотрудники становятся невнимательными, работают неохотно, перестают пред лагать усовершенствования, чтобы не затянуть проект еще сильнее, и наконец, некоторые из них, как правило самые высококлассные специалисты, просто увольняются. Итак, честные и объективные оценки сроков работ жизненно необхо димы и вам, и компании. В следующих разделах приведены советы по их формированию. Оценка производительности и продуктивности В главе 6 рассказывалось о том, почему систему отслеживания проблем ни в коем случае нельзя использовать для оценки производительности труда программистов. Теперь же мы поговорим о том, какую пользу может принести отслеживание производительности собственных подчиненных. Разница здесь в том, что программисты не являются вашими подчиненны ми. Поэтому любые попытки оценки их деятельности будут восприняты в штыки. С другой стороны наблюдение за производительностью собствен ного персонала поможет улучшить его работу и не приведет к конфликтам, поскольку результаты наблюдений не выйдут за стены вашей рабочей ком наты. Страстным приверженцем оценки производительности персонала явля ется такой известный автор, как Деминг (Deming, 1982). Он считает, что получаемые данные позволяют значительно повысить качество работы. Вот какие преимущества может вам дать оценка производительности работы со трудников группы тестирования. • Можно определить, сколько времени требуется в среднем на выпол нение конкретной задачи. На основе этих данных можно планиро вать работу в дальнейшем. • Если например, известно, что в среднем тестировщик находит око ло 8 ошибок в день, обычно от 1 до 25, вы не удивитесь, если кто- то из сотрудников найдет за день 24 ошибки, но, если их окажется 120, вы сразу поймете, что здесь что-то не так. • Наблюдая за динамикой показателей производительности подчинен ных, можно оценить, каковы результаты ваших собственных усилий по ее повышению. Помогает ли данный тип обучения? Ускоряет ли работу автоматизация определенных тестов или видов деятельности? Для оценки пользы усовершенствований необходима возможность ана лиза динамики производительности работ. Глава 14: Управление группой тестирования 4 4 1 Вот несколько примеров того, что можно определить. • Среднее количество циклов тестирования. Наш опыт показывает, что типичная программа достигает коммерчески приемлемого каче ства после восьми полных циклов тестирования. Однако эта оцен ка не универсальна — для некоторых продуктов могут потребоваться десятки циклов, а есть и такие простые программы, которые отла живаются за несколько циклов. • Длительность типичного цикла тестирования. Этот показатель имеет смысл только тогда, когда каждая версия программы или определенной ее части всегда проходит полный цикл тестирования. Если же новая версия программы поступает каждую неделю незави симо от того, насколько протестирована предыдущая, данная оцен ка теряет смысл. • Количество ошибок, документируемых за день одним тестировщи- ком. Если один тестировщик находит за день в среднем 5 ошибок и вы предполагаете, что всего в программе их будет найдено около 1000, значит, на ее тестирование потребуется 200 человеко-дней. • Время тестирования одного устройства. При этом время настройки устройства следует учитывать отдельно. • Количество страниц документации, проверяемых за один час. Конечно, это время зависит от типа документации и целей ее проверки. • Количество сообщений об ошибках, тестируемых за один час. Сколько времени займет тестирование всего блока обработки оши бок? • Часть (количество страниц) плана тестирования, выполняемая за один час. Сколько времени уйдет на выполнение всего плана? Можно придумать и множество других примеров. Целый ряд показате лей продуктивности программного обеспечения приводит в своей книге Джонс (Jones, 1991). Собранные данные послужат убедительной аргументацией в перегово рах с руководителем проекта. Оперируя конкретными цифрами, гораздо легче объяснить, почему для тестирования программного продукта потре буется не два цикла, как хотелось бы руководителю проекта, а восемь. Покажите, сколько времени занимает в среднем каждый цикл тестирова ния, и объясните почему. Благодаря такой обстоятельности вы сможете получить больше времени и персонала, а значит, обеспечить более спокой ную работу с гораздо лучшими результатами. Статистические данные о производительности персонала полезны, но только при правильном употреблении. Если вы попытаетесь использовать 4 4 2 Часть III: Управление проектами и группами их для давления на подчиненных, утверждая, что они работают недостаточ но быстро, ничего хорошего от этого не ждите. В частности, такой извес тный автор, как Деминг (Deming, 1982), решительно выступает против подобного использования собранной информации. Если вы работаете в компании, где статистические данные о производительности труда могут быть использованы против отдельных тестировщиков, не собирайте эту информацию. Определение и оценка каждой задачи Прежде чем пытаться оценить общий объем необходимого тестирова ния, составьте полный список его задач. В этом списке ничто не должно быть упущено. Понятно, что составить такой список и оценить сроки выполнения каждой из задач не так-то просто, и одному человеку с этим не справиться. Вот хороший способ, как это сделать. Попросите руководство выделить вам на день или два конференц-зал или большую комнату. Соберите вместе всех тестировщиков, которым предстоит работать над продуктом. Если проект невелик и программу бу дет тестировать один-единственный сотрудник, пригласите еще кого-ни будь, имеющего опыт тестирования и знающего продукт (возможно, того, кто тестировал его предыдущий выпуск). Принесите на собрание специфи кацию, план тестирования, план тестирования предыдущего выпуска, ру ководства пользователя, заметки и любые другие материалы, которые помогут в определении задач. Возьмите лист бумаги, запишите на нем все основные задачи тестиро вания и прикрепите его к стене. У вас может получиться 5, 10 или 20 крупных задач — едва ли больше. Затем для каждой из основных задач перечислите на отдельном листе бумаги все ее составляющие. Эти листы также развесьте по стенам. Некоторые из подзадач могут оказаться настоль ко сложны, что потребуют дальнейшего разбиения. Их составляющие тоже перечислите на отдельных листах. Придумав еще одну базовую задачу, вы будете дописывать ее в главный список, а затем брать новый лист бумаги и перечислять на нем все ее составляющие. Когда все будет готово, можно начинать собрание. Вначале каждый сотрудник несколько раз обойдет комнату, переходя от списка к списку и дописывая в него новые элементы. Каждый должен увидеть, что дописали другие, и убедиться, что больше добавить нечего. Собрание должно проводиться по принципу мозгового штурма. Его первая цель — собрать максимум идей. Поэтому пока не критикуйте ни одну из них. Пусть все, что приходит людям в голову, попадет на бумагу. Отобрать правильные идеи вы сможете позднее. Глава 14: Управление группой тестирования 4 4 3 Составив списки, соберитесь все вместе для группового обсуждения. По очереди выбирая из списка каждую задачу, попытайтесь определить, сколь ко времени потребуется на ее выполнение. Везде, где только возможно, разбивайте задачи на более мелкие и определяйте время выполнения их со- ставляющих. Оценивая время, записывайте три значения: кратчайший срок, длиннейший и средний. Нередко оценки, даваемые вашими сотрудниками, будут казаться вам Преувеличенными. Это нормально. Поощряйте совершенно свободное выражение людьми своего мнения, только пусть они обязательно обосно- Цвывают высказываемые заключения. Ведь в конечном счете должна соста виться реальная картина, а не нечто желаемое, но невыполнимое. Не допускайте, чтобы сотрудник, высказавший неверную на чей- либо взгляд оценку, почувствовал себя глупым или виноватым. Напротив, всячески поощряйте свободное выражение сотрудниками собственного мнения. Оно вполне может оказаться верным. Если же нет, они сами поймут это в ходе дискуссии или некоторое время спустя. Когда вы сложите время всех предложенных в ходе обсуждения задач, результат окажется огромным. Он может в 5 или 10 раз превышать запла нированную длительность всего проекта. Это нормально. А вот если ока жется, что предполагаемые работы по тестированию прекрасно укладываются в график проекта, тогда стоит обеспокоиться. Теперь, имея четкий список задач, можно приступать к принятию ре шений. • Выделите задачи, которые не могут быть выполнены. • Распределите приоритеты между остальными. • Решите, какие из задач будут выполнены только частично и какие это будут части. (При этом, выбирая тесты, вы в одних случаях будете полагаться на логику, а в других действовать методом случай ного отбора.) • Выделите задачи, требующие наиболее быстрого выполнения (для тех из них, которые к тому же будут часто повторяться, можно зап ланировать автоматизацию). • В случае необходимости напишите подробную и убедительную док ладную записку, поясняющую, почему тестирование не может быть выполнено в запланированные руководством сроки или почему вам требуются дополнительные тестировщики, а также чего можно до стичь при большем количестве времени, людей или денег. 4 4 4 Часть III: Управление проектами и группами Классификация проекта Нередко стоимость работ по тестированию приходится оценивать задол го до того, как у вас появится достаточно информации. Поэтому вам нужна определенная схема классификации проектов с приблизительными оценка ми их стоимости. • Начните с определения сложности продукта. Воспользуйтесь трех- или пятибалльной шкалой, от простейшей программы, которую вам когда-либо приходилось тестировать, до многофункционального, сложного для понимания и использования программного продукта. • Затем сделайте предположения о том состоянии, в котором про дукт попадет вам в руки. Снова воспользуйтесь трех- или пятибал льной шкалой. Сколько ошибок предполагается найти в программе? В программах одних руководителей проектов больше ошибок, чем в программах других. То же самое относится и к программистам. Если в давно работающую программу вносится всего несколько исправ лений, ошибок будет не много. Если же разрабатывается самый первый выпуск сложного продукта, он будет полон ошибок. • Определив шкалы сложности и надежности проектов, можно соста вить таблицы оценки их стоимости и длительности. Пример такой таблицы с совершенно гипотетическими цифрами приведен на рис. 14.1. Ее данные можно интерпретировать так: на тестирование не сложного изменения высоконадежной программы хорошим програм мистом уходит неделя; более сложное изменение в крайне ненадежной программе (или выполненное плохим программистом) тестируется 64 недели. Глава 14: Управление группой тестирования 4 4 5 Повторяющиеся задачи и задачи, выполняющиеся фиксированное число раз Одни задачи решаются в ходе проекта только один раз, другие же по вторяются многократно. • Задачи, выполняющиеся фиксированное число раз. Большая часть из них выполняется только однажды. Например, только один раз анализируется первый черновик руководства пользователя. Сколько бы еще версий руководства ни проходило через ваши руки, первый черновик тестируется только однажды. Бывают и такие задания, которые выполняются заранее известное количество раз. Например, инструкции по установке продукта про веряются обычно трижды: сразу после их написания, перед выходом руководства в печать и в ходе финального тестирования продукта. Сколько бы ни вносилось в программу изменений, насколько бы ни растягивался проект, количество проверок установочных инструкций не меняется. Еще одним примером одноразовой работы является написание плана тестирования. Один раз проводится последняя проверка целостности продукта. Однажды выполняются первое приемочное тестирование, сертификация альфа-версии, сертификация бета-версии и многие тесты устройств. Близки к этому типу и многие тесты граничных условий — те, которые выполняются очень редко. • Повторяющиеся задачи. Большая их часть выполняется на каждом цикле тестирования. Например, в большинстве тестовых групп при получении очередной версии программы прежде всего проводится быстрое тестирование ее функциональности. • Многие регрессионные тесты можно проводить на каждом втором или каждом третьем цикле. Это тоже повторяющиеся задачи, и ко личество их повторений зависит от общей длительности тестирова ния: если, например, программа пройдет 30 циклов тестирования, эти регрессионные тесты будут выполнены 10 или 15 раз. Общее количество времени, необходимого для тестирования програм мы, складывается: • из суммы длительностей всех фиксированных заданий, • из среднего количества времени, уходящего на выполнение всех повторяющихся задач в течение одного цикла, умноженного на количество циклов. Примерно к середине проекта вы уже будете проводить все эти вычис ления и прикидки быстро и практически безошибочно. Основываясь на уже 4 4 6 Часть III: Управление проектами и группами имеющемся опыте, вы сможете точно оценить количество времени, необ ходимого для полного завершения тестирования продукта. Советы Вот несколько моментов, которые часто упускают из виду. • Если один человек тестирует несколько продуктов, учтите дополни тельное время, которое ему потребуется для переключения между ними. Каждый раз, переходя от одного проекта к другому, такому специалисту необходимо будет вспомнить, на чем он остановился и что делать дальше. • Накладные расходы лучше всего выделить в отдельный список. Кроме основной работы, приличное количество времени уходит на совещания, составление отчетов и прочие подобные дела. Постарай тесь поточнее выяснить, сколько именно, учитывая особенности работы и традиции конкретной компании. Соберите своих людей где-нибудь в кафе в спокойной располагающей обстановке и побе седуйте с ними на эту тему. Подготовьте список затрат времени, неизбежность которых можно убедительно объяснить руководству. Если ваши подчиненные тратят на тестирование по шесть часов в день, значит, работа прекрасно организована. • Изучите индивидуальные особенности своих подчиненных. Одни люди по природе более быстрые, чем другие. Некоторые охотно остаются после работы. Одни обладают прекрасными способностя ми к тестированию, а другие лучше справляются с планированием и документированием работы. Кто-то с удовольствием учится новому, а кто-то, напротив, чрезвычайно консервативен. Все это необходи мо учитывать при планировании работ и предварительной оценке сроков их выполнения. Разумеется, всегда поручать людям только ту работу, которая им больше всего по душе, вы не сможете, но знать об их желаниях и склонностях просто обязаны. • |