Автор: Кристин Джеквони (Kristin Jackvony)
Оригинал статьи
Перевод: Ольга Алифанова

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

Почему я ненавижу системы тест-менеджмента

Причина первая: слишком долгая настройка

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

Причина вторая: слишком трудная поддержка

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

Причина третья: они могут помешать заниматься исследовательским тестированием

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

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

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

Причина пятая: их функциональность зачастую мало связана с качеством

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

Почему я пользуюсь системой тест-менеджмента

Недавно моя компания начала использовать систему управления кейсами Qase. Изначально я планировала полностью ее игнорировать, но я работала над проектом, сложность которого все росла и росла, и менеджер предложил дать системе шанс. Я была приятно удивлена! В результате я предлагаю ее всем командам в моей компании, и вот почему:

Причина первая: ее очень легко настроить

У нее нет никаких требований к созданию тест-кейса, кроме наличия названия. Я решила делать название единственным шагом каждого кейса. К примеру, если я хочу создать кейс, проверяющий, что пользователь может авторизоваться при помощи единого входа (SSO), я создаю кейс с названием «Пользователь может авторизоваться через SSO», и тест готов! При помощи этого подхода я создала 350 кейсов за пару часов.

Причина вторая: она очень гибкая

Тест-кейсы в Qase можно группировать по папкам, и вы можете именовать и организовывать эти папки как угодно. Можно создавать папки, вложенные в папки внутри папок. Можно запросто организовать кейсы любым удобным для вашей команды образом.

Причина третья: она может сберечь мое время

В этой системе можно запросто создать и сохранить тест-планы на основе кейсов. Просто задайте ему имя и выберите все кейсы, которые должны в нем содержаться. Затем при необходимости запуска этого плана создать и стартовать прогон можно за пару секунд. Это значительно быстрее создания тест-плана с нуля каждый раз, когда нужно прогнать регрессионный набор, или копирования таблицы Excel/Confluence и ее форматирование для нового запуска.

Причина четвертая: использование системы управления кейсами напомнит о тестах, которые вы могли пропустить

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

Причина пятая: система управления кейсами – хорошая организационная база для тест-автоматизации

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

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

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