суббота, 30 января 2016 г.

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

Всем привет!

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

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





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

  • Хостинг - облачное решение, на своем сервере
  • Цена - не должна быть высокой, еще лучше, если система будет бесплатной
  • Удобство использования - проверяли в результате использования пробных версий
  • Возможность создания проектов
  • Управление ролями и правами пользователей
  • Возможность создавать тест-кейсы/чек-листы с каким-либо видом группировки
  • Возможность создавать тест-планы
  • Возможность запускать тесты на выполнение и отмечать результаты выполнения
  • Отчетность (по тестовым запускам, покрытию требований)
  • Импорт/экспорт тест-кейсов
  • Ведение требований, связь требований и тест-кейсов
  • Интеграция с баг-трекинг системами
  • Оповещения по почте о событиях
  • Техподдержка
Какие системы сравнивали:
  • 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 местах. Поскольку чек-листы для функциональности и регрессионный чек-лист никак не связаны. Может получиться, и наверняка получится, рассинхрон. Поэтому среди двух понятий тест-плана:
  • Тест-план как набор задач на выполнение чек-листов (понятие в "Ситечко")
  • Тест-план как набор проверок/тест-кейсов для выполнения (например, "Регрессионный тест-план", "Тест-план для тестирования фичи")
я бы предпочла реализацию второго понятия. Мне так удобнее.

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



Комментариев нет:

Отправить комментарий