Такая вещь, как API (от англ. application programming interface — программный интерфейс приложения) – очень интересный виртуальный объект как по своей структуре, так и по возможностям. Это универсальный инструмент, с помощью которого пользователь может заставить несколько приложений работать вместе. API предоставляет возможность интерпретировать ПО, невзирая на его сложность или простоту.
При этом API может меняться и модифицироваться. Если пользователь взаимодействует исключительно с внутренним API, то проблем не возникнет. А вот если отдел разработки и, соответственно, группа QA-инженеров обязана взаимодействовать с внешними ресурсами, могут возникнуть определенные трудности.
Ведь любая часть API может модифицироваться или сломаться в самый неподходящий момент. И чтобы подобное случалось с вами как можно реже, стоит просчитывать ситуацию наперед, то есть создавать и постоянно тестировать API.
Полезно будет воспользоваться следующими стратегиями.
Вначале тесты
Данная стратегия основана следующем: пользователь должен понять тот факт, что приложение постоянно будет меняться. И не получится просто пользоваться API и рассчитывать, что спустя некоторое время оно будет одинаково стабильным.
Сразу же после создания API нужно разрабатывать целый блок юнит-тестов, которые позволяют убедиться в том, что продукт работает корректно. Затем данные тесты стоит выполнять регулярно после внедрения новых версий API (проверяем, что нет никаких конфликтов, что все стабильно и надежно на системном уровне).
Естественно, что подобный метод требует определенного ресурса усилий, так как тесты стоит создавать заранее, а новые оригинальные проверки добавлять уже после процесса создания API. Но со временем это покажется вам очень хорошей стратегией!
Отслеживание дефектов при работе API
Можно попробовать вместо тестирования API следить за его работой и исправлять дефекты уже по факту обнаружения. Но подобная стратегия не всегда находит одобрение в кругу тестировщиков, поскольку их первоочередная задача состоит в том, чтобы находить и фиксировать баги до того момента, пока ПО попадет широкое использование.
Некоторые разработчики советуют в данной ситуации придерживаться серединного подхода. Его особенность состоит в том, чтобы просто отслеживать баги и разбираться в их природе уже после того, как будет зафиксирован факт, что что-то сломалось.
Стоит понимать, что мониторинг багов не должен быть слишком высокотехнологичным. Однако стоит учитывать, что природа найденного дефекта полностью изучена и не повлечет за собой ряд дополнительных негативных последствий.
Можно как заручиться особенным программным обеспечением, которое будет заточено исключительно на слежку за API, так и привлечь группу пользователей с имеющегося штата сотрудников, которые будут сообщать отделу разработки в случае поломок или обнаружения системных аномалий.
Краткий вывод
Проверка стороннего API полностью схожа с тестированием любого среднестатистического программного обеспечения. Достаточно заранее продумать выбранную стратегию проверки и следовать заданным критериям. В процессе полезно будет фиксировать все проблемы, с которыми сталкивался отдел QA, рекомендации, которые можно предоставить отделу разработки и технической поддержке, а также сформировать удобное и понятное руководство для конечного потребителя.
Оставить комментарий