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

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

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

тогда ПМ и КУА виноваты, что не тестили спеку

тогда ПМ и КУА виноваты, что не тестили спеку

а если все согласовано с клиентом и он говорит "да ребята, это все норм, пусть так будет"?)

ну вот тогда это зона ответственности клиента, т к он зааппрувил спеки

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

В этом то и проблема. Не решить, а спихнуть.

У меня были случаи, когда приходилось в бурные споры с клиентом вступать по поводу новой спеки и подобного. В некоторых моментах казалось "ну такого быть не может! Это точно бага макета\спеки" - а мне "нет - это именно так задумано" ?

ну это не бага спеки а ошибка в человеческой логике / понимании что приведет к багу и такое надо детально прояснить клиенту, и если он не самодур или кретин, то все решается

Иногда хочется подойти к девелоперу, воспроизвести баг и так лицом его в монитор: Ктооооо это сделал? Ктоооооо это сделал?

http://bash.im/index?text=%E3%E5%F0%EC%EE%EA%E0%EF%F1%F3%EB%E0

вот старый подход, но действенный )

Иногда хочется подойти к девелоперу, воспроизвести баг и так лицом его в монитор: Ктооооо это сделал? Ктоооооо это сделал?

И монитор попрыгать чтоб больше не гадил?

#whois категорически приветствую! DevManager проектов разработки авиационных систем и ПО для авионики. Стараемся менять подходы в очень консервативном окружении.

#whois категорически приветствую! DevManager проектов разработки авиационных систем и ПО для авионики. Стараемся менять подходы в очень консервативном окружении.

Тестируют же люди..

А ввремя я так написал шуточку, да.

Иногда хочется подойти к девелоперу, воспроизвести баг и так лицом его в монитор: Ктооооо это сделал? Ктоооооо это сделал?

а толку портить личные отношения с человеком из-за его неквалифицированности/невнимательности. возвращаешь баги снова и снова. если ТЛ девелоперов следит за проблемами своих падаванов - всё решится быстро

Да понятное дело.

+ это как бэ не профессионально.

Но, как пелось в песне у Шаова: ...Но как приятно тихо встать С улыбкою сказать "Пардон" По люстре стулом садануть И просветленным выйти вон

Я может ща фигню скажу, но я дружу с девелоперами. Мы вместе ржем над коммитами. Или когда переоткрываешь тикет и патчик приложишь, он подойдёт, ты ему все разжуешь. Он спасибо скажет

Я может ща фигню скажу, но я дружу с девелоперами. Мы вместе ржем над коммитами. Или когда переоткрываешь тикет и патчик приложишь, он подойдёт, ты ему все разжуешь. Он спасибо скажет

нормальное явление. я так периодически бл на грувях просматриваю

То же самое.

круто

Мы с нашими вообще в одной комнате. И на обед ходим вместе иногда и смеемся и всё такое.

Я может ща фигню скажу, но я дружу с девелоперами. Мы вместе ржем над коммитами. Или когда переоткрываешь тикет и патчик приложишь, он подойдёт, ты ему все разжуешь. Он спасибо скажет

Я тож стараюсь дружить))) они полезного чего могут подкинуть

чего?

Вообще, дружить надо со всеми :)

чего?

Ну, багов там весёлых )

хорошие люди, да

Ну, багов там весёлых )

Я обычно скриптики прошу

Иногда хочется подойти к девелоперу, воспроизвести баг и так лицом его в монитор: Ктооооо это сделал? Ктоооооо это сделал?

а иногда "Ну почему именно таааак?! ведь в тз четко понятно что...". После таких случаев еще раз вдаешься в раздумие о степени однозначности тз. Когда я на 100% уверена, а оказывается "ну там четко не сказано" или "Ну я не дочитывал таск" или "Мне показалось что" или "Мне было так удобно". И тут виноваты все, в определенной степени.

Я обычно скриптики прошу

А я деньги, одежу и мотоцикл )

У нас есть правило, что тестировщик смотрит в бранчдиф перед началом тестирования и если что то не понимает то просит девелопера рассказать что он тут сделал. Иногда он сразу сам баг находит :)

А я деньги, одежу и мотоцикл )

Не наш метод)))

Мы с нашими вообще в одной комнате. И на обед ходим вместе иногда и смеемся и всё такое.

У нас тоже так)

У нас есть правило, что тестировщик смотрит в бранчдиф перед началом тестирования и если что то не понимает то просит девелопера рассказать что он тут сделал. Иногда он сразу сам баг находит :)

