Как проверить действительно-ли невозможно исправить дефект?
#1
Отправлено 24 июля 2008 - 07:33
В 1-й колонке текст при уменьшении колонки хайдится, но
при увеличении видно всего пару слов, последнее не закончено, вместо последних букв троеточие.
Девелопер утверждает, что в отличие от таблиц(последующие колонки),
где текст можно скрыть\показать в дереве папок такое невозможно,
и что это является особенностью java.
К сожалению java я не владею.
Подскажите пожалуйста, как проверить, правда ли это,
и если нет, как доказать, что дефект исправим?
#2
Отправлено 24 июля 2008 - 11:15
Если очень коротко, то любой дефект исправим (ну хорошо, большинство дефектов). Вопрос только в цене этого исправления. И цена это может быть очень высокой.
Соберите информацию о проблеме. Насколько это *действительно* *важно*, как это влияет на приложение и его пользователей. Эти данные обсудите с разработчиком. Обычно, если вы хорошо подготовитесь, вы вдвоем найдете решение, ибо разработчик - ваш друг и имеет те же цели, что и вы. В последнюю очередь проблему можно эскалировать, пойдя к менеджеру, но доказательства *важности* проблемы в таком случае должны быть очень весомые.
#3
Отправлено 24 июля 2008 - 11:25
Мне важно было знать, насколько адекватно разработчик описал ситуацию.Соберите информацию о проблеме. Насколько это *действительно* *важно*, как это влияет на приложение и его пользователей. Эти данные обсудите с разработчиком. Обычно, если вы хорошо подготовитесь, вы вдвоем найдете решение, ибо разработчик - ваш друг и имеет те же цели, что и вы. В последнюю очередь проблему можно эскалировать, пойдя к менеджеру, но доказательства *важности* проблемы в таком случае должны быть очень весомые.
Информацию я уже нашла и выводы сделала.
За совет большое спасибо.
#4
Отправлено 25 июля 2008 - 04:36
Он, вероятно, имел в виду, что это является особенностью того виджета для рисования дерева, который он использовал, с дефолтным рендерером.
Можно либо сделать собственный рендерер (вместо DefaultTreeCellRenderer), либо использовать другой виджет, например, "накрученную" таблицу с возможностью сворачивания строк, как в дереве (можно погуглить по слову TreeTable или JTreeTable, что-нибудь должно найтись).
По теме топика (как проверить, действительно ли невозможно исправить дефект):
Если разработчик говорит, что нечто невозможно -- попробуйте спросить других разработчиков, желательно "конкурентов" того, первого. Они между собой негласно соревнуются, и если один говорит, что нечто невозможно, а второй придумывает, как это сделать, то у второго прибавляются очки к карме, а у первого убавляются :)
Тренинги для тестировщиков (тестирование производительности, защищенности, тест-дизайн, автоматизация):
Линейка тренингов по Selenium
#5
Отправлено 25 июля 2008 - 06:22
Да и еще: Исправить возможно ВСЕ в проекте, если он не использует сторонний софт(модули и т. д.), но это уже отдельная тема для разговора
#6
Отправлено 25 июля 2008 - 07:33
А если разработчик наберет много очков кармы, то в следующей жизни он станет тестировщиком :).то у второго прибавляются очки к карме, а у первого убавляются :)
Чубака — это вуки с планеты Киши, но живет Чубака на планете Эндо, а теперь вдумайтесь:
в этом же нет смысла. С какой стати Чубаке, вуки высотой два с половиной метра,
жить среди эвоков, которые чуть выше полуметра. В этом нет абсолютно никакого смысла.
#8
Отправлено 25 июля 2008 - 12:29
Тестером это в лучшем случае... но по правде, он станет пользователем того софта что сам написал... вот тогда то он и понервничает :)А если разработчик наберет много очков кармы, то в следующей жизни он станет тестировщиком :).то у второго прибавляются очки к карме, а у первого убавляются :)
Исправить можно абсолютно все, но никто на это не пойдет из-за элементарной финансовой необоснованности... Но если затраты будут соизмеримы с убытками от этого бага, то фиксить придется, как не крути... Но решать это уже будете не вы, а вышестоящие манагеры... Вот.Исправить возможно ВСЕ в проекте, если он не использует сторонний софт(модули и т. д.)
Про Тестинг
#9
Отправлено 25 июля 2008 - 12:41
Как то Вы далеко глянули, я рассмотрел случай конкретной ситуации, а то есть, если программер говорит что исправить нельзя, это не причина убирать дефект, а лишь показатель не компетентности программера. Если он считает что исправление повлечет за собой большие трудозатраты и соотвественно "оно того не стоит", то это соотвественно ОН, т. е. программер должен сообщить руководству, но дефект не должен быть закрыт по причине "нельзя исправить, особенности языка"Исправить можно абсолютно все, но никто на это не пойдет из-за элементарной финансовой необоснованности... Но если затраты будут соизмеримы с убытками от этого бага, то фиксить придется, как не крути... Но решать это уже будете не вы, а вышестоящие манагеры... Вот.
#10
Отправлено 25 июля 2008 - 14:47
А кто говорил про закрытие дефекта? вроде бы я ни словом об этом не обмолвился :)Как то Вы далеко глянули, я рассмотрел случай конкретной ситуации, а то есть, если программер говорит что исправить нельзя, это не причина убирать дефект, а лишь показатель не компетентности программера. Если он считает что исправление повлечет за собой большие трудозатраты и соотвественно "оно того не стоит", то это соотвественно ОН, т. е. программер должен сообщить руководству, но дефект не должен быть закрыт по причине "нельзя исправить, особенности языка"Исправить можно абсолютно все, но никто на это не пойдет из-за элементарной финансовой необоснованности... Но если затраты будут соизмеримы с убытками от этого бага, то фиксить придется, как не крути... Но решать это уже будете не вы, а вышестоящие манагеры... Вот.
Есть много замечательных статусов у дефектов, которые практически равносильны закрытому, таких как Deferred, Fix in Future Version и т.д. И тогда уже менеджер решает какой и когда разморозить, и поставить кастомеру...
А вообще баг может быть закрыт, если он исправлен (Fixed) либо не валиден (Rejected), в других случаях он еще дышит...
Про Тестинг
#11
Отправлено 25 июля 2008 - 15:05
Я не говорю о том, что говорите Вы, я говорю о этой ситуации, если конкретней: То девелопер утверждал о невозможности исправления дефекта, и этот его ответ явно не говорил о статусе Fix in Future Version.
Так же мне уже кажеться тут началось придирание к словам, я высказал свое мнение на вышеописанную ситуцию более того, моё видение данной ситуации не имело цель: принять к исполнению, и слово закрыт в моей интерпритации имело абстрактный характер, неважно какой статус разрабочик хотел что бы поставил QC, я говорил о том что разрабочик не прав в конкретно данной ситуации.
Не первый раз женат (с)
Количество пользователей, читающих эту тему: 0
0 пользователей, 0 гостей, 0 анонимных