TestRail и Google Таблицы: где хранить и как управлять тест-кейсами на практике

Зачем это нужно?

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

С тест-кейсами в работе QA-инженера ровно та же история.

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

Чтобы не запутаться, не потерять и не дублировать проверки, QA-инженеры используют специальные инструменты для хранения и управления тест-кейсами. В этом уроке мы разберём два самых популярных подхода:

• Google Таблицы — простой, бесплатный и знакомый многим инструмент.
• TestRail — профессиональная система управления тестированием, которую используют в серьёзных IT-компаниях.

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

Теория

Часть 1. Что такое система управления тест-кейсами?

Когда программисты пишут программу, а QA-инженеры её проверяют, возникает вопрос: где хранить всю информацию о проверках?

Ответ — в системе управления тест-кейсами (по-английски: Test Management System, сокращённо TMS). Это специальная программа или таблица, в которой записаны:

• все тест-кейсы (что и как проверять),
• результаты каждого запуска (прошёл тест или нет),
• история изменений (кто и когда менял проверку),
• статистика (сколько тестов прошло, сколько упало).

Представьте кулинарную книгу. Каждый рецепт — это тест-кейс. Вы знаете, какие ингредиенты нужны (шаги теста), каким должно быть блюдо в итоге (ожидаемый результат) и отмечаете галочкой, приготовили вы это блюдо или нет (статус теста). TMS — это такая кулинарная книга для тестировщика.

Часть 2. Google Таблицы как инструмент тестировщика

Google Таблицы (Google Sheets) — это бесплатный онлайн-редактор таблиц от компании Google. Он похож на Microsoft Excel, но работает прямо в браузере и позволяет нескольким людям редактировать файл одновременно.

Многие небольшие команды и начинающие QA-инженеры начинают именно с Google Таблиц, потому что:

• это бесплатно,
• не нужно ничего устанавливать,
• всё интуитивно понятно,
• легко поделиться с коллегами.

Как выглядит тест-кейс в Google Таблицах?

Каждый тест-кейс — это одна строка таблицы. Столбцы — это поля тест-кейса. Вот стандартный набор столбцов:

💡 Аналогия: ID тест-кейса — это как инвентарный номер на мебели в офисе. Без него легко перепутать два похожих стула. С номером — сразу понятно, о каком именно стуле идёт речь.

Преимущества и ограничения Google Таблиц

Плюсы:

• Бесплатно и доступно сразу.
• Легко настроить под себя.
• Подходит для маленьких команд и учебных проектов.
• Все изменения сохраняются автоматически.

Минусы:

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

Часть 3. TestRail — профессиональная система управления тестами

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

Адрес официального сайта: https://www.testrail.com

TestRail — платный инструмент, но у него есть бесплатный пробный период (Trial), который позволяет попробовать все функции без оплаты. Кроме того, некоторые компании предоставляют доступ к TestRail своим сотрудникам.

Ключевые понятия TestRail

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

Проект (Project) — это верхний уровень организации. Один проект = одно приложение или продукт, которое тестируется. Например, «Мобильное приложение банка» или «Сайт интернет-магазина».

Набор тестов (Test Suite) — папка внутри проекта, где хранятся тест-кейсы. Например, «Регистрация», «Вход в систему», «Оплата». Это как разделы в той самой кулинарной книге: «Супы», «Салаты», «Десерты».

Тест-кейс (Test Case) — отдельная проверка внутри набора. Всё то же самое, что мы описывали выше.

Тест-ран (Test Run) — это запуск группы тест-кейсов для конкретной версии программы. Например, вышла новая версия приложения — вы создаёте тест-ран и отмечаете, какие тесты прошли, а какие нет.

Тест-план (Test Plan) — объединение нескольких тест-ранов. Используется, когда нужно протестировать продукт сразу на нескольких устройствах или в нескольких средах.

💡 Аналогия для Test Run: Представьте, что вы — инспектор санэпидемстанции, и пришли проверять ресторан. У вас есть список пунктов проверки (тест-кейсы). Один визит в ресторан = один тест-ран. По итогам каждого визита вы отмечаете, что прошло проверку, а что нет.

Структура тест-кейса в TestRail

В TestRail тест-кейс содержит следующие поля:

Статусы тест-кейсов в TestRail

Когда вы проводите тест-ран, каждому тест-кейсу нужно присвоить статус:

• Passed — тест прошёл успешно ✅
• Failed — тест провалился, найдена ошибка ❌
• Blocked — тест невозможно выполнить из-за другой проблемы 🚫
• Untested — тест ещё не выполнялся ⬜
• Retest — тест нужно перепроверить (например, после исправления бага) 🔄