Отличная практика, кстати.

У нас есть правило, что тестировщик смотрит в бранчдиф перед началом тестирования и если что то не понимает то просит девелопера рассказать что он тут сделал. Иногда он сразу сам баг находит :)

круто

У нас есть правило, что тестировщик смотрит в бранчдиф перед началом тестирования и если что то не понимает то просит девелопера рассказать что он тут сделал. Иногда он сразу сам баг находит :)

У нас на некоторых проектах присутствует практика пулл-реквестов. Тоже часть багов на подобном отсмотре отсеивается.

А возможно я руководитель, которого заставляют вводить схему мотивации за ошибки. Как мне поступить? Не меняя работу

Почему пропущенный баг является ошибкой тестировщика по умолчанию?

Уже решили же всё.

Почему пропущенный баг является ошибкой тестировщика по умолчанию?

Шо? Опять?

У нас на некоторых проектах присутствует практика пулл-реквестов. Тоже часть багов на подобном отсмотре отсеивается.

код-ревью делает вся команда?

хотя не важно, это крутая практика

Кстати, нас больше двухсот. ура!

Наверное.

Вообще научиться смотреть в бранчдиф это хорошо: 1. Видно что тронуто и что надо проверить 2. Начинаешь понимать кодовую базу 3. Простейшие баги находишь 4. Иногда ветка создана но девелопер не запушил и можно сразу переоткрывать 5. В глазах девелопера ты почти равный человек 6. Ты крут

Не всегда дают доступ, увы.

код-ревью делает вся команда?

Нет. Только один девелопер другого.

Уже решили же всё.

А я таки всё пропустил

Не всегда дают доступ, увы.

+

Зато ты поработал!

код-ревью делает вся команда?

у нас 2 иосника и 2 андроидщика - так что да - можносказать, что вся команда) А я отдел тестирования в полном составе))

Но по сути, ревьювит один человек.

Вообще научиться смотреть в бранчдиф это хорошо: 1. Видно что тронуто и что надо проверить 2. Начинаешь понимать кодовую базу 3. Простейшие баги находишь 4. Иногда ветка создана но девелопер не запушил и можно сразу переоткрывать 5. В глазах девелопера ты почти равный человек 6. Ты крут

Я вот бы сошел с ума смотреть сам в код продукта типа ворда, тем более на бранч дифы при 5-7 активных бранчей

у нас одна фича - один бранч

у нас бранч под предпоследнюю сборку, транк - под последнюю

у нас одна фича - один бранч

А фича - это например что? Хочу понять, какого размера кусок логики. Мы пытались перейти на такую систему на паре проектов и получалось больше минусов, чем плюсов.

ну фича например: сделать в чате отправку картинок

То есть довольно небольшие? Не возникает проблем с мержами, особенно если миграции были?

То есть довольно небольшие? Не возникает проблем с мержами, особенно если миграции были?

Нет у нас все чётко

Просто у нас многоуровневая но простая система веток

Просто у нас многоуровневая но простая система веток

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

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

А кто решает, когда новую ветку заводить, а когда работать в одной? (если над одной задачей работают, тут понятно, а если над разными?)

То есть как это оговорено в эм... принятых правилах процесса разработки в команде?

Или у вас не бывает таких ситуаций? А если не бывает, то почему? Задачи распределяются классно или разбивка по задачам изначально хорошая?

разные задачи - разные ветки

Nick K, [16.08.16 15:05] если программисты работают над смежными или одной задачей - пусть работают в одной ветке Nick K, [16.08.16 15:45] разные задачи - разные ветки Так в одной или в разных?

обычно в разных

обычно в разных

Кто и в какой момент определяет, что нужно отступить от этого правила и работать в одной?

> @pefremova Кто и в какой момент определяет, что нужно отступить от этого правила и работать в одной? сами девелоперы с ТЛ

> @pefremova Кто и в какой момент определяет, что нужно отступить от этого правила и работать в одной? сами девелоперы с ТЛ

Во время распределения задач то есть? (Иначе откуда они узнают, что есть другая связанная задача) А как задачи распределяются? Пачками на митингах?

во время декомпозиции задачи же

Так тут зависит от того, кто декомпозирует задачу, тимлид самостоятельно или совместно с командой.

ghjuhfvvbcns

техлид жк

коллеги, поделитесь пожалуйста опытом. кто как тестирует (веб-сервис) на продакшене и как скрываются тестовые данные и тестовые аккаунты от пользователей?