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

Аудит и оптимизация QA-процессов
онлайн, начало 4 декабря
Практикум по тест-дизайну 2.0
онлайн, начало 4 декабря
Школа Тест-Аналитика
онлайн, начало 9 декабря
Школа тест-менеджеров v. 2.0
онлайн, начало 9 декабря
Фотография

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


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

#21 sua

sua

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

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

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

SALar Oct 15 2003, 01:09 PM:
Замечу что важность ошибки и приоритет исполнения далеко не одно и тоже. Может быть минорная бага с высшим приоритетом и наоборот.


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

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

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


1. Коробочный продукт - САПР
2. Да выборки делаем. Обычно это нужно в двух случаях
- на момент планирования версии - обсуждение с заказчиком, а что ж собственно делать
- во время разработчки на стадиях Alpha, Beta, Final - анализ качества и количества багов. Например, если крашей становиться меньше, то можно предположить, что версия становиться стабильней или еще, если кол-во реквестов растет, то надо начинать говорить об изменении сроков и т.д.
3. При планировании конечно используем, но наша специфика такова, что мы чаще ограничены сроками, а там сколько успеем, столько успеем. Да и динамика такова, что репорт живет максимум 2 недели от занесения до закрытия
Поэтому, например, такая вещь как признак, что баг надо пофиксить в мифическом "Следующем релизе" для нас неактуальна

Я как проджект манаджер каждый день просматриваю пул задач и решаю, что надо делать. Т.е. девелоперам приходят только те задачи.баги, которые надо было сделать вчера и до обеда :D
  • 0

#22 OlegSh

OlegSh

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

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

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

Можно воспринимать как шутку но из этих слов

3. При планировании конечно используем, но наша специфика такова, что мы чаще ограничены сроками, а там сколько успеем, столько успеем. Да и динамика такова, что репорт живет максимум 2 недели от занесения до закрытия
Поэтому, например, такая вещь как признак, что баг надо пофиксить в мифическом "Следующем релизе" для нас неактуальна

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

#23 sua

sua

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

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

Отправлено 17 октября 2003 - 05:27

Можно воспринимать как шутку


Интересно, а что в моих словах похоже на шутку?

но из этих слов следует, что оставшиеся минорные баги просто не считаются багами и фиксить их не надо.


Из того что баг не пофикшен не следует того, что это не баг. Следует только то, что на данном этапе этот баг отложен и решение о том когда и как его фиксить будет приниматься позже

А если серьезно,то я еще не видел в своей жизни ни одного законченного и сданного проекта без официальных баг, а если их нет, то это только значит то, что о них просто молчат


Полностью согласен
  • 0

#24 Green

Green

    Гуру

  • Members
  • PipPipPipPipPipPip
  • 1 233 сообщений
  • ФИО:Гринкевич Сергей
  • Город:Москва

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

Сэм Канер в своей книге "Тестирование программного обеспечения" приводит список из более чем 400 стандартных ошибок. Существует также их классификация по группам...

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

Ребята, разрешите вернуть вас к теме вопроса. :D

IMHO, нет большого смысла дополнять описание выявленного дефекта программы ссылкой на пункт списка наиболее распространенных ошибок.

Во-первых, очень легко ошибиться. Незная кода трудно однозначно определить на какую имеено ошибку из списка похожа полученная.

Во-вторых, необходимость постоянно сверяться со столь большим списком затруднит работу.

В третьих, я не вижу (может быть - пока) большой ценности в наличии такой статистики. Что может сказать информация, что в этом билде было обнаружено и задокументировано три дефекта из раздела "Ошибки управления потоком"?

На мой взгляд, этот список всего лишь помогает определить, где могут скрываться проблемы. Если хотите, своеобразный заменитель интуиции или опыта (кому что ближе B) ).
  • 0
Гринкевич Сергей

#25 OlegSh

OlegSh

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

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

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

To sua,
Как шутку можно воспринимать мой вывод из процитированного текста - "следует, что оставшиеся минорные баги просто не считаются багами и фиксить их не надо. "

И я не совсем понимаю, что означают слова

Поэтому, например, такая вещь как признак, что баг надо пофиксить в мифическом "Следующем релизе" для нас неактуальна

в контексте

Из того что баг не пофикшен не следует того, что это не баг. Следует только то, что на данном этапе этот баг отложен и решение о том когда и как его фиксить будет приниматься позже

Если проект закончен, то в когда же будут пофикшены отложенные баги, если не в следующем релизе/сервис паке/хот фиксе?
  • 0

