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

Бредовый баг, бредовое решение:
http://habrahabr.ru/...telecom/133075/

Баг вполне достоин занять место в коллекции панбагона.

Бредовый баг, бредовое решение:
http://habrahabr.ru/...telecom/133075/

Баг вполне достоин занять место в коллекции панбагона.

Я бы не была столь категорична )))

По сути - три компонента:
- телефон
- симка
- базовые станции

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

Это так - навскидку.
По жизни - самая гадость из возможных сбоев.

)))))
Тут же как получается.
Есть претензии из эксплуатации. Еще не баг.
Далее - цепочка технических разборок.
Которая может привести (или не привести) к багу.

)) вообще ситуация для меня крайне интересна в плане как провести по документам такой баг (если это баг).

ПС. Баг здесь - ошибка в ПО. ))

Ну вот Vasiliy приводит в соседней теме описание бага.

Для описания ошибки может использовать такую форму.

Начальные условия - программа запущена при таких-то условиях. Если там сложная логика вкладок или надо выполнить какие-то подготовительные действия, то это тоже описывается здесь.
Действия - нажал, подождал, etc.
Результат - сообщение об ошибке, упала, ничего не произошло (хотя ожидалось).

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

P.S. Первый и последний пункты могут быть не во всех случаях, имхо.

А в приведенном в этой ветке сбое с телефоном, как оформить баг?

))) хорошая тренировка, ОК?

Ну вот Vasiliy приводит в соседней теме описание бага.
...
А в приведенном в этой ветке сбое с телефоном, как оформить баг?

А что тут особые сложности?:)

Начальные условия - 2 сим-карты разных операторов.

Действия с одной симкой - включи, подождали.
Результат - перезагрузка.

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

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

Ну вот Vasiliy приводит в соседней теме описание бага.
...
А в приведенном в этой ветке сбое с телефоном, как оформить баг?

А что тут особые сложности?:)

Начальные условия - 2 сим-карты разных операторов.

Действия с одной симкой - включи, подождали.
Результат - перезагрузка.

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

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

И?
Отдали эту багу программистам.
Что по Вашему программист с ней должен делать?
Мотаться по Ленинградской области (к примеру) от базовой станции к базовой станции?
Периодически вставляя разные симки?

(хихикает) на бытовом уровне см. мастер-класс "Тестирования на примере банкомата"

)) собственно, тут уже обсуждение на тему "Как мы пишем баги? Понятно или нет?"

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

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

я тож в сотовых не специалист.
Вопрос не как предоставить информацию.
Она уже предоставлена -- есть претензии из эксплуатации. Уже зафиксированные.

Дальше эти претензии надо переработать и как-то (при необходимости) донести до программистов.

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

Как-то такие баги норовят жить несколько своей жизнью.

где-то на стыке --- сбой.
Кстати.
Пока не определена причина я бы не стала называть это "баг".

Почему нет? Ведь баг - это как раз нечто, вызывающее сбой в работе компбтера или программы (вспоминая, The first case of the bug found)

Она уже предоставлена -- есть претензии из эксплуатации. Уже зафиксированные.
Дальше эти претензии надо переработать и как-то (при необходимости) донести до программистов.

И тут у меня чисто по ролям-бумагам все не гладко получается.
Пусть проблема локализована, и пусть ясно - что можно путем изменения ПО телефона ее ликвидировать.
Тогда можно и багу писать. И в багтрекинг заносить.
Но кому писать? И кто будет заносить в багтрекинг?
(чисто по ролям и оформлению баги).

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

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

)))))
В словах "как правило", "крупная компания".
А также (в случае примера из ТС) умильно выглядит передача из техподдержки "обычно" к тестировщикам.
)).
ch_ip! Ну что в описанном примере, где прожарка телефона в духовке снимает проблему, сделают тестировщики?

Да ничего.

ch_ip все верно описал.
Есть проблема, ее двигают по инстанциям - пока не дойдет до того, что либо решат, либо как-то еще примут решение по ней.
А что вас так волнует прогрев телефона в духовке? Я думаю, что если потребуется, то и такой метод тестировщики на месте тоже рассмотрят. Хотя наверняка отнесут его к разряду извращений конечных пользователей.
Где-то на просторах Рунета ходит история как пользователи в отсутствии администратора сделали себе ручками таблицу для перекодировки битых символов в почте)) И даже успешно ей пользовались. До тех пор пока им не открыли глаза, что это делается одним кликом в программе. Есть подозрение, что прогрев телефона - это извращение такого же порядка.

В словах "как правило", "крупная компания".

Мы же конкретный пример рассматриваем. И Би-лайн, и Сони-Эрикссон являются крупными компаниями с отделами тестирования и техподдержки

А также (в случае примера из ТС) умильно выглядит передача из техподдержки "обычно" к тестировщикам.

Не понял, что такое ТС

ch_ip! Ну что в описанном примере, где прожарка телефона в духовке снимает проблему, сделают тестировщики?

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

В словах "как правило", "крупная компания".

Мы же конкретный пример рассматриваем. И Би-лайн, и Сони-Эрикссон являются крупными компаниями с отделами тестирования и техподдержки

А также (в случае примера из ТС) умильно выглядит передача из техподдержки "обычно" к тестировщикам.

Не понял, что такое ТС

ch_ip! Ну что в описанном примере, где прожарка телефона в духовке снимает проблему, сделают тестировщики?

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

