Стандартная классификация ошибок внутри компании
#1
Отправлено 02 октября 2003 - 11:19
#2
Отправлено 08 октября 2003 - 06:41
Можно ссылки в студию или документ в почту (выложу в раздел Портфель).
Редактор портала www.it4business.ru
#3
Отправлено 08 октября 2003 - 07:10
#4
Отправлено 08 октября 2003 - 07:12
#5
Отправлено 08 октября 2003 - 08:18
По поводу предопределённого заранее типа ошибок, говорить не могу - ибо не знаю такого метода :)
Редактор портала www.it4business.ru
#6
Отправлено 08 октября 2003 - 08:43
#7
Отправлено 08 октября 2003 - 08:49
А о каких говорите вы?
Редактор портала www.it4business.ru
#8
Отправлено 08 октября 2003 - 10:22
Есть ли какое-то рациональное зерно в использовании дополнительно и такого списка?
Наверное, имеет смысл взглянуть на список групп ошибок Канера:
- Ошибки пользовательского интерфейса
- Обработка ошибок
- Ошибки, связанные с граничными условиями
- Ошибки вычислений
- Начальное и последующее состояния
- Ошибки управления потоком
- Ошибки обработки или интерпретация данных
- Ситуации гонок
- Повышенные нагрузки
- Аппаратное обеспечение
- Контроль версий и идентификаторов
- Ошибки тестирования
#9
Отправлено 08 октября 2003 - 10:31
Рациональное зерно в использовании приведенного (или подобного) списка есть.
Но и слово "модуль" Вы произнесли не случайно. Ошибки одной группы могут относиться к разным модулям, а, значит, скорее всего, их будут устранять разные люди.
Полезно группировать и так, и эдак
#10
Отправлено 08 октября 2003 - 10:50
#11
Отправлено 08 октября 2003 - 10:57
#12
Отправлено 08 октября 2003 - 13:01
NOT NULL в базе поставить на поле ;)У нас такая группа есть. Другое дело, что она не является обязательной для заполнения.
#13
Отправлено 08 октября 2003 - 13:09
У вас StarTeam?Не использую, потому как не злан что такая спецификация есть.
Можно ссылки в студию или документ в почту (выложу в раздел Портфель).
У него есть поля на форме Change Request
"Component" и "Category"
В компонент - что именно падает "Main Menu - System - File - Open File Dialog"
В категорию - категорию(:)) ошибки "Design"
И потом манагер проекта захотел посмотреть по каким-то параметрам количество багов - выборку по базе :) а-ля
Select count(*) as BugCout from starbase.Changes Where Component like 'Main Menu%'
У нас вообще тулзня заполняет эти поля
#14
Отправлено 10 октября 2003 - 08:15
С таким разнообразием как вы привели не работаем.
Различные типы ошибок (гонки, затыки, доступ) находятся на определённых этапах тестирования, поэтому не вижу особой надобности особо их разрабсывать.
А в стартиме ошибки по модулям раскидываю просто по разным папкам - открыл нужный модуль и работаиш - разработчикам тоже удобно.
Редактор портала www.it4business.ru
#15
Отправлено 10 октября 2003 - 11:37
Тестировщикам зато нет :(А в стартиме ошибки по модулям раскидываю просто по разным папкам - открыл нужный модуль и работаиш - разработчикам тоже удобно.
Сидит вот у меня девочка, ее от слова "сиквэл" в дрожь бросает. Как ей объяснить что вот эта ошибка произошла на бизнес-уровне, а вот эта, хоть и похожая, на уровне клиента. А вот эта вот, ну просто идентичная с предыдущей, - вообще не наша и желающие могут написать претензии в Майкрософт....
Это может быть оправдано, когда проект небольшой (у меня сейчас 4500 файлов исходников только по одному проекту) и разнесены они по папочкам удобным для разработчиков.
Тут именно указывается компонент. А на каком уровне сломалось, это уже девелопер пусть смотрит - у нас задачи другие. Нам под отладчиком тестировать некузяво ....
#16
Отправлено 10 октября 2003 - 11:40
У нас баги делаться по Projects (или Module в другой интерпретации), по Components (область функциональной области)
А еще одна проблема для нас была расстановки проиритетов. Мы также придумали собственную систему:
1- Crash - функция вызывает падеж программы или порчу данных
2 - Blocking point - функция отрабатывает, но результат ноль
3 - Incorrect - функция работает, что-то делает, но неправильно, т.е. результат не совпадает с ожидаемым
4 - Cosmetic - GUI (очепятки, размещение эл-ов ит.д.) и мелкие недочеты функционирования
5 - Requests - предложения по улучшению
6 - specifications - ошибки спецификации
Интересно a как это реализовано у коллег?
#17
Отправлено 10 октября 2003 - 11:54
Это её персональная проблема и к вопросу организации процесса отношения не имеет.Сидит вот у меня девочка, ее от слова "сиквэл" в дрожь бросает.
Это ей обьяснять и не надо :) На это есть вы. У меня когда сотрудники не сообразят куда закинуть (бизнесс уровень, дата) - просто кидают на меня. Когда я не знаю, кто именно сейчас ведёт этот кусок функционала из девелоперов - просто кидаю на ведущего разработчика.Как ей объяснить что вот эта ошибка произошла на бизнес-уровне, а вот эта, хоть и похожая, на уровне клиента. А вот эта вот, ну просто идентичная с предыдущей, - вообще не наша и желающие могут написать претензии в Майкрософт...
Опять не правда ваша - проект большой, но опять таки к предмету темы дела не имеет.Это может быть оправдано, когда проект небольшой (у меня сейчас 4500 файлов исходников только по одному проекту) и разнесены они по папочкам удобным для разработчиков.
Да какая мне разница сколько в нём файлов исходников? :)
У системы есть N модулей. Каждому модулю в разделе риквестов по две папки для начала:
-- ЮзерИнтерфейс - сюда и дизайн и юзабилити, и неспецификацию по тем же полям ввода, табордерам, шорткатам и пр
-- БизнесЛогика (вылеты, спецификация, логика, предложения и тыды)
Бедные девелоперы - как же вы им риквесты, то биш запросы на изменение то ставите? :)А на каком уровне сломалось, это уже девелопер пусть смотрит
Девушек успокаивать, которые в дрожи бьются? ;)- у нас задачи другие.
Guriy, без обид, просто призываю более предметно и обоснованно.
Редактор портала www.it4business.ru
#18
Отправлено 10 октября 2003 - 11:56
Note :
Enhancement
Feature request
Bug:
Crash
Exception occured (не приводящие к слёту программы)
Data error
I/O error
Incorrect result
Interface error (ошибки пользовательского интерфейса)
Spelling error
Кроме этого поля (Category), у каждого дефекта было поле Importance
Майк.
#19
Отправлено 10 октября 2003 - 12:00
Очень продумано.А еще одна проблема для нас была расстановки проиритетов. Мы также придумали собственную систему:
1- Crash - функция вызывает падеж программы или порчу данных
2 - Blocking point - функция отрабатывает, но результат ноль
3 - Incorrect - функция работает, что-то делает, но неправильно, т.е. результат не совпадает с ожидаемым
4 - Cosmetic - GUI (очепятки, размещение эл-ов ит.д.) и мелкие недочеты функционирования
5 - Requests - предложения по улучшению
6 - specifications - ошибки спецификации
Во многом зависит от системы которую вы тестируете, но чувствую, что проработано. А потом вы это используете как предлагалось выше? То есть строите разные выборки, чтобы погсомтреть что-то? И если не секрент что именно? Или при планировании применяете? Приоритеты ж ведь.
У нас сейчас тип бага это просто указание разработчику что именно вылетело - если угодно просто более формальное описание проблемы. Потом я для себя реальной пользы не вижу. Считать сколько было замечаний по дизайну, а сколько по функционалу мне не очень интересно. Мы стараемся всё таки работать на результат (на продукт), а не на цифры отчётов.Интересно a как это реализовано у коллег?
Редактор портала www.it4business.ru
#20
Отправлено 15 октября 2003 - 11:09
-----------
Полное описание ошибки.
Описание
1) ID
2) Заголовок
3) Описание и воспроизведение (можно разбить на две части)
4) Аттач
Управленческие признаки:
1) Приоритет исправления. 4 градации
2) Важность. 4 градации + предложение
3) Номер версии. Крупная версионность, такая как "Альфа", "Вета", ...
4) Владелец.
5) Состояние ошибки. Из Rational Rose.
Аналитические признаки:
1) Часть программы. Обычно 5-15.
2) Тип ошибки. Можно брать из Канера.
Достаточно стандартная ситуация:
Необходимо стабилизировать альфа версию для отправки клиенту. Часть ошибок переносится на бету, недочеты по производительности и авторизации не исправлять.
Запрос программиста к базе:
Часть программы: журнал операций (удобней править один пакет подряд)
Состояние: "назначена" или "в работе"
Тип: "функционал", "дизайн" (остальное не важно СЕЙЧАС)
Версия: "Альфа".
Вывести в порядке важности.
Другой запрос:
Срочно исправить ошибки с высоким приритетом (данные ошибки блокируют работу остальных участников команды)
--------------------
Принятая классификация по важности:
1. Critical (критическая) - с этой ошибкой приложение не может выполнять своих базовых функций
2. Major (важная) - выпадает важная функциональность
3. Average (средняя) - система ведет себя нестабильно и непредсказуемо
4. Minor () - функция реализована неудобно
5. Enhancement () - нужно добавить в спецификацию
Другой вариант оценки:
1. End User не может выполнять свою работу без внесение изменений в код
2. End User не может выполнять свою работу без консультации с фирмой разработчиком и / или выполнения нетривиальных действий (ручная инициализация базы, …).
3. End User может выполнять свою работу, но это неудобно
4. Мелкие недочеты, такие как, некорректные сообщения системы, отсутствие обозначения полей, обязательных к заполнению, ошибки в падежах, …
Понятно, что приведенные описания условны. Так отсутствие проверки на недопустимость каскадного удаления, приводит к потере данных. Это явно критическая ошибка. При этом конечный пользователь может успешно работать с системой. В конечном итоге тестер принимает решение, об определении важности ошибки исходя из своего опыта и практики, принятой в фирме.
Приоритеты:
1. Исправить немедленно.
Данная ошибка блокирует дальнейшую работу остальных участников проекта либо это требование заказчика.
2. По окончании текущей работы
3. Решать в рабочем порядке.
Порядок продолжения разработки и / или внесения изменений планируется разработчиком, исходя из общего плана.
4. Устранить при возможности.
Данная ошибка может быть исправлена при наличии ресурсов или малой ресурсоемкости.
Изначально тестер назначает приоритеты исходя из соответствия важности и критичности для проведения тестов. В дальнейшем менеджер проекта может изменять приоритеты.
Замечу что важность ошибки и приоритет исполнения далеко не одно и тоже. Может быть минорная бага с высшим приоритетом и наоборот.
--
Сергей Мартыненко
Блог 255 ступеней (байки для оруженосца)
facebook (Дети диаграммы Ганта)
ВебПосиделки клуба имени Френсиса Бэкона
Количество пользователей, читающих эту тему: 0
0 пользователей, 0 гостей, 0 анонимных