Приложение 2 Примеры применения некоторых приемов тестирования

1. Условия тестирования.

Тестирование должно проводиться строго в штатных средах работы программного продукта, запрещается тестировать в одной среде, а результаты тестирования относить и на другие среды тестирования. Подобная ошибка является очень распространенной среди новичков-тестеров, которые отождествляют среды тестирования на основании их внешнего сходства. Например, среди новичков-тестеров часто встречаются такие ошибочные действия:

• результаты тестирования продукта под Windows98 относят также и на Windows 95;

• результаты тестирования продукта с использованием MS SQL Server 7.0 относят также и на тестирование с использованием MS SQL Server 6.5;

• результаты тестирования продукта с использованием Internet Explorer 5.0 относят также и на тестирование с использованием Internet Explorer 4.xx.

Такие ошибки могут привести к серьезным последствиям, так как полностью работоспособный функционал в одной среде тестирования, может содержать «Immediate» баги в другой среде тестирования. Чтобы избежать подобных ошибок необходимо строго следовать тестплану, а по спорным вопросам, связанным со средами тестирования надо сразу же вносить ясность.

Исходя из требуемых условий тестирования, его проводят в нормальных условиях функционирования коммерческого программного продукта, то есть в обычных условиях функционирования продукта у заказчика. Недопустимо тестировать программный продукт на:

• некорректно работающих операционных системах,

• операционных системах, Registry которых содержит нежелательную информацию, могущую повлиять на результаты тестирования (в обиходе на «грязных» машинах),

• на операционных системах с установленными другими программными продуктами, компоненты которых могут искажать результаты тестирования («грязные» машины),

• машинах с одновременно работающими другими программными продуктами, за исключением тех, которые описаны в тестплане и в требованиях к среде тестирования,

• на машинах, не соответствующих по своим техническим характеристикам условиям тестирования, например, необходимым условиям по измерению перформанса.

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

2. Интерфейс пользователя

Тестеру необходимо помнить, что заказчик хочет видеть имплементированную в программном продукте функциональность через графический User interface (UI), а не через SELECT по базе, командную строку и т. п. Поэтому к тестированию UI надо подходить особенно серьезно.

UI – это «лицо» программного продукта. Компания разрабатывает программные продукты не для себя и не «вообще», а для покупателей – наших заказчиков, которые будут в первую очередь судить о программном продукте по UI. Ничто не вызывает такого раздражения у заказчика, как уродливость UI, которая будет видна на демонстрациях для его потенциальных клиентов. Увечные UI мало «проходят», у заказчика они обычно вызывают недоумение и отторжение. И риск расторжения контракта. И соответственно, потерю денег, бонусов и т. п.

Каждое окно, включая и диалоговые, должно иметь стандартные элементы управления окном (свернуть, развернуть, закрыть).

Главное окно также должно содержать:

• Строку заголовка (с кнопками сворачивания, разворачивания и закрытия).

• Строку меню. Для удобства работы с меню уровень вложенности меню должен ограничиваться двумя уровнями.

• Инструментальную строку (кнопки вызова команд, помощи и т. п.).

• Строку сообщений или иной элемент, кратко информирующий о текущем состоянии программы, выполняемой операции и т. п.

При выполнении какой-либо операции, связанной с необратимым изменением данных, перед началом выполнения длительной (более 15 мин.) операции по обработки данных должен выводиться запрос на подтверждение. При этом запрос должен содержать возможность отказа от выполнения операции, или, в зависимости от особенностей программного продукта - альтернативный путь выбора или выполнения операции.

Все элементы пользовательского интерфейса должны активизироваться как с помощью графического манипулятора (мышь, трекбол – у лэптопов и ноутбуков), так и с помощью только клавиатуры (функциональных клавиш и клавиш управления курсором). Если перемещение фокуса на заданный элемент управления с помощью клавиш невозможно, то это является багой и подлежит занесению в баг-лист с приоритетом не ниже «medium». Проверка активизации всех элементов пользовательского интерфейса с помощью клавиш должна обязательно присутствовать в тестплане по данному программному продукту.

Пример:

N%	MATS	Test Type	Test Description	Expected Result	Passed / Failed	Comments	Build	Date tested	Tester
1		Keyboard controls	Verify you can activate all controls in Cache tab using keyboard keys only.	All controls are activated.	Passed		1011	10/12/00	Ivanov

Если имеется ошибка, то:

N%	MATS	Test Type	Test Description	Expected Result	Passed / Failed	Comments	Build	Date tested	Tester
1		Keyboard controls	Verify you can activate all controls in Cache tab using keyboard keys only.	All controls are activated.	Failed	KBD1 (medium)	1011	10/12/00	Ivanov

Должно обеспечиваться выделение выбранных пользователем элементов управления стандартным для операционной системы способом в пределах рабочего поля окна или объекта. Если выделения элемента управления стандартным способом не происходит, то это является багой и подлежит занесению в баг-лист с приоритетом не ниже «high».

В том случае, когда какое-либо окно программы после открытия не имеет выделенного по умолчанию элемента управления, то это является багой и подлежит занесению в баг-лист с приоритетом не ниже «medium». Если выделение объекта производиться нестандартным способом, то это должно быть отражено в отдельном пункте тестплана.

3. Воспроизводимость результатов тестирования.

Главное требование к результатам тестирования - это их воспроизводимость.

Воспроизводимость результатов, полученных одним тестером на одной машине подразумевает возможность повторения этих результатов независимо от первого тестера другим тестером на другой машине при одних и тех же условиях тестирования.

Необходимо напомнить, что результатом тестирования (по данному пункту тестплана) является либо подтверждение работоспособности продукта по этому пункту, либо записанная в баг-лист бага. Соответственно, этот результат должен воспроизводиться. Невоспроизводимый результат никакой практической ценности для обеспечения качества продукта не имеет.

Для обеспечения воспроизводимости результатов тестирования необходимо соблюдать следующие правила:

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

• не заносить «нестабильные» («unstable») баги, так как их в дальнейшем не удастся повторить. Границей между стабильной и нестабильной багой является минимальное число циклов действий воспроизведения баги. Статистически достаточным является три проводимых последовательно цикла воспроизведения баги. Если бага все три раза воспроизвелась, то ее можно считать стабильной.

Чаще всего, когда есть сомнения в стабильности баги, для перепроверки баги “на стабильность” достаточно:

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

• перезапустить SQL-сервер (для приложений баз данных) и повторить действия, вызывающие багу;

• перезапустить Internet Information Server (для Web-приложений) и повторить действия, вызывающие багу;

• перезапустить терминальную программу (при работе с удаленным хостом Unix) и повторить действия, вызывающие багу;

• перезапустить программу-демон (при работе с Unix);

• перезагрузить операционную систему.

После того, как все эти действия были проведены, а “сомнительная” бага проявляется, ее можно считать стабильной и заносить в баг-лист.

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

4. «Known feature»

Разрабатываемые коммерческие программные продукты обычно у заказчика функционируют в среде:

• программных продуктов, уже имеющихся у заказчика - его собственной разработки;

• программных продуктов главных мировых поставщиков программного обеспечения;

• программных продуктов, ранее разработанных компанией;

• программных продуктов третьих фирм.

Некоторые программные продукты главных мировых поставщиков программного обеспечения и программные продукты третьих фирм обладают так называемыми «known feature» – «известными проблемами», которые по сути своей являются выявленными, но еще не исправленными ошибками (исправление которых проводится, как правило, в следующей версии программного продукта). Поэтому при разработке программного продукта все баги, связанные с «known feature» (по другим программным продуктам) также должны заноситься в баг-лист.

В любом случае багу в баг-лист необходимо записать, потому что заказчику неинтересно, почему что-то не работает, ему необходим программный продукт в соответствии с его запросами. В соответствии с записанной багой проджект менеджер, дизайнер и девелоперы должны принять меры, чтобы найти выход из сложившийся ситуации для обеспечения требований заказчика (или согласовать возникшее положение с «known feature» на проекте с заказчиком).

5. Здравый смысл.

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

Пример:

Задизайнирована и проимплеменчена небольшая утилита ATE для операционной системы Linux 6.2. При прохождении тестплана баг по функциональности не найдено. Для запуска утилиты применяется команда:

java -classpath .:./lib/parser.jar:./lib/jaxp.jar -Djava.rmi.server.codebase=file:/ATEHOME -Djava.security.policy=./rmi.policy com.bios.ate.controller.emulator.ATEServer 2001

С формальной точки зрения ничего из ряда вон выходящего в подобной процедуре запуска нет – обычная командная строка запуска Linux. Но здравый смысл подсказывает, что простому пользователю сразу и правильно набрать все это будет крайне трудно, риск ошибиться в букве или в точке весьма велик. Вряд ли ATE будет запущена менее чем с третьего раза……..

В данном случае, согласуясь со здравым смыслом, тестер должен записать багу с приоритетом не ниже “medium”. Описание баги должно включать требование к девелоперам создать один (исполняемый) файл “Start_ATE”, содержащий скрипт запуска утилиты ATE. Запуск файла в Linux осуществляется очень просто:

./Start_ATE

6. Действия тестера в случае возникновения проблем с прохождением тестплана.

Тестплан должен быть пройден полностью и в установленные лид-тестером сроки. Однако иногда могут возникать проблемы, не позволяющие пройти тестплан. Объективными причинами появления таких проблем чаще всего являются:

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

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

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

Первое правило, которое тестер-новичок должен соблюдать во всех случаях: необходимо сообщить о возникшей проблемной ситуации своему непосредственному начальнику – лид-тестеру (или саблиду). Неинформирование лид-тестера о сложившейся проблемной ситуации является грубым нарушением служебных обязанностей тестера и может привести к срыву запланированных работ. Лид-тестер должен принять соответствующее решение (по устранению возникшей проблемы), которым и должен в дальнейшем руководствоваться тестер.

В любом случае, в данной ситуации самым худшим из всех поступков тестера, является замалчивание проблемы.

Необходимо заметить, что, столкнувшись с проблемой, тестер не должен сразу же, беспомощно разводя руками, идти к лид-тестеру и взваливать на него решение каждой мелочи, а должен в максимальной степени (использовав все свои профессиональные способности) принять меры к преодолению возникшей проблемы, дать по возможности максимально объективную оценку возникшей проблеме и попытаться определить затраты рабочего времени на преодоление прооблемы. Тестирование в компании носит гибкий характер, поэтому надо активно искать пути преодоления трудностей, а не пасовать перед первой же проблемой.

Для принятия тестером правильного решения о том, что проблема с прохождением тестплана является критической, необходим опыт работы в реальном проекте. Для этого в компании новичку-тестеру дается месячный испытательный срок. В течение этого срока новичок-тестер должен закрепить практическим опытом полученные в Учебном Центре знания.

При выполнении практических заданий в Учебном Центре, учащийся должен исходить из того, что проблема наступила, если для ее преодоления потребуется 1-2 часа учебного времени, выделенного на прохождение учебного тестплана. Если учащийся не может пройти данный пункт тестплана, то должен сообщить об этом в письме по электронной почте своему преподавателю. Учебный процесс максимально приближен к реальному тестированию, преподаватель в данном случае выполняет роль лид-тестера.

В целом, для достижения максимальной эффективности тестерского труда при прохождении тестплана надо руководствоваться рядом достаточно простых принципов:

• вначале надо пройти максимальное число доступных для проверки пунктов тестплана (чтобы быстрее получить общую картину состояния билда), а уже после этого вернуться к проблемным пунктам, если таковые имеются;

• на начальном этапе прохождения тестплана надо стремиться к выполнению максимального объема работ по обеспечению прохождения отдельного конкретного пункта тестплана, то есть готовить все необходимые материалы, записывать все выполненные действия и т. п., чтобы при прохождении этого пункта тестплана в следующий раз (на следующем билде) потребовались бы минимальные затраты рабочего времени;

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

• Примечание. Приоритет баги жестко предопределен только в одном случае: если статус пункта тестплана MATS – то бага в MATS пункте всегда получает приоритет «Immediate».

06/20/19	Page 43