#26 sua

sua

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

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

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

2OlegSh
Я не знаю специфику вашего проекта\проектов. В нашем случае проект - это только отдельный модель программы. Кроме этого так исторически сложилось, что изменения у нас происходят по спирали, т.е.
- принимается выпустить X+1ую версию программы
- решается, что будут добавлены такие-то и такие фичи, кроме этого будут внесены изменения в такие-то и такие проекты (модули), написанные ранее (в том числе и баг фиксы)

Поэтому у нас не существует ситуации, когда мы завершили проект и забыли о нем. нам надо проддерживать софтину с 20-ти летней историей и несколькими десятками тысяч польхзователей по всему миру
Опять же поэтому невозможно исправить ВСЕ баги (даже известные), а на данный момент наша база имеет примерно около 2000 репортов о них от конечных пользователей, не считая нашей внутренней базы ошибок.

Исходя из вышесказанного, наша основной принцип при выпуске каждой новой версии: "Не навреди", т.е. если работает, то лучше оставить что-то не доделанное, если есть возможность обойти проблему
  • 0

#27 Julic

Julic

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

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

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

У нас используется следующая классификация багов:

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

Severity - feature
trivial
text
tweak
minor
major
crash
block
  • 0

#28 Green

Green

    Гуру

  • Members
  • PipPipPipPipPipPip
  • 1 233 сообщений
  • ФИО:Гринкевич Сергей
  • Город:Москва

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

Судя по некоторым высказываниям респондентов этой темы (и не только этой). Могу сделать вывод, что многие не знакомы с классическим трудом Сэма Канера (и группы).

Это классический труд, написанный самыми извествными специалистами в области качества ПО! НАСТОЯТЕЛЬНО РЕКОМЕНДУЮ ПРОЧЕСТЬ!
  • 0
Гринкевич Сергей

#29 Tester

Tester

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

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

Отправлено 03 ноября 2003 - 17:00

Приведу еще один пример, может, кому то пригодится:
A - OS/Browser crash
B - application/site crash
C - incorrect functionality
D - not implemented yet
E - cosmetic(interface) bug
F - setup bugs
OK - OK
Кроме того, у нас в bug reports есть поле Customer Impact со стандартными приоритетами (Urgent, High, Normal, Low).
  • 0

#30 Green

Green

    Гуру

  • Members
  • PipPipPipPipPipPip
  • 1 233 сообщений
  • ФИО:Гринкевич Сергей
  • Город:Москва

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

Попробую вернуть всех к вопросу Олешки. :-)

Спрашивала она не о системе классификации багов (это давольно просто и у многих используются очень похожие классификаторы). Вопрос стоял о СИСТЕМЕ КЛАССИФИКАЦИИ ДЕФЕКТОВ ПО (в программистских терминах - например: ситуация гонок или деление на ноль).

По сути, речь идет о параллельной системе классификации. Она более присуща типу тестирования "белый ящик", когда известен код или реакция системы столь очевидна, что можно с очень высокой степенью вероятности назвать не внешний признак (например: косметический баг или некорректная операция), а суть дефекта.

B) Не все так просто в этом мире!
  • 0
Гринкевич Сергей

#31 Олешка

Олешка

    Консультант

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

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

Green, спасибо :)

Краткое резюме по постам -

Классификацию по группам ошибок не используют.

Баг трекинг тулы используют для организации обмена информацией между тестировщиками и разработчиками, но не для сбора материала для анализа проблем.

ИМХО, использовать классификацию по группам ошибок было бы полезно в больших сопровождаемых системах и при работе с многократно использующимся кодом.
  • 0

#32 sua

sua

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

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

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

По сути, речь идет о параллельной системе классификации. Она более присуща типу тестирования "белый ящик", когда известен код или реакция системы столь очевидна, что можно с очень высокой степенью вероятности назвать не внешний признак (например: косметический баг или некорректная операция), а суть дефекта.



Спасибо за разъяснение :D

2Олешка
Да, подобную классификацию не используем. Честно говоря, не уверен в необходимости использования такого подхода, кроме как журит девелоперов: "Ты по чему такой плохой, что постоянно допускаешь деление на 0" :angry:
Но это все шутки - а реально зачем вы используете эту классификацию? я не думаю, что это большое подспорье девелоперам
  • 0

#33 Green

Green

    Гуру

  • Members
  • PipPipPipPipPipPip
  • 1 233 сообщений
  • ФИО:Гринкевич Сергей
  • Город:Москва