1. Так я же в посте написала "И тут у меня чисто по ролям-бумагам все не гладко получается.
Пусть проблема локализована, и пусть ясно - что можно путем изменения ПО телефона ее ликвидировать. ".
Т.е. писала о СВОИХ проблемах.
2. ТС - топик-стартер.
3. ОК. Значит, в плане ролей (именно ролей!) у Вас получается, что тестировщики будут обрабатывать ВСЮ информацию?
В т.ч. и займутся анализом - что происходит с телефоном при прожарке в духовке????
(тихо удивляется... какие-то специфические тестировщики - специалисты в пластмассах, особенностях поведения всех деталек телефона при длительном нагреве... --- ?????).
Ну и с вышками - уж очень большие объемы информации Вы предлагает собрать. Причем разнообразной.
Почему это не баг?
Да потому что отказы железа (плохая пайка, корпус, который мешает принимать сигнал (ну помните -- эпопея с айфоном?), отвалившиеся кнопки) багом не называются.
Неисправность/отказ попросту. И все.

1. Так я же в посте написала "И тут у меня чисто по ролям-бумагам все не гладко получается.
Пусть проблема локализована, и пусть ясно - что можно путем изменения ПО телефона ее ликвидировать. ".
Т.е. писала о СВОИХ проблемах.

Кажется, я не понимаю, в чем у вас проблема с ролями-бумагами.

3. ОК. Значит, в плане ролей (именно ролей!) у Вас получается, что тестировщики будут обрабатывать ВСЮ информацию?
В т.ч. и займутся анализом - что происходит с телефоном при прожарке в духовке????
(тихо удивляется... какие-то специфические тестировщики - специалисты в пластмассах, особенностях поведения всех деталек телефона при длительном нагреве... --- ?????).
Ну и с вышками - уж очень большие объемы информации Вы предлагает собрать. Причем разнообразной.

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

Почему это не баг?
Да потому что отказы железа (плохая пайка, корпус, который мешает принимать сигнал (ну помните -- эпопея с айфоном?), отвалившиеся кнопки) багом не называются.
Неисправность/отказ попросту. И все.

У меня другой опыт. В конторе-разработчике собственных плат и ПО к ним, где я работал, баги железа были такими же багами, как и все остальные. Ну и я привел в качестве примера классику по нахождения мотылька, который вообще ни к железу, ни к софту не относился, но был багом, ибо вызывал сбой в работе ЭВМ.

А причина всему одна...

Эти споры баг/не баг возникают потому что баг (дефект, проблема?) - понятие субъективное. И возникает оно когда ожидания одного лица отличаются от увиденного. Второе еще можно жестко зафиксировать, а первое никак, т.к. оно у разных лиц разное и, более того, еще во времени меняется. Usability баги тому отличные примеры. А дальше начинается social science woodoo со всякими Парадоксами Эрроу и другими интересными штуками, косвенно имеющими отношение к тестированию. Ну и согласно тому же social science woodoo приходится применять соответствующие примеры - контекст, ограничение влияющих лиц и т.п.


ЗЫ: Я к тому что ch_ip прав - для производителя телефонов косяки железа для одной модели это очень серьезная проблема, т.е. баг.

Ну...
Давайте по порядку.
Дефект(неполадки, сбои) выявлен на этапе серийного производства телефонов. ОК? Раз уже в продаже.

Предположим, нашлась причина этого дефект. Ну пусть там какой-то элемент Z(а не программа в телефон зашитая глючит) в телефоне плохо работает. И пусть найден способ исправить ситуацию. Элемент Z заменить на элемент Z1.
Тогда выпускается извещение, что с такого (......дата, партия, т.е. после наступления какого события) Z меняется на Z1.

Ок? Я сейчас весьма примерно говорю.
Т.е. для случая дефект из-за элемента есть совершенно четко оговоренный порядок отработки ситуации. См. ЕСКД. У западников своя система, но принципы принципиально (хихикает) не отличаются.
Потому багом можно называть (да хоть морковкой - дело вкуса, в конце концов - демократия!) конечно, но к чему? Есть устоявшаяся система.

Жизнь у бага несколько иная, чем у железячного косяка.

А причина всему одна...

Эти споры баг/не баг возникают потому что баг (дефект, проблема?) - понятие субъективное. И возникает оно когда ожидания одного лица отличаются от увиденного. Второе еще можно жестко зафиксировать, а первое никак, т.к. оно у разных лиц разное и, более того, еще во времени меняется. Usability баги тому отличные примеры. А дальше начинается social science woodoo со всякими Парадоксами Эрроу и другими интересными штуками, косвенно имеющими отношение к тестированию. Ну и согласно тому же social science woodoo приходится применять соответствующие примеры - контекст, ограничение влияющих лиц и т.п.


ЗЫ: Я к тому что ch_ip прав - для производителя телефонов косяки железа для одной модели это очень серьезная проблема, т.е. баг.

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

Жизнь у бага несколько иная, чем у железячного косяка.

Опять же - it depends. Как ни странно у железячного косяка и у бага есть много разных способов как прожить свою жизнь. iPhone4, например, ничего нигде не меняли. Мучения Symbian отдельная история того как одна маленькая, но очень замечательная ось пыталась мутировать подстраиваясь под изменившиеся требования реальности (epic fail в итоге, а в целом баги/дефекты/проблемы мешали).