Fix version что это
Поиск задач в JIRA (простым языком). Часть 2: Продвинутый поиск
Структуру JQL-запросов без примеров сложно понять специалистам, не знакомым ранее с JIRA.
Мы уже успели рассказать про быстрый и базовый поиск. Теперь же прейдем к самому мощному из трех методов — к продвинутому поиску.
В этом режиме вы можете указывать критерии, которые нельзя задавать в остальных предыдущих двух режимах (например, сортировку ORDER BY). Но придётся освоить создание структурированных запросов с помощью JIRA Query Language (JQL).
А если вы находитесь в режиме «базового» поиска, нажмите кнопку «Продвинутый»
1. Создание JQL-запросов
Простейший запрос на JQL состоит из поля, за которым следует оператор, а затем одно или несколько допустимых значений для этого поля. Например:
Такой запрос поможет найти все задачи проекта «YAT». Здесь использовано поле «project», оператор эквивалента «=» и допустимое значение «YAT».
Более сложный запрос может выглядеть так:
project = «YAT» AND assignee = currentuser()
Так мы отберём все задачи проекта «YAT», назначенные на текущего пользователя
(то есть на вас). В запросе содержатся: логический оператор «AND», поле «assignee» для отбора задач по текущему пользователю, оператор эквивалента «=» и функция «currentuser()», возвращающая имя текущего пользователя системы.
При создании запроса в режиме «продвинутого» поиска JIRA показывает список всех возможных операторов для поля запроса.
Также JIRA показывает список доступных значений для полей «AffectedVersion«, «FixVersion«, «Components«, кастомных полей формата «Version» и выпадающих списков.
При использовании в поиске полей формата «User» JIRA позволяет найти необходимого пользователя по его фамилии.
Вы можете использовать круглые скобки в сложных JQL-запросах. Например, если хотите найти все разрешенные задачи в проекте «SysAdmin», а также все задачи (любого статуса, любого проекта), назначенные в настоящее время системному администратору (admin), то можете использовать круглые скобки, обозначая приоритет логических операторов в запросе.
(project=SysAdmin AND status=resolved) OR assignee=admin
В JQL есть зарезервированные символы.
Внимание!
Также в JIRA есть зарезервированные слова.
Если в тексте поиска упомянуто одно из перечисленных ниже слов, этот текст нужно выделить либо двойными кавычками («. «), либо одинарными (‘. ‘).
Список зарезервированных слов:
| A | «abort», «access», «add», «after», «alias», «all», «alter», «and», «any», «as», «asc», «audit», «avg» |
| B | «before», «begin», «between», «boolean», «break», «by», «byte» |
| C | «catch», «cf», «char», «character», «check», «checkpoint», «collate», «collation», «column», «commit», «connect», «continue», «count», «create», «current» |
| D | «date», «decimal», «declare», «decrement», «default», «defaults», «define», «delete», «delimiter», «desc», «difference», «distinct», «divide», «do», «double», «drop» |
| E | «else», «empty», «encoding», «end», «equals», «escape», «exclusive», «exec», «execute», «exists», «explain» |
| F | «false», «fetch», «file», «field», «first», «float», «for», «from», «function» |
| H | «having» |
| I | «identified», «if», «immediate», «in», «increment», «index», «initial», «inner», «inout», «input», «insert», «int», «integer», «intersect», «intersection», «into», «is», «isempty», «isnull» |
| J | «join» |
| L | «last», «left», «less», «like», «limit», «lock», «long» |
| M | «max», «min», «minus», «mode», «modify», «modulo», «more», «multiply» |
| N | «next», «noaudit», «not», «notin», «nowait», «null», «number» |
| O | «object», «of», «on», «option», «or», «order», «outer», «output» |
| P | «power», «previous», «prior», «privileges», «public» |
| R | «raise», «raw», «remainder», «rename», «resource», «return», «returns», «revoke», «right», «row», «rowid», «rownum», «rows» |
| S | «select», «session», «set», «share», «size», «sqrt», «start», «strict», «string», «subtract», «sum», «synonym» |
| T | «table», «then», «to», «trans», «transaction», «trigger», «true» |
| U | «uid», «union», «unique», «update», «user» |
| V | «validate», «values», «view» |
| W | «when», «whenever», «where», «while», «with» |
2. Использование шаблонов для поиска по тексту
Специальные символы могут быть использованы для определения шаблонов поиска по тексту. Рассмотрим несколько примеров:
| Знак | Область применения и описание | Пример |
|---|---|---|
| ? | «?» используется для замены одного символа в шаблоне. Например, написание слов «text» и «test» отличается одним символом. Для поиска обоих вариантов достаточно задать шаблон: te?t | summary |
«te?t»
нуля или нескольких символов. Например, для отбора текста
«Windows», «Win95» или «WindowsNT» можно использовать
шаблон: win*
Для отбора текста «Win95» или «Windows95»
можно использовать шаблон: wi*95
» может быть использована для задания
нечетких поисковых шаблонов. В этом случае символ «
»
подставляется в конце нужного слова. Например,
чтобы найти термин, орфографически похожий на «roam»,
используйте шаблон: roam
В результате могут быть найдены слова «foam» или «roams».
3. Логические операторы JQL
| Оператор | Описание | Пример |
|---|---|---|
| AND | Логическая операция «И», соединяющая два или несколько условий. Используется для уточнения условий отбора. | project = «YAT» and status = «Оpen» — отобрать все задачи проекта «YAT» в статусе «Open» |
| OR | Логическая операция «ИЛИ», соединяющая два или несколько условий. | reporter = demo_1 or reporter = demo_2 — отобрать все задачи проекта, автором которых является пользователь demo_1 или пользователь demo_2. |
| NOT | Для реверсирования результата логического условия. | not assignee = demo_1 — отобрать все задачи, исполнителем которых не является пользователь demo_1. |
| ORDER BY | Сортировать по. |
По умолчанию будет использоваться собственный порядок,
применяемый для этого поля. Вы можете переопределить направление сортировки —
по возрастанию («asc») или убыванию («desc»).
отобрать все задачи, у которых пустые поля «Due date» (Срок исполнения),
отсортировать результаты выборки по полю «Created» (Создано).
duedate = empty order by created, priority desc —
отобрать все задачи, у которых пустые поля «Due date» (Срок исполнения),
отсортировать результаты выборки по полю «Created» (Создано)
в собственном порядке, затем по полю «Priority» (Приоритет)
в убывающем порядке.
| Оператор | Описание | Пример |
|---|---|---|
| = | Эквивалент. |
Используется для задания
критерия полного соответствия.
либо можно использовать запись
NOT reporter = demo_1
Используется для создания выражений
с полями формата «Version»,
формата дата-время и числовых полей.
duedate > now()
Используется для создания выражений
с полями формата «Version»,
формата дата-время и числовых полей.
duedate >= «2008/12/31»
created >= «-5d»
currentLogin()
Внимание
Самая ранняя не выпущенная версия определяется порядком, а не датами.
Применяется для создания выражений с полями «AffectedVersion» (Проявляется в версиях»), «FixVersion» (Исправлено в версиях), кастомными полями формата Version.
Unreleased
Version(project)
earliestUnreleased
Version
(ABC)
fixVersion =
earliestUnreleased
Version
(ABC)
Используется в выражениях с полями
«Created» (Создано),
«Due Date»
(Срок исполнения),
«Resolved»
(Дата решения),
«Updated» (Обновлено), кастомными полями формата даты-времени.
где inc —
опциональный
инкримент
(±)nn(y|M|w|d|h|m).
Если спецификатор единицы
измерения времени опущен,
по умолчанию используется
естественный период функции,
т. е. 1 день.
Внимание
Самая последняя выпущенная версия определяется порядком, а не датами.
fixVersion =
latestReleased
Version(ABC)
Внимание
LinkType чувствителен к регистру.
(issueKey)
linkedIssues
(issueKey,linkType)
(ABC-123,
«is duplicated by»)
Используется для создания выражений с полями «Reporter» (Автор), «Assignee» (Исполнитель), «Voter», «Watcher» и кастомными полями формата «User».
(Group)
in membersOf(QA)
Для отбора задач JIRA Service Desk, требующих согласования текущего пользователя или уже согласованных текущим пользователем.
Применяется к полям типа «Approvals».
myApproval()
Для отбора задач JIRA Service Desk, требующих согласования текущего пользователя.
Применяется к полям типа «Approvals».
myPending()
created >
startOfDay
(«-3d») – задачи,
созданные за
последние три дня.
Month()
Используется в выражениях с полями
«Created» (Создано),
«Due Date»
(Срок исполнения),
«Resolved»
(Дата решения),
«Updated» (Обновлено), кастомными полями формата дата-время.
где inc —
опциональный
инкримент
(±)nn(y|M|w|d|h|m).
Если спецификатор единицы
измерения времени опущен,
по умолчанию используется
естественный период функции,
т. е. 1 месяц.
created > startOfMonth
(«+14d») — задачи,
созданные с пятнадцатого
числа текущего месяца.
Week()
Используется в выражениях с полями
«Created» (Создано),
«Due Date»
(Срок исполнения),
«Resolved»
(Дата решения),
«Updated» (Обновлено), кастомными полями формата даты-времени.
где inc —
опциональный
инкримент
(±)nn(y|M|w|d|h|m).
Если спецификатор единицы
измерения времени опущен,
по умолчанию используется
естественный период функции,
т. е. 1 неделя.
created >
startOfWeek
(«-1») — задачи,
дата создания которых
старше начала
прошлой недели.
Year()
Используется в выражениях с полями
«Created»
(Создано),
«Due Date»
(Срок исполнения),
«Resolved»
(Дата решения),
«Updated» (Обновлено), кастомными полями формата дата-время.
где inc —
опциональный
инкримент
(±)nn(y|M|w|d|h|m).
Если спецификатор единицы
измерения времени опущен,
по умолчанию используется
естественный период функции,
т. е. 1 год.
created >
startOfYear
(«-1») — задачи,
дата создания
которых старше
начала прошлого года.
IssueTypes()
IssueTypes()
subtask
IssueTypes()
Versions()
Применяется для создания выражений с полями «AffectedVersion» (Проявляется в версиях), «FixVersion» (Исправлено в версиях), кастомными полями формата Version.
используется
для отбора задач
по всем проектам.
unreleased
Versions
(project)
unreleased
Versions(ABC)
Issues()
votedIssues()
Issues()
watchedIssues()
Надеюсь, что разбор продвинутого режима поможет вам при поиске задач.
Пользуйтесь и не теряйтесь 😉
Поиск задач в JIRA (простым языком). Часть 1: Быстрый и базовый поиск
В последнее время JIRA активно используют организации, не имеющие прямой связи с IT. Специалистам, не знакомым ранее с JIRA, бывает сложно понять структуру JQL-запросов, если не привести примеры.
Для упрощения восприятия, мы решили собрать всю документацию, локализовать и разместить в одном месте. И начнем мы с «базового» и «быстрого» поиска.
Многие сталкивались с необходимостью либо найти подходящую задачу в многообразии уже созданных, либо отобрать группу задач, отвечающих определенным критериям. Для этого JIRA предоставляет гибкую функциональность, рассчитанную как на технического специалиста, так и на обычного пользователя, а также позволяет сохранять поисковые запросы для последующего использования. Сохраненный запрос называется фильтром.
Существует три способа поиска задач в JIRA:
Стоит отметить, что, независимо от выбранного способа поиска, в качестве ответа будут возвращены только доступные для вашего просмотра задачи. Доступность определяется схемами прав доступа и безопасности в проектах, которым принадлежат данные задачи.
Быстрый поиск
Наименее точный и самый быстрый способ поиска задач в JIRA. Поле ввода расположено в правом верхнем углу экрана. Чтобы использовать его, просто начните вводить искомое.
1. Быстрый переход к задаче
Если известен ключ задачи, над которой вы работаете, то для быстрого перехода нужно ввести его и нажать Enter.
Предположим, вы работаете над задачей с ключом «YAT-106», в этом случае можно ввести в поле «Поиск» значение «YAT-106» или «yat-106».
Зачастую вам даже не нужно вводить полный ключ, достаточно ввести цифровую часть. Если вы работаете над проектом «YAT», то при вводе в поле «106» система автоматически перенаправит вас на «YAT-106».
2. Интеллектуальный быстрый поиск
JIRA позволяет использовать «интеллектуальный» быстрый поиск с минимальной типизацией. Например, для поиска всех задач типа «Task» в проекте «YAT», имеющих статус «Done», необходимо искать строку «Task Done YAT». И JIRA перенаправит вас в окно навигатора с отобранными по заданному критерию задачами.
В таблице ниже представлены специальные термины для «интеллектуального» быстрого поиска:
| Параметр поиска | Описание | Пример строки поиска |
|---|---|---|
| my | Поиск задач, назначенных на вас. | my open task |
| r: | Поиск задач, автором которых являетесь вы или другой пользователь, либо автор не определен. |
Внимание
Между «r:» и определением автора
не должно быть пробелов.
автором которых являетесь вы.
r:demo_3 — поиск задач, автором которых
является пользователь с логином demo_3.
r:none — поиск задач,
автор которых не задан.
определенного проекта
по его имени или ключу.
YAT
yat
истекает сегодня, либо уже закончился.
updated:
due:
«Created» (Создано),
«Updated» (Обновлено),
«Due Date» (Срок исполнения)
отвечали бы заданным критериям.
Соответственно,
параметру «Created» (Создано)
будет соответствовать «created»,
«Updated» (Обновлено) — «updated»,
«Due Date» (Срок исполнения) — «due».
При простановке условий можно использовать термины
«today», «yesterday», «tomorrow».
Также возможна запись вида «-1w»,«1w» обозначающая,
что интересующая нас дата лежит в интервале
от (-1 неделя) до (+1 неделя) от текущего
системного времени.
Запись вида «1w» обозначает, что интересующая нас
дата лежит в диапазоне от (+1 неделя)
от текущего системного времени.
Валидные аббревиатуры для даты и времени:
‘w’ (week), ‘d’ (day), ‘h’ (hour), ‘m’ (minute).
созданных за текущий день.
created:yesterday —
задачи, созданные за вчерашний день.
updated:-1w — задачи,
обновленных за последнюю неделю.
due:1w — срок исполнения начинается через
одну неделю от текущей даты.
due:-1d,1w — срок исполнения
лежит в диапазоне
от ( — 1 день)
до ( + 1 неделя)
created:-1w,-30m — дата создания
лежит в диапазоне от
( — 1 неделя)
до (
— 30 минут)
created:-1d updated:-4h — задачи, созданные
за последние сутки
и обновленные в течении
предыдущих четырех
часов.
high
medium
low
Внимание
Можно использовать значения во множественном числе.
task
bugs
tasks
duplicate
значением поля «Component/s» (Компоненты).
Внимание
Между «с:» и определением компонента
не должно быть пробелов.
в названии компонентов которых
содержится слово «security».
поля «Affects Version/s»
(Проявляется в версиях)
Внимание
Между «v:» и определением версии не должно быть пробелов.
со значениями для поля
«Affects Version/s»
(Проявляется в версиях):
Но не включает задачи
со следующими значениями
для поля «Affects Version/s»
(Проявляется в версиях):
Для отбора задач, содержащих
также минорные версии и версии сборок,
используется запись вида:
В результат запуска будут отобраны задачи
со значениями для поля
«Affects Version/s»
(«Проявляется в версиях»):
поля «Fix Version/s»
(Исправлено в версиях).
Поиск по параметру «ff:» производится
подобно поиску по параметру «v:».
ff:3.0*
3. Быстрый поиск по тексту
Также вы можете отбирать задачи, содержащие определенный текст — просто введите его в поле «Поиск». JIRA ищет задачи по тексту только в трёх определенных полях:
Базовый поиск
Это удобный пользовательский интерфейс для отбора задач. Чтобы им пользоваться, вам не обязательно знать JIRA Query Language (JQL).
Перейдите по пункту меню Поиск → Поиск запросов;
и выберете критерии поиска:
Стандартно «базовый» поиск содержит:
4. Поставьте галочку напротив необходимого поля;
5. Определите критерий отбора по этому полю.
Для удаления добавленного критерия отбора просто воспользуйтесь кнопкой
для данного критерия.
Запрос из «базового» поиска можно перевести в «продвинутый» JQL поиск, и наоборот. Однако запрос из «продвинутого» JQL поиска нельзя перевести в «базовый», если:
Как составить безупречный баг-репорт?
Профессия тестировщика ПО очень многогранна, ведь она требует внимания к деталям, креативности, коммуникативных навыков и усидчивости. Последнее качество особенно пригодится для такой части работы QA-инженера, как составление тестовой документации.
Один из примеров ― баг-репорт (от англ. bug report ― отчёт об ошибке), который содержит описание всех найденных дефектов в работе приложения. Не имеет значения, тестируете ли вы компьютерную игру, приложение для банка или сайт онлайн-магазина ― составление правильного отчёта является залогом продуктивного QA-процесса.
Баг-репорт содержит ответы на следующие вопросы:
С этим техническим документом предстоит ознакомиться разработчикам, которые внесут изменения в программный код и исправят ошибки. Именно поэтому баг-репорт должен быть лаконичным, понятным и содержать максимум полезной информации.
Разберёмся, как добиться этого сочетания.
Как выявляют баги?
Вы, как инженер по обеспечению качества, можете узнать о наличии дефектов в программном обеспечении несколькими способами:
Идеальный сценарий ― первый, когда дефекты выявляются до релиза специалистами по обеспечению качества. Но иногда до начала составления баг-репорта тестировщику приходится изучать чужой опыт взаимодействия с ПО при появлении ошибки.
Какой инструмент используют для документирования дефектов?
Самой распространённой системой для отслеживания дефектов является JIRA. Данный ресурс позволяет фиксировать ошибки и следить за их жизненным циклом. Но эта программа не такая простая, особенно для новичков в ИТ. Поэтому важно ознакомиться с её функционалом.
Студенты QA Academy уже на базовом курсе получают необходимый багаж знаний для эффективной работы с JIRA, а в этой статье мы подробно рассказали, как прокачать своё мастерство поиска в этой баг-трекинговой системе.
Некоторые компании отдают предпочтение и менее известным инструментам, например, Redmine или Mantis.
Каких правил придерживаться при написании баг-репорта?
Правило №1: следуйте принципу «1 дефект = 1 баг-репорт». Это позволит сохранить прозрачность процессов на проекте и детально следить за исправлением недочётов.
Правило №2: пишите баг-репорт простым и лаконичным языком, ведь от того, насколько быстро разработчик поймёт суть проблемы зависит скорость внесения правок в код.
Правило №3: описывайте дефект кратко, но с сохранением максимума полезной информации.
Правило №4: удостоверьтесь в воспроизводимости ошибки до заведения баг-репорта, повторите свой алгоритм действий и по возможности сократите число шагов.
Правило №5: проверьте, нет ли идентичного дефекта, который уже был зафиксирован.
Если всё в порядке, можно переходить к описанию.
Из каких элементов состоит баг-репорт?
Форма заполнения баг-репорта включает несколько полей (атрибутов). Туда тестировщик вносит характеристики дефекта. Число атрибутов может варьироваться в зависимости от баг-трекинговой системы и особенностей проекта, но с некоторыми тестировщики работают постоянно. Рассмотрим их:
Summary (заголовок)
Первый элемент баг-репорта — это краткое описание сути проблемы. В этом поле мы должны коротко и ясно описать выявленный дефект. Уже на этом этапе вы можете придерживаться правила «Что? Где? Когда или в каких условиях?». Не лишним будет добавить и данные о тестовом окружении, под которым выявлен дефект. Формулируйте этот атрибут в виде связного предложения, так будет проще вникнуть в суть проблемы.
Давайте рассмотрим конкретный пример. Представьте, что вы тестируете площадку объявлений menyaemsya.com. Согласно требованиям, поле с описанием товара должно содержать максимум 350 символов. Но вы видите, что система пропускает описание, которое превышает данный лимит. Для этого дефекта вам нужно составить баг-репорт. Воспользуемся подсказкой «Что? Где? Когда?», чтобы составить заголовок. Получается:
«Ограничение на ввод символов в поле с описанием товара отсутствует на всех страницах».
При тестировании мобильных приложений важно внести и название платформы, iOS или Android.
Заголовок готов. Можем двигаться дальше.
Description (описание)
Содержание этого поля отличается в зависимости от баг-трекинговой системы. Например, JIRA или Redmine предполагают описание шагов воспроизведения ошибки. Пользователи Mantis тут могут более подробно описать суть проблемы, а для описания пути воспользоваться атрибутом «Steps to reproduce» (в пер. с англ. «действия по воспроизведению»). Выглядеть это описание может следующим образом:
Если же предстоит выполнить слишком большую последовательность действий, то вы можете начать с описания условий.
«Пользователь авторизован на сайте menyaemsya.com и перешёл в корзину».
Actual/expected result (фактический/ожидаемый результат)
Нам предстоит ещё раз указать на суть дефекта и добавить информацию о том, как элемент ПО должен работать корректно.
Пример заполнения данного раздела:
«При внесении информации в поле “Описание” количество вводимых пользователем знаков не лимитируется. Ожидается, что после внесения 350 символов система не будет выводить на экран знаки и предложит пользователю сократить текст».
Attachments (вложения)
Этот элемент репорта позволяет проиллюстрировать суть бага и поделиться дополнительными данными. Вы можете прикрепить скриншоты, фото, видеозапись или иные файлы. Это упростит понимание сути проблемы и поможет быстрее сориентироваться.
Priority (приоритет)
Это важное поле, которое содержит информацию о срочности исправления дефекта. Данные этого атрибута помогают менеджеру планировать работу на проекте, ведь чем выше приоритет, тем скорее необходимо внести изменения.
Системы определения важности могут отличаться, но скорее всего вы встретитесь с подобной градацией:
Высокий приоритет имеют критические дефекты, которые необходимо исправить в кратчайшие сроки. Категория P3 включает те баги, которые не влияют на работу системы и могут быть устранены в последнюю очередь.
Severity (серьёзность)
Ошибки имеют и другую характеристику ― степень серьёзности влияния на систему.
Status (статус)
В этом поле находится актуальная информация о том, в каком состоянии текущая задача. Содержание этого атрибута может варьироваться в зависимости от баг-трекинговой системы. Вы можете столкнуться со следующими обозначениями:
Такими являются основные элементы баг-репорта, с которыми приходится встречаться чаще всего. Но в отчёте могут содержаться и дополнительные поля:
Резюмируем
Написание баг-репорта ― важный элемент QA-процесса, который позволяет ускорить устранение дефекта и подготовить качественное ПО к выходу на рынок. До начала написания документа важно:
Хороший отчёт об ошибке написан простым и понятным языком, содержит максимум полезной информации. Ключевыми атрибутами баг-репорта являются заголовок, описание, приоритет и статус ошибки. Стоит придерживаться порядка написания отчёта и заполнять все поля в зависимости от особенностей трекинговой платформы и требований проекта.
Умение составлять подобные репорты является важным для тестировщика навыком, который вы можете развить, ежедневно тренируясь. А освоить азы вам помогут наши замечательные преподаватели, сотрудники международной ИТ-компании, на курсе «Основы тестирования ПО». Присоединяйтесь!