Отправлено 04 ноября 2003 - 09:21

я не думаю, что это большое подспорье девелоперам

В любом деле есть палка у которой два конца. (какой-то китайский философ :D )
Вот этой бы палкой разработчиков гонять! (это уже совсем другой не менее китайский философ :lol: ).

Если разработчику точно указать место положение ошибки, то любой скажет спасибо. Но для тестировщика это давольно трудная задача - "копать" код. Кстати, не только для тестировщика. Далеко не каждый разработчик обрадуется заданию - просматривать чужой код.

Если разработчику подробно описать некорректное поведение системы, то это ему поможет быстрее локализовать место нахождение ошибки и условия ее проявления. Что бы этого добиться тестировщик должен сам очень четко представлять, что же он тестирует. И если он может осмыслить программу не только на уровне операций и интерфейса пользователя, но и на уровне объектов и методов, это может помочь ему создать более узконаправленные тесты, что, безусловно, скажеться на результатах тестирования.

Ложкой дегтя в этой бочке меда является то, что очень легко белое принять за черное и дать не некорректную оценку найденной проблеме. В этом случае, можно отвлечь внимание разработчика на устранение не существующего дефекта.
  • 0
Гринкевич Сергей

#34 Олешка

Олешка

    Консультант

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

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

Да, подобную классификацию не используем. Честно говоря, не уверен в необходимости использования такого подхода, кроме как журит девелоперов: "Ты по чему такой плохой, что постоянно допускаешь деление на 0" :angry:
Но это все шутки - а реально зачем вы используете эту классификацию? я не думаю, что это большое подспорье девелоперам

Мы не используем. Прежде чем что-то использовать, надо хотя бы представлять, а что это даст. Для этого и был открыт тред - обсудить ситуацию.
  • 0

#35 Green

Green

    Гуру

  • Members
  • PipPipPipPipPipPip
  • 1 233 сообщений
  • ФИО:Гринкевич Сергей
  • Город:Москва

Отправлено 04 ноября 2003 - 10:23

Линки на документы:

Microsoft Solutions Framework Дисциплина управления подготовкой MSF вер. 1.1
http://www.microsoft...ss_mngt_rus.doc

Microsoft Solutions Framework Дисциплина управления проектами MSF вер. 1.1
http://www.microsoft...ct_mngt_rus.doc

Microsoft Solutions Framework Дисциплина управления рисками MSF вер. 1.1
http://www.microsoft...ks_mngt_rus.doc

Microsoft Solutions Framework Модель проектной группы MSF вер. 3.1
http://www.microsoft...m_model_rus.doc

Microsoft Solutions Framework Модель процессов MSF вер. 3.1
http://www.microsoft...s_model_rus.doc
  • 0
Гринкевич Сергей

#36 Green

Green

    Гуру

  • Members
  • PipPipPipPipPipPip
  • 1 233 сообщений
  • ФИО:Гринкевич Сергей
  • Город:Москва

Отправлено 04 ноября 2003 - 10:27

Прикол, писал в одну конфу, а попал в другую... :D

Мистика! :ph34r:
  • 0
Гринкевич Сергей

#37 SNord

SNord

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

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

Отправлено 05 ноября 2003 - 11:13

To Олешка:

Вопрос, может быть, несколько в стороне, но более близкой темы не обнаружил:
Канер советует отложенным отчетам присваивать новые номера при переходе к работе над новым выпуском программы. А как Вы поступаете? Может, нужно как раз со старым ID продолжать?
  • 0

#38 Олешка

Олешка

    Консультант

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

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

To Snord: У нас каждому описанию проблемы присваивается номер и статус (Open, Closed, Fixed etc.). Если проблема осталась открытой, она будет висеть на проекте. Периодически (перед тем как планировать изменения и дополнения к проекту) пересматриваются все незакрытые проблемы.

Новый номер не присваиваем. Еще и потому, что bug tracking тул не поддерживает такой возможности.
  • 0

#39 Case

Case

    Основатель

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

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

Прикол, писал в одну конфу, а попал в другую...

В какую конференцию перенести?
  • 0
Слава Панкратов
Редактор портала www.it4business.ru


Школа Тест-Аналитика
онлайн
Организация автоматизированного тестирования
онлайн
Школа тест-менеджеров v. 2.0
онлайн
Тестирование юзабилити (usability)
онлайн



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

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

Яндекс.Метрика
Реклама на портале