Пока нет оценок.
Пожалуйста, подождите...

Любая тест-автоматизация содержит так называемую сердцевину, которая состоит из трёх частей — стимула, ответов и определенной суммы проверок. Далее поговорим детально о каждой составляющей, дабы выделить всё то важное, что способно помочь сделать вашу автоматизацию еще более гибкой.

Понятие стимула, ответа и проверки

Если говорить просто, стимул — это конкретное действие, которое вызывает конкретную реакцию. В сфере тестирования ПО и автоматизации, стимулы могут исходить из разнообразных источников, к примеру:

  • Клик клавиши;
  • Вызов API;
  • Ввод специальной команды в операционной системе.

Любое из данных действий должно вызывать конкретную реакцию.

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

  1. Обновление страницы либо же навигация, которая вызванная нажатием клавиши;
  2. Обратное сообщение, которое будет возвращено вызовом API;
  3. Внешняя программа возвращает итог благодаря вводу команды внутри определенной операционной системы.

Стоит отметить, что один и тот же стимул способен вызывать массу ответов. При этом, определенный ответ может быть реакцией сразу на несколько разнообразных стимулов. Это стоит отметить отдельно, так как QA может потребоваться тестировать сразу несколько комбинаций, ответов или стимулов.

Проверки — то, что нужно использовать для определения, верный ли ответ был получен в ответ на стимул.
Для тест-примеров, проверки могут быть в такой форме:

  1. Смог ли пользователь перейти на верную страницу после нажатия определенной клавиши?
  2. Получил ли он верные значения в ответном письме после API-вызова?
  3. Смогла ли отобразить внешняя программа корректный итог в ответ на вызов системы?

Запрограммированные в автоматизации все проверки, традиционно, отображаются как утверждения, а не в форме вопросов, как это описано выше.

Проверки и детерминизм

Конвенциональная мудрость тестирования ПО гласит, что все проверки должны быть исключительно детерминистическими. То есть, всегда должны быть способны на программной основе определить, корректное утверждение или нет. Говоря простыми словами, если вы не можете понять, эффективно утверждение или нет, то у вас не получится сказать, должен ли тест информировать об успешности или неудаче выполненной проверки.

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

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

При всем этом, такой подход автоматизации — это не просто доказательство пройденного или нет теста. Это про ПК, которые, так или иначе, помогают тестировщикам при выполнении повторяющихся операций и сравнении данных.

Оставить комментарий