Записки Тестировщика / Василий Волгин: post #1047 — TG.ME

Есть довольно типичная проблема в интеграционных задачах. Функционал начинают разрабатывать и тестировать, а потом выясняется, что часть сценариев на стороне интеграции вообще не поддерживается. Формально при этом все может выглядеть нормально: - есть задача; - есть общий чек-лист; - есть список функций, которые нужно проверить. Но сам чек-лист не отвечает на главный вопрос: а что конкретно доступно в этой интеграции? Например, перед началом работ можно сделать простую матрицу(сейчас списком, но можно и в виде таблицы): • Функция A: поддерживается • Функция B: не поддерживается • Функция C: поддерживается с ограничениями • Функция D: требует отдельной настройки • Функция E: статус нужно уточнить На первый взгляд элементарная вещь. Но если такой сверки нет, легко получить странную ситуацию: разработка реализует сценарий, QA его тестирует, находит неработающий функционал, а позже выясняется, что работать он изначально и не должен был. В итоге время потрачено, хотя проблему можно было увидеть еще до разработки. Общие чек-листы полезны, но у них есть неприятный побочный эффект: появляется ощущение, что все пункты одинаково применимы к любой интеграции. А это почти никогда не так. Поэтому перед тестированием интеграционной задачи полезно задать вопрос не только: «Как это проверить?» Но и: «А что из этого вообще поддерживает вторая сторона?» Иногда такая простая матрица экономит больше времени, чем еще двадцать пунктов в чек-листе.