¿Debería un desarrollador también actuar como probador? [cerrado]

Somos un equipo scrum de 3 desarrolladores, 1 diseñador, el scrum master y el propietario del producto. Sin embargo, no tenemos un probador oficial en nuestro equipo. Un problema que siempre está con nosotros, es que, probar la aplicación y pasar esas pruebas y eliminar errores se ha definido como uno de los criterios para considerar un PBI (Producto de la Lista de Producto) como hecho.

Pero el problema es que, no importa cuánto (3 desarrolladores y 1 diseñador) intentemos probar la aplicación y los casos de uso implementados, todavía no se ven algunos errores y arruinan nuestra presentación ( ley de Murphy ) a las partes interesadas.

Como remedio, recomendamos que la compañía contrate un nuevo probador. Alguien cuyo trabajo estaría probando, y probando solo. Un probador profesional oficial.

Sin embargo, el problema es que el scrum master y las partes interesadas creen que un desarrollador (o un diseñador) también debería ser un probador.

¿Tienen razón? ¿Deberíamos nosotros los desarrolladores (también diseñadores) ser probadores también?

Ex ante: parece haber mucha confusión sobre lo que se considera probar lo que no. Claro, cada desarrollador necesita probar su código mientras lo crea, él / ella necesita verificar que funcione. Ella / él no puede entregarlo a un probador antes de que él / ella piense que está hecho y que es lo suficientemente bueno. Pero los desarrolladores no lo ven todo. Es posible que no reconozcan los errores. Estos errores solo se pueden encontrar más adelante en el ciclo de desarrollo cuando se realizan pruebas exhaustivas. La pregunta es si los desarrolladores deben realizar ese tipo de pruebas o no, y en mi humilde opinión, esto debe analizarse desde el punto de vista del gerente de proyecto:

Los desarrolladores pueden ser probadores, pero no deberían serlo . Los desarrolladores tienden a evitar involuntariamente / inconscientemente usar la aplicación de una manera que pueda romperla. Eso es porque lo escribieron y lo prueban principalmente en la forma en que debería usarse.

Un buen probador, por otro lado, intenta torturar la aplicación. Su intención principal es romperlo. A menudo usan la aplicación de formas que los desarrolladores no habrían imaginado. Están más cerca de los usuarios que del desarrollador y, a menudo, tienen un enfoque diferente para probar un flujo de trabajo.

Además, el uso de desarrolladores como probadores aumenta los costos de desarrollo y no beneficia tanto la calidad del producto como tener un probador dedicado. No permitiría que los desarrolladores hicieran una prueba cruzada de sus trabajos cuando un probador pueda hacerlo mejor por poco dinero. Solo si el ciclo de retroalimentación entre los desarrolladores y los probadores se volviera demasiado costoso, haría que los desarrolladores hicieran una prueba cruzada del código de los demás, pero en mi experiencia eso rara vez es el caso y depende en gran medida del proceso.

Eso no significa que un desarrollador deba ser descuidado y dejar todo al probador. El software debe estar respaldado por pruebas unitarias y los errores técnicos deben reducirse al mínimo antes de entregar el software al probador. Aún así, a veces tienes una solución aquí, rompes los problemas u otros errores que ningún desarrollador podría prever, está bien. Además, las pruebas de integración deben ser realizadas principalmente por los desarrolladores. El objetivo principal del probador es verificar que se cumplan los requisitos.

En un equipo tan pequeño (y también dependiendo del tamaño de la aplicación), también puedo ver al probador en un rol híbrido, escribiendo pruebas unitarias y pruebas de IU. Definitivamente deberías contratar uno .

Pero más importante que el probador son las congelaciones / ramas regulares. No presente nada que no haya sido probado adecuadamente. Cuando agregaste una función o cambiaste algo, todo lo que la rodea debe verificarse nuevamente. Solo obtendrá una mala reputación si su empresa no lo hace. No sueltes algo inestable. Cuando el cliente quiera tener el software en una fecha determinada, deje de desarrollarlo lo suficientemente temprano y pruébelo de manera adecuada, para que tenga tiempo suficiente para corregir errores. A menudo es mejor rechazar las solicitudes de funciones de último momento que implementarlas de manera deficiente o liberarlas sin las pruebas adecuadas.

Los desarrolladores pueden ser probadores del código de otros desarrolladores.

Pero probar su propio código no es un buen movimiento: los desarrolladores tienden a tener bloqueos mentales sobre su propio código y, por lo tanto, tienen dificultades para diseñar pruebas completas o apropiadas.

Siempre habrá desarrolladores que piensen que lo hacen bien, pero generalmente no lo hacen (y estoy seguro de que tengo muchos puntos ciegos).

Si REALMENTE NO PUEDE contratar a un probador, haga que los desarrolladores realicen pruebas cruzadas entre sí, es decir, si A escribe el código y realiza pruebas unitarias, haga que B revise esas pruebas unitarias y vea si hay otras cosas que podrían agregarse. . Y haga que B intente probar el código (como usuario) e informe defectos.

Esto no es perfecto, pero es mejor que un solo desarrollador tratando de hacer todo.

A veces, sus colegas pueden ser realmente buenos para romper su software, porque disfrutan de eso y no les importa demasiado, porque no es SU código.

¿Debería el periodista tender a escribir correctamente? Quiero decir, es trabajo de correctores y editores encontrar todos los errores gramaticales.

