Считаете ли вы, что инженерам-программистам стоит поработать инженерами по обеспечению качества в течение определенного периода времени? [закрыто]

Я верю, что это так. Почему?

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

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

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

4. Определение «завершенного» инженера-программиста всегда интересно ... если он потратил время как инженер по обеспечению качества, возможно, это определение будет более точно соответствовать разработчику программного обеспечения.

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

Что вы все думаете?

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

Хорошая программная инженерия имеет опыт работы в области качества, включая тестирование, метрики и статистику. Любой, кто занимается разработкой программного обеспечения любого рода, должен знать (если не знаком с) поддержание качества исходного кода и создание / сопровождение эффективных тестовых примеров. Со временем я бы заподозрил, что любой разработчик программного обеспечения сможет понять различные аспекты качества - качество кода, переносимость, удобство обслуживания, тестируемость, удобство использования, надежность, эффективность и безопасность.

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

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

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

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

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

4. Определение «завершенного» инженера-программиста всегда интересно ... если он провел время в качестве инженера по обеспечению качества, возможно, это определение будет более точно соответствовать разработчику программного обеспечения.

«Полный» может быть измерен только в соответствии с требованиями. Либо требования удовлетворены, и проект завершен, либо имеются неполные требования, и проект не завершен. Любая другая мера завершенности бесполезна.

Заставить программистов отвечать за свой код и требовать от них исправления собственных ошибок, можно позаботиться об этом. Это и потеря бонуса и / или работы.

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

«... должны работать инженерами по контролю качества ...»? Вы делаете это звучит как состязание или наказание.

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

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

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

В общем, варианты, которые вы представляете, звучат очень противоречиво и заставляют меня задуматься о том, были ли у вас действительно плохие впечатления от некоторых ужасных разработчиков. По моему мнению, разработчик должен ВСЕГДА знать о проблемах качества и тестирования и должен гордиться своей работой, чтобы они не считали ее завершенной, пока она не пройдет такие же строгие тесты в своих модульных тестах, как то, что будет использовать официальный отдел контроля качества. Если бы у меня был коллега, или я был техническим руководителем в команде, и у меня был бы разработчик, который продемонстрировал бы какую-то «склонность» к QA, он бы нашел меня вытащившим его для исправления отношения. Если обе стороны монеты, поставляющей программное обеспечение, не могут сотрудничать и действовать как команда, существует реальная культурная проблема. Я не хотел бы работать там, и HR, наряду с высшим руководством, должен был бы понять.

Привлечение программистов к работе в качестве инженеров QA - это рецепт потери ваших лучших разработчиков. Программирование и контроль качества требуют разных навыков и мыслительных процессов.

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

QA проводит тестирование с точки зрения пользователя. Думать, как разные типы пользователей, придумывать странные крайние примеры и делать непонятные проблемы воспроизводимыми - это навыки QA.

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

Хороший тестировщик должен обладать поистине дьявольскими навыками, уметь делать то, для чего программное обеспечение не предназначено, но может ожидать, что пользователь будет делать это в реальном мире. Это требует умения, терпения, умения понять, что может пойти не так, понимания менталитета пользователя и многих других факторов.

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

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

Вот некоторые потенциальные проблемы, которые я вижу с вашим предложением:

1) Если вы предлагаете на короткое время нанять новых инженеров-программистов в отдел обеспечения качества, разве это не даст обратного эффекта? - они могут предположить, что QA - это то, что вы делаете, когда вы новичок, и вы не понимаете, что вы делаете - в конце концов, именно так это сработало для них.

2) Быть очень плохим тестером какое-то время не обязательно научит их чему-то ценному. Но это может сделать их недоступными позже, потому что они предположат, что они знают все о тестировании сейчас, потому что они провели 6 недель в тестовом отделе однажды.

3) Учитывая, что они, очевидно, будут там только в течение короткого времени, и отдел QA будет знать это, также вероятно, что им будут давать только относительно нетребовательные, простые задачи, которые требуют небольшого контроля или понимания, но которые заставляют их быть занятыми , Это только усилит 1 и 2.

4) Если вы хотите избежать 1, 2 и 3, как вы будете убеждать свой испытательный отдел в том, что стоит потратить огромное количество энергии на обучение и контроль кого-то, кто даже не заинтересован в тестировании? (Я могу вам сказать, что требуется очень много времени и энергии, чтобы работать с кем-то, кто, давайте помним, не был выбран из-за их способностей к тестированию . Вы не предлагаете команде тестов дополнительный ресурс в течение нескольких недель, вы просите их потерять одного из своих самых опытных людей на несколько недель, пока они учат вашего новичка).

Сказав все это, я думаю, что ваша общая цель - улучшить понимание тестирования новыми разработчиками программного обеспечения - действительно фантастическая. Я думаю, что предложение Грега, скорее всего, достигнет его - заставьте ваши команды разработчиков и QA тесно сотрудничать, и работайте над преодолением любых барьеров между командами. (В настоящее время я работаю в компании, в которой тестировщики и программисты работают в одной команде - это действительно здорово, и я никогда не хочу возвращаться к работе в отдельных командах.)

Если вы по-прежнему заинтересованы в том, чтобы программисты работали в QA - вот вам совет: приведите пример. Иди сам первым. Возможно, превратите это во что-то, что члены вашей команды могут делать, когда они и так хороши, и хотят получить это дополнительное преимущество, проводя немного времени каждую неделю с другими командами, которые специализируются на перекрывающихся областях - тестирование, администраторы баз данных и т. Д. Если Вы представляете это так, тогда у вас будет больше шансов на успех.

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

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