¿Se supone que un programador es autosuficiente?

En mi lugar de trabajo actual, no tenemos probadores, la razón para ello es que la administración es: "si tuviéramos probadores, no probaría su propio código en absoluto". Este tipo de pensamiento parece ser perjudicial para la calidad del producto, ya que si bien pruebo mi propio código, hay muchas cosas que extrañaré solo por el hecho de que conozco el sistema de adentro hacia afuera y no sé cómo usarlo. está mal". Las pruebas de recuadro negro realmente no funcionan ya que inconscientemente evito las trampas en las que caería un probador dedicado. Gran parte de mi tiempo se dedica a corregir errores que se han deslizado en el código de producción y han sido encontrados por el usuario final.

El sistema en cuestión es grande pero lo desarrollé únicamente yo. Esto también ha causado que algunas tareas administrativas caigan en mi regazo, como definir horarios y trabajar en especificaciones.

¿Debería este tipo de tareas ser mi responsabilidad? Me veo estrictamente como programador y nada más. Y si estos son mi responsabilidad, ¿en qué medida? ¿Cuándo es un proyecto tan grande que requiere probadores? ¿Debería un programador tener que refinar la especificación, preocuparse por la gestión del proyecto o incluso brindar soporte al cliente?

Nota

Algunos podrían tener la impresión de que estoy en contra de ampliar mis responsabilidades; ese no es el caso, estoy ansioso por obtener un papel que implique más tareas administrativas, pero actualmente no está en la descripción de mi trabajo. Hasta que esté oficialmente contratado como tal o los deberes adicionales comiencen a aparecer en mi cheque de pago, voy a pensar en mí mismo como "solo" un programador. Desafortunadamente, como desarrollador junior, el cambio a tareas administrativas no va a suceder muy pronto.

Excelentes respuestas hasta ahora, ¡sigan llegando si tiene algo que agregar o experiencias personales para compartir!

Usted hacer que los probadores. Solo que los llamas "usuarios finales". Esto es perjudicial por todas las razones que describe; no importa cuán concienzudo sea un codificador, simplemente nunca podrá hacer un trabajo lo suficientemente bueno para superar sus propias ideas preconcebidas sobre cómo se "supone" que el código debe usarse para que pueda encontrar todas las formas en que puede arruinarlo .

Debe volver a abrir este problema con la administración. En este punto, parece que tiene algunos datos sólidos para respaldar su caso; El enfoque actual de no intervención para el control de calidad desperdicia su tiempo y compromete la experiencia de sus usuarios. Debe tener cuidado en la forma en que presenta esto para que quede claro que se trata de un problema estructural y no un caso de "Simplemente apesta en las pruebas", pero parece una discusión que debe suceder.

Parece que estás en una encrucijada con este empleador. Si tiene la intención de seguir siendo un programador y nada más, es posible que deba comenzar a retroceder y solicitarles que comiencen a obtener la ayuda que necesita para quitar algunas de las tareas gerenciales, ya sea trayendo a alguien nuevo o expandir las responsabilidades de un compañero de trabajo existente. ("Esto no es para lo que me contrataste, y estas tareas no van a desaparecer. El tiempo que paso haciendo esto mal es el tiempo que no estoy gastando en lo que soy bueno"). Pero eso puede o puede No sea realista. ¿Crees que podrías manejar pasar a un rol más gerencial si te dieran los recursos y la autoridad que necesitarías para hacer bien el trabajo?

En cuanto a qué tan grande debe ser un proyecto antes de que necesite probadores, no estoy seguro de cómo definir esa línea con precisión, pero definitivamente creo que la has cruzado. Está gastando más tiempo del que le gustaría arreglar los informes de errores de los usuarios reales; para mí eso dice que es hora de invertir más esfuerzo para evitar que los errores lleguen a los usuarios en primer lugar.

Sí. Si usted tiene que, usted debe ser capaz de probar el código. (No estoy hablando de pruebas unitarias, sino de pruebas de aceptación y demás).

No se . Los probadores son mejores en pruebas que tú. Y como usted señala, al igual que la corrección de pruebas, es muy difícil detectar sus propios errores. Tener globos oculares adicionales tendrá un gran impacto (bueno) en la calidad de su programa.

Tienes muchas otras preguntas. Solo responderé una:

¿Debería un programador tener que refinar la especificación?

¡Sí! Debe implementar la especificación, por lo que debe asegurarse de que la especificación sea realmente implementable. Además, como programador, capacitado en pensamiento claro, precisión y demás, puede ayudar a las personas a descubrir lo que realmente debe hacerse y eliminar los requisitos ambiguos o lógicamente defectuosos.