Sin embargo, los periodistas proporcionan algún corrector ortográfico por sí mismos. Sin embargo, el corrector es una profesión separada e importante.

Lo mismo sobre desarrolladores y probadores, excepto el hecho de que el control de calidad es una parte aún más importante del desarrollo. Incluso si es un buen desarrollador, simplemente no tiene tiempo para probar exhaustivamente todos los casos de prueba, para cubrir todos los entornos, navegadores y sistemas operativos que admite su producto.

Si uno, además de desarrollarse, también hace ese trabajo constantemente, solo significa un hecho simple: es un probador a tiempo parcial.

no importa cuánto (3 desarrolladores y 1 diseñador) intentemos probar la aplicación y los casos de uso implementados, aún así algunos errores no se ven y arruinan nuestra presentación ... a las partes interesadas.

Considere realizar una "ejecución controlada" para un sprint o dos, rastreando el desarrollo y probando los esfuerzos por separado. Al final de dicha ejecución, analice los datos recopilados para averiguar cuánto esfuerzo dedica a las pruebas.

Si descubre que las pruebas requieren mucho esfuerzo, pase esos datos a la administración; será una evidencia convincente que respalde su solicitud (mucho más convincente de lo que tiene ahora).

De lo contrario (si encuentra que su prueba lleva poco tiempo), considere invertir un esfuerzo adicional para hacerlo mejor (o aprender cómo hacerlo). Negocie ese esfuerzo adicional que planifica con su administración, porque en su lugar pueden preferir contratar a un evaluador. :)

... recomendamos que la empresa contrate un nuevo probador. Alguien cuyo trabajo estaría probando, y probando solo. Un probador profesional oficial.

Sin embargo, el problema es que el scrum master y las partes interesadas creen que un desarrollador (o un diseñador) también debería ser un probador.

Tengo que admitir que la administración de su empresa me parece bastante floja. Quiero decir, está bien, puede ser realmente difícil averiguar cuántos probadores serían mejores para el proyecto, está bien.

Pero tener al menos un probador es solo una apuesta segura, es realmente divertido que duden en intentarlo, mientras afirman que son scrum / agile .

Bueno, tuvimos dos pruebas cruzadas de desarrolladores después de que el primero hizo algunos cambios en una pantalla de entrada. Esto fue cuando nuestro probador regular estaba de baja por maternidad.

Básicamente, cambió una pantalla de listado de facturas que los usuarios usaron para seleccionar las facturas antes de hacer zoom para editar mediante un botón "Editar". Se eliminó la lista original y se insertó una nueva vista de cuadrícula, con filtrado, agrupación, clasificación y todo tipo de funcionalidades geniales.

Las pruebas fueron excelentes y cargaron los cambios al cliente al día siguiente. Dos semanas después, el cliente llama y dice: "Nos gusta mucho lo nuevo que pones, ahora podemos ver todo tipo de información. Pero ... er ... ¿a dónde vamos a editar las facturas ahora? ?? "

Resulta que el desarrollador sacó la casilla de verificación (para la selección) y el botón de edición y dado que los desarrolladores siempre hicieron doble clic para seleccionar un elemento de todos modos, ninguno de ellos encontró nada malo ...

Los desarrolladores y usuarios viven en mundos diferentes, hacer pruebas cruzadas es mejor que hacer que el desarrollador pruebe su propio trabajo, pero aún no es lo mismo.

Como otros han dicho aquí, los desarrolladores pueden realizar una prueba cruzada del código de los demás (pruebas unitarias o funcionales), y tal vez su scrum master y el propietario del producto puedan ayudarlo con las pruebas de integración, pero para las pruebas de aceptación del usuario debe asegurarse de obtener muchos comentarios de las pruebas del cliente, lo que significa implementaciones frecuentes con las que pueden trabajar de la misma manera que lo hacen los usuarios reales y un canal de comunicaciones realmente abierto .

Debe diseñar teniendo en cuenta la capacidad de prueba, pero si no tiene un probador dedicado, algunas cosas simplemente pasarán desapercibidas porque no hay suficientes horas en el día para diseñar, implementar y probar el software.

Probar software es un trabajo profesional a tiempo completo. Se necesita un buen cerebro, talento y mucha experiencia para convertirse en un buen probador. Es ridículo suponer que un desarrollador de software, no importa cuán inteligente sea, puede acercarse a un probador profesional cuando la prueba es solo un pequeño componente de su trabajo diario.

Además de eso, surge el problema de que inconscientemente el desarrollador de software no quiere encontrar errores.

Estoy de acuerdo con su punto de que los desarrolladores / diseñadores deberían probar su código, con la certeza de que el diseñador / desarrollador que hizo una sección de código no será el único conjunto de "ojos" en ese código antes de comprometerse a vivir. Si bien eso no va a agarrar todo, al menos ayudará a evitar la ceguera que se arrastra en las pruebas y la reevaluación de su propio código durante el desarrollo.

Por la mención del caso de uso, supondré que también está utilizando herramientas de cobertura de código. De lo contrario, podría ayudar a ver qué código podría no probarse, y podría aparecer errores inesperados durante ciertas condiciones.

Dicho esto, si hay suficiente trabajo o si su organización es de un tamaño decente, estoy de acuerdo en que se necesita una persona de control de calidad profesional, ayudaría a enfocar un poco más los roles de todos, y también podrían ver si hay algún patrón sobre qué se está perdiendo y, lo que es más importante, cómo solucionarlo.