Home

Автор: Роберт Сабурин (Robert Sabourin)
Оригинал статьи
Перевод: Ольга Алифанова

Что делать, если в вашем тестовом проекте поджимает время? Когда код запаздывает? Когда дедлайны приближаются? Играете ли вы в "если бы только"? "Если бы только у нас было больше автотестов", или "если бы только наши тесты были устойчивее, чтобы нам не пришлось прогонять такое количество тестов для выявления багов". Проблема с этой игрой в том, что если вы начали в нее играть – уже поздно что-то менять.

Вы добросовестно следуете уже составленному плану, а затем прекращаете тестировать, когда ваше время истекло? Что, если тесты, которые вы не успели провести, ценнее проведенных тестов?

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

Планируйте с учетом изменений

Я всегда начинаю со списка отличных тест-идей, применимых к проекту. Тест-идеия – это описание типа теста, который нужно провести. См. таблицу 1 для примерного списка.

Давайте рассмотрим некоторые поля в таблицах. ID – это всего лишь порядковый номер. Источник – это источник тест-идеи. Для этих идей существует множество источников; некоторые, которыми я пользуюсь регулярно, перечислены в таблице 2.

Таблица 1. Список тест-идей для проекта. Аббревиатуры расшифрованы в таблице 2.

Таблица 2. Источники тест-идей.

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

В тестировании размер имеет значение – отсюда поле "Размер". Я рассматриваю размер тест-идеи как оценку разумного объема усилий, которые нужно вложить для удовлетворительного внедрения этой идеи, учитывая состояние тестируемого ПО, а также навыки и компетентность тест-команды. В недавнем проекте мы использовали очень простую шкалу: маленький, средний, большой. Маленькая тест-идея занимает менее 90 минут для внедрения. Средняя – день, а большая – около недели. Эта шкала предполагает опытного тестировщика и достаточно чистое от багов ПО. Если тест-идеи еще больше – мы разбиваем их на несколько, или реорганизуем их каким-то другим образом.

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

Фиксируйте тест-идеи

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

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

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

Умейте меняться

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

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

1. Идеи основаны на достойной доверия информации?
2. Система готова к этой тест-идее?
3. Существуют ли альтернативные тест-идеи той же ценности?
4. Можно ли скомбинировать эту идею с другими?
5. Можно ли выбрать сокращенную версию этой идеи?

Идеи основаны на достойной доверия информации?

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

Прежде чем мы перейдем к приоритезации тест-идеи, важно рассмотреть надежность источника идеи и нашего понимания ее размера и важности. В крупных интернет-приложениях множество идей происходит из предположений о том, как пользователи будут обращаться с системой. Примером могут быть типы браузеров. Сколько пользователей будут использовать IE, Chrome, Opera или иные браузеры, работая с системой? Обычно значение дается или как ожидаемое абсолютное (10 000 пользователей будут предположительно пользоваться Opera), или как относительный процент (30% пользователей будут предположительно пользоваться Opera). Иногда информация может смотреться как доказуемые фактические данные, хотя на самом деле это приукрашенный домысел.

Итак, как оценивать надежность? Во-первых, проверьте надежность всех фактов, на которых основана тест-идея. Затем присвойте уровень надежности – примерная шкала от 1 до 10, где 10 – абсолютно доказуемый факт, а 1 – полнейший домысел. Когда уровень надежности слишком низок, получите больше информации, прежде чем расставлять приоритеты. Я ищу другие источники, смотрю на прошлые проекты, или беседую с коллегами. Отложите эту тест-идею, пока надежность ее источников не улучшится.

Система готова к этой тест-идее?

В некоторых случаях тест-идея может опережать свое время. Перефразируя Кеннеди – спрашивайте не только о том, готов ли ваш тест к системе, но и о том, готова ли система к вашему тесту.

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

В первом цикле мы нашли множество багов. Во втором мы ожидали найти меньше багов – но нашли еще больше. Многие фичи отлично работали в первом цикле, но начали отказывать во втором.

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

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

Существуют ли альтернативные тест-идеи?

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

Приоритезируя тест-идеи, спрашивайте себя, можно ли получить ту же самую информацию о системе другим способом? Какие альтернативы мне доступны?

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

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

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

Можно ли скомбинировать эту идею с другими?

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

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

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

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

Можно ли выбрать сокращенную версию этой идеи?

Тест-идея может быть чересчур велика. К примеру, я работал над проектом по обновлению старых версий системы до новой версии. В качестве тест-идеи кто-то предложил исчерпывающее тестирование всех возможных комбинаций. У системы было пять поддерживаемых ОС, семь источников ПО, два языка, две локали, и две разные опции установки.

Для проверки всех комбинаций потребовалось бы 280 тест-кейсов (5*7*2*2*2). Каждый занял бы более получаса на прогон (в случае успешного прохождения), и даже в идеальном мире вышло бы 140 часов тестирования.

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

Можно даже серьезно улучшить тест-идею, сократив ее масштаб или фокус. Вы можете столкнуться с такой идеей, тестируя серверные базы данных, требующих миграции со старой структуры на новую: убедиться, что базы данных со всех ранее поддерживаемых версий могут мигрировать на новую версию. Идея звучит простой, но на самом деле она довольно широка. Она включает тестирование, что запись с новым полем в новой ревизии может мигрировать (что произойдет с новым полем?); проверка того же самого для удаленного поля; тестирование поля, у которого изменился тип данных, и миграция тестовой базы данных для всех поддерживаемых версий.

Анализ того, из чего на самом деле состоит тест-идея, позволяет вам лучше принимать решения, что тестировать, а что оставить за рамками.

Начинайте правильно

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

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

Некоторые тестировщики настаивают на необходимости полного тест-плана до старта проекта; понадобится сложная система управления изменениями, чтобы внести малейшую правку. Эти тестировщики будут сопротивляться любом Agile-подходу. В правильной ли они команде? Решение вопроса с их сопротивлением до внедрения приоритезации тест-идей сохранит вам много сил и нервов. Если вы не можете изменить отношение человека, вам, возможно, придется выбрать другой проект и убедить скептиков, продемонстрировав там успех.

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

Приоритезация тест-идей

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

Советую назначать периодические встречи по приоритезации. Они могут стартовать, как только стартовало тестирование, и приоритезация завершается только вместе с завершением проекта.

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

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

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

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

Обсудить в форуме