Tengo una aplicación PHP que es muy grande. Por lo general, hay 2-3 desarrolladores trabajando a tiempo completo y estamos llegando al punto en el que estamos haciendo cambios y creando errores (¡características de tos!). El software no es complejo, por ejemplo, simplemente están sucediendo muchas cosas (35 controladores, aproximadamente los mismos modelos, etc.).

Incluso teniendo cuidado, es fácil que un cambio en esta vista (ajustar una identificación en un elemento) destruya una consulta ajax que ocurre bajo alguna condición especial (desconectada mientras está parado sobre un pie).

Las pruebas unitarias son las primeras cosas que nos vienen a la mente, pero las probamos en otra aplicación, y es muy fácil olvidarlas / o pasar más tiempo escribiendo pruebas que haciendo pruebas. Tenemos un entorno de preparación donde se verifica el código antes de enviarlo en vivo.

Tal vez necesitamos una persona Q / A a tiempo parcial?

Alguien tiene alguna sugerencia / pensamiento.

Sí, necesita personal de Q / A. Algunas de las muchas razones incluyen

• Un probador dedicado cuesta dinero, pero a menudo menos dinero que un desarrollador, por lo que el beneficio de no gastar su tiempo es mayor que el gasto adicional.
• Un probador dedicado sabe cómo probar cosas, particularmente cosas que no es obvio cómo automatizar. Conducir pruebas automatizadas para interactuar con un sistema a través de un navegador es una disciplina algo complicada pero bien establecida. Si encuentra a alguien que ya sabe cómo hacerlo, no tiene que pasar aún más tiempo aprendiendo buenas herramientas y configuraciones.
• Un probador profesional sabe cómo encontrar defectos. Es mucho más probable que piensen como pensaría un usuario de la aplicación y, por lo tanto, ejercen aquellos estados en el sistema que realmente aparecerán en producción, lo que significa que esos errores que resultan ser altamente visibles tenderán a encontrarse antes , ahorrándole vergüenza y costos por parches ultra urgentes.
• Generalizando eso, un probador no piensa como un desarrollador . Es difícil transmitir cuánta diferencia hace esto si no lo ha experimentado. Conscientemente o no, un desarrollador no quiere encontrar defectos. Saben cómo funciona el sistema y tienden a evitar las típicas entradas o datos sin sentido (para ellos) que causan problemas en la vida real. Si algo funciona de manera inesperada, saben cómo solucionarlo y tienden a no verlo como un defecto. Ellos nuncatienen dificultades para comprender qué significan las respuestas del sistema, porque las escribieron, a pesar de que esta es una causa importante de problemas en casi todos los sistemas reales. En pocas palabras: los programadores tienden a ser malos para tener los problemas típicos que tienen los usuarios, porque son especialistas altamente capacitados. Al probador le resulta mucho más fácil realizar las pruebas más relevantes.

Dicho esto, nada supera la cooperación productiva entre un desarrollador y un probador para conducir la calidad del sistema a través del techo. Un desarrollador a menudo nota los síntomas de que algo está mal antes de lo que haría el probador. Un desarrollador a menudo puede aconsejar a un probador cómo reproducir un problema de manera mucho más eficiente y cómo escribir un informe de problema adecuado, es decir, incluir los detalles que son realmente necesarios para resolver el problema. Pero todo eso requiere al menos un probador con el que pueda trabajar junto.

Probablemente necesite más o mejores pruebas de regresión (no pruebas unitarias específicas ). ¿Qué tipo de pruebas deberían ser para analizar usted mismo, pero deberían detectar los errores de los que está hablando? Le sugiero que comience a hacer un plan de prueba y priorice esas pruebas, y cuando lo haga, inicialmente no piense demasiado en la automatización de pruebas.

Luego, pregúntese si puede automatizar algunas o la mayoría de las pruebas con un esfuerzo razonable. Si la respuesta es sí, entonces debe programarlos. Si la respuesta es "no", y cree que la "persona de Q / A a tiempo parcial" es más barata, entonces debería ser lo que necesita. En la mayoría de los casos, es una buena idea tener ambas cosas: una persona de preguntas y respuestas para realizar pruebas manuales e inventar nuevas pruebas, y también muchas pruebas de regresión automatizadas.

Contrata un QA profesional

Esto debe hacerse si está desarrollando un proyecto comercial. Tener un producto listo sin una estrategia de prueba sólida le costaría más con las correcciones de errores. Además, ganar nuevos clientes o retenerlos también dependerá de cuán buena sea su aplicación probada.

En general, las pruebas unitarias deben aplicarse a su base de código, sin embargo, las pruebas de integración y las pruebas manuales no deben descartarse.

La prueba unitaria es una muy buena idea, especialmente si su proyecto está creciendo. Si escribir pruebas unitarias se convierte en un hábito, facilitará mucho su trabajo. Hay un video en youtube sobre cómo escribir código limpio, que es más fácil de mantener y probar.

Un ingeniero de control de calidad también es imprescindible. Un buen probador de control de calidad no solo encontrará errores en la funcionalidad, sino que también probará si la aplicación es fácil de usar (lo cual es casi imposible de probar por sí mismo). Aquí hay un buen artículo que explica cómo el equipo de control de calidad le ahorrará tiempo y dinero y ayudará a entregar un mejor software.

15 controladores y modelos no son muy grandes. Se necesita un tiempo para que la prueba de escritura sea un hábito, patearse mutuamente (primero de una manera amistosa) ayuda mucho.

Existen herramientas que pueden controlar la cobertura de la prueba hasta cierto punto. Herramientas de cobertura de código para PHP