Опыт использования тест-менеджмент системы Ситечко

Всем привет!

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

Почему Ситечко

Перед внедрением системы мы проводили анализ решений, существующих на рынке. 

Оценка продуктов происходила по следующим параметрам:

• Хостинг - облачное решение, на своем сервере
• Цена - не должна быть высокой, еще лучше, если система будет бесплатной
• Удобство использования - проверяли в результате использования пробных версий
• Возможность создания проектов
• Управление ролями и правами пользователей
• Возможность создавать тест-кейсы/чек-листы с каким-либо видом группировки
• Возможность создавать тест-планы
• Возможность запускать тесты на выполнение и отмечать результаты выполнения
• Отчетность (по тестовым запускам, покрытию требований)
• Импорт/экспорт тест-кейсов
• Ведение требований, связь требований и тест-кейсов
• Интеграция с баг-трекинг системами
• Оповещения по почте о событиях
• Техподдержка

Какие системы сравнивали:

• TestRail
• TestLink
• Ситечко
• TestStuff
• TestLodge
• PractiTest
• Klaros-Testmanagement
• TestCollab
• RedCase плагин для Redmine
• еще некоторые монструозные системы, которые не буду перечислять

В конечном итоге мы выбирали между TestRail (слишком дорогая), TestLink (не очень user friendly) и Ситечко (черная лошадка). Коллективным решением было принято выбрать "Ситечко" как систему, гармонично сочетающую все наши требования к тест-менеджмент системе.

Процесс тестирования с Ситечко

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

Процесс работы с тест-менеджмент системой для таких проектов у нас происходит по следующей схеме.

1) Создание и настройка нового проекта

Настройка проекта после создания:

• Добавление в проект пользователей. Почему-то на этом шаге у нас периодически происходит перенаправление на страницу с сообщением об ошибке выполнения операции, хотя пользователь в итоге успешно создается.
• Баг-трекер. На сайте заявлена интеграция с самыми популярными баг-трекерами. С Redmine интеграцию быстро настроить не получилось. 
• Остальные части настраиваем на более поздних шагах процесса тестирования

2) Работа с требованиями

Для получения отчетов "Покрытие требование" и "Тестирование требований" в проект заносятся требования. Например, если у вас есть Техническое задание, написанное в виде сценариев использования системы, можно каждый сценарий указывать в виде требования. Если вам не нужны эти отчеты, требования можно не создавать. 

На следующем шаге процесса проверки связываются с требованиями и получается примерно такая картина:

Для каждого требования имеется возможность просмотреть список привязанных к нему проверок. В этой функциональности имеется 1 дефект, в некоторых в списке проверки дублируются.

3) Проектирование чек-листов

Здесь все работает, как часы.

Несмотря на то, что Ситечко позиционируется как система для ведения чек-листов, мы проектируем гибрид чек-листа + набора тест-кейсов. Для простых ситуаций описываем проверку, для сложных/требующих пояснения - тест-кейс. Например, это может выглядеть так:

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

• Создание чек-листа на основе первой версии требований.
• Изменение чек-листа при изменении требований.

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

В конечном итоге, мы получаем набор чек-листов в статусе "Согласовано".

4) Выполнение тестирования

В системе "Ситечко" выполнение тестирования осуществляется из раздела "Тест-план". План тестирования - это набор задач для выполнения чек-листов в рамках итерации.

На этом шаге, перед формированием тест-плана, необходимо завершить настройку свойств проекта, а именно

• создать итерацию тестирования (при редактировании итерации у нас также выходит ошибка)
• создать сборку для тестирования
• создать одно или несколько окружений

После этого в разделе "Тест-план" в рамках итерации создаются задачи для чек-листов, которые вы запланировали выполнить в рамках итерации. Задачи можно заводить двумя основными способами - через создание одиночной задачи или через создание сразу всех задач для выполнения чек-листов на нужных окружениях через матрицу (например, выполнить чек-лист для smoke-тестирования на окружениях - браузере Chrome, FireFox и т.д.).

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

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

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

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

Что для нас не очень удобно - это указание одной сборки для всего чек-листа. Чаще всего мы проводим тестирование чек-листа на разных сборках. Для нас было бы удобнее дополнительное поле "Сборка" для каждой проверки. Мы обычно указываем сборку в комментарии (чаще всего, это информация о ветке и ревизии из репозитория, или версия приложения)

5) Формирование отчетности

Система предоставляет возможность формировать 4 типа отчетов. Мы используем в основном отчет "Запущенные чек-листы", который позволяет посмотреть статистику выполнения всех чек-листов.

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

Итоги

Плюсы

• Система содержит необходимую функциональность для всех основных этапов процесса тестирования программного обеспечения.
• Нет ничего лишнего. Система простая для понимания и достаточно удобная в использовании. Пользовательский интерфейс приятный.
• Есть удобная дополнительная функциональность - импорт/экспорт проверок, чит-листы и др.
• Система очень хорошо подходит для небольших проектов, без большого количества релизов
• Невысокая стоимость приложения
• Наличие как облачной версии, так и хостинга на своем сервере.

Минусы

• Наличие дефектов в системе. Это главный минус для нас. Возможно, мы были недостаточно настойчивы при общении с техподдержкой. Но то, что в коммерческом ПО присутствуют такие дефекты и обновления самой системы выходят редко - мне, как тестировщику, не нравится :)
• Отсутствие возможности в рамках одного проекта параллельно работать с несколькими релизами.  Например, иметь версию чек-листов, требований для релиза 1 и для релиза 2. Думаю, из-за этого система будет не очень удобна массивным приложениям, которые достаточно часто выпускают новые релизы с новой функциональностью.
• Отсутствие возможности выполнять 1 чек-лист одновременно несколькими тестировщиками.
• Недоработанность отчетов, связанных с требованиями. Невозможность экспорта отчетов в Word.

Где-то посерединке между плюсом и минусом

Реализация работы с чек-листами. Сама концепция чек-листов мне очень импонирует. Вместо подробных тест-кейсов писать краткие и емкие проверки. Но реализация работы с чек-листами в "Ситечко" меня немного смущает. Опишу на примере конкретной ситуации. Допустим, в рамках каждой итерации (в рамках процесса разработки ПО, а не в рамках сущности "Ситечко") мы создаем чек-листы для новой функциональности. И ведем один чек-лист для регрессионного тестирования, который по окончании каждой итерации дополняем отдельными проверками из чек-листов для новой функциональности (путем копирования-вставки). Если во время очередной итерации разработки ПО нам потребуется изменить чек-листы, разработанные ранее (в случае изменения требования), изменения проверок потребуется вносить в 2 местах. Поскольку чек-листы для функциональности и регрессионный чек-лист никак не связаны. Может получиться, и наверняка получится, рассинхрон. Поэтому среди двух понятий тест-плана:

• Тест-план как набор задач на выполнение чек-листов (понятие в "Ситечко")
• Тест-план как набор проверок/тест-кейсов для выполнения (например, "Регрессионный тест-план", "Тест-план для тестирования фичи")

я бы предпочла реализацию второго понятия. Мне так удобнее.

Вот и все, друзья.

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