Соглашусь, что синергичны, и не соглашусь, что тестеровщик не может выполнять работу если потребуется - если опыта тестеровщика достаточно, а задача не рокет-сайнс, то может (при наличие формальных прав конечно). И самому пару раз приходилось, и видел у коллег. Просто такая работа, даже если будет сделана качественно, будет сделана со скоростью джуна-девелопера. Просто из-за того, что QA даже зная "как писать" имеет меньше опыта с инструментами (банально шоткаты в идешке), хуже знает код-базу проекта (будет искать по проекту там, где вы точно знаете где, имеет особенности ментальности из-за которой перепроверит каждый свой метод руками, а потом еще нахлобучит юнитов, даже если это будут единственные юниты в проекте (лол, такое было кстати!) Так и разработчик, если ему дать действительно сложную задачу в тестировании, например "локализировать плавающий баг в распределенной системе по неполному и неточному описанию от саппорта и настроить стенд с гарантированным воспроизведением" при достаточном опыте справится, но времени потратит в разы больше.
Раз уж подняли эту тему, вот вам забавное эмпирическое наблюдение про культуру оплаты труда QA: в командах, где компенсация инженеров тестирования примерно соизмерима с разработчиками, и все об этом знают, последние плодят меньше багов на фичу и лучше тестируют свою работу сами перед "официальной" передачей в тестирование. В командах, где разработчики получают (или думают, что получают) в разы больше, регулярно встречался с тем, что разработчики не то, что не хотят писать хотя бы unit-тесты, если палкой не заставляют, так могут отдать в тестирование вообще не работающую сборку/несобираемый код итд. Предпологаю, что фактор психологический, т.к. в первых командах разработчики больше ценят время тестеровщиков как полноценных коллег. Хотя на истинность наблюдений не претендую.
Есть один нюанс, абсолютно не важный, в мемчиках, но крайне важный, когда мы обсуждаем новости юридического характера, и который все забывают/игнорируют. Де-юре CD project (читается кстати цэ дэ прОййект, т.к. это польский) != си ди проджект рэд (далее CDPR). Первая — это публичная компания издатель. И именно её инвесторы подали иск. Вторая — это частная и даже не акционерная студия- разработчик. Де-факто, конечно, цеде пройект контролирует почти всё, что происходит в CDPR, но де-юре судьба иска во многом будет зависеть от того, что написано в иске, кто ответчик (Цэде пройект или CDPR), и на основании чьих высказываний (согласно именно иску) инвесторы были предположительно введены в заблуждение
Этот вопрос однажды встретился мне на собеседовании. Он про классы и методы.
Всегда очень с подозрением отношусь к компаниям, которые на интервью спрашивают вопросы вроде: «Вот вам и безобразный и заведомо не работающий код, в котором больше одной ошибки. Какую из них вернет интерпретатор?» — А какая собственно разница? Я готов еще понять, если бы под этим вызовом была бы еще обработка TypeError и NameError с разной логикой, хотя, это еще безобразнее. Сразу вопрос к потенциальному нанимателю: «а какую задачу мне придется выполнять, если надо будет разбирать такой код?». Вы хотите понять, понимаю ли я логику построения и разворачивания цепочки вызовов? Ну так придумайте релевантную практике задачу, где это значимо. Не можете? значит в вашем проекте просто нету таких задач, и этот навык не релевантен вашей позиции, зачем его проверять?
То есть, фактически, он на протяжении 14 лет что-то выпускал, но не развивал бизнес Microsoft так активно, как казалось со стороны.
Я аж на хабре зарегистрировался из многолетнего ридонли, чтобы указать на эту ошибку. Вы не учли сплит 2:1 в феврале 2013. Т.е. тот кто купил бы в 2000 за 47, продал бы с уходом Балмера уже две за 82. Конечно, 17,5% из года в год, не самый большой рост, но уж точно нельзя сказать, что Балмер не развивал бизнес.
P.S.: А еще цена акций, в отрыве от других показателей не является показателем стоимости бизнеса. Только рыночной цены.
Соглашусь, что синергичны, и не соглашусь, что тестеровщик не может выполнять работу если потребуется - если опыта тестеровщика достаточно, а задача не рокет-сайнс, то может (при наличие формальных прав конечно). И самому пару раз приходилось, и видел у коллег. Просто такая работа, даже если будет сделана качественно, будет сделана со скоростью джуна-девелопера. Просто из-за того, что QA даже зная "как писать" имеет меньше опыта с инструментами (банально шоткаты в идешке), хуже знает код-базу проекта (будет искать по проекту там, где вы точно знаете где, имеет особенности ментальности из-за которой перепроверит каждый свой метод руками, а потом еще нахлобучит юнитов, даже если это будут единственные юниты в проекте (лол, такое было кстати!)
Так и разработчик, если ему дать действительно сложную задачу в тестировании, например "локализировать плавающий баг в распределенной системе по неполному и неточному описанию от саппорта и настроить стенд с гарантированным воспроизведением" при достаточном опыте справится, но времени потратит в разы больше.
Раз уж подняли эту тему, вот вам забавное эмпирическое наблюдение про культуру оплаты труда QA:
в командах, где компенсация инженеров тестирования примерно соизмерима с разработчиками, и все об этом знают, последние плодят меньше багов на фичу и лучше тестируют свою работу сами перед "официальной" передачей в тестирование.
В командах, где разработчики получают (или думают, что получают) в разы больше, регулярно встречался с тем, что разработчики не то, что не хотят писать хотя бы unit-тесты, если палкой не заставляют, так могут отдать в тестирование вообще не работающую сборку/несобираемый код итд.
Предпологаю, что фактор психологический, т.к. в первых командах разработчики больше ценят время тестеровщиков как полноценных коллег.
Хотя на истинность наблюдений не претендую.
Всегда очень с подозрением отношусь к компаниям, которые на интервью спрашивают вопросы вроде: «Вот вам и безобразный и заведомо не работающий код, в котором больше одной ошибки. Какую из них вернет интерпретатор?» — А какая собственно разница? Я готов еще понять, если бы под этим вызовом была бы еще обработка TypeError и NameError с разной логикой, хотя, это еще безобразнее. Сразу вопрос к потенциальному нанимателю: «а какую задачу мне придется выполнять, если надо будет разбирать такой код?». Вы хотите понять, понимаю ли я логику построения и разворачивания цепочки вызовов? Ну так придумайте релевантную практике задачу, где это значимо. Не можете? значит в вашем проекте просто нету таких задач, и этот навык не релевантен вашей позиции, зачем его проверять?
Я аж на хабре зарегистрировался из многолетнего ридонли, чтобы указать на эту ошибку. Вы не учли сплит 2:1 в феврале 2013. Т.е. тот кто купил бы в 2000 за 47, продал бы с уходом Балмера уже две за 82. Конечно, 17,5% из года в год, не самый большой рост, но уж точно нельзя сказать, что Балмер не развивал бизнес.
P.S.: А еще цена акций, в отрыве от других показателей не является показателем стоимости бизнеса. Только рыночной цены.