Часть I. Процесс быстрого тестирования. ворить с разработчиком и позволить ему убедить себя в том, что дефект при­ сутствует в самом тесте, или же в том

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

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

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

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

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

Как проводить опросы претендентов

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

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

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

• Задайте вопросы, которые могут продемонстрировать, обладает ли канди­ дат перечисленными выше качествами, которые необходимы для того, что­ бы успешно справиться со своими обязанностями. Обычно вопросы, подоб­ные " Достаточно ли вы умны для выполнения такой-то работы? " или " Доста­ точно ли вы терпеливы, чтобы выполнять обязанности, на которые претендуе­ те? ", едва ли дадут нужную информацию. Разумеется, можно предложить кан­ дидату рассказать о предыдущей работе в других местах; такой рассказ может пролить свет на некоторые из этих качеств. Например, можно поинтересо­ ваться: " Приходилось ли вам менять проектные приоритеты в тех случаях, ко­ гда требовалось немедленно перейти от тестирования продукта А к тестирова­ нию продукта В? Если да, то как это все происходило? Были ли у вас какие-либо затруднения при изучении технологии, связанной с продуктом В? С учетом приобретенного опыта, что у вас получилось хорошо? Что бы вы хотели изме­ нить? " Если для формирующейся группы тестирования подыскивается работ­ ник, обладающий одним или несколькими из перечисленных выше качеств, стоит заблаговременно подготовить набор вопросов для выяснения области интересов кандидата.

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