Перейти к содержимому

Фотография

Стандартная классификация ошибок внутри компании


  • Авторизуйтесь для ответа в теме
Сообщений в теме: 38

#1 Олешка

Олешка

    Консультант

  • Members
  • PipPipPipPip
  • 497 сообщений
  • ФИО:Ольга
  • Город:Рига, Латвия

Отправлено 02 октября 2003 - 11:19

Bug tracking tools ориентированы на свободную форму ввода описания ошибки. Сэм Канер в своей книге "Тестирование программного обеспечения" приводит список из более чем 400 стандартных ошибок. Существует также их классификация по группам, можно вводить коды и т.д. Использует ли кто-нибудь подобные списки в своей работе, если да - как вы это связываете с bug tracking системой?
  • 0

#2 Case

Case

    Основатель

  • Members
  • PipPipPipPipPipPip
  • 7 071 сообщений
  • ФИО:Панкратов Вячеслав
  • Город:Украина, Киев.

Отправлено 08 октября 2003 - 06:41

Не использую, потому как не злан что такая спецификация есть.
Можно ссылки в студию или документ в почту (выложу в раздел Портфель).
  • 0
Слава Панкратов
Редактор портала www.it4business.ru

#3 Олешка

Олешка

    Консультант

  • Members
  • PipPipPipPip
  • 497 сообщений
  • ФИО:Ольга
  • Город:Рига, Латвия

Отправлено 08 октября 2003 - 07:10

В принципе у меня есть документ, составленный на основе все той же книги, но не знаю насколько корректно с точки зрения авторских прав выкладывать его на сайте.
  • 0

#4 Олешка

Олешка

    Консультант

  • Members
  • PipPipPipPip
  • 497 сообщений
  • ФИО:Ольга
  • Город:Рига, Латвия

Отправлено 08 октября 2003 - 07:12

Кроме того, пока хотелось бы проговорить саму идею. Например, мы используем bug tracking и регистрируем там ошибки, описывая поведение программы, как есть, а также указывая, как должно быть. Насколько будет полезно использовать предопределенный заранее тип ошибок - похоже, что это скорее вариант check list? Что скажете?
  • 0

#5 Case

Case

    Основатель

  • Members
  • PipPipPipPipPipPip
  • 7 071 сообщений
  • ФИО:Панкратов Вячеслав
  • Город:Украина, Киев.

Отправлено 08 октября 2003 - 08:18

По поводу авторских прав - можно вывесить сам док (не анонсируя его через сервер), только для работы в форуме, то есть в форуме просто дадим ссылку на документ.

По поводу предопределённого заранее типа ошибок, говорить не могу - ибо не знаю такого метода :)
  • 0
Слава Панкратов
Редактор портала www.it4business.ru

#6 Olga

Olga

    Новый участник

  • Members
  • Pip
  • 42 сообщений

Отправлено 08 октября 2003 - 08:43

Разбивка ошибок на группы позволяет быстрее производить поиск нужных отчетов по проблемам. У нас часто руководитель просит сформировать отчеты по ошибкам связанным с тем-то и тем-то.
  • 0

#7 Case

Case

    Основатель

  • Members
  • PipPipPipPipPipPip
  • 7 071 сообщений
  • ФИО:Панкратов Вячеслав
  • Город:Украина, Киев.

Отправлено 08 октября 2003 - 08:49

У меня таких групп две - интерфейс и бизнесс логика.
А о каких говорите вы?
  • 0
Слава Панкратов
Редактор портала www.it4business.ru

#8 Олешка

Олешка

    Консультант

  • Members
  • PipPipPipPip
  • 497 сообщений
  • ФИО:Ольга
  • Город:Рига, Латвия

Отправлено 08 октября 2003 - 10:22

У нас тоже есть группы, относящиеся к модулям приложения, или к стадиям тестирования. Речь о другом - есть список типичных ошибок.
Есть ли какое-то рациональное зерно в использовании дополнительно и такого списка?

Наверное, имеет смысл взглянуть на список групп ошибок Канера:
  • Ошибки пользовательского интерфейса
  • Обработка ошибок
  • Ошибки, связанные с граничными условиями
  • Ошибки вычислений
  • Начальное и последующее состояния
  • Ошибки управления потоком
  • Ошибки обработки или интерпретация данных
  • Ситуации гонок
  • Повышенные нагрузки
  • Аппаратное обеспечение
  • Контроль версий и идентификаторов
  • Ошибки тестирования

  • 0

#9 SNord

SNord

    Новый участник

  • Members
  • Pip
  • 64 сообщений
  • Город:Санкт-Петербург

