Звернення до нації
в нашому світі існують люди, які можуть знайти баги навіть в ідеально написаної тобою програмі. Оборонятися від такої несправедливості безглуздо, тому краще цю справу впорядкувати.
Для цього використовуються системи управління дефектами на кшталт "Mantis".
- Так, можна називати дефекти багами. Головне не в назві, головне в тому, що їх треба лагодити.
Принципова схема роботи з Mantis
А оскільки ми ще і знаємо, на чиє ім'я направити цей репорт, і вкажемо це в системі, то статус нового репорт буде Assigned. І це дуже круто, адже:
Що таке issue?
Всі записи в Mantis називаються issue.
Принципово це перекладається як "предмет спору, розбіжність, проблема". Зазвичай це перекладають як "Завдання".
Фішка в тому, що кожне окремо взяте issue може бути або в будь-який момент стати як "Повідомлення про баг", і "ЗАВДАННЯМ НА РОЗРОБКУ".
Якщо я зробив запис з повідомленням про дефект - це повідомлення про баг.
Якщо я зробив запис про те, що треба б зробити функцію сортування - це вже завдання на розробку.
Як правило, через п'ять хвилин після роботи з Mantis ймовірність плутанини зникає. Перевірено на людях.
Загальні правила роботи з Mantis
Детальна схема роботи з Mantis
Розрулювання багів через Mantis
На зображенні досить докладна, але все-таки принципова схема.
Подібні схеми різняться від контори до контори, але це саме "принциповий підхід".
Попередження: для того, щоб працювати з Mantis в такому ось режимі, слід повозитися з налаштуванням статусів.
Управління проектом через Mantis
Це фантастика. Справа в тому, що Mantis зроблений для розробників. і зовсім не призначався для роздачі завдань і складання графіків успішності.
Але менеджерам системи типу Mantis подобаються тим, що вони можуть в режимі нереального часу бачити статус кожного завдання окремо - вона в роботі, або по ній потрібно більше інформації, або вона передана в тестування, або вона вже взагалі закрита. Тому всі менеджери на планеті Земля намагаються використовувати Mantis і як систему управління завданнями. Іноді це виходить успішно. Іноді немає.
Однак деякі товариші примудряються прикрутити до Mantis систему обліку часу. яке було витрачено бравими розробниками на вирішення існуючих проблем.
Друге і останнє звернення до нації
Отже, Mantis це інструмент для розробників.
Записи в подібній системі допомагають сортувати список завдань, які увійдуть в черговий реліз.
Записи в подібній системі допомагають не випустити з уваги якісь проблеми і / або завдання, не забути і не сховати.
Дефолтний пароль адміністратора при першій установці Mantis:
Username: administrator
Password: root
Все вищесказане відноситься до роботи з баг-трекерів В ПРИНЦИПІ, а не тільки до Mantis зокрема.
Ви хочете, щоб відбувалося як в Jira - там спершу уточнюється, яке діло ви хочете створити, а потім відкривається відповідний шаблон?
Mantis за замовчуванням є баг-трекером, який може стати issue-трекером (ось у чому його сила).
Вам слід додати додаткове поле, яке буде визначати, що за issue ми створюємо. Воно буде відображатися на сторінках, а також в загальному фільтрі на сторінці View Issues.
1)
Якщо це поле потрібно у всіх проектах, які будуть з'являтися в системі, то спершу переконайтеся в правому верхньому куті, що ви перебуваєте в "All projects". Інакше зміна буде стосуватися тільки проекту, в якому ви перебуваєте в даний момент.
3)
Створите нове поле:
- Name. Task type (назвіть як завгодно)
- Type. Enumeration
- Possible Values. Task | Bug | New feature (ваше рішення)
- Default Value. Task (з'являтиметься по-замовчуванню в випадаючому списку - ставите те, що хочете з поля "Possible Values")
- Add to Filter. + (Тобто, ставимо галочку)
- Display When Reporting Issues. +
- Required On Report. +
4)
Тепер при відкритті нового issue будете вибирати зі списку потрібне значення.
А потім сортувати в фільтрі - що завдання, а що - баги.
Ось тепер зрозумів. ВЕЛИЧЕЗНЕ СПАСИБІ. 🙂
Не можу зрозуміти чому при створенні інциденту (issue) ніяк не виходить вибрати тип на зразок "Feature Request", "Change Request", "Bug", "Information", як у вас написано. Що я не так роблю?
У вашого логіна в системі які права?
Адміністратор ... Але я завів тестового з правами "ініціатор". Схоже я напевно щось не розумію в системі статусів і прав?
Принципово це перекладається як «предмет спору, розбіжність, проблема». Зазвичай це перекладають як «Завдання».
я б перевів це як звіт, адже по суті своїй в Mantis'е зберігаються звіти про баги або доповнення з описом і умовами ....
до речі в свіжих мантіс є крім «Relationships» ще й теги, теж дуууже зручна доопрацювання
Є глибокий сенс у тому, щоб акаунти рівня Developer і Tester (за замовчуванням ролі тестувальника в Mantis немає) були позбавлені можливості ставити статус Closed. Принципово це повинен робити менеджер проекту. Менеджер повинен отримувати минулий весь девелоперський цикл завдання тільки в статусі Tested.
тут не погоджуся ... навіщо ж менеджеру закривати перевірені після рішення звіти ?!
я б перевів це як звіт
"Додати новий звіт" - звучить?
навіщо ж менеджеру закривати перевірені після рішення звіти ?!
Потім, що стан релізу оцінюється станом все ще відкритих завдання. "Звітів". Коли вони все закриті, реліз оголошується "вийшли". Інакше мається на увазі, що по ньому ще треба зробити якісь роботи.
"Створити звіт" так звучить, по дефолту в мантіс "Створити питання" ....
у нас є роадмеп за яким можна судити про стан проекту ... коли всі звіти по проекту в статусі закритий, тобто тестувальник всі звіти перевірили і закрили, значить проект готовий до здачі!
Надійніше за все - в мантіс. Призначити завдання на своє ім'я. Вказати реліз або ще й білд, в якому треба буде до цього питання повернутися. І в потрібний час дійсно до нього повернутися.
Якщо є час вказати якісь подробиці на кшталт "як відтворити" - це тільки плюс, адже завдання можна буде комусь передати, і розраховувати на її адекватне відтворення.
Швидкість виправлення дефекту і його значимість не пропорційні 🙂
Якщо на виправлення дефекту потрібно менше 10 секунд, але потрібно не забути це виправлення протестувати свого часу, то що робити, куди це записується?
Відмінна інструкція (просто і ємко). Мені, правда, частіше доводиться користуватися JIRA, ніж мантіс, але саме тим товаришам, з якими я використовую Mantis частіше доводиться пояснювати що це за штука і навіщо вона потрібна.
Офіційний спiвпрацювальнік по підготувальні тестувальніків компанії [Astound Commerce], Київ (QA Trainer).
Іноді веду «[підклас]» для тестувальників.
Написав свій [глосарій] термінології тестування (english only).
Неодноразовий доповідач [SQA Days], [QA Fest] та інших конференцій з тестування ПО.
Неспішно їжджу на «[Волга ГАЗ-21]» 1965 року випуску.
Граю щось схоже на важкий блюз [на класичній гітарі].