Comienza Ya. Es Gratis
ó regístrate con tu dirección de correo electrónico
Rocket clouds
PRUEBAS DE SOFTWARE por Mind Map: PRUEBAS DE SOFTWARE

1. Las redundancias traen consigo una pérdida o desaprovechamiento de tiempo por lo que hay que intentar ejecutar las pruebas más adecuadas a cada situación y lo más rápido posible. Es importante encontrar los errores que más impacto puedan tener sobre el producto lo más rápido posible. Aunque sea aconsejable no desaprovechar el tiempo, no hay que olvidarse de la planificación, preparación de las pruebas, y de prestar atención a todos los detalles. No abandonar las estrategias previamente establecidas ante la primera señal de problemas o retrasos. Es decir, en un intento de ahorrar tiempo, se debe tener cuidado de no cometer errores que tendrán como consecuencias invertir más tiempo del que se intenta ahorrar.

2. Evitar redundancia

3. Reducir costes

3.1. Para reducir costes se debería prestar especial atención a la adquisición de elementos que puedan ayudar a la ejecución de pruebas, del tipo de herramientas para la ejecución de pruebas o entornos de pruebas. Habría que cerciorarse de que realmente fueran necesarias y de que existe el tiempo y las habilidades suficientes para emplearlas de manera ventajosa. También, es aconsejable evaluar las herramientas antes de comprarlas y ser capaz de justificar estos gastos frente al análisis de costos-beneficios

4. Validación y Verificación en el desarrollo de software

4.1. El propósito o función del sistema. El nivel de confianza necesario depende de lo crítico que sea el software para una organización. - Las expectativas del usuario. Actualmente, es menos aceptable entregar sistemas no fiables, por lo que las compañías deben invertir más esfuerzo en llevar a cabo las actividades de verificación y validación. - Entorno de mercado actual. Cuando un sistema se comercializa, los vendedores del sistema deben tener en cuenta los sistemas competidores, el precio que sus clientes están dispuestos a pagar por el sistema y los plazos requeridos para entregar dicho sistema. Cuando una compañía tiene pocos competidores, puede decidir

5. Tipos de pruebas

5.1. Pruebas de caja negra En este tipo de prueba, tan sólo, podemos probar dando distintos valores a las entradas. Los datos de prueba se escogerán atendiendo a las especificaciones del problema, sin importar los detalles internos del programa, a fin de verificar que el programa corra bien. Este tipo de prueba se centra en los requisitos funcionales del software y permite obtener entradas que prueben todos los flujos de una funcionalidad (casos de uso).

5.2. Pruebas manuales Una prueba manual es una descripción de los pasos de prueba que realiza un evaluador (usuario experto). Las pruebas manuales se utilizan en aquellas situaciones donde otros tipos de prueba, como las pruebas unitarias o las pruebas Web, serían demasiado difíciles de realizar o su creación y ejecución sería demasiado laboriosa

5.3. Pruebas automáticas A diferencia de las pruebas manuales, para este tipo de pruebas, se usa un determinado software para sistematizarlas y obtener los resultados de las mismas. Por ejemplo, verificar un método de ordenación

5.4. Pruebas unitarias Se aplican a un componente del software. Podemos considerar como componente (elemento indivisible) a una función, una clase, una librería, etc.

5.5. Pruebas de integración Consiste en construir el sistema a partir de los distintos componentes y probarlo con todos integrados. Estas pruebas deben realizarse progresivamente. El foco de atención es el diseño y la construcción de la arquitectura de software.

5.6. Pruebas de aceptación Son las únicas pruebas que son realizadas por los usuarios expertos, todas las anteriores las lleva a cabo el equipo de desarrollo. Consiste en comprobar si el producto está listo para ser implantado para el uso operativo en el entorno del usuario. Podemos distinguir entre dos tipos de pruebas; en ambas existe retroalimentación por parte del usuario experto: - Pruebas alfa: las realiza el usuario en presencia de personal de desarrollo del proyecto haciendo uso de una máquina preparada para las pruebas. - Pruebas beta: las realiza el usuario después de que el equipo de desarrollo les entregue una versión casi definitiva del producto

