Простите.. больше не буду

Чо-чо, была вакансия в Гетте? :)

И были и есть и буду есть..

:))

запостите в чат вакансий)

интересно посмотреть на задачи и деньги

Сек

"Хорошо", видимо, работать в гетте, раз там вакансии "были и есть и будут"(с)

Я думаю про деньги там не напишут..

"Хорошо", видимо, работать в гетте, раз там вакансии "были и есть и будут"(с)

Ну разширяемся ..

Так что в ближайшее время это выражение будет актуальным..

"Хорошо", видимо, работать в гетте, раз там вакансии "были и есть и будут"(с)

А где, по вашему, хорошо? :)

А где, по вашему, хорошо? :)

Хорошо там где нас нет :)

Я, просто, к тому, что в большинстве топовых it компаний вакансии были, есть и будут. Проще назвать компании, где ситуация другая.

Но это всё опять оффтоп.

хорошо работать в маленькие стабильной крутой команде, где тебе никто голову не делает и с внешним миром ты особо не контачишь

но так будет редко)

плюсую к мнению предыдущего оратора

Такую команду надо потыкать палочкой

Такую команду надо потыкать палочкой

почему же?)

И проверить живая ли она еще

хорошо работать в маленькие стабильной крутой команде, где тебе никто голову не делает и с внешним миром ты особо не контачишь

как это, не контачить с внешним миром?

Маленькие стабильные команды могут быть внутри компании. Если маленькой стабильной командой компания ограничивается, то компания мертва. :)

как это, не контачить с внешним миром?

паспорт забрали, к батарее приковали.

как это, не контачить с внешним миром?

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

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

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

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

мне не требуется, у меня все идеально)

но так было не всегда

мне просто интересно, какие решения принимаются по продукту в рамках qa)

Как делать, что делать, в каких приоритетах.

Как-т так.

ну такие согласования всегда ведь есть

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

Блин... где бы почитать идеальную сттаью по тму как настроить работу когда у тебя 15 проектов. некоторые мобильные приложения. Некоторые веб. некоторые воообще ПО... ^_^ С точки зрения QA и QC

ну такие согласования всегда ведь есть

я скорее про то, чтобы тебе не нужно было идти к 10 людям, чтобы фавиконку поменять

хорошо, если ты как, что и приоритеты обсуждаешь с командой

плохо, если с кучей левых людей

Блин... где бы почитать идеальную сттаью по тму как настроить работу когда у тебя 15 проектов. некоторые мобильные приложения. Некоторые веб. некоторые воообще ПО... ^_^ С точки зрения QA и QC

Может быть, будет полезно. http://portall.zp.ua/video/sharing-odnogo-cheloveka-na-neskolkikh-proektakh/id-NiCzyRt-a8D.html

Блин... где бы почитать идеальную сттаью по тму как настроить работу когда у тебя 15 проектов. некоторые мобильные приложения. Некоторые веб. некоторые воообще ПО... ^_^ С точки зрения QA и QC

Вот неплохое видео на эту тему от Spotify ему уже три года https://vimeo.com/85490944

ты один на 15 проектах?

соболезную

Ну нет. у нас один рук. и 3 тестера (в том числе я) проектов... штук 15. их ведут 5 менеджеров. ну и мы пытаемся оптимизировать и улучшить в плане качества и прочего. Например сейчас есть такая вещь что тестируются отдельные ветки с фичами. а потом собирается мастер и паблишится он. Без тестирования. То есть не учитывается что разные фичи могли переконфликтовать и что то сломать в момент мержа в мастер.

0_о

я надеюсь вы не ракеты в космос отправляете)

oO

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

я надеюсь вы не ракеты в космос отправляете)

))

тестить мастер стоит только на момент поломки автоматических тестов

бранч должен добавлять такие локальные проверки

нет автотестов на даный момент. Летом или позже ток внедрим

иначе начинается тестирование всего мастера, что создает сначала ад у куа, потом ад перекидывается на разрабов

Ну нет. у нас один рук. и 3 тестера (в том числе я) проектов... штук 15. их ведут 5 менеджеров. ну и мы пытаемся оптимизировать и улучшить в плане качества и прочего. Например сейчас есть такая вещь что тестируются отдельные ветки с фичами. а потом собирается мастер и паблишится он. Без тестирования. То есть не учитывается что разные фичи могли переконфликтовать и что то сломать в момент мержа в мастер.

беги оттуда)))

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

твой подход мне больше нравится

я бы наверное руки отрубил за мердж без тестирования

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

нет автотестов на даный момент. Летом или позже ток внедрим

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

я бы наверное руки отрубил за мердж без тестирования

ну вот. с точки зрения рука тестить до мерджа не стоит. с твоей пиздец без этого жить нельзя )

ну так объясни это ему доходчиво

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

например "ты дурак?!??"

ну вот. с точки зрения рука тестить до мерджа не стоит. с твоей пиздец без этого жить нельзя )

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

например "ты дурак?!??"

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

или пригласи сюда мы объясним

к сожалению, был печальный опыт тестирования именно фичебранчевых проектов

ручное тестирование обычно означает, что рук сам из обезьян

например "ты дурак?!??"

тогда эту фразу уже можно употребить в утвердительном предложении\

ну а какой плюс тестов и веток и мастера. по сравнению с тестом только мастера?

ERROR: S client not available

их нет)

чтобы тестировать надо понимать контекст

ну а чо вы тогда ...

почему нет?

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

ну а какой плюс тестов и веток и мастера. по сравнению с тестом только мастера?

в том что в ветках тестируется изолированный функционал, а в мастере все вместе

Извени а какой в этом плюс?

локализация проблемы

ну а какой плюс тестов и веток и мастера. по сравнению с тестом только мастера?

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

какая разница как работает фича в изоляции если на проде она будет работать со всем скипом всех фич?

плюс - меньше будет беспричинных багов

какая разница как работает фича в изоляции если на проде она будет работать со всем скипом всех фич?

огромная разница

ну вот я по прежнему не вижу в чем плюс.

простой пример

калькулятор

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

если ты тестируешь и находишь баг в операции сложения

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

у меня такого никогда не было ))) О_о

то уже на мастере ты не чинишь всю формулу расчета

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

и деливерить свой компьютер на прод

у меня такого никогда не было ))) О_о

а у вас ошибки в логи валятся? там наверно дофига набегает

мне и не нужно чинить всю формулу. и девелоперу не нужно. Он откатит мастер. починит операцию сложения. смержит заново и отдаст мне.

а как он узнает?

ты наверное перед этим будешь пытаться локализовать и плакать)

ты наверное перед этим будешь пытаться локализовать и плакать)

то есть минус в том что локализовать потом багу сложно. и кто то будет плакать )

с нашей стороны корабль не тонет?

ну и вот смотри... что дешевле.. локализовать эту багу и плакать? или тестироваьт все в двойном обьеме?

> кто то будет плакать ) Это надо говорить "компания терпит необоснованные убытки"

ну и вот смотри... что дешевле.. локализовать эту багу и плакать? или тестироваьт все в двойном обьеме?

тут вопрос, зачем вы работаете. если нужно дешевле, можно вообще не тестировать) вопрос в том, что с вами потом никто работать не будет

крч . я по прежнему не вижу вау пиздец как херово тестить только мастер

тут вопрос, зачем вы работаете. если нужно дешевле, можно вообще не тестировать) вопрос в том, что с вами потом никто работать не будет

блин вот давайте не падаьт в крайности