Home

Автор: Майкл Болтон (Michael Bolton)
Оригинал статьи
Перевод: Ольга Алифанова

Мне пишет тестировщик:

“Я тестирую API. Он принимает различные настройки и параметры. Не знаю, как получить доступ к этим настройкам из самого API, поэтому мне приходится менять их через фронтэнд. Более того, некоторые ответы на определенные запросы длинны и сложны, и я не имею ни малейшего понятия, как это тестировать! Онлайн-примеры тестирования API склонны концентрироваться на проверке кода статуса ответа, верификации схемы, или, возможно, правильности определенной строки. Как мне убедиться, что ответ верен целиком?"

Мой ответ:

Никак.

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

Помимо прочего, неуверенность в правильности чего-то сама по себе предполагает наличие проблем. К примеру, вопрос вскрывает явную проблему: вы недостаточно знакомы с продуктом и тем, как его тестировать. Пока недостаточно. И, спешу заметить, это нормально.

Неуверенность, как что-то тестировать, всегда до какой-то степени присутствует. Учась тестировать, и учась тестировать новый для вас продукт, нормально испытывать некоторую неуверенность и смущение. Не очень-то беспокойтесь об этом. Чтобы тестировать продукт, вам нужно научиться его тестировать. Вы учитесь тестировать продукт, пробуя тестировать продукт – а также сообщая о встреченных вами проблемах и обсуждая их. Обучение – исследовательский процесс. Применяйте исследовательский подход к поиску проблем!

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

Если такого API не существует, возникнет проблема: внутренняя тестируемость вашего продукта ниже возможной. Когда тестировать сложнее или времязатратнее, учитывая ограниченное время на тесты, тестирование также становится более поверхностным. Следствием сниженной тестируемости будет повышенный шанс упустить баги. Хорошей идеей будет уведомить менеджмент о проблемах тестируемости прямо сейчас. Сообщите об этих проблемах. Сделав это, вы уже получите как минимум часть ответа на вопрос, который вам неминуемо (возможно, много позже) задаст менеджер – "Почему ты не нашел этот баг?"

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

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

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

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

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

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

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

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

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

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

Если вы не заметили проблем, вы можете честно сказать, что не заметили проблем. Это не значит, что продукт верен. Правильность может относиться к неимоверному количеству факторов.

Результат хорошо сформулирован и синтаксически верен? Точны ли данные в результате? Достаточно ли они подробны? Не чересчур ли они подробны? Нет ли отсутствующих элементов? Есть ли лишние элементы? Не меняла ли какая-либо функция оригинальные данные (например, в базе данных), трансформируя их в ответ API? Были ли исходные данные вообще верными?

Достаточно ли быстро вернулся ответ? Результат кажется верным, но находится ли система в стабильном состоянии? Результат кажется верным на этот раз; будет ли он верным в следующий раз? Был ли ответ верно залогирован? Если вернулась ошибка, вернулось ли подходящее, полезное сообщение об ошибке, которое легко поймет сторонний разработчик? В плане вопросов, которые мы можем задать – мы еще даже не начинали.

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

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

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

Социальная причина важна, но иногда немного нелепа. Тестировщик должен концентрироваться на поиске проблем, потому что в большинстве случаев никто больше не концентрируется на риске и поиске проблем. Все остальные думают только об успехах.

У разработчиков, проектировщиков и менеджеров есть задача создать полезный продукт, который решит проблемы пользователей. Уникальная роль тестировщика – в способности замечать, если продукт не решает эти проблемы, а также если он привносит новые.

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

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

А вот и практический повод концентрироваться на проблемах: если вы концентрируетесь на риске и усердно ищете проблемы и не находите их, вы можете делать обоснованные выводы о правильности совершенно бесплатно!

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