Замечательно, с терминологией определелись
Расширение или нет ноборов тестов завист от конкретной ситуации - с этим тоже спорить сложно
У нас есть такая проблема -
после локализации нужно проверить элементы GUI на предмет - длины строки в контроле (т.е. "влазит" ли строка в, например, комбо бокс и т.п.) - вот тут то мы и сталкиваемся с техническими проблемами. Может у кого есть опыт решения таких задач?

Публикую произведение одного из наших тестировщиков

Собрались на экзамен ВижЫл Тест, Робот и Винраннер
Кто проще и лучше, у кого функций погуще

Первый встал ВижЫл Тест - в процессе работы не пьёт, не курит, не ест
Не ворует чужих невест, прогу любую осилит вот те крест
Спец бейсик не знаешь? Ничего, жить захочешь – на нем загутаришь
Таки не понимаешь? Калякай код, начальство потом запаришь...

Робот встал второй, о чем речь – ни в зуб ногой
Однако сразу в строй, функции горой, интерфейс настрой
Не будь балдой, автоматизацию dxf/dwg для себя открой
Кнопку нажми, скрипт напиши, не мельтеши и в бой

И тут встает Винраннер, запускай – осилишь, даже если полный ламер
Процессов в памяти не видит, перезагрузку ненавидит
Зато ГУЙ не обидит, запомнит, оформит и запишет,
Что смотришь, еле дышишь? Пора домой, слышишь?

Пока шел сыр-бор, ни о чем разговор, пришел во двор неизвестный до сих пор
Тянет к себе как магнит, хвалить себя не велит, знакомтесь - ТестКомплит
---------------------------------------------------------------------------------------------------
(© Терапевт)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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