Soy un estudiante que trabaja en mi BE (CS) y mi pregunta es la siguiente:

1. ¿Se necesitan pruebas en el campo del software?
2. Si creamos un software con mucho cuidado, ¿por qué deberíamos probarlo?
3. Después de las pruebas podemos estar seguro de que hemos logrado este objetivo (las obras producto / software como está previsto) porque hemos hecho la prueba para ello? ¿Es posible?

Mi pregunta: ¿es necesario probar el software ?

Sí. Porque no importa lo bueno que seas, no puedes pensar en todo.

• También se le pedirá que haga que su software haga cosas que nunca pretendió que hiciera.
• Usted también no tener requisitos que son tan claras que usted será capaz de pensar en todas las posibilidades para asegurarse de que el código no se rompe.
• También trabajará con el software y las API de otras personas que no siempre funcionarán según lo previsto, pero supondrá que sí funciona o debería provocar defectos en su caso "perfecto".

Sí

Por la misma razón que un chef prueba su comida mientras la cocina.

Trabajo con alguien que piensa así, piensa que debido a que es un programador sénior ya no necesita probar su código. La compañía no comprende cuán peligrosa es esta actitud y, en lugar de despedirlo de inmediato, contrataron a más programadores para abordar la acumulación de errores. Sin saber de dónde proviene esta acumulación, creen que es parte de lo que se trata la programación. Básicamente tenemos 3 programadores que trabajan en este modo y un equipo de 20 que no hacen nada más que probar y corregir los errores que estos tres crean.

AUSENCIA DE PROPER TESTING MATA .

Entonces, a menos que sea DIOS o cualquier versión de algún ser perfecto (ahora esto me gustaría ver) o a menos que quiera activamente ser despedido muy rápido, le sugiero que comience a probar.

El software está escrito por personas.

Las personas son imperfectas y cometen errores.

A medida que aumenta la complejidad de una empresa, aumenta el número potencial (y el impacto) de errores, descuidos o cosas olvidadas, generalmente de manera exponencial.

Entonces sí, se necesitan pruebas. Aporta equilibrio y perspectiva.

¿Subirá a un vuelo que ejecuta un sistema operativo que sabe que usó en su computadora portátil y le dio una pantalla de la muerte en su color favorito? Piénsalo.

Ningún codificador es perfecto. Lejos, lejos, lejos de eso realmente. Necesita pruebas, y los evaluadores a menudo aportan una perspectiva (también conocida como casos de uso) que los desarrolladores no tenían.

Haga una búsqueda en los errores de software más famosos en Google para saber a qué me refiero.

Y a nivel universitario, lea un poco sobre el desarrollo basado en pruebas, pruebas unitarias y prácticas ágiles para saber dónde están las cosas en este momento.

La prueba es una necesidad absoluta para cualquier aplicación no trivial (en tamaño o función) que se va a utilizar realmente. No encontrará un solo desarrollador que se preocupe por su oficio (como lo demuestra su visita a este sitio) que responderá y dirá que las pruebas no son necesarias.

Además de lo que ya se ha publicado, contar con un conjunto completo de pruebas unitarias automatizadas en cualquier aplicación le hará tener más confianza en futuros cambios de código. Esta mayor confianza (ya que las pruebas unitarias proporcionan una GRAN red de seguridad) dará como resultado cambios de código más rápidos en las aplicaciones existentes (debido a menos retroceso / doble verificación)

Errare humanum est

No existe un software libre de errores.

El desarrollador más experto escribe código con errores. Incluso si existiera un desarrollador perfecto, todavía habría errores debido a discrepancias entre:

• necesidades del usuario y documentos de especificación
• especificación y diseño
• entornos de hardware y software esperados y reales
• ayer y hoy verdad: todo lo mencionado anteriormente está sujeto a cambios que no se informan perfectamente en cada paso del proceso de desarrollo.

El desarrollador perfecto es solo una parte de todo. Y los desarrolladores perfectos no existen.

La mayoría de los programas de la vida real:

a) contienen cientos de líneas de código o más, dispersas en numerosos archivos;
b) son desarrollados por más de un programador;
c) utilizado en entornos que son diferentes del entorno del desarrollador

Por lo tanto, si no verifica cómo funciona el programa en una situación de la vida real, la probabilidad de que no funcione será cercana al 100%.