Часть 4. Сравнение: когда использовать что?

Вывод: Начинайте с Google Таблиц — это отличный учебный инструмент. Когда вы придёте на работу в IT-компанию, скорее всего, там будет TestRail или похожая система (например, Zephyr, qTest, Xray). Понимая принципы работы с Google Таблицами, вы очень быстро освоите любую профессиональную TMS.

Пример: создаём тест-кейсы для формы входа

Разберём конкретный пример. Допустим, мы тестируем форму входа на сайт интернет-магазина. У формы есть два поля: «Email» и «Пароль», и кнопка «Войти».

Как это выглядит в Google Таблицах

Вот как могут выглядеть тест-кейсы в таблице:

| ID     | Название                              | Предусловие                    | Шаги                                                                 | Ожидаемый результат                              | Статус  |
|--------|---------------------------------------|--------------------------------|----------------------------------------------------------------------|--------------------------------------------------|---------|
| TC-001 | Вход с корректными данными            | Пользователь зарегистрирован   | 1. Открыть сайт. 2. Ввести email. 3. Ввести пароль. 4. Нажать "Войти" | Пользователь попадает на главную страницу        | Pass    |
| TC-002 | Вход с неверным паролем               | Пользователь зарегистрирован   | 1. Открыть сайт. 2. Ввести email. 3. Ввести НЕВЕРНЫЙ пароль. 4. Войти | Появляется сообщение: "Неверный email или пароль" | Pass    |
| TC-003 | Вход с пустым полем Email             | —                              | 1. Открыть сайт. 2. Оставить поле Email пустым. 3. Ввести пароль. 4. Войти | Появляется сообщение: "Введите email"            | Fail    |
| TC-004 | Вход с незарегистрированным email     | —                              | 1. Открыть сайт. 2. Ввести несуществующий email. 3. Ввести пароль. 4. Войти | Появляется сообщение: "Неверный email или пароль" | Not Run |

Что означает Fail в TC-003? Это значит, что мы выполнили этот тест и обнаружили ошибку: программа не показала сообщение «Введите email», а, например, просто перезагрузила страницу или ничего не сделала. Это баг — ошибка в программе, которую нужно исправить.

Как это выглядит в TestRail

В TestRail тот же тест-кейс TC-003 будет оформлен так (описание отдельных полей формы):

Title:         Вход с пустым полем Email

Section:       Авторизация > Форма входа

Type:          Functional (Функциональный)

Priority:      High (Высокий)

Preconditions: Пользователь находится на странице входа.
               Поле Email не заполнено.

Steps:
  1. Открыть браузер и перейти на сайт магазина.
  2. Убедиться, что поле "Email" пустое.
  3. В поле "Пароль" ввести любое значение, например: "test123".
  4. Нажать кнопку "Войти".

Expected Result:
  Под полем "Email" появляется сообщение с текстом:
  "Пожалуйста, введите адрес электронной почты."
  Пользователь остаётся на странице входа.
  Авторизация не происходит.

💡 Обратите внимание: В TestRail шаги и ожидаемый результат разделены очень чётко. Это помогает другому тестировщику повторить тест в точности так же, как задумывалось — даже если он видит этот тест-кейс впервые.

Типичные ошибки при написании тест-кейсов

Давайте посмотрим на неудачный пример и исправим его:

❌ Плохой тест-кейс:

Title: Проверить вход

Steps: Войти в систему и посмотреть, что будет.

Expected Result: Должно работать.

Почему это плохо?

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

✅ Хороший тест-кейс:

Title: Успешный вход зарегистрированного пользователя

Preconditions:
  - Пользователь зарегистрирован с email: [email protected], пароль: Test1234!
  - Пользователь НЕ авторизован в системе.

Steps:
  1. Открыть браузер.
  2. Перейти по адресу: https://shop.example.com/login
  3. В поле "Email" ввести: [email protected]
  4. В поле "Пароль" ввести: Test1234!
  5. Нажать кнопку "Войти".

Expected Result:
  - Пользователь перенаправляется на страницу: https://shop.example.com/dashboard
  - В правом верхнем углу отображается имя пользователя.
  - Кнопка "Войти" заменяется кнопкой "Выйти".

Почему это хорошо?

• Конкретные данные для ввода.
• Пошаговые действия.
• Чёткий ожидаемый результат с несколькими критериями проверки.
• Любой человек может повторить этот тест и получить тот же результат.

Практика

Упражнение 1. Создайте свою первую таблицу тест-кейсов в Google Таблицах

Что нужно сделать:

