1. Definicion
1.1. Las pruebas son básicamente un conjunto de actividades dentro del desarrollo de software. Dependiendo del tipo de pruebas, estas actividades podrán ser implementadas en cualquier momento de dicho proceso de desarrollo.
1.2. El objetivo de las pruebas es presentar información sobre la calidad del producto a las personas responsables de éste. Las pruebas de calidad presentan los siguientes objetivos: encontrar defectos o bugs, aumentar la confianza en el nivel de calidad, facilitar información para la toma de decisiones, evitar la aparición de defectos.
2. Principios
2.1. Principio 1: Las pruebas revelan la presencia de bugs, no la ausencia de ellos.
2.1.1. Probar reduce la probabilidad de que existan bugs pero nunca se puede asegurar que no quede ninguno oculto.Además, cada tipo de pruebas que realicemos (de sistema, de integración, añadir auditorías de código…) son más efectivas para detectar un tipo de bug.
2.2. Principio 2: Es imposible probarlo todo.
2.2.1. El flujo de control de un sistema software no trivial como los que acostumbramos a utilizar en el día a día contiene miles de decisiones.Estas decisiones se pueden combinar entre ellas para dar lugar a una infinidad de posibles caminos. De entrada, probar todos los caminos es un problema inabordable.
2.3. Principio 3: Cuanto antes se comience a probar…mejor.
2.3.1. Corregir un bug con una revisión en la fase de captura de requisitos o en una prueba unitaria tiene un coste mucho menor a lo que costará corregir este bug cuando se detecte en una prueba de sistema, o peor aún, en una prueba de aceptación por el cliente.
2.4. Principio 4: Las aglomeración de defectos. ¡Los bugs siempre van en pandilla!
2.4.1. Entender esto es muy importante para plantear una buena estrategia de pruebas: los bugs suelen ir en grupo. Se concentran en determinados puntos de un sistema software, no manteniendo una distribución uniforme a lo largo del mismo.
2.5. Principio 5: La paradoja del pesticida.
2.5.1. O la necesidad de ajustar continuamente tu plan de pruebas… porque según este principio un plan de pruebas va perdiendo efectividad conforme se ejecuta sucesivas veces. Con lo que cada vez tenderá a encontrar menos bugs… ¡lo que no significa que no hayan!
2.6. Principio 6: Las pruebas se deben adaptar a necesidades específicas.
2.6.1. Esto viene a enlazar con lo que he comentado antes. Si tu producto se centra en el ámbito de la seguridad deberás adaptar tus casos de prueba para intentar forzar situaciones o posibles escenarios no amistosos.
2.7. Principio 7: La falacia de la ausencia de errores.
2.7.1. Para terminar, nos encontramos con la satisfacción del usuario y con el hecho de que los usuarios elijan tu software para resolver sus necesidades.Que hayas corregido muchos bugs no significa que finalmente tu software sea un éxito.
3. Entornos Especializados
3.1. ¿En que consisten?
3.1.1. Estas pruebas validan que la configuración y el entorno en los que se ejecutarán los casos de prueba presenten características de hardware y software similares al ambiente de producción en el que residirá la aplicación que se está probando.
3.2. Tipo de Pruebas que se realizan segun el Entorno
3.2.1. Entorno Grafico
3.2.1.1. El uso de estas pruebas es como su nombre lo indica, probar la interfaz para ver si realmente está cumpliendo la función que desarrollará.
3.2.1.1.1. Esta prueba se aplica: Ventanas, Menus emergentes y pruebas con el raton y Entrada de datos.
3.2.2. Pruebas de Arquitectura Cliente/Servidor
3.2.2.1. Se utilizan para medir o probar el rendimiento y la robustez del sistema.
3.2.2.1.1. Estas pruebas se aplican en el: Servidor, Base de Datos y Pruebas de Comunicaciones de Redes.
4. Tipos
4.1. Pruebas de Contenido:
4.1.1. Estas pruebas como su nombre lo indica, buscan verificar que el contenido del sistema sea coherente y consistente a la vez. También se debe de verificar que las palabras usadas para transmitir una idea al usuario sean las adecuadas y que la idea transmitida sea la misma.
4.2. Pruebas de Caja Negra:
4.2.1. El sistema de pruebas de caja negra no considera la codificación dentro de sus parámetros a evaluar, es decir, que no están basadas en el conocimiento del diseño interno del programa. Estas pruebas se enfocan en los requerimientos establecidos y en la funcionalidad del sistema.
4.3. Pruebas de Caja Blanca:
4.3.1. Al contrario de las pruebas de caja negra, éstas se basan en el conocimiento de la lógica interna del código del sistema. Las pruebas contemplan los distintos caminos que se pueden generar gracias a las estructuras condicionales, a los distintos estados del mismo, etc.
4.4. Pruebas de Integración:
4.4.1. Las pruebas de integración bus can probar la combinación de las distintas partes de la aplicación para determinar si funcionan correctamente en conjunto.
4.5. Pruebas del sistema:
4.5.1. Son similares a las pruebas de caja negra, solo que éstas buscan probar al sistema como un t odo. Están basadas en los requerimientos generales y abarca todas las partes combinadas del sistema.
4.6. Pruebas de Funcionalidad:
4.6.1. Este tipo de pruebas examina si el sistema cubre sus necesidades de funcionamiento, acorde a las especificaciones de diseño. En ellas se debe verificar si el sistema lleva a cabo corr ectamente todas las func iones requeridas, se debe verificar la validación de los datos y se deben realizar prueba s de comportamiento ante distintos escenarios.
4.7. Pruebas de Usabilidad:
4.7.1. Las pruebas realizadas en este rubro tienen la finalidad de verificar que tan fácil de usar es un sistem a. Las pruebas de usabilidad deben verificar aprendizaje (qué tan fácil es para los usuarios realizar tareas básicas la primera vez que tienen contacto con el sistema), eficiencia (una vez que los usuarios han aprendido algo del sistema, que tan rápido pueden llevar a ca bo las tareas), manejo de errores (cuántos errores comete el usuario, que tan graves s on éstos y que tan fácil es para el usuario recuperarse de ellos) y grado de satisfacción ( que tan satisfactorio es usar el sistema).