Home

Автор: Аарон Ходдер (Aaron Hodder)

Оригинал статьи: http://testerkiwi.blogspot.ru/2016/02/lean-testing-in-theory-and-practice.html#more

Перевод: Ольга Алифанова

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

Мое любимое определение тестирования дал Кем Кейнер: «Тестирование – это эмпирическое исследование, которое проводится с целью предоставить заинтересованным лицам информацию о продукте или сервисе, который тестировался».

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

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

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

«Люди, совместно работающие – это самая важная часть контекста любого проекта». Знание существует в головах у людей. Оно не прячется в спецификациях и письмах – это просто репрезентация знания. В проекте у каждого есть кусочек головоломки, но никто не знает головоломку целиком. Любая практика, улучшающая социальное взаимодействие – и любой инструмент, позволяющий мне внятно объяснить, что происходит – это хорошо.

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

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

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

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

Мы должны подстраивать свои практики под окружение, а не пытаться выкроить из окружения нечто подходящее для наших практик.

Если принципы школы контекстного тестирования описывают нашу реальность и то, как следует думать о ней, есть ли принципы, рассказывающие, как нам действовать?

Lean-тестирование

Три-четыре года назад я столкнулся с принципами безотходной (lean) разработки ПО, созданными Мэри и Томом Поппендиком и основанными на принципах безотходного производства. Принципы отозвались в моей душе как нечто знакомое. Я адаптировал их и применил их к тестированию. Если принципы контекстной школы описывают мир и наш взгляд на него, то, с моей точки зрения, принципы lean-тестирования описывают наши действия в этом мире:

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

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

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

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

Сотрудничество и коммуникация. Мы работаем не в вакууме, и я стараюсь рассказать, что я делаю и как я это делаю любому, кому это интересно. Это очень важно для поддержания прозрачности и доверия. Кстати говоря…

Поддерживайте прозрачность и доверие. Наше главное имущество, помогающее добиваться сделанного дела и делать свою работу на «пять» - это доверие. Множество театрального тестирования и мусорной деятельности возникает там, где доверие на нуле – дабы избежать наказания и критики. Я верю в значимость отчетности. Зачастую, если меня спрашивают о метриках или статусных отчетах в определенных форматах – это их единственный способ спросить «Что вообще происходит?». Я стараюсь максимально держать всех в курсе. Это также означает, что вместо ответа «тест прошел/тест упал», я пытаюсь рассказать, как я это тестировал, и почему я считаю, что это баг (или не баг). Ошибки моего мышления и аргументации сразу же видны окружающим. Окружение, основанное на доверии, позволяет мне быть прозрачным в своем труде, а прозрачность – основа доверия.

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

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

IEEE829-документация и предварительное создание кейсов

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

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

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

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

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

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

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

Говоря о заранее созданных тест-кейсах, я, безусловно, предпочитаю более исследовательский подход к тестированию, и вот почему:

1. В начале проекта мы знаем о нем меньше всего.
2. Опытные тестировщики, владеющие техникой исследовательского тестирования, выполнят сотни тестов за всего лишь одну сессию. Только некоторые из них достойны повторного прогона.
3. Большая часть тестов рождается из результатов прогона предыдущих тестов.
4. Полезность теста зачастую неясна до того, как он будет прогнан. Вы не знаете, стоит ли поднимать этот камень, пока вы не поднимете его и не увидите, что под ним скрывалось.
5. Тестировщики, следующие сценарию, все равно отвлекутся от него.
6. Разные тестировщики по-разному интерпретируют инструкции. В результате два разных тестировщика по-разному выполнят один и тот же кейс.

Следовательно:

1. Тест-кейсы говорят вам совершенно не то, что вы думаете.

Давайте пересмотрим принципы lean-тестирования, которые я предлагал выше, чтобы подвести итог обсуждения тест-кейсов и обширной документации.

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

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

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

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

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

Итак, что же дальше?

Если настала пора отбросить наши предварительно написанные кейсы и обширную документацию, как мы заполним эту пустоту? Чем займемся вместо этого?

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

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

Эвристическая модель стратегии тестирования

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

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

Сессионный тест-менеджмент

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

Важные элементы SBTM:

Чартер: кратко описывает задачу или миссию тест-сессии

Ограниченная по времени сессия: непрерывный период времени, потраченный на тестирование или преследование целей чартера. Обычно сессия длится от 60 до 120 минут, но вы можете ограничить ее половиной рабочего дня или целым днем за счет гранулярности измерений.

Отчет о сессии: отражает все произошедшее во время сессии и может включать:

• Чартер или миссию
• Окружение
• Время начала и окончания
• Имя тестировщика
• Заметки о том, как проводилось тестирование
• Список найденных багов
• Список найденных проблем
• Время, потраченное вне чартера

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

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

Пример отчета о тест-сессии

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

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

Узнать больше о сессионном тест-менеджменте можно здесь:

http://www.satisfice.com/sbtm/

http://www.satisfice.com/articles/sbtm.pdf

http://www.satisfice.com/articles/et-article.pdf

ПО для создания майнд-карт

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

Итак, с чего начать?

1. Начните планировать фреймворк

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

2. Начните учиться и собирать информацию

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

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

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

Кликните на картинку для увеличения

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

3. Начните путешествие

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

Вот пример: я что-то устанавливал, и программа спросила меня про номер порта (3306). Интересненько. Помечу-ка я это как тест-идею.

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

4. Создавайте тест-чартеры

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

5. Продолжайте подправлять карту

Ваша карта – это модель. Меняется модель – меняется и карта. То, что вы считали важным, будет удаляться, а то, о чем вы и не подозревали, станет неотъемлемой частью карты. Карта отражает ваше личное понимание продукта на данный момент времени.

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

Отчетность, отслеживаемость – это не синонимы догматизма и перегрузок. Я предлагаю вам способ сделать тест-менеджмент более «чистым». Возможно, в вашем контексте существуют и способы получше моего.

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