Как ваш техписатель (ТП) или выпускающий билд тестировщик (Т) собирает текст для Release Notes (РН)? РН всегда собирает один человек или любой в состоянии сделать это? На всех стадиях разработки и выпуска продукта проводится проверка текста на адекватность или полагаетесь только на ТП, который в последний день перед выпуском шерстит все закрытые задачи и выписывает нечто приблизительное? А может только выбирает подряд все Summary из задач, вошедших в билд? Храните ли вручную собранные РН в Системе Контроля Версий (СКВ), легко ли их найти и вставить в инсталлятор продукта?
Как создавать описание билда, которое будет понятно пользователю, и он его обязательно изучит – об этом и расскажу.
ConquestSS публикует билды десктопных продуктов не часто (максимум – раз в полгода), а посему существует система бета (b) и предвыпускных (rc) билдов, для которых нет надобности компоновать РН. Вместо текста показывается шаблонный текст: "RELEASE NOTES [ProductName] [MajorNumber].[MinorNumber] Release [ReleaseNumber] (draft, not completed)".
Общепринятая структура РН: Новинки (Н – Features), Улучшения (У - Improvements), Исправленные Ошибки (ИО – Fixed Bugs), Исключено (И – Deleted/Deprecated), Возможные Проблемы (ВП – Detected Bugs). На каком этапе удобнее группировать? Для автоматизации конечно же надо начинать с низов – каждую задачу сразу распределять по структуре РН.
Из каких источников ТП может брать информацию для составления РН? К каждому сабмиту в СКВ разработчик обязательно пишет короткий комментарий о сделанных изменениях, который понятен сотрудникам со знанием языка программирования. Хоть СКВ и имеет самое правильное распределение задач по номерам билдов, но тексты комментариев к сабмитам мало подходят для РН, ведь их будет читать пользователь, не знающий "кухни" продукта. Поэтому инфу лучше брать из Баг-Трекинговой Системы (БТС). Но в БТС задачи ведутся для параллельных билдов или даже продуктов, поэтому нужны определённые пометки. В Jira есть очень полезная и удобная штука – лейблы, которые может добавлять и менять любой пользователь БТС, а также по ним легко фильтровать. Поскольку одна задача может содержать несколько лейбл, то и проблема параллельных билдов/продуктов вполне разрешима. Для автоматизации сбора РН была предложена система лейбл: "RN_[MinProductName]_[MajorNumber].[MinorNumber].[ReleaseNumber].[LastPublishedBuildNumber]+", где префикс "RN_" означает причастность задачи к РН, "MinProductName" – короткое наименование продукта, " [MajorNumber].[MinorNumber].[ReleaseNumber].[LastPublishedBuildNumber]" – полный номер последнего опубликованного билда, "+" – символ плюса означает последующий выпускаемый билд/версию. Например, в феврале выпустили Продукт Компании (ПК) версии "3.5.7.123", а в апреле собираются выпустить "ПК 3.6.2.ХХХ", в таком случае лейбла для задач, которые необходимо описать в РН ближайшего выпускаемого билда, будет "RN_ПК_3.5.7.123+".
Из какого поля брать тексты, чтоб это было быстро, при минимальном влиянии человеческого фактора? Значение из Summary вряд ли будет понятно пользователю, так как его составляют коротко, понятно лишь для проектировщиков и тестировщиков. Полное описание из Description совсем не подходит для РН, так как много технических деталей, а выбирать пару строк значит прикручивать парсер. Хоть у задач Jira и есть поле Components, но в нём может быть указано несколько модулей продукта, и для РН группировка станет сложной. И самое трудное – тип задачи Н/У/ИО/И/ВП – нельзя брать из поля Type, так как в БТС оформленный баг вполне может быть описан в РН как улучшение, а закрытая новинка без полного тестирования должна быть в блоке исключённых функциональностей. Учитывая вышеизложенные проблемы, было предложено создать текстовое поле "Release Notes Text", не обязательное для заполнения, но с возможностью правки для любого вида задач. История правок в Jira после ревизии аналитиком или разработчиком помогает обучать ТП. Черновой вариант от разработчика способствует составлению тест-аналитиком более полного комплекса тестовых случаев, а подправленный тестировщиком текст добавляет его понятливости конечным пользователем.
Для автоматизации сбора РН пришлось чётко описать во внутренней Wiki схему заполнения поля "Release Notes Text":
- в первой строке указать имя блока группировки РН кратко (Н/У/ИО/И/ВП) или подробно (Новшество/Улучшение/Исправленные Ошибки/Исключено/Возможные Проблемы);
- во второй строке указать одно наименование модуля или функциональной страницы продукта;
- в остальных строках описать задачу понятным для конечного пользователя языком.
При соблюдении такой структуры становится легко и просто распарсить и сгруппировать текст РН. А если показ РН в продукте делается в HTML формате, то необходимое форматирование удобно делать сразу в поле Jira.
Черновой вариант текста к каждой задаче хорошо бы оформлять программисту, потом подправлять тестировщику, а уже ТП завершит процесс форматирования и лексической пригодности.
Сочетание "непустое поле РН" и "наличие лейблы" является итоговым фильтром задач, которые должны быть отмечены в РН ближайшего выпускаемого билда. Лейблу проставляет ТП после полной проверки РН. Сбор текстов из спец.поля Jira – элементарное действие, но необходим самописный парсер для отсева дубликатов, группирования без излишних заголовков и выставления сортировки, соответствующей маркетинговым целям. Этот же автосборщик РН делает тексты в двух вариантах – с указанием номеров задач для промежуточных билдов и отчёта о наличии текстов, их корректности функциональной и лингвистической. Примечание: из РН, собираемых в html-формате, работают линки номеров задач Jira.
Аннотация к билду удобна для налаживания обратной связи с пользователем. К каждому пункту новшества и изменения в РН стоит добавить три чекера "Помогло", "Незаметно", "Лишнее". А в конце текста РН добавить функцию отправки результатов в Вашу техподдержку с возможностью дописать личное мнение о билде. Маркетинг может простимулировать какими-нибудь бонусами отправленную анкету. Будьте уверены, анализ анкет даст огромное поле деятельности аналитикам и тестировщикам.
Как создавать описание билда, которое будет понятно пользователю, и он его обязательно изучит – об этом и расскажу.
ConquestSS публикует билды десктопных продуктов не часто (максимум – раз в полгода), а посему существует система бета (b) и предвыпускных (rc) билдов, для которых нет надобности компоновать РН. Вместо текста показывается шаблонный текст: "RELEASE NOTES [ProductName] [MajorNumber].[MinorNumber] Release [ReleaseNumber] (draft, not completed)".
Общепринятая структура РН: Новинки (Н – Features), Улучшения (У - Improvements), Исправленные Ошибки (ИО – Fixed Bugs), Исключено (И – Deleted/Deprecated), Возможные Проблемы (ВП – Detected Bugs). На каком этапе удобнее группировать? Для автоматизации конечно же надо начинать с низов – каждую задачу сразу распределять по структуре РН.
Из каких источников ТП может брать информацию для составления РН? К каждому сабмиту в СКВ разработчик обязательно пишет короткий комментарий о сделанных изменениях, который понятен сотрудникам со знанием языка программирования. Хоть СКВ и имеет самое правильное распределение задач по номерам билдов, но тексты комментариев к сабмитам мало подходят для РН, ведь их будет читать пользователь, не знающий "кухни" продукта. Поэтому инфу лучше брать из Баг-Трекинговой Системы (БТС). Но в БТС задачи ведутся для параллельных билдов или даже продуктов, поэтому нужны определённые пометки. В Jira есть очень полезная и удобная штука – лейблы, которые может добавлять и менять любой пользователь БТС, а также по ним легко фильтровать. Поскольку одна задача может содержать несколько лейбл, то и проблема параллельных билдов/продуктов вполне разрешима. Для автоматизации сбора РН была предложена система лейбл: "RN_[MinProductName]_[MajorNumber].[MinorNumber].[ReleaseNumber].[LastPublishedBuildNumber]+", где префикс "RN_" означает причастность задачи к РН, "MinProductName" – короткое наименование продукта, " [MajorNumber].[MinorNumber].[ReleaseNumber].[LastPublishedBuildNumber]" – полный номер последнего опубликованного билда, "+" – символ плюса означает последующий выпускаемый билд/версию. Например, в феврале выпустили Продукт Компании (ПК) версии "3.5.7.123", а в апреле собираются выпустить "ПК 3.6.2.ХХХ", в таком случае лейбла для задач, которые необходимо описать в РН ближайшего выпускаемого билда, будет "RN_ПК_3.5.7.123+".
Из какого поля брать тексты, чтоб это было быстро, при минимальном влиянии человеческого фактора? Значение из Summary вряд ли будет понятно пользователю, так как его составляют коротко, понятно лишь для проектировщиков и тестировщиков. Полное описание из Description совсем не подходит для РН, так как много технических деталей, а выбирать пару строк значит прикручивать парсер. Хоть у задач Jira и есть поле Components, но в нём может быть указано несколько модулей продукта, и для РН группировка станет сложной. И самое трудное – тип задачи Н/У/ИО/И/ВП – нельзя брать из поля Type, так как в БТС оформленный баг вполне может быть описан в РН как улучшение, а закрытая новинка без полного тестирования должна быть в блоке исключённых функциональностей. Учитывая вышеизложенные проблемы, было предложено создать текстовое поле "Release Notes Text", не обязательное для заполнения, но с возможностью правки для любого вида задач. История правок в Jira после ревизии аналитиком или разработчиком помогает обучать ТП. Черновой вариант от разработчика способствует составлению тест-аналитиком более полного комплекса тестовых случаев, а подправленный тестировщиком текст добавляет его понятливости конечным пользователем.
Для автоматизации сбора РН пришлось чётко описать во внутренней Wiki схему заполнения поля "Release Notes Text":
- в первой строке указать имя блока группировки РН кратко (Н/У/ИО/И/ВП) или подробно (Новшество/Улучшение/Исправленные Ошибки/Исключено/Возможные Проблемы);
- во второй строке указать одно наименование модуля или функциональной страницы продукта;
- в остальных строках описать задачу понятным для конечного пользователя языком.
При соблюдении такой структуры становится легко и просто распарсить и сгруппировать текст РН. А если показ РН в продукте делается в HTML формате, то необходимое форматирование удобно делать сразу в поле Jira.
Черновой вариант текста к каждой задаче хорошо бы оформлять программисту, потом подправлять тестировщику, а уже ТП завершит процесс форматирования и лексической пригодности.
Сочетание "непустое поле РН" и "наличие лейблы" является итоговым фильтром задач, которые должны быть отмечены в РН ближайшего выпускаемого билда. Лейблу проставляет ТП после полной проверки РН. Сбор текстов из спец.поля Jira – элементарное действие, но необходим самописный парсер для отсева дубликатов, группирования без излишних заголовков и выставления сортировки, соответствующей маркетинговым целям. Этот же автосборщик РН делает тексты в двух вариантах – с указанием номеров задач для промежуточных билдов и отчёта о наличии текстов, их корректности функциональной и лингвистической. Примечание: из РН, собираемых в html-формате, работают линки номеров задач Jira.
Аннотация к билду удобна для налаживания обратной связи с пользователем. К каждому пункту новшества и изменения в РН стоит добавить три чекера "Помогло", "Незаметно", "Лишнее". А в конце текста РН добавить функцию отправки результатов в Вашу техподдержку с возможностью дописать личное мнение о билде. Маркетинг может простимулировать какими-нибудь бонусами отправленную анкету. Будьте уверены, анализ анкет даст огромное поле деятельности аналитикам и тестировщикам.
Комментариев нет:
Отправить комментарий