Здравствуйте, Pzz, Вы писали:
Pzz>Побывав в обеих шкурах (и начальника и подчиненного), я понял, что с Pzz>начальской позиции многие вещи выглядят совсем по-другому.
Pzz>То, что с позиции простого подчиненного может выглядеть, как полный Pzz>идиотизм, с начальской позиции может выглядеть единственным возможным Pzz>решением. Такова жизнь, увы...
Это тогда надо брать простого подчинённого, приводить его в кабинет к начальнику и тыкать мордой в икру, говоря:
— Смотри, скотина, какая хреновая икра, какая мелакая!! Сидите там в своём окопе — ничего не понимаете, как начальнику тяжело!
Здравствуйте, Guepard, Вы писали:
G>Есть у вас на работе такая штука? У нас это выражается в том, что раз в неделю все "прекращают кодировать" и только тестируют, причем по общему плану. Ну вы сами понимаете, как тестеры из разработчиков. G>Не могу понять, зачем нужна эта хрень. Это начальство боится, что мы перед отправкой билда заказчику сломаем его, то на кой тогда контроль версий?
Вполне нормальная практика. Потому что за 2 часа до отправки билда, после регрешн тестинга в багтрекинге оказывается 15 свежеоткрытых багов. а вообще в таком случае помогают постоянные транзишены с тестерами и использование модульного тестирования.
Здравствуйте, Guepard, Вы писали:
G>Есть у вас на работе такая штука? У нас это выражается в том, что раз в неделю все "прекращают кодировать" и только тестируют, причем по общему плану. Ну вы сами понимаете, как тестеры из разработчиков. G>Не могу понять, зачем нужна эта хрень. Это начальство боится, что мы перед отправкой билда заказчику сломаем его, то на кой тогда контроль версий?
Всегда хорошо иметь выделенных тестеров (как собственно, хорошо быть богатым и здоровым), да не всегда получается...
В случае необходимости таким образом фиксировать билд, более разумен, на мой взгляд, подход, когда в какой-то момент собирается версия ("оттестированная"), после чего начинается её тестовая экплуатация (или финальное тестирование). В этот момент разработчики занимаются несложными минорными разработками (которые нужно накапливать в поцессе экусплуатации приложения), требующими небольших ресурсов. В момент, когда возникает необходимость срочного фикса в собранном билде, разработчик доделывает или откладывает минорное исправление и занимается urgent-ной ошибкой в билде. Таким образом несколько экономятся ресурсы.
P.S. Единственное, в чём ваше "начальство" право, так это в том, что не нужно в последний момент вносить изменения в стабильную версию, если это не критические изменения, исправляющие ошибки, не позволяюие эксплуатировать приложение.
Есть у вас на работе такая штука? У нас это выражается в том, что раз в неделю все "прекращают кодировать" и только тестируют, причем по общему плану. Ну вы сами понимаете, как тестеры из разработчиков.
Не могу понять, зачем нужна эта хрень. Это начальство боится, что мы перед отправкой билда заказчику сломаем его, то на кой тогда контроль версий?
Guepard wrote: > > Есть у вас на работе такая штука? У нас это выражается в том, что раз в > неделю все "прекращают кодировать" и только тестируют, причем по общему > плану. Ну вы сами понимаете, как тестеры из разработчиков. > Не могу понять, зачем нужна эта хрень. Это начальство боится, что мы > перед отправкой билда заказчику сломаем его, то на кой тогда контроль > версий?
В разработке ядра Линукса применяетса аналогичный подход. В какой-то
момент объявляется feature freeze, и патчи с новыми фичами перестают
приниматься. Принимаются только патчи с исправлениями ошибок.
Хотя этот подход и неудобен для разработчиков, в нем есть определенный
смысл. Feature freeze период предназначен для выявления и исправления не
совсем очевидных ошибок (совсем очевидные вылезают и в процессе
нормальной разработки).
В ядре 2.6 от этого подхода в определенном смысле отказались. Видимо,
именно по-этому ядра 2.6 до сих пор не так стабильны, как 2.2 и 2.4.
Pzz>В разработке ядра Линукса применяетса аналогичный подход. В какой-то Pzz>момент объявляется feature freeze, и патчи с новыми фичами перестают Pzz>приниматься. Принимаются только патчи с исправлениями ошибок.
Насчет новых фич понятно. По весь прикол состоит в том, что нам не дают даже исправлять уже известные баги!
Guepard wrote: > > Насчет новых фич понятно. По весь прикол состоит в том, что нам не дают > даже исправлять уже известные баги!
Тогда в чем смысл такого тестирования. Ну натестировали вы что-то,
узнали про новые баги. Дальше-то что, если исправлять баги все равно
невозможно?
Т.е., я могу понять идею того, что сначала прогоняется полный круг
тестирования, потом все найденные баги исправляются, и т.д. в цикле. Но
неужели полный круг тестирования занимает у Вас неделю?
Может быть, стоит подумать об автоматизации прогона тестов? Я думаю,
даже полный круг тестирования для операционной системы Windows занимает
часы (возможно, десятки часов), но не дни.
Pzz>Может быть, стоит подумать об автоматизации прогона тестов? Я думаю, Pzz>даже полный круг тестирования для операционной системы Windows занимает Pzz>часы (возможно, десятки часов), но не дни.
Наверное, я, как всегда, непонятно выражаюсь. У нас процесс организован так: всю неделю, кроме последнего дня, идет параллельная рзработка и тестирование. Часть тестеров ищут новые баги, а часть — проверяют, сделаны ли старые. Программеры тоже — кто-то делает новые фичи, кто-то (большинство) — фиксит баги. В пятницу разработка останавливается — кодируют только те, чьи изменения жизненно важны для проекта (например, программа не открывается).
При этом организуются 2 ветки в VSS — старая, которая будет отправлена заказчику, туда-то и вносятся изменения, и "новая" — над которой работа продолжится на следующей неделе.
И вот в пятницу подключают разработчиков к тестированию...
Непонятно, почему надо пятницу тратить на какое-то идиотское "тестирование" (это когда разработчики 80% времени торчат в Интернете, а 20%- вяло что-то тестируют), и почему нельзя просто работать с "новым" проектом...
а об автоматизации тестирования наше начальство не думает. Оно вообще мало о чем думает...
Guepard wrote: > > Pzz>Может быть, стоит подумать об автоматизации прогона тестов? Я думаю, > Pzz>даже полный круг тестирования для операционной системы Windows занимает > Pzz>часы (возможно, десятки часов), но не дни. > > Наверное, я, как всегда, непонятно выражаюсь. У нас процесс организован > так: всю неделю, кроме последнего дня, идет параллельная рзработка и > тестирование. Часть тестеров ищут новые баги, а часть — проверяют, > сделаны ли старые. Программеры тоже — кто-то делает новые фичи, кто-то > (большинство) — фиксит баги. В пятницу разработка останавливается — > кодируют только те, чьи изменения жизненно важны для проекта (например, > программа не открывается).
Ну что, очень разумно.
Непонятно только, сколько же у вас багов, что большинство разработчиков
должны заниматься именно их фиксеньем?
> При этом организуются 2 ветки в VSS — старая, которая будет отправлена > заказчику, туда-то и вносятся изменения, и "новая" — над которой работа > продолжится на следующей неделе. > > И вот в пятницу подключают разработчиков к тестированию... > Непонятно, почему надо пятницу тратить на какое-то идиотское > "тестирование" (это когда разработчики 80% времени торчат в Интернете, а > 20%- вяло что-то тестируют), и почему нельзя просто работать с "новым" > проектом...
Вообще, разработчика полезно время от времени тыкать мордой в то, что он
наразрабатывал. А то многие разработчики даже понятия не имеют,
насколько плохо их софтина ведет себя на каком-нибудь другом компутере,
а не на том, на котором она разрабатывалась...
> а об автоматизации тестирования наше начальство не думает. Оно вообще > мало о чем думает...
Побывав в обеих шкурах (и начальника и подчиненного), я понял, что с
начальской позиции многие вещи выглядят совсем по-другому.
То, что с позиции простого подчиненного может выглядеть, как полный
идиотизм, с начальской позиции может выглядеть единственным возможным
решением. Такова жизнь, увы...
Spidola wrote: > > Pzz>То, что с позиции простого подчиненного может выглядеть, как полный > Pzz>идиотизм, с начальской позиции может выглядеть единственным возможным > Pzz>решением. Такова жизнь, увы... > > Это тогда надо брать простого подчинённого, приводить его в кабинет к > начальнику и тыкать мордой в икру, говоря: > — Смотри, скотина, какая хреновая икра, какая мелакая!! Сидите там в > своём окопе — ничего не понимаете, как начальнику тяжело!
Ну, если Вы думаете, что роль начальника сводится к тому, чтобы икру
жрать, в то время, как нормальные люди работают, Вам стоит задуматься о
смене места работы. Мне так кажется...
Здравствуйте, Pzz, Вы писали:
Pzz>Ну, если Вы думаете, что роль начальника сводится к тому, чтобы икру Pzz>жрать, в то время, как нормальные люди работают, Вам стоит задуматься о Pzz>смене места работы. Мне так кажется...
Да шучу я Что вы прямо лично так всё...
Мне очень понравилось выражение "тыкать мордой" и я подумал, что, возможно, альтернативный метод доже даст улучшение качества кода
Spidola wrote: > > Мне очень понравилось выражение "тыкать мордой" и я подумал, что, > возможно, альтернативный метод доже даст улучшение качества кода
S>Здравствуйте, Pzz, Вы писали:
Pzz>>Мордой надо тыкать в софтварий, а не в икру
S>Кого как
Кончайте флейм! Давайте дело!
У нас и новые фичи разрабатываются, и баги правятся. Вообще-то мне всегда казалось, что править баги можно и нужно в течение всего проекта. Ну а поскольку у нас большая текучка — одни люди наделают багов, потом уходя, другие их исправляют, и при этом полное отсутствие документации и порядка в спецификациях, то что же вы хотите... вопрос в другом — на хрена тратить целый день на совершенно формальное тестирование, когда его можно потратить с толком???
Здравствуйте, Guepard, Вы писали:
G>Кончайте флейм! Давайте дело! G>У нас и новые фичи разрабатываются, и баги правятся. Вообще-то мне всегда казалось, что править баги можно и нужно в течение всего проекта. Ну а поскольку у нас большая текучка — одни люди наделают багов, потом уходя, другие их исправляют, и при этом полное отсутствие документации и порядка в спецификациях, то что же вы хотите... вопрос в другом — на хрена тратить целый день на совершенно формальное тестирование, когда его можно потратить с толком???
Этот вопрос тебе надо задать своему начальству.
Уже давно доказано, что разработчик должен заниматься разработкой — тестер из него хреновый.
А если начальство это не понимает или не хочет понимать, тут ничего особо не поделаешь
> При этом организуются 2 ветки в VSS --- старая, которая будет отправлена > заказчику, туда-то и вносятся изменения, и "новая" --- над которой работа > продолжится на следующей неделе.
а какую ветку тестят и куда вносятся и когда найденные баги?
Здравствуйте, ironwit, Вы писали:
I>Guepard wrote:
>> При этом организуются 2 ветки в VSS --- старая, которая будет отправлена >> заказчику, туда-то и вносятся изменения, и "новая" --- над которой работа >> продолжится на следующей неделе.
I>а какую ветку тестят и куда вносятся и когда найденные баги?
Тестят старую ветку. Найденные баги правятся в исключительных случаях (если они очень важны), и правятся они на старой ветке. Исправления вносятся и в новую. Я так понимаю, что только ради этого и делается стоп-девелопмент... Но есть же мержинг... не понимаю...
S>Это тогда надо брать простого подчинённого, приводить его в кабинет к начальнику и тыкать мордой в икру, говоря: S>- Смотри, скотина, какая хреновая икра, какая мелакая!! Сидите там в своём окопе — ничего не понимаете, как начальнику тяжело!
А я бы на месте подчиненного и не против был, пусть тыкает, а я потихоньку икорку буду подъедать
Здравствуйте, Guepard, Вы писали:
G> вопрос в другом — на хрена тратить целый день на совершенно формальное тестирование, когда его можно потратить с толком???
Ну, в принципе, формальное тестирование дело неплохое, поскольку результатом его является формальное отсутствие ошибок Однако, всвязи с отсутствием "формальных" тестеров, формализовать процесс тестирования "частично" действительно нецелесообразно. Тем более, что в вашем случае, насколько я понял, процесс именно "формальный", а не оптимизированный. Пардон за тавтологию
Другое дело, если бы существовал план тестирования, который был бы обоснован и требовал определённого ресурса, который, в свою очередь, негде взять (кроме как привлечь разработчиков). Тогда всё объяснимо. Если нет такого плана, то можно было бы распределить ресурсы и пооптимальнее. Хотя, как я наблюдал неоднократно, "план тестирования" выглядит как "погоняйте приложение пару часиков"...
Guepard wrote:
> Тестят старую ветку. Найденные баги правятся в исключительных случаях > (если они очень важны), и правятся они на старой ветке. Исправления > вносятся и в новую. Я так понимаю, что только ради этого и делается > стоп-девелопмент... Но есть же мержинг... не понимаю...
Не понял.
нашли баг.
1. критический — поправили кусок кода в старой ветке и сделали тоже
самое (вручную?) в новой ветке.
2. не критический — что тут?
Девиз у Майкрасофта — что-то типа "Клиент не может ждать". Когда-то наступает момент, при котором пора прекращать разработку и выпускать продукт, перед этим жестко продукт протестировав и исправив.
Иначе мы бы никогда не увидели os windows Бабло тоже нужно зарабатывать
G>Есть у вас на работе такая штука? У нас это выражается в том, что раз в неделю все "прекращают кодировать" и только тестируют, причем по общему плану. Ну вы сами понимаете, как тестеры из разработчиков. G>Не могу понять, зачем нужна эта хрень. Это начальство боится, что мы перед отправкой билда заказчику сломаем его, то на кой тогда контроль версий?
Здравствуйте, ironwit, Вы писали:
I>Не понял. I>нашли баг. I>1. критический — поправили кусок кода в старой ветке и сделали тоже I>самое (вручную?) в новой ветке. I>2. не критический — что тут?
Пока ничего. А в понедельник он исправляется уже на "новой" ветке.
По п.1. В новой ветке ничего не делается. Новая ветка — она для продолжения работы в понедельник. Старую отправляют.
После того, как критические баги в старой исправлены, старая ветка мержится с новой (исправлений обычно немного).
Здравствуйте, Guepard, Вы писали:
G>...
Мне кажется, Вам по пятницам надо Code Review устраивать.
Особенно, если народ 80% времени в инете сидит.
Если Вы работаете в частной компании, то, кажется, необходимо серьезно задуматься об эффективности менеджмента на нижнем уровне.
Guepard wrote:
> Пока ничего. А в понедельник он исправляется уже на "новой" ветке.
то есть их просто записывают? нда. теперь дошло.. кажется... ИМХО маразм
и экономия на тестерах.
Здравствуйте, ironwit, Вы писали:
I>Guepard wrote:
>> Пока ничего. А в понедельник он исправляется уже на "новой" ветке. I>то есть их просто записывают? нда. теперь дошло.. кажется... ИМХО маразм I>и экономия на тестерах.
Вы не поверите, но на 12 разработчиков в нашем проекте приходится порядка 7 тестеров!
И все равно бардак жутчайший.
Guepard wrote:
> Вы не поверите, но на 12 разработчиков в нашем проекте приходится > порядка 7 тестеров! > И все равно бардак жутчайший.
сдуру можно и ч..н сломать
а по теме — у нас 3 разработчика (скоро будет 5) тестера будем нанимать
только после 5 разработчика... А может немного и раньше.. Но у нас софт
специфический — его много тестит парралельная группа разработчиков