Отправлено 08 октября 2003 - 10:31

to Олешка:
Рациональное зерно в использовании приведенного (или подобного) списка есть.
Но и слово "модуль" Вы произнесли не случайно. Ошибки одной группы могут относиться к разным модулям, а, значит, скорее всего, их будут устранять разные люди.
Полезно группировать и так, и эдак
  • 0

#10 Олешка

Олешка

    Консультант

  • Members
  • PipPipPipPip
  • 497 сообщений
  • ФИО:Ольга
  • Город:Рига, Латвия

Отправлено 08 октября 2003 - 10:50

То есть получается, что просто в bug tracking надо завести еще одну группу - по классу ошибки?
  • 0

#11 Olga

Olga

    Новый участник

  • Members
  • Pip
  • 42 сообщений

Отправлено 08 октября 2003 - 10:57

У нас такая группа есть. Другое дело, что она не является обязательной для заполнения.
  • 0

#12 Guriy

Guriy

    Опытный участник

  • Members
  • PipPipPipPip
  • 316 сообщений
  • Город:Киев, Украина

Отправлено 08 октября 2003 - 13:01

У нас такая группа есть. Другое дело, что она не является обязательной для заполнения.

NOT NULL в базе поставить на поле ;)
  • 0

#13 Guriy

Guriy

    Опытный участник

  • Members
  • PipPipPipPip
  • 316 сообщений
  • Город:Киев, Украина

Отправлено 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%'

У нас вообще тулзня заполняет эти поля
  • 0

#14 Case

Case

    Основатель

  • Members
  • PipPipPipPipPipPip
  • 7 071 сообщений
  • ФИО:Панкратов Вячеслав
  • Город:Украина, Киев.

Отправлено 10 октября 2003 - 08:15

Категорию канешно используем, я имею в виду что у нас сиа не стандартизовано, а так канечно отмечаем - не в дизайне, не в спецификации, повторяющаяся и пр.
С таким разнообразием как вы привели не работаем.
Различные типы ошибок (гонки, затыки, доступ) находятся на определённых этапах тестирования, поэтому не вижу особой надобности особо их разрабсывать.

А в стартиме ошибки по модулям раскидываю просто по разным папкам - открыл нужный модуль и работаиш - разработчикам тоже удобно.
  • 0
Слава Панкратов
Редактор портала www.it4business.ru

#15 Guriy

Guriy

    Опытный участник

  • Members
  • PipPipPipPip
  • 316 сообщений
  • Город:Киев, Украина

Отправлено 10 октября 2003 - 11:37

А в стартиме ошибки по модулям раскидываю просто по разным папкам - открыл нужный модуль и работаиш - разработчикам тоже удобно.

Тестировщикам зато нет :(

Сидит вот у меня девочка, ее от слова "сиквэл" в дрожь бросает. Как ей объяснить что вот эта ошибка произошла на бизнес-уровне, а вот эта, хоть и похожая, на уровне клиента. А вот эта вот, ну просто идентичная с предыдущей, - вообще не наша и желающие могут написать претензии в Майкрософт....

Это может быть оправдано, когда проект небольшой (у меня сейчас 4500 файлов исходников только по одному проекту) и разнесены они по папочкам удобным для разработчиков.

Тут именно указывается компонент. А на каком уровне сломалось, это уже девелопер пусть смотрит - у нас задачи другие. Нам под отладчиком тестировать некузяво ....
  • 0

#16 sua

sua

    Новый участник

  • Members
  • Pip
  • 7 сообщений

Отправлено 10 октября 2003 - 11:40

Мы в свое время долго бились над классификацие багов у нас в компании и в конце концов пришли к определенному решению. Оно доморощенное, т.к. на тот момент мы были не знакомы с первоисточниками, но и на данный момент нас вполне удовлетворяет
У нас баги делаться по Projects (или Module в другой интерпретации), по Components (область функциональной области)

А еще одна проблема для нас была расстановки проиритетов. Мы также придумали собственную систему:
1- Crash - функция вызывает падеж программы или порчу данных
2 - Blocking point - функция отрабатывает, но результат ноль
3 - Incorrect - функция работает, что-то делает, но неправильно, т.е. результат не совпадает с ожидаемым
4 - Cosmetic - GUI (очепятки, размещение эл-ов ит.д.) и мелкие недочеты функционирования
5 - Requests - предложения по улучшению
6 - specifications - ошибки спецификации
Интересно a как это реализовано у коллег?
  • 0

#17 Case

Case

    Основатель

  • Members
  • PipPipPipPipPipPip
  • 7 071 сообщений
  • ФИО:Панкратов Вячеслав
  • Город:Украина, Киев.

Отправлено 10 октября 2003 - 11:54

Сидит вот у меня девочка, ее от слова "сиквэл" в дрожь бросает.

Это её персональная проблема и к вопросу организации процесса отношения не имеет.

Как ей объяснить что вот эта ошибка произошла на бизнес-уровне, а вот эта, хоть и похожая, на уровне клиента. А вот эта вот, ну просто идентичная с предыдущей, - вообще не наша и желающие могут написать претензии в Майкрософт...

Это ей обьяснять и не надо :) На это есть вы. У меня когда сотрудники не сообразят куда закинуть (бизнесс уровень, дата) - просто кидают на меня. Когда я не знаю, кто именно сейчас ведёт этот кусок функционала из девелоперов - просто кидаю на ведущего разработчика.

