Выбираем TMS

Эта статья не про какой-то конкретный инструмент TMS(Test Management System), а обобщение личного опыта, который я получил, когда в первый раз подбирал систему с своей команды инженеров по тестированию ПО.

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

Так, как не ошибиться при выборе системы, в которой команда будет писать тесты, прогонять тесты и анализировать их? Пока речь именно про «ручные» тесты.

Я бы выделил три задачи, которые будут определять функциональность TMS

1. Поддержка тестов. Здесь я подразумеваю все то, что обеспечит тестировщикам удобство в создании, оформлении, обновлении, поиске и хранении тестов. Почему удобство? Написание теста при всей творческой составляющей процесс рутинный, добавить шаг(и), внести описание, проверить, что тест правильно описывает процесс в приложении, и все сначала, если постоянно при ловить такое

то процесс набора тестов, как минимум будет занимать больше времени.

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

3. Репортинг, это опять про удобство. Удобство анализа, например, что мы покрыли, и как много багов нашли на единицу спеки.

Ниже я рассмотрю эти задачи подробно и подчеркну дополнительные аспекты.

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

Версионность. Полезность этой возможности неочевидна, но если ваш софт поставляется в разных версиях, может быть очень актуальна. У одного контрагента живет версия 1.0.*, у второго 2.0.*, поддерживать надо обе, и если версии проверок не разбросаны по TMS, а лежат рядом, это удобно, например, для контроля полноты проверок разных версий, определения скоупа на будущий релиз.

Да, решать это можно по разному:

* часть в названии — неудобно (обязательно испортишь название при редактировании),

* метки — хорошо

* версии — отлично

Импорт тестов. Эта фича будет актуальна, если вам важно сохранить базу тестов и/или историю прогонов. Здесь вопрос про скорость. Если новая TMS не умеет импортировать тесты, тестировщикам понадобиться время, чтобы перенести базу тестов и результаты прогонов в новый инструмент. Да, время потратить придется в любом случае, как минимум, чтобы привести тесты из старой TMS к «съедобной» форме, разделители в csv, разметка xml, набор полей в xls, но если механизма нет, то важно оценить каковы будут ваши затраты на поддержку тестов в разных инструментах или самописный перенос.

Коротко смотрим следующее:

* наличие фичи импорта

* поддержка форматов для импорта, максимально дешевых для вашей команды

Экспорт тестов. Будет актуально, если вам постоянно надо отчитываться перед заказчиком в документированной форме о написанных тестах и проведенных прогонах. Опять же важны формат, структура документа, исходить надо из того, кто и насколько придирчиво это будет читать на этапе приемки.

Сегментирование

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

Плохое сегментирование. В качестве пример подойдет тип трека pre-condition в одном из «де-факто стандартов отрасли». и возможность прилинковать его к трекам типа Test в Jira. Само название трека говорит, что это pre-condition, т. е. производитель сразу намекает, хочешь использовать несколько одинаковых шагов в одних и тех же тестах, либо страдай: переноси их из теста в тест — актуализируй во всех тестах, либо борись с делемой: трек pre-condition, но мы в него будем складывать все и pre-, и middle-, и post- состояния. Усложнение можно добавить так:- не добавлять возможность увидеть шаги из pre-condition в процессе прогона теста, т. е. тестировщику придется переходить со страницы прогона теста на другую, чтобы узнать к чему ему надо прийти, либо трек pre-condition может содержать только описательное поле без шагов, без нормального редактора, так что, либо форматируешь руками, либо весь текст будет сплошным нечитабельным куском, он же condition, что тут непонятного, много туда вписывать не надо все должно быть коротко ясно, а то что продукт сложный это уже «проблемы индейцев».

Параметризация. Здесь речь про возможность использовать Data-driven approach. Одно описание шагов, на несколько вариантов набора данных. Если у вас уникальные пользовательские пути, да, вам это неактуально, но если у вас высокие технологическая или бизнес сложность, то составление сценариев по Data Flow Testing и Control Flow Testing это ваше все (Lee Copeland. «A Practitioner’s Guide to Software Test Design»). У вас должна быть возможность редактировать ваши наборы, менять местами и главное прокидывать в оба артефакта в тест и в сегмент.

Казалось бы, что тут думать, должно быть удобно тому, кто будет анализировать, но есть нюансы

Гибкость настройки репортов

Есть примеры репортов и их легко настраивать. Это идеальный вариант, но как показывает практика редкий

Есть шаблон и есть дока. Т.е. производитель дает какой-то общий скелет в котором на нативном(или не очень) языке есть разметка, которую вы можете поправить под свои запросы . Если дока есть, то вам нужен человек, который с этим будет разбираться при подготовке шаблонов и после, если шаблон по какой-то причине сломается(данные в тестах в особом формате, новая версия TMS и т.д.)

Есть шаблон, но доки нет. Это самый дорогой вариант. Здесь, непонятно, либо производитель считает, что все настолько просто, что описывать нечего, либо функционал очень скромный, тогда надо считать, что TMS не покрывает требования к репортингу и покрывать их придется силами одного (минимум) из членов команды.

Информативность репортов

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

Это не конечный вариант и скорее всего он будет дополняться. Но это база, на основе которой должен выстраиваться процесс подбора TMS. И лучше потратить время на отбор, составить список инструментов, запустить пилотную эксплуатацию, проверить на удобство использования и пригодность инструмента в текущих процессах, чем потом кому-то придется убеждать всю команду, что она "неправильно готовит" выбранный (и уже оплаченный) инструмент.

Спасибо за внимание и удачи в выборе.