Lo que dicen y la realidad son probablemente dos cosas diferentes. Lo más probable es que la razón sea:
"¿Por qué tengo que pagar el sueldo de un probador cuando puedo hacer que el programador cumpla una doble función?"

Por supuesto, no van a decir eso y inventarán todo tipo de excusas que consideren razonables. Puedo pensar en varias refutaciones hasta su punto, pero honestamente no van a ayudar. He visto esta batalla una y otra vez y simplemente cambiarán su enfoque cada vez que desacredites su razonamiento actual. Eventualmente se darán por vencidos y solo te indicarán que lo hagas de todos modos y serás etiquetado como un demandante.

El mejor enfoque que puedo pensar es abordarlo no desde un punto de vista de calidad, que la gerencia nunca parece valorar hasta que haya problemas, sino desde un punto de vista de costos. Los probadores son, o al menos son percibidos como, menos costosos que los programadores. Recuérdeles que al hacer que usted cumpla una doble función, están pagando un recurso mejor pagado (programador) para que haga el trabajo que podría realizar un recurso menos costoso (probador). Por lo tanto, no están maximizando el valor que están extrayendo de su habilidad de programación.

Este enfoque tiene el inconveniente de desmoronarse si usted es asalariado y no tienen reparos en hacer que trabaje más horas extras no remuneradas, pero vale la pena intentarlo.

El sistema en cuestión es grande pero lo desarrollé únicamente yo. Esto también ha causado que algunas tareas administrativas caigan en mi regazo, como definir horarios y trabajar en especificaciones.

Lo suficientemente justo.

¿Debería este tipo de tareas ser mi responsabilidad?

En última instancia, depende de su gestión decidir.

Me veo estrictamente como programador y nada más.

Quizás estés en el trabajo equivocado entonces. A mucha gente le gusta que le den la responsabilidad extra.

Y si estos son mi responsabilidad, ¿en qué medida?

Si la gerencia lo dice, sí.

¿Cuándo es un proyecto tan grande que requiere probadores?

Cuando hay mucho otro trabajo que los desarrolladores tienen que hacer. En ese momento, la gerencia debe decidir si desean emplear un probador dedicado o arriesgarse a escatimar en las pruebas. (En última instancia, los desarrolladores solo pueden hacer mucho).

Hay ventajas definitivas en tener probadores dedicados, pero también hay inconvenientes ... además del costo de contratar personal adicional.

Si un programador tiene que refinar la especificación,

Si es necesario, si. De hecho, si la especificación necesita un refinamiento y no hay nadie más trabajando en ella, es probable que si no lo hace, el proyecto falle.

preocuparse por la gestión del proyecto

Si es necesario, si.

o incluso proporcionar soporte al cliente?

Si es necesario, si.

A mí me parece que estás sobrecargado de trabajo y reaccionas a la presión. Esto es un problema. Pero tomar la posición de que "no es tu trabajo hacer X, Y, Z" no va a ayudar. Un mejor plan es dejar en claro que solo hay mucho que puede hacer, y señalar que es probable que esto haga que se pierdan los plazos, que se pierda la calidad, una atención al cliente deficiente, etc. Pero haz tu mejor esfuerzo de todos modos ... sin dañar tu salud, relaciones, etc. en el proceso.

Tenemos probadores. No quisiera trabajar sin ellos. Aunque escribo pruebas unitarias (usando TDD) y pruebas de integración automatizadas para todo mi código, los probadores todavía tienen una función muy valiosa.

1. Son altamente calificados y tienen diferentes habilidades para los programadores.
   1. Tienen mucha experiencia y conocimiento sobre cómo hacer pruebas de control de calidad y cómo verificar que el código que se ha producido realmente coincide tanto con las expectativas del usuario como con el comportamiento real de los usuarios.
   2. Han experimentado muchos errores y son muy buenos para pensar en situaciones que podrían dañar el software.
   3. Tienden a ser cínicos y sistemáticos. He observado que los programadores suelen ser mucho más optimistas.
2. Proporcionan valiosos comentarios tempranos sobre usabilidad. Por ejemplo, al crear una API REST recientemente, las áreas que los evaluadores de control de calidad no podían entender fácilmente eran una buena indicación de las áreas con las que el usuario tampoco estaría contento.
3. Prueban en el entorno real, de hecho, muchas configuraciones del hardware real, sistema operativo, etc.
4. Saben cómo construir bancos de prueba realistas y a gran escala y realizar pruebas de rendimiento, carga y estrés
5. Se centran en evitar que salgan las malas versiones. Los programadores tienden a centrarse en liberar el código. Es casi como si un programador lanzara el código por defecto, pero un probador de control de calidad necesitará una razón para lanzarlo (¡se ha demostrado que funciona!)

