Должен ли программист быть самодостаточным?

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

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

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

Заметка

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

До сих пор отличные ответы, держите их, если у вас есть, что добавить или поделиться личным опытом!

Вы делаете есть тестеры. Только вы называете их «конечными пользователями». Это вредно по всем причинам, которые вы описываете; независимо от того, насколько вы добросовестный кодер, вы просто никогда не сможете сделать достаточно хорошую работу, преодолевая ваши собственные предвзятые мнения о том, как код «должен» использоваться для вас, чтобы найти все способы, которыми он может облажаться ,

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

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

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

Да. Если вам нужно , вы сможете проверить свой код. (Я имею в виду не юнит-тесты, а приемочные тесты и тому подобное.)

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

У вас много других вопросов. Я отвечу только один:

Должен ли программист уточнить спецификацию?

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

То, что они говорят, и реальность, вероятно, две разные вещи. Скорее всего, обоснование таково:
«Почему я должен платить зарплату тестеру, когда я могу просто заставить программиста выполнять двойную обязанность?»

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

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

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

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

Справедливо.

Должны ли такие задачи быть моей обязанностью?

Это в конечном итоге решать вашему руководству.

Я вижу себя строго как программиста и ничего больше.

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

И если это моя ответственность, то в какой степени?

Если руководство скажет так, да.

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

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

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

Если программист должен уточнить спецификации,

При необходимости да. Фактически, если спецификация нуждается в доработке, и над ней больше никто не работает, то неспособность сделать это может привести к сбою проекта.

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

При необходимости да.

или даже обеспечить поддержку клиентов?

При необходимости да.

Для меня это звучит так, будто вы перегружены работой и реагируете на давление. Это проблема. Но принятие позиции, что «не твоя работа - делать X, Y, Z», не поможет. Лучшим планом будет дать понять, что вы можете сделать так много, и указать, что это может привести к несоблюдению сроков, снижению качества, плохой поддержке клиентов и так далее. Но в любом случае сделайте все возможное ... не повреждая свое здоровье, отношения и т.д. в процессе.

У нас есть тестеры. Я бы не хотел работать без них. Несмотря на то, что я пишу модульные тесты (используя TDD) и автоматический интеграционный тест для всего своего кода, у тестеров все еще есть очень полезная функция.

1. Они высококвалифицированные и имеют разные навыки для программистов.
   1. Они имеют большой опыт и знания о том, как проводить QA-тестирование и как убедиться, что созданный код действительно соответствует как ожиданиям пользователя, так и фактическому поведению пользователей.
   2. У них много ошибок, и они очень хорошо продумывают ситуации, которые могут сломать программное обеспечение.
   3. Они имеют тенденцию быть циничными и систематическими. Я заметил, что программисты часто гораздо более оптимистичны.
2. Они обеспечивают ценную обратную связь о юзабилити. Например, при создании REST API в последнее время области, которые тестировщики QA не могли легко понять, были хорошим показателем областей, которыми пользователь также был бы недоволен.
3. Они тестируют в реальной среде, на самом деле многие конфигурации реального оборудования, ОС и т. Д.
4. Они знают, как создавать масштабные, реалистичные, тестовые стенды и выполнять тесты производительности, нагрузки и стресса.
5. Они сосредоточены на предотвращении выхода плохих релизов. Программисты, как правило, сосредоточены на выпуске кода. Это почти как программист выпустит код по умолчанию, но тестировщику QA понадобится причина, чтобы освободить его (было показано, что он работает!)

«Если бы у нас были тестеры, вы бы вообще не тестировали свой собственный код»

« Если бы у вашей машины был ремень безопасности, вы бы все время ломали его! »

Должны ли такие задачи быть моей обязанностью? [...] И если это моя ответственность, то в какой степени?

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

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

Это не совсем правильный вопрос. Вам лучше спросить: «Когда качество продукта / имиджа компании настолько важно, что для этого нужны тестеры?»

Если программист должен уточнить спецификации, [...]

Да, безусловно. В большинстве случаев существует большое несоответствие между тем, что нужно разработчику / исполнителю, и тем, что клиенты предоставляют [как спецификации].

Часто вам нужно найти серые / неуказанные области и задать правильные вопросы, заметить и указать на технически невозможные или противоречащие требования и т. Д. (Особенно если вы являетесь единственным разработчиком).

[...] беспокоиться об управлении проектом или даже обеспечить поддержку клиентов?

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

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

1. Спецификация продукта + варианты использования
   Даже если все знают (или думают, что знают), какова функциональность продукта, его необходимо записать. Вы не можете протестировать приложение без четкой спецификации. Спецификация определяет, что является правильным поведением и что является ошибкой.
2. Модульные тесты, интеграционные тесты
   Тесты внутренних устройств, которые сложно протестировать через пользовательский интерфейс, исключительные состояния приложений Это необходимо для каждой более крупной системы. Оба типа тестов имеют еще одно интересное свойство - они заставляют вас снова проходить каждую часть кода, и вы поймете ошибки / проблемы архитектуры, которые вы никогда раньше не видели.
3. Стандарты качества кода и кодирования
   Одной из задач, которые должен выполнять QA, является измерение сложности кода. Код низкой сложности уменьшает вероятность ошибок (предотвращая ошибки).
4. Обзоры кода
   Когда проект достигает заданного размера или его используют многие пользователи, пересмотр кода является обязательным. Другой программист всегда находит проблемы с кодом / ошибки, которые вы пропустили. Программисты иногда не видят очевидных ошибок в своем собственном коде.
5. Документирование
   Документируйте свой код и его архитектуру, это поможет вам осознать возможные недостатки (мой собственный опыт).
6. Тестеры
   Тестер - это не обезьяна, которая просто щелкает по интерфейсу пользователя. Тестировщик берет спецификацию и варианты использования и создает контрольные примеры. Затем он / она проверяет их один за другим. Если конечные пользователи сообщают об ошибке, для этого необходимо добавить контрольный пример.

Программист никогда не должен создавать спецификацию (1). Вы не там, чтобы решить функциональность. Обычно им приходится общаться с конечными пользователями, создавать графические дизайны и т. Д. Это трудоемкая задача. Если программист решает функциональность, обычно это заканчивается «все в порядке, но не могли бы вы все изменить в этом окне к завтрашнему дню»? «это не то, что я хотел», «это работает, но его трудно использовать», «в нем отсутствует единственная функциональность, которая нам действительно нужна».

То, что программист может достичь, это 2, 3 и 5.

Вам нужен еще один программист для 4. Любая компания с большим ИТ-проектом и только одним разработчиком, который знает, что система работает на очень опасной почве.

Если вам не хватает времени, никогда не пытайтесь создавать тестовые случаи (5). Обычно требуется преданный человек, так как это занимает много времени. Без тестовых случаев тестирование - это просто шутка.