Aforismo de Dijstra

¿A qué se refiere Dijstra con este aforismo?

Aforismo de Dijstra: “Probar programas sirva para demostrar la presencia de errores, pero nunca para demostrar su ausencia”. Se refiere a que en la programación al momento de crear una aplicación siempre al realizar pruebas de software, encontraremos muchos errores, pero argumenta que es normal, porque en el mundo real no hay software perfecto, no es posible hacer pruebas que te muestren exactamente todos los errores que existan. Es posible que encontremos infinitos casos de prueba pero lo mas importante es que hay que saber implementarlo.   

Comparación entre pruebas de Software

Tipo de prueba	Descripción		¿Qué se utiliza como base para la prueba?	¿Será útil para tu aplicación móvil?
Pruebas unitarias	Son una forma de comprobar nuestro código a nivel de módulos individuales para asegurarnos que funcionan correctamente por separado. Esto nos proporciona un plus de estabilidad a nuestro código porque se puede asegurar que ese trozo de código no tiene fallos.		El proceso que se lleva a cabo, consta de tres partes. El Arrange, donde se definen los requisitos que debe cumplir el código principal. El Act, el proceso de creación, donde vamos acumulando los resultados que analizaremos. Y el Asert, que se considera el momento en que comprobamos si los resultados agrupados son correctos o incorrectos. Dependiendo del resultado, se valida y continúa, o se repara, de forma que el error desaparezca.	Para la aplicación móvil que estamos desarrollando si es útil, en la cuestión de enviar un comentario o al momento de reservar una cita.
Pruebas de integración	Incremental ascendente ( Bottom-up)	Empieza la construcción y la prueba con los módulos de los niveles más bajos de la estructura del programa. Dado que los módulos se integran de abajo hacia arriba, el proceso requerido de los módulos subordinados a un nivel dado siempre están disponibles y se elimina la necesidad de resguardos.	Se crean primero los componentes de más bajo nivel (E, F) y se crean componentes conductores para simular a los componentes que los llaman. A continuación se desarrollan los componentes de más alto nivel (B, C, D) y se prueban. Por último dichos componentes se combinan con el que los llama (A). Los componentes auxiliares son necesarios en raras ocasiones. Este tipo de enfoque permite un desarrollo más en paralelo que el enfoque de arriba abajo, pero presenta mayores dificultades a la hora de planificar y de gestionar.	Si, ya que como menciona la prueba de integración Incremental ascendente(Buttom-up) es el proceso requerido a través de módulos en este caso de interfaces, y en nuestra aplicación se requiere el uso de mucha interfaces.
Pruebas de integración	Incremental descendente (Top-down)	Se integran los módulos moviéndose hacia abajo por la jerarquía de control. Comenzando por el módulo principal, los módulos subordinados se van incorporando a la estructura bien, en forma primero en profundidad, que integra todos los módulos de un camino de control principal de la estructura, o primero en anchura, que incorpora todos los módulos directamente subordinados a cada nivel, moviéndose por la estructura de forma horizontal.	El primer componente que se desarrolla y prueba es el primero de la jerarquía (A). Los componentes de nivel más bajo se sustituyen por componentes auxiliares para simular a los componentes invocados. En este caso no son necesarios componentes conductores. Una de las ventajas de aplicar esta estrategia es que las interfaces entre los distintos componentes se prueban en una fase temprana y con frecuencia.	En este caso al mostrar alguna imágenes, ya que se mostrara un carrusel de imágenes, también al momento de mostrar mensajes al usuario.
Pruebas de sistema	Son pruebas de integración del sistema de información completo, y permiten probar el sistema en su conjunto y con otros sistemas con los que se relaciona para verificar que las especificaciones funcionales y técnicas se cumplen. Dan una visión muy similar a su comportamiento en el entorno de producción. Las pruebas de sistemas buscan discrepancias entre el programa y el objetivo o requerimiento, enfocándose en los errores hechos durante la transición del proceso al diseñarla especificación funcional.		Pruebas funcionales: Dirigidas a asegurar que el sistema de información realiza correctamente todas las funciones que se han detallado en las especificaciones dadas por el usuario del sistema. Pruebas de comunicaciones:Determinan que las interfaces entre los componentes del sistema funcionan adecuadamente, tanto a través de dispositivos remotos, como locales. Asimismo, se han de probar las interfaces hombre/máquina. Pruebas de rendimiento:Consisten en determinar que los tiempos de respuesta están dentro de los intervalos establecidos en las especificaciones del sistema. Pruebas de volumen: Consisten en examinar el funcionamiento del sistema cuando está trabajando con grandes volúmenes de datos, simulando las cargas de trabajo esperadas. Pruebas de sobrecarga: Consisten en comprobar el funcionamiento del sistema en el umbral límite de los recursos, sometiéndole a cargas masivas. El objetivo es establecer los puntos extremos en los cuales el sistema empieza a operar por debajo de los requisitos establecidos. Pruebas de disponibilidad de datos: Consisten en demostrar que el sistema puede recuperarse ante fallos, tanto de equipo físico como lógico, sin comprometer la integridad de los datos. Pruebas de facilidad de uso:Consisten en comprobar la adaptabilidad del sistema a las necesidades de los usuarios, tanto para asegurar que se acomoda a su modo habitual de trabajo, como para determinar las facilidades que aporta al introducir datos en el sistema y obtener los resultados. Pruebas de operación: Consisten en comprobar la correcta implementación de los procedimientos de operación, incluyendo la planificación y control de trabajos, arranque y rearranque del sistema, etc. Pruebas de entorno: Consisten en verificar las interacciones del sistema con otros sistemas dentro del mismo entorno. Pruebas de seguridad: Consisten en verificar los mecanismos de control de acceso al sistema para evitar alteraciones indebidas en los datos.	En este caso las pruebas de sistema, son útiles, ya que permite probar el sistema así como también verificar que las especificaciones funcionales y técnicas se cumplan correctamente.
Pruebas de aceptación	Son definidas por el usuario del sistema y preparadas por el equipo de desarrollo, aunque la ejecución y aprobación final corresponden al usuario.		Con base a la prueba de aceptación, estas pruebas van dirigidas a comprobar que el sistema cumple los requisitos de funcionamiento esperado, recogidos en el catálogo de requisitos y en los criterios de aceptación del sistema de información, y conseguir así la aceptación final del sistema por parte del usuario.	Es útil, ya que esta prueba pretender comprobar que el sistema cumpla con los requerimientos de funcionalidad de la aplicación.
Pruebas de instalación	Las pruebas de instalación tienen como finalidad verificar y validar que el sistema se instala apropiadamente en cada cliente, bajo las siguientes condiciones: · Instalaciones nuevas, nuevas máquinas a las que nunca se les ha instalado el sistema. · Actualizar máquinas previamente instaladas con el sistema. · Instalar versiones viejas en máquinas previamente instaladas con el sistema		· Diseñar sripts para validar las condiciones de la máquina a instalar. · Realizar la instalación	Es útil, ya que la prueba de instalación tiene como finalidad que el sistema se instale correctamente.

