Приветствую! Справедливое замечание! Немного опишу данный кейс с нашей стороны. В задачи нашего направления не входит тестирование фронтальных частей систем (за редким исключением, например, сервисы и приложения связанные с СБП). В основном, мы занимаемся тестированием взаимодействия между системами, а фронтом занимаются наши коллеги из смежных отделов (как ручное тестирование, так и UI-автотесты). И через Postman мы просто генерим нужные нам операции для проверки объектов и взаимодействий которые находятся "под капотом". В данном случае для нас действительно нет принципиальной разницы, будет сделана операция через фронт или же сформируется после выполнения цепочки запросов из Postman. А с учётом того, что это существенно экономит нам время, мы можем выделить его на проверку именно тех взаимодействий которые нам и требуются.
Полностью с Вами согласен, что при ручном тестировании фронтальных систем нельзя полностью полагаться на решения по автоматизации, а надо пощупать фронт собственными руками.
Вопросы правильные и также заслуживают внимания. Однако, в рамках одной статьи или комментария достаточно проблематично дать исчерпывающее описание всех возможностей какого-либо софта. Более того, Postman для нас является лишь одним из решением в стеке технологий и потому мы не выстраиваем процессы вокруг Postman, а встраиваем его в наши рабочие процессы (которые в свою очередь могут трансформироваться после добавления нового инструмента). Поэтому я всего лишь хотел поделиться теми подходами, которые мы используем на практике и которые помогли нам оптимизировать те или иные процессы.
Но если вас действительно интересуют ответы на эти вопросы, то буду рад дать на них ответы в отдельном посте!
Половину героев угадал (3 и 4), половине был приятно удивлён!
По третьему сценарию добавил бы, что, когда длительное время работаешь с одним вендором, так или иначе в процессе анализа дефектов собирается общая картина по тому в каких местах чаще всего встречаются дефекты. "Я точно уверен, что здесь у вас баг, но у меня пока нет достаточно доказательств" - очень знакомая ситуация. Немного не вяжется с концепцией (ведь герой впервые видит преступников), но пересечения имеются.
Четвёртый сценарий сам по себе содержит основную идею тестирования, что работать надо серыми клеточками, а физическая деятельность должна быть максимально оптимизирована.
С пятым героем, увы, не так хорошо знаком. Однако, полностью согласен с тем, что если кто-то говорит, что где-то нет багов, то надо всё бросать и в срочном порядке проверять этот функционал.
Шестой герой выдавил из меня скупую слезу, ведь в детстве это был мой любимый сериал. С тезисом полностью согласен, грамотно подобранный и 'надрессированный' инструментарий позволяет существенно оптимизировать рабочие процессы.
Не так часто получается применять подобные подходы на практике, однако, перед приёмочными испытаниями всегда составляются пользовательские сценарии для демонстрации функциональности.
Зачастую, во время испытаний просят выполнить действие, которое не входило в первоначальный сценарий. И потому, в процессе тестирования исследуются всевозможные (в рамках разумного) отклонения от сценария.
Продукт не должен работать по принципу "Шаг влево, шаг вправо - расстрел".
И если при тестировании отталкиваться от общепринятых практик и личного опыта, то действительно можно обнаружить неявные дефекты.
Уже на основании этих дефектов вносить правки в спецификацию и расширять тестовую модель, что в конечном счёте неизбежно улучшает пользовательский опыт. А если что-то делает пользовательский опыт лучше, то это надо применять
Имеются предположения по новым детективам и их головным уборам, но лучше дождусь следующей части. :)
Спасибо за отзыв! :)
Рад, что статья была полезна :)
Приветствую!
Справедливое замечание!
Немного опишу данный кейс с нашей стороны.
В задачи нашего направления не входит тестирование фронтальных частей систем (за редким исключением, например, сервисы и приложения связанные с СБП).
В основном, мы занимаемся тестированием взаимодействия между системами, а фронтом занимаются наши коллеги из смежных отделов (как ручное тестирование, так и UI-автотесты).
И через Postman мы просто генерим нужные нам операции для проверки объектов и взаимодействий которые находятся "под капотом".
В данном случае для нас действительно нет принципиальной разницы, будет сделана операция через фронт или же сформируется после выполнения цепочки запросов из Postman.
А с учётом того, что это существенно экономит нам время, мы можем выделить его на проверку именно тех взаимодействий которые нам и требуются.
Полностью с Вами согласен, что при ручном тестировании фронтальных систем нельзя полностью полагаться на решения по автоматизации, а надо пощупать фронт собственными руками.
Приветствую!
Вопросы правильные и также заслуживают внимания.
Однако, в рамках одной статьи или комментария достаточно проблематично дать исчерпывающее описание всех возможностей какого-либо софта.
Более того, Postman для нас является лишь одним из решением в стеке технологий и потому мы не выстраиваем процессы вокруг Postman, а встраиваем его в наши рабочие процессы (которые в свою очередь могут трансформироваться после добавления нового инструмента).
Поэтому я всего лишь хотел поделиться теми подходами, которые мы используем на практике и которые помогли нам оптимизировать те или иные процессы.
Но если вас действительно интересуют ответы на эти вопросы, то буду рад дать на них ответы в отдельном посте!
Доброго времени суток :)
Половину героев угадал (3 и 4), половине был приятно удивлён!
По третьему сценарию добавил бы, что, когда длительное время работаешь с одним вендором, так или иначе в процессе анализа дефектов собирается общая картина по тому в каких местах чаще всего встречаются дефекты.
"Я точно уверен, что здесь у вас баг, но у меня пока нет достаточно доказательств" - очень знакомая ситуация.
Немного не вяжется с концепцией (ведь герой впервые видит преступников), но пересечения имеются.
Четвёртый сценарий сам по себе содержит основную идею тестирования, что работать надо серыми клеточками, а физическая деятельность должна быть максимально оптимизирована.
С пятым героем, увы, не так хорошо знаком. Однако, полностью согласен с тем, что если кто-то говорит, что где-то нет багов, то надо всё бросать и в срочном порядке проверять этот функционал.
Шестой герой выдавил из меня скупую слезу, ведь в детстве это был мой любимый сериал. С тезисом полностью согласен, грамотно подобранный и 'надрессированный' инструментарий позволяет существенно оптимизировать рабочие процессы.
Огромное спасибо за продолжение статьи! :)
Спасибо за статью!
Не так часто получается применять подобные подходы на практике, однако, перед приёмочными испытаниями всегда составляются пользовательские сценарии для демонстрации функциональности.
Зачастую, во время испытаний просят выполнить действие, которое не входило в первоначальный сценарий. И потому, в процессе тестирования исследуются всевозможные (в рамках разумного) отклонения от сценария.
Продукт не должен работать по принципу "Шаг влево, шаг вправо - расстрел".
И если при тестировании отталкиваться от общепринятых практик и личного опыта, то действительно можно обнаружить неявные дефекты.
Уже на основании этих дефектов вносить правки в спецификацию и расширять тестовую модель, что в конечном счёте неизбежно улучшает пользовательский опыт. А если что-то делает пользовательский опыт лучше, то это надо применять
Имеются предположения по новым детективам и их головным уборам, но лучше дождусь следующей части. :)