Ex ante: Parece que hay mucha confusión sobre lo que se considera como probar lo que no es. Claro, cada desarrollador necesita probar su código a medida que lo crea, él / ella necesita verificar que funcione. Ella / él no puede dárselo a un probador antes de que él / ella piense que está hecho y 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 considerarse desde el punto de vista del gerente de proyecto:
Los desarrolladores pueden ser evaluadores, pero no deberían ser probadores . Los desarrolladores tienden a evitar, de manera no intencionada / inconsciente, utilizar la aplicación de una manera que pueda romperla. Esto se debe a que lo escribieron y, en su mayoría, lo prueban de la forma en que debería usarse.
Por otro lado, un buen probador trata de torturar la aplicación. Su intención primaria es romperlo. A menudo usan la aplicación de maneras 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, usar a los desarrolladores como evaluadores aumenta los costos de desarrollo y no beneficia la calidad del producto, sino que tiene un probador dedicado. No dejaría que los desarrolladores hicieran pruebas cruzadas de sus trabajos cuando un probador lo puede hacer mejor. Solo si el bucle de retroalimentación entre los desarrolladores y los evaluadores se volviera demasiado costoso, haría que los desarrolladores hicieran una prueba cruzada del código de cada uno, pero en mi experiencia, eso rara vez es el caso y depende mucho 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 tiene soluciones aquí, solucione problemas u otros bugs que ningún desarrollador podría prever, eso está bien. Además, las pruebas de integración deben ser realizadas principalmente por los desarrolladores. El principal objetivo 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 evaluador en un papel híbrido, escribiendo pruebas unitarias y pruebas de interfaz de usuario. Definitivamente debes contratar uno .
Pero más importante que el probador son las congelaciones / ramas regulares. No presente nada que no haya sido debidamente probado. Cuando ha agregado una función o cambiado algo, todo lo que lo rodea debe verificarse nuevamente. Solo obtendrás una mala reputación si tu empresa no lo hace. No sueltes algo inestable. Cuando el cliente desea tener el software en una fecha determinada, entonces deje de desarrollarlo lo suficientemente temprano y pruébelo adecuadamente, de modo que tenga tiempo suficiente para corregir los errores. A menudo es mejor rechazar las solicitudes de funciones de último minuto que implementarlas de forma deficiente o lanzarlas sin realizar las pruebas adecuadas.