Además de todas las otras excelentes respuestas, incluso si sabe que es perfecto y libre de errores, piense en los otros programadores que tendrán que lidiar con su código en el futuro. No lo sabrán como usted y querrán confiar en sus pruebas para asegurarse de que no hayan roto nada después de haber realizado un cambio. ¡Por supuesto, esto también se aplica a usted mismo después de que no haya visto su código en un año!

SÍ.

Aquí hay otra perspectiva un poco más sutil que aún no se ha cubierto:

Nunca subestimes la necesidad de una "verificación independiente" . Es la misma razón por la que es bueno tener algunos editores independientes que revisen su trabajo antes de enviar una gran pieza de escritura para su publicación. No importa qué tan buen escritor seas, ocasionalmente harás una lluvia de ideas y escribirás algo como "en" en lugar de "eso", o algo así. Si lo vuelve a leer usted mismo, incluso con bastante cuidado, generalmente lo perderá, porque su cerebro acepta automáticamente el flujo de su proceso de pensamiento como correcto y pasa por alto el error. Para un nuevo conjunto de ojos, ese tipo de error suele ser bastante evidente.

Obtiene lo mismo en la programación: es bastante fácil entrar en un flujo donde su código, o su "prueba de desarrollo" básica de su propio código, parece correcto porque lo está probando y usándolo de cierta manera. Pero luego, cuando aparece otro par de manos y hace clic en las cosas de una manera u orden ligeramente diferente, todo se derrumba.

Ahora, por supuesto, en teoría podría ir por el camino de verificar formalmente cada posibilidad y rama lógica en su código, pero para un software no trivial, esto será mucho más costoso y requerirá más tiempo que hacer que alguien más explote código para ti Y probablemente todavía extrañarás cosas en las que nunca pensaste.

Lo que aún no se ha tocado: incluso si su código es perfecto, todavía no está seguro. Los compiladores tienen errores que pueden hacer que incluso el código perfecto se comporte incorrectamente después de la compilación. Los sistemas operativos tienen errores que pueden hacer que un binario perfecto se comporte incorrectamente cuando se ejecuta. El hardware tiene errores que pueden causar problemas.

Por eso también probar en una máquina no es suficiente para productos comerciales. Deben ser probados en la mayor cantidad posible de combinaciones de hardware y software que puedan encontrar en la naturaleza como sea posible.

El líder del equipo que escribió el software para el transbordador espacial voló antes de cada lanzamiento para firmar que el software no dañaría el transbordador.

¿Qué crees que le dio la confianza para hacerlo?

Constantemente está probando código simplemente compilándolo y usándolo. En algunos IDE, recibirá controles de cordura a medida que escribe. A menos que nunca ejecute su código, está haciendo pruebas.

Cuánto prueba es realmente la raíz de este tipo de preguntas y la respuesta se reduce al riesgo. Usted prueba tanto como tiene sentido hacerlo desde el punto de vista de la gestión de riesgos. Probar todo o nada suele ser imposible. Probar casi nada suele ser un mal movimiento. Todo en el medio es un juego justo, dependiendo del nivel de riesgo y la exposición de su entregable.

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.

Las pruebas siempre se realizarán y siempre se encontrarán errores. Es solo que la prueba la realizará internamente su equipo o el usuario final será el probador. El costo de un error encontrado por el usuario final es tremendamente más alto que si lo hubiera encontrado durante las pruebas.

Sugeriría tomar un buen curso de computación tolerante a fallas. El diseño cuidadoso del software es solo uno de los pilares para lograr robustez en su producto de software. Los otros dos pilares son pruebas suficientes y diseño redundante. La intención básica es acomodar un número exponencial de condiciones de falla desconocidas y priorizar el manejo de algunas de las conocidas:

1.) elimine la mayor cantidad posible de fallas a través del diseño y la implementación adecuada 2.) elimine las fallas imprevistas de la fase de diseño y la implementación incorrecta a través de diversas formas de prueba (unidad, integración, aleatorio) 3.) lidie con cualquier falla sobrante a través de la redundancia ( temporal => recalcular, reintentar o espacial => guardar copias, paridad)

Si elimina la fase de prueba, se queda solo con las fases de diseño y redundancia para abordar las fallas.

