Автор: Дейв Вестервельд (Dave Westerweld)
Оригинал статьи: https://offbeattesting.com/2018/07/30/api-testing-is-exploratory-testing/
Перевод: Ольга Алифанова

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

Это верно вне зависимости от того, каким видом тестирования вы занимаетесь. Размышляя о тестировании, требующем глубоких технических навыков, мы полагаем, что оно не особенно требует исследования, но лично я так не думаю. К примеру, я много тестирую API и работаю над курсами, обучающими API-тестированию. Это тестирование тоже требует исследовательского подхода!

Множество инструментов может помочь вам с тестированием API, и я пользуюсь многими из них. позвольте внести ясность: использование инструментов не отменяет исследования. Я находил в API множество багов, но сделал я это совсем не способом "заставить инструмент прочитать спецификацию в Swagger, а потом нажать на запуск". Я сделал это, изучая API. Большая часть инструментов для тестирования API направлена на то, чтобы помочь вам настроить автоматизированный регресс. У регрессионного тестирования есть свои задачи и своя польза, но не забывайте, что те же самые инструменты могут помочь вам при исследовании вашего API.

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

Ошибки проектирования

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

Отсутствующая функциональность

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

Проблемы алгоритмов

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

Заключение

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

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