Huele como una pregunta de tarea.
¿Se necesitan pruebas en el campo del software?
Sí. Absolutamente. En todos los niveles. Fuera de unos pocos dominios especializados, todavía no estamos en una etapa en la que podamos demostrar matemáticamente que nuestro código es correcto contra errores específicos (al menos no en un plazo razonable), por lo que tenemos que arrojar piedras para ver si y donde se rompe
Si creamos un software con mucho cuidado, ¿por qué deberíamos probarlo?
La prueba no se trata solo de encontrar errores de codificación. También se trata de asegurarse de cumplir con todos sus requisitos y de que el sistema en general funcione como se espera. Si tengo el requisito de que una transacción fallida debe devolver un código de error específico, entonces necesito escribir una prueba para verificar que la funcionalidad existe y que funciona correctamente.
Y todo eso supone que la especificación y el diseño son completos, correctos e internamente consistentes, lo que a menudo no es el caso. Incluso si cumple con las especificaciones al pie de la letra y sigue el diseño hasta el último punto y punto y coma, si la especificación o el diseño son incorrectos, habrá problemas en el momento de la integración. A menudo, las pruebas del sistema o de la integración se producen cuando descubres que la especificación en sí misma tiene errores y necesita ser revisada (ver la historia de guerra a continuación).
Después de la prueba, ¿podemos estar seguros de que hemos logrado este objetivo (el producto / software funciona según lo previsto) porque lo hemos hecho? ¿Es posible?
No, no al 100%. No podemos probar todas las combinaciones concebibles de entradas o rutas de ejecución en cualquier código que no sea el más simple. No podemos dar cuenta de todos los factores ambientales. No podemos imaginar todos los modos de falla posibles.
Podemos probar hasta un punto en el que estamos razonablemente seguros de que no hay grandes problemas. Nuevamente, esta es la razón por la que necesitamos realizar pruebas en todos los niveles. Escriba un conjunto de pruebas para asegurarse de que su código maneje las condiciones de borde correctamente (entrada incorrecta, resultados inesperados, excepciones, etc.). Prueba de unidad para verificar que su código cumpla con sus requisitos. Prueba del sistema para verificar el procesamiento de extremo a extremo. Prueba de integración para verificar que todos los componentes se hablen entre sí correctamente. Realice pruebas de usabilidad para asegurarse de que todo funcione de tal manera que los clientes no quieran dispararle.
Escenario del mundo real: estaba trabajando en un sistema de fondo que ocasionalmente enviaba actualizaciones a un servicio GUI para mostrar en una tabla en la pantalla. Durante el proyecto, se agregó un requisito para agregar filtrado a la pantalla (por ejemplo, el operador podría elegir mostrar un subconjunto de las entradas en la tabla). Error de diseño n. ° 1: el servicio de GUI debería haber realizado el filtrado (tengo esta noción pintoresca y anticuada de que las funciones de administración de pantalla deberían ser responsabilidad del software de administración de pantalla), pero debido a la política y mi incapacidad para reconocer los problemas antes de que se conviertan problemas , ese requisito se colocó en el servicio de fondo. Bueno, está bien, no hay problema, puedo hacer eso. Filtra los cambios de estado, recibo un mensaje y luego envío un mensaje de creación o eliminación paracada fila de la tabla , porque así es como funciona la interfaz (error de diseño # 2: no hay forma de enviar actualizaciones a varias filas en un solo mensaje; ni siquiera pudimos enviar un solo mensaje "borrar" o "borrar" para borrar toda la mesa).
Bueno, todo funciona bien durante el desarrollo; Las pruebas de unidad, sistema e integración muestran que envío la información correcta y manejo los cambios de filtro correctamente. Luego llegamos a las pruebas de usabilidad, y todo se cae con fuerza , porque el volumen de datos era abrumador. La latencia de red entre mi servicio de back-end y la GUI fue del orden de .15 a .25 segundos. No está mal si solo tiene que enviar actualizaciones para una docena de filas más o menos. Mortal cuando tienes que enviar actualizaciones para varios cientos. Comenzamos a recibir informes de errores de que la GUI se estaba congelando después de cambiar el estado del filtro; bueno, no, lo que estaba sucediendo era que estaba tomando el orden de varios minutos para actualizar la pantalla porque el protocolo de mensaje de actualización de una fila a la vez con cabeza de hueso no podía manejar un escenario del mundo real.
Tenga en cuenta que todo eso podría y debería haber sido anticipado por todos, desde el contratista principal hasta el pequeño yo si nos hubiéramos molestado en hacer incluso el análisis más básico de antemano. La única defensa que ofreceré es que estábamos cerrando el segundo año de un proyecto de seis meses que iba a ser desechado casi inmediatamente después de la entrega, y todos estábamos desesperados por ver la parte posterior.
Lo que nos lleva a la razón final para la prueba: CYA. Los proyectos del mundo real fracasan por una variedad de razones, muchas de ellas políticas, y no todos actúan de buena fe cuando las cosas van mal. Los dedos se señalan, se hacen acusaciones y, al final del día, debe poder señalar un registro que muestre que al menos sus cosas funcionaron como se suponía.
If we create a software with care in during its development period then why should we go for Test?- Porque pase lo que pase, incluso el programador más hábil comete errores.