Además, desde el punto de vista del producto, sus partes interesadas (por ejemplo, la administración, los usuarios, los inversores) querrán algún tipo de garantía de que su producto cumple con ciertas especificaciones de calidad y seguridad, criterios, etc. Además de todo esto, ¿no ha probado el software que construiste solo para tener un 'chequeo de cordura'? Todos estos motivos hacen que las pruebas de software sean más convincentes.

Todos los programas tienen errores, al menos para empezar.

Ha habido algunos estudios que convergen en aproximadamente 1 error por cada cinco líneas de código no probado.

Una lección de historia:

En la década de 1960, IBM necesitaba un programa "NOP" para poder ejecutar alguna funcionalidad en JCL sin ejecutar realmente un programa. Los desarrolladores crearon un programa de ensamblador de una línea en el que todo el código estaba contenido dentro de su nombre "IEFBR14", siendo el código real:

       BR 14 * brach to return address in register 14

Durante su larga duración, este programa de una línea ha estado sujeto a 2 informes de errores y cinco enmiendas.

La refactorización de código es realmente más rápida cuando tienes pruebas unitarias. Una prueba unitaria también le muestra el uso simple de la función concreta, por lo que tiene un pequeño "cómo" que puede ser realmente útil en grandes proyectos donde los programadores no saben exactamente todo el código.

Cuando está desarrollando con TDD (desarrollo basado en pruebas) no tiene getter / setters innecesarios, etc. Simplemente crea lo que necesita.

Para responder el n . ° 3 de su pregunta:

Habiendo sido programador y probador de software, sí, puede estar seguro de que cumple con los requisitos del software durante las pruebas.

{poniéndose el sombrero de control de calidad}

¿Cómo? Puede hacer esto rastreando sus pruebas desde el código de prueba a los criterios de aceptación, los criterios de aceptación a las características y las características a los requisitos. Si rastrea cada prueba en la cadena de diseño y se asignan a uno o más requisitos, puede estar seguro de que sus pruebas se están utilizando para garantizar que el código cumpla con sus requisitos (aunque esto trae a colación la noción de cobertura de prueba adecuada, que es una otro tema). Si no puede rastrear una prueba en la cadena de diseño, es probable que esté probando cosas que no son necesarias, y esto es una pérdida de tiempo. Los criterios de aceptación también pueden incluir la comprobación de comportamientos no deseados; también puede probarlos, lo que lo acerca un paso más a una versión de calidad.

{QA hat off}

Ningún código está libre de errores, es menos costoso con el tiempo cuando se dedica más esfuerzo a evaluar su calidad durante el desarrollo.

He sido probador de software durante 3 años. Inicialmente, yo mismo era escéptico sobre la necesidad de realizar pruebas, ya que pensaba que si el departamento de desarrollo y la administración de proyectos hacen su trabajo, no deberían surgir errores en el software.

PERO este no es el caso. ++++++++

Los errores ocurren a menudo, algunos de ellos críticos para la operación de un proyecto. También hay pruebas entre navegadores (lo que significa probar en diferentes navegadores existentes como SAFARI, FIREFOX, CHROME e Internet Explorer) y trabajé en el proyecto donde botones de interfaz simples como SÍ y NO en una ventana de encuesta donde no funciona solo en todos los navegadores Algunos.

Trabajé en pruebas de páginas de Internet, estaba probando CAMBIOS DE TEXTO simples y pensé para mí mismo que de ninguna manera podría haber defectos en este simple trabajo, pero no sucede.

También he visto cuando nuevos desarrolladores se unen al equipo y reciben una pieza de trabajo de actualización para un formulario de aplicación de Internet complejo existente con una serie de enlaces / llamadas a páginas externas, se produjo un error debido a la falta de comunicación entre los desarrolladores antiguos y nuevos, por varias razones (sin tiempo para educar, sin voluntad de educar, etc.).

SÍ

Imagine que su software es solo una función lógica Y (b1, b2) donde b1 y b2 son solo bits. Con eso, necesita 4 casos de prueba para asegurarse de que su software esté libre de errores, si su entorno circundante ofrece exactamente para lo que fueron especificados.

Ahora su sistema está compuesto por muchas funciones cuya más simple es mucho más complicada que esa función lógica. ¿Cómo se aseguraría de que esté libre de errores?

(continuará)