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

Софта для организации тест-планов на рынке много. Однако он довольно дорогой (в среднем $ 25 за одного пользователя в месяц). Бесплатный софт тоже есть, но выглядит он как заскорузлое говно мамонта. Мы с вами сейчас посмотрим ключевых игроков. А также посмотрим, как можно упорядочить тест-план в Google Docs, используя деревья (бонус — наш удобный экспресс-шаблон, годный, если у вас на проекте несколько тысяч тест-кейсов и 3−4 тестировщика).

От инструмента для контроля и проведения тестов по факту требуется не так уж много:

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

Таблички в Excel или гуглодоках вполне соответствуют всем этим параметрам (кроме багтрекера). Конечно, можно хитрить, раскрашивая строки в другие цвета или пытаться располагать тест-кейсы чётко друг за другом, и при условных 10+ тестах это может сработать. Это годный вариант, если тест-план реально маленький, делается для смоук-тестов (например, интернет-магазина, где мы прописываем проверку критического пути: главная → фильтр → карточка → корзина → заказ → оплата) и проверяем его при каждом деплое. Но представьте аляпистый ад тестера при 1000+ тестах? Вот-вот.

Проблема больших тест-планов на крупных проектах не нова, и большие ребята написали десяток систем для хранения тестов. Ниже мы посмотрим на самые популярные.


TestRail

Одно из самых популярных ПО. Пользователи хвалят его за понятную структуру: есть тест-сьюты (наборы тестов), внутри них секции или отдельные тест-кейсы, в каждом кейсе можно прописать сценарий, шаги и ожидаемый результат. По итогам автотеста будет показан результат: тест либо пройден, либо завален, либо надо перетестить. Тут же и статистика в диаграммах:

Одна проблема — 30 $ за одного пользователя в месяц. Кроме того, есть сообщения от пользователей, что на больших тест-планах система начинает тупить. Сами не сталкивались, но настораживает.


qTest

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

Инструмент условно бесплатный — можно получить демку, пройдя длиннющую форму регистрации. После, конечно же, с вас всё равно попросят денежку, но фиксированного прайса нет — вместо этого «гибкие параметры ценообразования и лицензирования в зависимости от бизнес-потребностей».

Есть и более дорогие предложения, но и софта подешевле (или даже бесплатно) тоже полно. Из того, что мы потыкали:

• PractiTest,
• Zephyr,
• Test Collab,
• TestFLO for JIRA,
• TestLink,
• XQual,
• TestCaseLab,
• QAComplete,
• QACoverage,
• Plutora Test,
• Inflectra,
• Meliora Testlab,
• Aqua,
• Panaya,
• Testpad.

Бесплатный софт (лидер среди бесплатного TestLink) — выглядит и работает, как правило, ужасно, а внутрь кода лучше вообще не заглядывать. Захочется либо плакать, либо пить виски. И плакать. И виски. Джек Дэниэлз должен помочь в автотестах!

В общем-то, простой табличный инструмент Гугла закрывал и раньше все потребности тестера, кроме проблем с огромным количеством тестов в одном месте. Решением стала простая группировка по строкам: эта функция появилась в таблицах весной 2018. Благодаря ей мы переработали наш шаблон тест-плана, добавив ему структурности, и успешно закрыли вопрос платного софта. Мы используем вкладки, чтобы разбить тесты по компонентам системы, и деревья — для группировки тестов по смыслу. То же самое можно сделать в коммерческом софте типа TestRail, но в Гугле это оказалось в разы удобнее.

Мы используем два разных документа — один для тест-планов, второй — для тестовых прогонов (в него копируется вкладка из тест-плана и тестер-с-мышкой может спокойно идти по системе и проверять ее по уже прописанным сценариям). Также мы вывели небольшие, но полезные метрики (вроде количества свалившихся тестов) внизу.

Чтобы сгруппировать задачи, достаточно выделить нужные строки и нажать правой кнопкой "сгруппировать", либо использовать хоткей Alt + Shift + Стрелка вправо. Группировка может быть многоуровневой.

Статус теста

Принцип такой же, как и в любом приложении для автотестов. Статус может быть Passed (все хорошо), Failed (тест провален), Blocked (невозможно протестировать) и Skipped (пропущен).


Приоритет

Это наша система приоритетов, которую мы используем у себя годами. В зависимости от ваших нужд нужно настроить, как говорится, «под себя». Значение выставляется тестером: 0 — критические баги; 1 — критичное Usability, забытые фичи; 2 — некритичные баги; 3 — некритичное Usability; 4 — тексты; 8 — хотелки, которые пока не будем делать.


Тест-кейс

Описание задачи для автотеста или блока задач. Блоки задач отмечаются тёмно-серым.

Группировка задач двойная: по вкладкам и по строкам. Каждая вкладка — отдельная страница проекта / компонент / раздел приложения. Тест-кейсы одной направленности на каждой вкладке объединяем в одну ветку группировкой строк.

Как правило, новые тесты — это результат глубокого отсмотра системы или обработки баг-листов с тестовых прогонов.


Действие / Описание / Ожидаемый результат

Здесь тестер прописывает конкретные действия, которые приведут к ожидаемому результату. Иерархия тестов получается ничуть не хуже, чем в платных приложениях.


Приоритет на автоматизацию

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


ID Автотеста

Детальное описание на английском — нужно, чтобы после прогонки пачки тестов не тратить время на идентификацию результатов с непонятными названиями вроде «тест 1» или «тест 2».

Банально, но про деревья в Гугл Таблицах многие не знают. А вещь полезная, если использовать ее с умом. Так что если наш пост или шаблон помогли вам сэкономить 20−30 баксов на каждого вашего тестировщика в месяц — несите добро в мир, ставьте лайки, шары, торшеры!