"si tuviéramos probadores, no probarías tu propio código"

"¡ Si tu auto tuviera el cinturón de seguridad, lo chocarías todo el tiempo! "

¿Debería este tipo de tareas ser mi responsabilidad? [...] Y si estos son mi responsabilidad, ¿en qué medida?

La respuesta a eso es "depende". Según tengo entendido, sus empleadores lo ven como el "departamento de TI de un solo hombre". Si ese es el caso, sí, son (su responsabilidad). Si tiene responsabilidades que odia y desea evitar, busque un puesto dentro de una empresa con un departamento de TI más grande.

¿Cuándo es un proyecto tan grande que requiere probadores?

Esa no es una pregunta correcta. Es mejor preguntar "¿cuándo es tan importante la calidad del producto / imagen de la empresa que requiere probadores?"

Si un programador tiene que refinar la especificación, [...]

Sí definitivamente. La mayoría de las veces, existe una gran discrepancia entre lo que necesita un desarrollador / implementador y lo que proporcionan los clientes [como especificaciones].

Muchas veces depende de usted encontrar áreas grises / no especificadas y hacer las preguntas correctas, notar y señalar requisitos técnicamente imposibles o contradictorios, etc. (especialmente si usted es el único desarrollador).

[...] preocuparse por la gestión del proyecto o incluso brindar soporte al cliente?

Eso depende de las responsabilidades que aceptó cuando asumió el cargo. Por ejemplo, algunos puestos requieren que se dirija directamente a los clientes. En igualdad de condiciones, trataría de evitar tales puestos (pero depende de usted, y es posible que no tenga muchas opciones de trabajo).

En primer lugar, las pruebas, o mejor dicho, Control de calidad, no se trata solo de probar la funcionalidad haciendo clic en la aplicación. La garantía de calidad se trata de procesos . No solo para probar la aplicación para encontrar los errores, también tienen que evitar que los desarrolladores los cometan.

1. Especificación del producto + casos de uso
   Incluso si todos saben (o piensan que lo hacen) cuál es la funcionalidad del producto, debe anotarse. No puede probar una aplicación sin una especificación clara. Una especificación define qué es el comportamiento correcto y qué es un error.
2. Pruebas unitarias,
   Pruebas de integración Pruebas de las partes internas que son difíciles de probar a través de la interfaz de usuario, estados de aplicación excepcionales. Esto es imprescindible para cualquier sistema más grande. Ambos tipos de pruebas también tienen otra propiedad interesante: te obligan a revisar cada parte del código nuevamente y te darás cuenta de errores / problemas de arquitectura que nunca antes viste.
3. Calidad del código y estándares de codificación
   Una de las tareas que debe realizar el control de calidad es medir la complejidad del código. El código de baja complejidad reduce la posibilidad de errores (prevención de errores).
4. Revisiones de código
   Cuando un proyecto alcanza un tamaño determinado, o es utilizado por muchos usuarios, las revisiones de código son imprescindibles. Otro programador siempre encuentra problemas de código / errores que te has perdido. El programador a veces es ciego a errores obvios en su propio código.
5. Documentación
   Documente su código y su arquitectura, lo ayudará a darse cuenta de posibles fallas (mi propia experiencia).
6. Testers
   Tester no es un mono que solo hace clic en la interfaz de usuario. Un probador toma las especificaciones y casos de uso y crea casos de prueba. Luego los prueba uno por uno. Si los usuarios finales informan de un error, se debe agregar un caso de prueba para eso.

Un programador nunca debe crear la especificación (1). No estás allí para decidir la funcionalidad. Por lo general, tienen que hablar con los usuarios finales, crear diseños gráficos, etc. Es una tarea que requiere mucho tiempo. Si un programador decide la funcionalidad, generalmente termina con "está bien, pero ¿podría cambiar todo en esta ventana mañana?" "esto no es lo que quería" "funciona, pero es difícil de usar" "le falta la única funcionalidad que realmente necesitábamos".

Lo que un programador puede lograr es 2, 3 y 5.

Necesita otro programador para 4. Cualquier empresa con un gran proyecto de TI y solo un desarrollador que conozca los pasos del sistema en un terreno muy peligroso.

Si no tiene suficiente tiempo, nunca se moleste en crear casos de prueba (5). Por lo general, se necesita una persona dedicada, ya que lleva mucho tiempo. Sin casos de prueba, la prueba es solo una broma.