Это может быть оправдано, когда проект небольшой (у меня сейчас 4500 файлов исходников только по одному проекту) и разнесены они по папочкам удобным для разработчиков.

Опять не правда ваша - проект большой, но опять таки к предмету темы дела не имеет.
Да какая мне разница сколько в нём файлов исходников? :)

У системы есть N модулей. Каждому модулю в разделе риквестов по две папки для начала:
-- ЮзерИнтерфейс - сюда и дизайн и юзабилити, и неспецификацию по тем же полям ввода, табордерам, шорткатам и пр
-- БизнесЛогика (вылеты, спецификация, логика, предложения и тыды)

А на каком уровне сломалось, это уже девелопер пусть смотрит

Бедные девелоперы - как же вы им риквесты, то биш запросы на изменение то ставите? :)

- у нас задачи другие.

Девушек успокаивать, которые в дрожи бьются? ;)

Guriy, без обид, просто призываю более предметно и обоснованно.
  • 0
Слава Панкратов
Редактор портала www.it4business.ru

#18 Mike

Mike

    Консультант

  • Members
  • PipPipPipPipPipPip
  • 1 079 сообщений
  • Город:Москва

Отправлено 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
  • 0
Best regards,
Майк.

#19 Case

Case

    Основатель

  • Members
  • PipPipPipPipPipPip
  • 7 071 сообщений
  • ФИО:Панкратов Вячеслав
  • Город:Украина, Киев.

Отправлено 10 октября 2003 - 12:00

А еще одна проблема для нас была расстановки проиритетов. Мы также придумали собственную систему:
1- Crash - функция вызывает падеж программы или порчу данных
2 - Blocking point - функция отрабатывает, но результат ноль
3 - Incorrect - функция работает, что-то делает, но неправильно, т.е. результат не совпадает с ожидаемым
4 - Cosmetic - GUI (очепятки, размещение эл-ов ит.д.) и мелкие недочеты функционирования
5 - Requests - предложения по улучшению
6 - specifications - ошибки спецификации

Очень продумано.
Во многом зависит от системы которую вы тестируете, но чувствую, что проработано. А потом вы это используете как предлагалось выше? То есть строите разные выборки, чтобы погсомтреть что-то? И если не секрент что именно? Или при планировании применяете? Приоритеты ж ведь.

Интересно a как это реализовано у коллег?

У нас сейчас тип бага это просто указание разработчику что именно вылетело - если угодно просто более формальное описание проблемы. Потом я для себя реальной пользы не вижу. Считать сколько было замечаний по дизайну, а сколько по функционалу мне не очень интересно. Мы стараемся всё таки работать на результат (на продукт), а не на цифры отчётов.
  • 0
Слава Панкратов
Редактор портала www.it4business.ru

#20 SALar

SALar

    Профессионал

  • Members
  • PipPipPipPipPipPip
  • 2 298 сообщений
  • Город:Москва


Отправлено 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.    Устранить при возможности.
Данная ошибка может быть исправлена при наличии ресурсов или малой ресурсоемкости.

Изначально тестер назначает приоритеты исходя из соответствия важности и критичности для проведения тестов. В дальнейшем менеджер проекта может изменять приоритеты.


Замечу что важность ошибки и приоритет исполнения далеко не одно и тоже. Может быть минорная бага с высшим приоритетом и наоборот.
  • 0

-- 

Сергей Мартыненко

Блог 255 ступеней (байки для оруженосца)

facebook (Дети диаграммы Ганта)

ВебПосиделки клуба имени Френсиса Бэкона 

 



Количество пользователей, читающих эту тему: 0

0 пользователей, 0 гостей, 0 анонимных