Home

Автор: Майкл Болтон (Michael Bolton)
Оригинал статьи
Перевод: Ольга Алифанова.

В прошлый раз я начал давать подробный ответ на вопрос, "Выполняете ли вы исследовательское тестирование, тестируя API? Как вы это делаете?"

Я начал с того, что перефразировал первый вопрос вот так:

Если у продукта есть API, тестируете ли вы его?

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

Заметим, что в методологии Rapid Software Testing тест – это действие, выполненное человеком, а не отдельная проверка или документированная тест-процедура. Тест – это сгусток исследования и экспериментов, выполняемых вами. Он может включать тысячи автоматизированных проверок или всего одну – а может и вовсе их не включать. Частично он может быть оформлен в письменном виде, закодирован как особая процедура. Тестирование может поддерживаться при помощи инструментов, документов, других артефактов или процессных моделей. Но самая важная часть тестирования – это то, о чем тестировщики думают и что они делают.

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

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

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

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

Предупреждаю, HTSM (Heuristic Test Strategy Model) – это не шаблон, не сценарий. Когда я сталкиваюсь с проектом и продуктом, идеи тестов приходят мне в голову в основном потому, что их рождает мой опыт, рефлексия, критический анализ и обратная связь. Я пользуюсь HTSM для генерации идей, дабы помочь им развиваться, если я буксую; я могу также использовать ее ретроспективно, как чеклист, по которому я пересматриваю и оцениваю свою стратегию и идеи о тестовом покрытии. А еще я могу пользоваться ей как способом описания работы тестировщика и передачи идей другим людям, как, например, сейчас.

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

Я помогаю кому-то – заказчику, разработчикам и другим заинтересованным лицам – оценивать качество продукта. Думая о ценности, мы зачастую думаем о ценности продукта для платежеспособных заказчиков и конечных пользователей, но этим круг лиц, которых интересует ценность продукта – или которые могут угрожать этой ценности -  не ограничивается. Качество – это ценность для значимого лица, так чьи же ценности будут значимыми? Кого мы упустили? (Эвристика Project Environment/Mission).

Прежде чем делать что-то еще, мне нужно хотя бы примерно разобраться, каким временем на выполнение миссии я располагаю. Пока я этим занят, я буду задавать другие относящиеся к временным рамкам вопросы о проекте: не приближается ли какой-либо дедлайн? Как часто появляются билды? Сколько времени мне нужно посвящать отчетам или иным артефактам? (Эвристика Project Environment/Schedule).

Тестировал ли этот продукт кто-либо еще? Кто это? Где он? Можно ли с ним поговорить? Если нельзя, существуют ли результаты или артефакты этого тестирования, которые могут мне помочь? Я участник команды? Какими навыками мы располагаем? Какие навыки нам нужны? Project Environment/Test Team

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

Что еще может понадобиться заказчику, разработчикам и другим заинтересованным лицам сейчас или позднее? Данные, сгенерированные для тестирования? Код автотестов? Результаты статистических тестов? Визуализация этих результатов? Инструменты, созданные мною, и документация к ним? Описание моего восприятия продукта? Формальные отчеты для регулирующих органов и аудиторов? ? Project Environment/Deliverables Я продолжаю пересматривать свою миссию и желаемые результаты в течение всего хода проекта.

Итак, что же за штуку мне нужно тестировать? Project Environment/Test Item Сверившись с миссией, я перехожу к простым вещам, чтобы начать изучать продукт. Начинать можно с чего-то одного, или заняться несколькими вещами параллельно.

Я разговариваю с разработчиками, если они доступны. Еще лучше, если я участвую в совещаниях, посвященных дизайну и планированию продукта. Моя задача на этих совещания- учиться, ратовать за тестируемость, выдвигать идеи и задавать вопросы о проблемах и рисках. Я спрашиваю о тестировании, проведенном разработчиками, и проверках, которые настроены ими. Project Environment/Developer Relations

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

Я изучаю документацию для API и продукта в целом. (Эвристика Project Environment/Information). Я хочу выработать понимание продукта – услуг, которые он предлагает, способов контроля за продуктом, его роли в окружающих его системах. Я аннотирую документацию или веду отдельные заметки, чтобы мои находки можно было потом вспомнить и обсудить. В ходе этого я обращаю особое внимание на любую неполноту или затруднение в понимании.

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

В ходе чтения документации я спрашиваю себя, какие простые, обычные, нормальные вещи я могу проделывать с продуктом. Если продукт доступен, я провожу симпатическое тестирование, пробуя отправить ряд базовых запросов при помощи инструмента, позволяющего прямое взаимодействие с продуктом через его API. Возможно, этот инструмент разработан внутри компании, или создан для API-тестирования, как Postman или SoapUI – или, возможно, я буду использовать интерпретатор вроде Ruby IRB вместе с полезными библиотеками – например, HTTParty (Эвристика Project Environment/Equipment and Tools).

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

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

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

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

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

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