Как писать тест-кейсы, которые пройдут испытание автоматизацией. Часть 1

22 июня 2018

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

Ведь успех проекта по автоматизации напрямую зависит от качества тест-кейсов, которые пишут инженеры по ручному тестированию.

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

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

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

  • Если вместо тест-кейсов вы пишете Gherkin-сценарии.
  • Если вы пишете тест-кейсы с использованием keyword-driven подхода.
  • Если у вас вместо тест-кейсов используется Test Survey или какая-то другая менее подробная документации и при этом у вас на проекте нет автоматизации.

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

Хороший автотест должен обладать следующими качествами:

  1. Быстрая скорость выполнения. На реальном проекте количество автотестов может доходить до нескольких сотен, а время выполнения и анализа ограничиваться парой часов. Здесь ценится каждая сэкономленная минута.
  2. Стабильность. Если багов в приложении нет, тест должен всегда проходить. Это очевидно, но не всегда легко достижимо.
  3. Независимость тестов друг от друга. Это значит, результат одного теста не влияет на результат других. Даже если тесты выполняются одновременно (например, в разных браузерах), они не должны мешать друг другу.
  4. Самодостаточность. Автотест не должен зависеть от каких-либо данных, которые в любой момент могут исчезнуть или измениться.
  5. Соответствие автотеста тест-кейсу. Каждый шаг автотеста должен быть таким же, как и в тест-кейсе. Только так вы сможете быстро исследовать результаты автотестов, находить баги, обновлять тесты.

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

Но перед тем, как перейти к рекомендациям по написанию тест-кейсов, поговорим о документации. Ведь любой проект по тестированию начинается с нее.

Выбор тестовой документации

На проектах по тестированию могут использоваться следующие виды документации: Acceptance Sheet, Test Survey или тест-кейсы.

Нас интересуют проекты с тест-кейсами, поскольку это самый подробный вид документации. Acceptance Sheet и Test Survey не годятся для автоматизации. Имея на руках Test Survey, автоматизатор, какой бы он опытный ни был, не сможет продумать шаги для автотеста, рискует пропустить важные проверки. А значит, тест не выполнит главной задачи – не сможет отловить дефекты.

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

Ну и еще один самый распространенный вопрос.

Как хранить и обновлять тест-кейсы?

Для хранения, редактирования и обновления тест-кейсов рекомендуется использовать тест-трекинговые системы.

Надеемся, что вы знаете, чем тест-трекер отличается баг-трекера. Если нет, поясним.

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

Тест-трекер имеет более широкую функциональность. Его основные функции следующие:

  1. проставление и хранение результатов прогонов теста (т.к. тесты прогоняются регулярно, на разных сборках приложения, окружениях, важно хранить информацию о предыдущих прогонах);
  2. возможность проставления результатов теста автоматически после прохождения автотеста;
  3. удобная форма записи шагов и ожидаемых результатов;
  4. отдельная система управления (можно назначать людей, кто будет проверять конкретные тесты, компоновать тест-кейсы в наборы для различных случаев);
  5. тест-кейсам присваиваются различные статусы, они не назначаются на разработчиков.

Часто тест-трекинговая система совмещена с баг-трекинговой.

Например, в TFS есть все: система хранения тестов, отслеживания дефектов и множество других инструментов для тестирования и управления проектом. JIRA используется как баг-трекинговая система, а для тест-трекинга можно использовать специальный плагин Zephyr.

Итак. Отдаем предпочтение тест-трекинговым системам (TTC). Никаких Excel-файлов. Excel-файл с тест-кейсами – это пережиток прошлого. К сожалению, некоторые команды этим пережитком до сих пор пользуются.

Вполне вероятно, у вас на проекте инженеры будут тоже использовать Excel-файлы. Если так, то все оформленные таким образом тест-кейсы для автоматизации все равно должны быть внесены в тест-трекер.

Сейчас поясним почему.

Представьте себе, вы написали тест-кейс, автоматизатор его заавтоматизировал. А потом вы внесли обновления в тест-кейс. Как автоматизатор узнает, какие тест-кейсы нужно обновить? Проще всего это сделать, изменив статус тест-кейса в тест-трекинговой системе. Это позволяет отследить все обновленные тесты.

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

Также если в тест-кейсе есть баг, автоматизатор должен знать об этом. Тест-трекер и с этой задачей поможет справиться. Просто прилинкуйте баг к тест-кейсу.

Преимущества использования тест-трекера для хранения и обновления тест-кейсов:

  • Меньше времени на коммуникацию;
  • Меньше времени на обновления.

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