Home

Автор: Маарет Пюхяярви (Maaret Pyhäjärvi)

Оригинал статьи

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

Я оттачивала свои навыки исследовательского тестирования, изучая продукты через графический интерфейс. Я практически слышу, как продукт шепчет мне "Нажми сюда… Введи что-нибудь другое… Смотрела ли ты в логи?"

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

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

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

Почему исследовательское тестирование API важно?

Я знакома с двумя взглядами на хорошее тестирование – как на тестирование, создающее артефакты, и как на тестирование как деятельность. Узнала я об этом, работая бок о бок с Йевеллином Фалько, увлеченным тестированием разработчиком. Когда он излагал свои взгляды на тестирование, становилось ясно, что я смотрю на тестирование иначе. При этом мы оба говорили о хорошем тестировании, но с разных точек зрения.

Тестирование как создание артефактов

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

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

Артефакты тест-автоматизации дают нам, в лучшем случае:

• Спецификацию – мы знаем, что именно мы создаем.
• Обратную связь – мы знаем, сделали ли мы то, что планировали.
• Регрессию – мы стараемся, чтобы со временем ничего не испортилось.
• Гранулярность – мы можем определить, что пошло не так, если тест упал.

Тестирование как деятельность (исследовательское тестирование)

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

В отличие от тестирования как создания артефактов, исследовательское тестирование дает нам:

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

Что дает нам тестирование?

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

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

Более того, исследование API рассматривается как нечто, предназначенное для программистов. Выскажусь конкретнее – есть ложное представление, что исследовательское тестирование не может использовать программирование/автоматизацию и является исключительно ручной деятельностью.

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

Пример API с ApprovalTests

Потратив некоторое время на изучение вопроса и думая о REST API, или даже устаревшем Cobol APPC API и фреймворках/библиотеках, обычно использующихся программистами, я остановилась на ApprovalTests. Автор – мой приятель-разработчик, который очень полагается на свои роскошные юнит-тесты. Я обрадовалась возможности поискать проблемы методом свободного поиска.

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

У ApprovalTests несколько основных точек соединения:

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

Лично я достаточно разбираюсь в программировании, чтобы оценить IDE-инструмент и фичу автоматического дополнения слов. В VisualStudio она зовется Intellisense. У меня как будто бы есть интерфейс: я ввожу несколько букв, и программа сама предлагает мне варианты. Этот интерфейс можно исследовать так же, как и любой другой! Инструменты показывают, что входит в API.

Используя IDE-дополнение слов, я узнала, что в API Approvals множество возможностей. Вот пример для различных вариантов выбора при тестировании определенных технологий с Approvals. Документация показывает, что Approvals.Verify() будет базовым сценарием.

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

Позже я узнала, что это связано с ведущим словом. Если назвать все ReportWith – это поможет быстрее вычленить репортеров.

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

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

У API есть взаимосвязи с другими инструментами, особенно с раннерами тестов (к примеру, nUnit и MSTest). Я хотела, чтобы мое окружение позволило исследовать сходства и различия между ними. Случайный порядок установки этих частей выявил баг в комбинации двух раннеров с каналом доставки (Nuget). В процессе тестирования я нарисовала карту окружения, с которым работала. Карта – это источник моих идей для тестирования зависимостей.

Не полагаясь только на доступную в онлайне информацию, я активно искала ее. Я спрашивала разработчика, что делают Approvals и Reporters, и получила длинный список того, что некоторые делают, а некоторые – нет. Список стал отличным источником идей для тестирования и помог довести до ума пользовательскую документацию.

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

Продолжение следует.

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