6. Diseño de casos de pruebas

6.1. Definir escenarios. Consiste en identificar todos los escenarios (caminos) a probar de un caso de uso: flujo básico, sub flujos y flujos alternativos

7. ADMINISTRACIÓN DE PRUEBAS

7.1. Estrategia de pruebas Existen distintas estrategias de pruebas, y dependiendo de su alineamiento con el objetivo de las pruebas y con los propios proyectos, estas estrategias pueden tener éxito o fallar. Otro punto a tener en cuenta es que no tiene por qué elegirse una sola estrategia. Puede utilizarse una estrategia de manera dominante y utilizar otras de complemento. Algunos autores como Krutchen, Pressman, Pfleger, Cardoso y Sommerville afirman que el proceso de ejecución de pruebas debe ser considerado durante todo el ciclo de vida de un proyecto, para así obtener un producto de alta calidad. Su éxito dependerá del seguimiento de una Estrategia de Prueba adecuada.

8. Roles y Responsabilidades

8.1. En RUP se definen los siguientes roles: - Administrador de pruebas - Analista de pruebas - Diseñador de pruebas - Ejecutor de pruebas

8.2. Administrador de pruebas Es el responsable del éxito total de la prueba. Involucra calidad y aprobación de la prueba, recurso de planeación, dirección, y solución a de los problemas que impiden el éxito de la prueba

8.3. El Plan de Pruebas, contiene la definición de las metas y objetivos a probar dentro del alcance de cada iteración del proyecto. Proporciona el marco de trabajo en el que el equipo llevará a cabo la prueba dentro de el horario coordinado. - El Resumen de Resultados de Pruebas, organiza y presenta un análisis resumen de los resultados de las pruebas y las medidas clave para revisar y definir estas, típicamente por los Stakeholders claves. Además, puede contener una declaración general de calidad relativa, puede mantener las recomendaciones de las pruebas que se realizaran a futuro. - La Lista de los Problemas, proporciona una manera de registrar para el Administrador del Proyecto los: problemas, excepciones, anomalías, u otras tareas incompletas que requieren atención que relaciona a la dirección del proyecto. - Cambios de Requerimientos. Se proponen cambios a los artefactos de desarrollo a través de Cambios de requerimientos (CR). Se usan los Cambios de Requerimientos para documentar los problemas, las mejoras solicitadas y cualquier otro tipo de solicitud para un cambio en el producto. El beneficio de CR es que proporcionan un registro de decisiones, debido a su proceso de valoración, asegura los impactos del cambio que puedan darse en el proyecto

9. Técnicas de pruebas

9.1. Técnicas de pruebas dinámicas Las técnicas de pruebas dinámicas ejecutan el software. Para ello introducen una serie de valores de entrada, y examinan la salida comparándola con los resultados esperados

9.2. Basadas en la especificación Son conocidas como técnicas de pruebas de caja negra o conducidas por entradas/salidas, porque tratan el software como una caja negra con entradas y salidas, pero no tienen conocimiento de cómo está estructurado el programa o componente dentro de la caja. Esencialmente, el técnico de pruebas se concentra en qué hace el software y no en cómo lo hace. Las técnicas basadas en especificaciones obtienen los casos de prueba directamente de las especificaciones o de otros tipos de artefactos que contengan lo que el sistema debería hacer

10. Herramientas de pruebas

10.1. Mediante la utilización de herramientas se puede conseguir reproducir cierto trabajo previamente realizado, obteniendo resultados consistentes. Esta característica es especialmente útil para confirmar que un defecto se ha arreglado, o para introducir datos de entrada a pruebas. Los principales beneficios que aporta el uso de herramientas como medio para llevar a cabo el proceso de pruebas son: - Reducir el trabajo repetitivo - Mejorar la consistencia - Facilitar las evaluaciones objetivas - Facilitar el acceso a información relacionada con pruebas