Home

Автор: Майкл Болтон (Michael Bolton)
Оригинал статьи: http://www.developsense.com/blog/2018/07/exploratory-testing-on-an-api-part-1/
Перевод: Ольга Алифанова

Меня недавно спросили, занимаюсь ли я исследовательским тестированием API, и как именно я это делаю. Вот мой ответ.

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

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

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

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

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

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

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

Тестирование – исследовательский по природе своей процесс. Исследовательский процесс может время от времени включать в себя демонстрацию, и некоторые демонстрации можно проводить при помощи проверок. Откуда берутся проверки? Из тестирования!

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

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

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

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

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

Узнавая о рисках, вы разрабатываете стратегии и идеи тестирования этих рисков. Разработка стратегий – это исследовательский процесс.

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

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

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

Иными словами, практически все, что мы делаем в процессе тестирования, кроме механического запуска проверок – это исследовательский процесс. Вопрос "проводите ли вы исследовательское тестирование API" равнозначен вопросу "Если в вашем проекте есть API, тестируете ли вы его?"

Ответ, конечно же, "Да". Но как? Об этом мы поговорим во второй части.

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