TMS: что сегодня все еще must have
Я немного подзастопорился с инфраструктурой KVM из-за текущих задач. Но обязательно вернусь к этой истории: чем дальше копаю, тем больше растут аппетиты. 🙂
А сегодня хочу вспомнить одну статью, которую когда-то выпускал про выбор TMS (Test Management System). Тема, конечно, холиварная, но всё же.
Недавно довелось посмотреть один продукт для тестирования Опыт подбора инструментов для команды у меня был. И я до сих пор немного скучаю по тому периоду, когда у нас с командой в пользованиибыл продукт, который вендор от релиза к релизу допиливал под наши потребности. Какой же это был кайф!
Потом стало рентабельнее переехать на Jira с плагином. И нет, это был не Xray. Слава богу, тогда у меня ещё была возможность сказать «нет», на это "чудо инженереной мыли".
Так вот, та статья состояла из нескольких блоков. И я задумался: в условиях, когда каждый крупный игрок заводит у себя одомашненный AI, а кто-то пилит собственные Wiki и TMS, чтобы не зависеть от вендора, поменялось ли моё представление о том, что должно быть must have?
И пока — как будто нет.
Начну с первого пункта: WYSIWYG-редактор Да, сейчас AI может отрефакторить практически любой текст. Но давайте вспомним одну простую вещь: тестировщики пишут тесты.
И тест никогда не будет существовать в единственном экземпляре. Его будут читать, выполнять, проверять, исправлять и сопровождать. Поэтому просто довериться тому, что получилось после генерации, и не вычитывать текст — нельзя.
Да, можно разбить спеку на атомарные требования с помощью LLM . Да, можно сформировать с ее же помощью позитивные и негативные проверки. Но есть нюансы. 1. Сложность описанной бизнес-логики иногда зашкаливает настолько, что при упрощении теста можно потерять важный нюанс подготовки. А иногда для сопровождения сценария вообще требуется приложить скриншоты. 2. Если тестировщику не нравится описание конкретного шага, у него должна быть возможность быстро его отредактировать. И очень желательно, чтобы вычитывать текст, вносить корректировки и перемещаться между шагами, ожидаемыми результатами и остальной информацией было удобно и можно было ради каждой правки не бегать в чат с ИИ. 3. Если процесс изменился точечно и надо добавить один - два шага, в некоторых моментах дороже будет зайти в чат и догрузить LLM контекстом
И для меня выборм между просто текстовым редактором и WYSIWYG-редактором очевиден, последний добавляет пойнтов к удобству.
Тестирование, Контроль качества и Обеспечение качества это рутинные процессы и вопрос удобсвта инструмента важен. Я как Test Lead хочу выстроить процесс и быть уверенным, что инструмент для написания тестов не станет причиной его саботажа.
На первый взгляд это может показаться мелочью: Мол, людям зарплату платят — какое ещё неудобство?
Но с точки зрения обеспечения качества всё выглядит иначе Неудобный инструмент → тяжёлый процесс → качество исполнения процесса падает.
И это не теоретическое рассуждение. Я видел такую картину и на производстве, и в телекоме, и в текущем секторе
Чем дороже продукт, тем лучше должна быть система качества и тем удобней должен быть инструмент, с помощью которого этот продукт "выпиливают"
Продолжение следует...