1. Откройте https://sheets.google.com (потребуется аккаунт Google — он бесплатный).
2. Создайте новую таблицу и назовите её: «Тест-кейсы: Форма регистрации».
3. Создайте следующие столбцы в первой строке (заголовки):
   • ID | Название | Предусловие | Шаги | Ожидаемый результат | Фактический результат | Статус | Приоритет
4. Напишите 3 тест-кейса для формы регистрации нового пользователя. Форма содержит поля: «Имя», «Email», «Пароль», «Подтверждение пароля» и кнопку «Зарегистрироваться».

Подсказки для тест-кейсов:

• Что будет, если все поля заполнены корректно?
• Что будет, если пароль и подтверждение пароля не совпадают?
• Что будет, если поле «Email» заполнено в неправильном формате (например, «ваш-email» вместо «ваш@email.com»)?

🎯 Цель упражнения: Почувствовать, как структурировать тест-кейсы и понять, что каждый тест проверяет только одну конкретную ситуацию.

Упражнение 2. Зарегистрируйтесь в TestRail и изучите интерфейс

Что нужно сделать:

1. Перейдите на сайт https://www.testrail.com.
2. Нажмите «Get Started» или «Free Trial» и зарегистрируйтесь (потребуется email).
3. После входа в систему найдите и изучите следующие разделы:
   • Projects (Проекты) — список проектов.
   • Test Cases (Тест-кейсы) — где хранятся тест-кейсы.
   • Test Runs & Results (Тест-раны и результаты) — где запускаются тесты.
4. Создайте новый проект с названием «Учебный проект».
5. Внутри проекта создайте один Test Suite (набор тестов) с названием «Авторизация».
6. Добавьте в этот набор один тест-кейс — любой из тех, что вы написали в упражнении 1, переведя его в поля TestRail.

🎯 Цель упражнения: Познакомиться с реальным профессиональным инструментом и понять, как перенести уже написанные тест-кейсы в TMS.

Упражнение 3. Проведите «мысленный» тест-ран

Что нужно сделать:

Откройте любой сайт — например, форму поиска на https://www.google.com. Вы будете его «тестировать».

1. Возьмите таблицу из упражнения 1 (или создайте новую) и напишите 5 тест-кейсов для поля поиска Google. Примеры ситуаций для проверки:

   • Поиск с обычным словом (например, «кот»).
   • Поиск с пустой строкой.
   • Поиск с очень длинным запросом (более 200 символов).
   • Поиск с использованием специальных символов (например, @#$%).
   • Поиск на другом языке.

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

3. Заполните столбцы «Фактический результат» и «Статус» (Pass/Fail) в вашей таблице.

🎯 Цель упражнения: Пройти полный цикл тестирования: написать тест → выполнить тест → зафиксировать результат.

Упражнение 4 (продвинутое). Сравните два подхода

Что нужно сделать:

Возьмите 3 тест-кейса из упражнения 1 и перенесите их в TestRail (в созданный в упражнении 2 проект).

После этого ответьте письменно (в отдельном документе или прямо в таблице) на следующие вопросы:

1. Что было удобнее заполнять: Google Таблицы или TestRail? Почему?
2. Какие поля в TestRail отсутствовали в вашей таблице Google?
3. Представьте, что в вашей команде 10 тестировщиков, и у каждого 100 тест-кейсов. Какой инструмент вы выберете? Обоснуйте.
4. Что, по вашему мнению, труднее всего при написании тест-кейсов?

🎯 Цель упражнения: Осознанно сравнить оба инструмента и сформировать собственное мнение о том, когда и какой из них использовать.

Ключевые выводы

• Тест-кейс — это подробная инструкция для одной конкретной проверки программы. Хороший тест-кейс понятен любому человеку и содержит чёткие шаги и ожидаемый результат.

• Google Таблицы — простой и бесплатный способ хранить тест-кейсы. Идеально подходит для обучения, небольших команд и проектов с небольшим количеством тестов.

• TestRail — профессиональная система управления тестированием. Предоставляет структуру, статистику, историю запусков и интеграцию с другими инструментами. Используется в большинстве серьёзных IT-компаний.

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

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

• Статус теста (Pass, Fail, Blocked, Not Run) — важная информация. Именно она показывает, в каком состоянии находится качество продукта на данный момент.

• Инструмент — это только средство. Главное — думать как тестировщик: искать граничные случаи, сомневаться в «очевидных» вещах и проверять то, что может пойти не так.

📌 Что дальше? В следующем уроке мы познакомимся с системами отслеживания ошибок — баг-трекерами (Jira и другими). Вы узнаете, как правильно оформить найденный баг, чтобы разработчик смог его воспроизвести и исправить.