Home

Оригинальная публикация:http://www.hacknot.info/hacknot/action/showEntry?eid=68

Перевод: Баранцев Алексей, ИСП РАН

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

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

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

Сокращение инструкции по воспроизведению ошибки

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

Решение: лучший способ избежать этой проблемы состоит в том, чтобы просто перечислить все действия, которые необходимы для воспроизведения ошибочного поведения, начиная с запуска приложения. Поместите в шаблон описания дефекта в качестве первого шага, который будет напоминать тестировщикам об этом правиле, примерно такой текст «1) Запустить приложение. 2) <ваш текст здесь>».

Отсутствие описания ошибочного поведения

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

Решение: поместите в шаблон описания дефекта пункт «Ошибочное поведение:» или «Наблюдаемое поведение:», чтобы тестировщик не забыл включить эту информацию.

Отсутствие описания ожидаемого поведения

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

Решение: поместите в шаблон описания дефекта пункт «Ожидаемое поведение:», чтобы тестировщик не забыл включить эту информацию.

Отсутствие обоснования ожидаемого поведения

Проблема: не всегда ясно, почему тестировщик решил, что наблюдаемое поведение ошибочно. В сообщение об ошибке может быть просто написано «должно случиться X» без объяснения того, почему X — правильное поведение. Ссылка на спецификацию требований — вполне подходящее обоснование. Если обоснование апеллирует к некоторому внешнему стандарту, ссылка на соответствующую часть этого стандарта тоже годится.

Решение: поместите в шаблон описания дефекта пункт «Ссылка на требования:», чтобы тестировщик не забыл включить эту информацию.

Повторное открытие старых сообщений для новых ошибок с похожими признаками

Проблема: сообщение об ошибке помечено как FIXED , и все считают, что с этим покончено, но в ходе дальнейшего тестирования тестировщик видит ошибочное поведение, которое очень похоже на то, которое было вызвано ошибкой, которую сочли FIXED . Рассуждая, что поведение является настолько похожим, что это должно иметь ту же самую причину, тестировщик делает вывод, что ошибка, ранее помеченная как FIXED , повторно всплыла, и изменяет статус сообщения об ошибке с FIXED на REOPEN . Это вызывает проблемы у разработчика, потому что повторное открытие ошибки подразумевает, что снова возникли первоначальные признаки ошибки, а не похожие признаки, замеченные тестировщиком. Испытатель, таким образом, выдаёт разработчику неправильный диагноз ошибки, вместо простого сообщения о наблюдаемом ошибочном поведении.

Решение: настаивайте на том, чтобы тестировщики воздерживались от повторного использования старых сообщений об ошибках, если наблюдаемое ошибочное поведение не в точности совпадает с тем, которое описано в старом сообщении. Даже в этом случае и то остаётся некоторая вероятность смешивания различных ошибок, которые вызывают идентичное наблюдаемое поведение. Если есть хотя бы малейшее сомнение, создавайте полностью новое сообщение об ошибке. Разработчик может всегда пометить его как дубликат старого сообщения об ошибке и повторно открыть старое сообщение самостоятельно, если исследование покажет, что новая и старая ошибки имеют одну и ту же причину.

См. также «Диагноз вместо описания симптомов»

Тестирование устаревшей версии программы

Проблема:

«Это исправлено!».
«Это НЕ исправлено!».
«Это исправлено! Вот скриншот, показывающий, что это работает!».
«Плевать я хотел на ваши скриншоты. У меня НЕ работает!».

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

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

Изобретение требований, основанных на личных предпочтениях

Проблема: вообще говоря, набор требований обычно не настолько закончен, чтобы явно определять поведение программы во всех возможных ситуациях. Помимо недосмотра со стороны тех, кто разрабатывал требования, часть их отнесена к «здравому смыслу». Требование типа «пользовательский интерфейс должен соответствовать Microsoft Windows User Interface Guidelines» является весьма широким и может быть сложно для интерпретации в каждом конкретном случае. Вместо досконального следования стандартам, некоторые тестировщики пытаются подменить их требования собственной версией «здравого смысла», принося этим свои недопонимания и неверные толкования. Например, я получил сообщение об ошибке, указывающее, что «подменю не должно появляться, если все подпункты в нём заблокированы». Тестировщик расценил это как «здравый смысл». Однако, стандарты пользовательского интерфейса явно декларируют, что такие подменю должны всегда появляться, даже когда все их пункты заблокированы, чтобы пользователь мог по крайней мере видеть содержание подменю и знал, где найти специфическую опцию, когда она станет доступна. Но сообщение об ошибке весьма решительно заявляет, что поведение «должно» быть другим. Тестировщик сфабриковал требование и решил придать ему значимость, употребив слово «должно», как будто это на самом деле требование.

Решение: см. «Отсутствие обоснования ожидаемого поведения»

Неиспользование снимков экрана

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

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

Использование нечётких или неоднозначных формулировок

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

Решение: науке не известно, однако большой тяжёлый предмет, брошенный со страшной силой, может, по крайней мере, служить предупреждением.

Диагноз вместо описания симптомов

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

Решение: см. «Решение» выше.

Завышение приоритета дефекта

Проблема: некоторые тестировщики демонстрируют тенденцию к завышению приоритета сообщений об ошибках, найденных на более поздних стадиях проекта. По мере продвижения тестирования идентификация новых ошибок становится всё труднее и труднее, поэтому кажется, что дополнительные усилия, потраченные на их нахождение, должны быть скомпенсированы более высоким приоритетом — это, как я полагаю, такой психологический приём. Разработчики обнаруживают, что дефекты, которые в начале проекта расценивались бы как низкоприоритетные, внезапно становятся главными проблемами. Этот эффект может также иметь быть связан с увеличивающимся напряжением или приближающимся крайним срокам.

Решение: для каждого приоритета, поддерживаемого вашей системой управления дефектами, обеспечьте ясное определение, которое может быть использовано для разрешения споров о приоритете того или иного дефекта.

Оправдание плохого покрытия плохими предположениями

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

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

См. «Диагноз вместо описания симптомов»