Diferencias entre Error, Defecto y Falla

Pruebas de Software

Niveles de Prueba del Software

En un proceso de pruebas formal, suelen confundirse con mucha facilidad, los niveles de pruebas con los tipos de prueba,  y a pesar de que se encuentren íntimamente relacionadas, tienen connotaciones diferentes en el proceso. Para entender un poco más, vamos a partir del hecho de que las pruebas pueden ejecutarse en cualquier punto del proceso de desarrollo de software,  y es aquí donde los niveles de prueba nos permiten entender con claridad los diferentes puntos o etapas en donde pueden ejecutarse ciertos tipos de prueba.  Por lo anterior, es común  que algunas personas se refieran a los niveles de pruebas o intenten clasificarlos como: pruebas de desarrollador, pruebas funcionales y pruebas de usuario final. Sin embargo, la terminología apropiada para referirse a los diferentes niveles corresponde a  la siguientes cuatro (4) clasificaciones  que son: pruebas unitarias, pruebas de integración, pruebas de sistema y pruebas de aceptación. En  cada uno de estos niveles de prueba, se podrán ejecutar diferentes tipos de prueba tales como: pruebas funcionales, no funcionales, de arquitectura  y asociadas el cambio de los productos.

A continuación una breve descripción de cada nivel de prueba:

Pruebas Unitarias o de Componente: este tipo de pruebas son ejecutadas normalmente por el equipo de desarrollo, básicamente consisten en la ejecución de actividades que le permitan verificar al desarrollador que los componentes unitarios están codificados bajo condiciones de robustez, esto es,  soportando el ingreso de datos erróneos o inesperados y demostrando así la capacidad de tratar  errores de manera controlada.

Pruebas de Integración: este tipo de pruebas son ejecutas por el equipo de desarrollo y consisten en la comprobación de que elementos del software que interactúan entre sí, funcionan de manera correcta.

Pruebas de Sistema: este tipo de pruebas deben ser ejecutadas idealmente por un equipo de pruebas ajeno al equipo de desarrollo, una buena práctica en este punto corresponde a la tercerización de esta responsabilidad. La obligación de este equipo, consiste en  la ejecución de actividades de prueba en donde se debe verificar que la funcionalidad total de un sistema fue implementada de acuerdo a los documentos de especificación definidos en el proyecto. Los casos de prueba a diseñar en este nivel de pruebas,  deben cubrir los aspectos funcionales y no funcionales del sistema.

Pruebas de Aceptación: Independientemente de que se haya tercerizado el proceso de pruebas y así la firma responsable de estas actividades haya emitido un certificado de calidad sobre el sistema objeto de prueba, es indispensable,  que el cliente designe a personal que haga parte de los procesos de negocio para la ejecución de pruebas de aceptación, es incluso recomendable, que los usuarios finales que participen en este proceso, sean independientes al personal que apoyó el proceso de desarrollo. Cuando las pruebas de aceptación son ejecutadas en instalaciones o ambientes proporcionados por la firma desarrolladora se les denominan pruebas Alpha, cuando son ejecutadas desde la infraestructura del cliente se les denomina pruebas Beta.