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

12

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

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

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

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

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

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

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

Macy Abbey
источник
1
Моя первая работа была QA. Я ненавидел это, но я ДЕЙСТВИТЕЛЬНО понял важность QA.
Работа
Я не полностью оценил творческий потенциал QA, пока не прочитал классическую книгу Гленфорда Майерса « Искусство тестирования программного обеспечения» .
Макнейл
5
Я сталкивался со многими инженерами-программистами, которые считают, что они так или иначе превосходят всех на планете ;-)
Стивен А. Лоу
Слишком верно, Стивен.
Macy Abbey
1
Вместо этого я бы посоветовал спросить, стоит ли инженерам-программистам делать некоторые вещи для обеспечения качества, а не думать, что какой-то неопознанный объект заставит их это сделать.
Дэвид Торнли

Ответы:

13

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

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

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

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

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

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

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

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

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

Томас Оуэнс
источник
Спасибо Томас, это очень информативный и продуманный ответ.
Macy Abbey
6

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

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

JeffO
источник
Верно, Джефф, но я думаю, что первый подход не обязательно учит их инструментам, которые им необходимы, чтобы стать более эффективными / надежными программистами. Это действительно оказывает давление, хотя, и это хорошо.
Мэйси Аббатство
Кроме того, одним из недостатков этого подхода является потеря программиста на некоторый период времени, одну неделю ... две недели, месяц? И я не думаю, что это хорошая идея, чтобы они выполняли работу, которая имеет очень мало общего с их текущей работой ... (чистит туалеты: P)
Macy Abbey
6

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

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

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

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

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

жестяной человек
источник
Привет, Грег, я задал вопрос, думая об инженере-программисте, который является новичком в этой области и не понимает ценности QA, и у которого не было большого опыта в разработке набора четко определенных критериев приемлемости. Причина, по которой я выбрал «иметь», заключается в том, что, как вы сказали, я не думаю, что многие разработчики программного обеспечения предпочтут работать инженером по обеспечению качества (как их единственная обязанность), потому что они явно решили стать разработчиком программного обеспечения. Я определенно ценю и разделяю вашу точку зрения на то, какими должны быть действительно хорошие отношения разработчика программного обеспечения и отношения с QA.
Macy Abbey
Как вы думаете, наличие нового инженера-программиста в качестве инженера QA поможет им достичь того уровня, на котором вы сейчас находитесь?
Macy Abbey
1
Точно нет. Убедитесь, что они понимают, как работают команды; Развивать отношение к проблемам; Культура - открытая атмосфера, которая побуждает людей работать в специальных командах для обсуждения и решения проблем. Слишком много людей и компаний поощряют накопления знаний и отношение «нас против всех». Честно говоря, «мы против всех» должны уйти в стенах компании, потому что это вредит всем.
Жестянщик
2
@Macy Abbey, одна из тактик, на которую следует обратить внимание, может заключаться в том, чтобы разработчики работали совместно с командой QA для разработки сценариев тестирования. Модульные тесты могут быть написаны и разработаны в тандеме, или команда QA может добавить свои тесты в папку «tests», где у разработчика есть модульные тесты. Некоторые люди думают, что между dev и QA должно быть разделение, но это способствует конкуренции. Если обе группы используют свои глазные яблоки и тестируют трюки вместе, возможно, они смогут обнаружить ошибки и пропущенные функции еще быстрее.
Жестянщик
@ Грег Спасибо, Грег, это звучит как хорошая тактика. Я верю, что вы убедили меня, что сочетание других тактик лучше, чем я изначально предлагал.
Мэйси Аббатство
5

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

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

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

Майкл Шоу
источник
1
Благодаря Птолемею, я делаю это предложение с небольшими временными рамками, так как я знаю, что кто-то работает в должности, которая не является той, на которую его нанимают, это определенно рецепт потери этого разработчика.
Macy Abbey
Дело не только в том, что они не будут работать в должности, для которой они были наняты, они также не будут в положении, которое они выбрали в качестве своей профессии, и ходили в школу. Это большая пощечина для многих людей, которые вкладывают свои сердца в свою карьеру. Для тех, кто считает работу только зарплатой, это будет хорошо.
Жестянщик
@ Грег: Те, кто в нем за зарплату, тоже не понравится. Их резюме будут более ценными с X + 1 годами разработки программного обеспечения, чем X годами разработки программного обеспечения и годом QA, по крайней мере, на раннем этапе. Не говоря уже о том, что вы должны платить своим специалистам по обеспечению качества, а также специалистам по программному обеспечению, потому что никто из них за зарплату не согласится на сокращение зарплаты.
Дэвид Торнли
Это предполагает, что вы работаете в месте, которое платит квалифицированным специалистам по обеспечению качества меньше, чем разработчикам. Я знаю, что некоторые места делают, но это не отражает мой опыт - когда я знал зарплаты людей, они обычно были на одном уровне.
testerab
1
В первые годы работы программистом ваша зарплата очень зависит от того, сколько лет у вас есть опыт программирования. Таким образом, имея 2 года C # и 1 год QA, вы получаете 2 года C #, а не 3 года C #.
Майкл Шоу
3

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

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

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

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

Рупеш Шеной
источник
Правда, Roopesh, хотя я думаю, что между двумя наборами навыков определенно есть пересечение, где работа в качестве QA для небольшого промежутка времени увеличит скорость, с которой кто-то улучшает свои навыки тестирования.
Macy Abbey
1

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

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

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

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

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

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

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

testerab
источник
0

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

Омега Центавра
источник
Этот анекдот, кажется, не содержит никакого ответа на вопрос.
никто не будет
-2

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

Панджияр Рахул
источник