Pruebas de Software, Gestion de Proyectos.

exploratory testing : se puede ejecutar en cualquier etapa del proceso de desarrollo, responsabilidad para gestionar el tiempo. mietras mas conoce el testing el producto mejores pruebas. 

pruebas caja blanca : ligado al codigo fuente. prueba funciones, clases, modulos etc.

                dentro de ella estan :

               

                - pruebas de flujo de control

                - pruebas de flujo de datos

                - pruebas branch testing

               

pruebas caja negra : no es su finalidad conocer como funciona el sw. SE QUE ES LO QUE HACE PERO SIN IMPORTAR COMO LO HACE.

pruebas unitarias : forma de probar que un modulo funciona correctamente por separado.

                deben ser :

                               automatizable .- no debe requerir intervencion manual

                               completas .- cubrir la mayor cantidad de codigo

                               reutilizables .- integracion continua

                               independientes .- la ejecucion de una prueba no afecta a otra

               

                ventajas :

                               fomentan el cambio .- el programador refactoriza su codigo contantemiente para mejorar su estructura

                               simplifica la integracion .- permite tener un alto grado de seguridad que el codigo funciona correctamente.                                              

pruebas de integracion : pruebas en conjunto, realizadas al termino de las pruebas unitarias.

Pruebas funcionales : pruebas para el aseguramiento de la tarea específica que originó la tarea.

Análisis de requisitos (planificacion) reuniones con el personal responsable para obtener toda la información posible sobre el funcionamiento del sw a evaluar, requisitos de pruebas y elaborar un plan de pruebas.

Diseño de plan de pruebas ( preparación ) En esta fase se identifica, acuerda y especifican los atributos y características de calidad que se van a probar. El objetivo es diseñar las pruebas para que tengan la mayor probabilidad de encontrar defectos con la mínima cantidad de esfuerzo y tiempo. Serán pruebas que se llevarán a cabo a través de la interfaz gráfica del software (GUI). Es decir, demostrar que las funciones del software son operativas, que la entrada se acepta de forma adecuada y que se produce una salida correcta, así como que la integridad de la información externa se mantiene

Ejecución En esta fase se ejecutarán los casos de prueba anteriormente diseñados de forma manual. Hay que s              eguir al detalle el guión establecido dejando cierta libertad al tester para detectar situaciones anómalas no contempladas. Las baterías de pruebas serán ejecutadas como mínimo una vez antes del paso a producción, independientemente de las ejecuciones anteriores. Los casos de prueba fallados se reportarán a los desarrolladores para su corrección hasta que su resultado sea correcto.

Gestión de incidencias. Cuando al realizar la acción de un step el resultado obtenido no es el esperado, habrá que abrir o reportar una incidencia para que el equipo de desarrollo tenga constancia del error. La redacción debe ser clara con todo tipo de detalle

Desarrollo en espiral

El desarrollo en espiral es un modelo de ciclo de vida del software definido por primera vez por Barry Boehm en 1986,¹ utilizado generalmente en la Ingeniería de software. Las actividades de este modelo se conforman en una espiral, en la que cada bucle oiteración representa un conjunto de actividades. Las actividades no están fijadas a ninguna prioridad, sino que las siguientes se eligen en función del análisis de riesgo, comenzando por el bucle interior.

ejemplo : RUP

Desarrollo en cascada

En Ingeniería de software el desarrollo en cascada, también llamado modelo en cascada (denominado así por la posición de las fases en el desarrollo de esta, que parecen caer en cascada “por gravedad” hacia las siguientes fases), es el enfoque metodológico que ordena rigurosamente las etapas del proceso para el desarrollo de software, de tal forma que el inicio de cada etapa debe esperar a la finalización de la etapa anterior.¹ Al final de cada etapa, el modelo está diseñado para llevar a cabo una revisión final, que se encarga de determinar si el proyecto está listo para avanzar a la siguiente fase. Este modelo fue el primero en originarse y es la base de todos los demás modelos de ciclo de vida.

La versión original fue propuesta por Winston W. Royce en 1970 y posteriormente revisada por Barry Boehm en 1980 e Ian Sommerville en 1985.²

Un ejemplo de una metodología de desarrollo en cascada es:

1. Análisis de requisitos.
2. Diseño del Sistema.
3. Diseño del Programa.
4. Codificación.
5. Pruebas.
6. Implantación.
7. Mantenimiento.

De esta forma, cualquier error de diseño detectado en la etapa de prueba conduce necesariamente al rediseño y nueva programación del código afectado, aumentando los costos del desarrollo. La palabra cascada sugiere, mediante la metáfora de la fuerza de la gravedad, el esfuerzo necesario para introducir un cambio en las fases más avanzadas de un proyecto.

Si bien ha sido ampliamente criticado desde el ámbito académico y la industria^{[cita requerida]}, sigue siendo el paradigma más seguido al día de hoy.

ejemplo : PMBOK

Desarrollo ágil de software

(Redirigido desde «Proceso ágil»)

El desarrollo ágil de software refiere a métodos de ingeniería del software basados en el desarrollo iterativo e incremental, donde los requisitos y soluciones evolucionan mediante la colaboración de grupos auto organizados y multidisciplinarios. Existen muchos métodos de desarrollo ágil; la mayoría minimiza riesgos desarrollando software en lapsos cortos. El software desarrollado en una unidad de tiempo es llamado una iteración, la cual debe durar de una a cuatro semanas. Cada iteración del ciclo de vida incluye: planificación, análisis de requisitos, diseño, codificación, revisión y documentación. Una iteración no debe agregar demasiada funcionalidad para justificar el lanzamiento del producto al mercado, sino que la meta es tener una «demo» (sin errores) al final de cada iteración. Al final de cada iteración el equipo vuelve a evaluar las prioridades del proyecto.

Los métodos ágiles enfatizan las comunicaciones cara a cara en vez de la documentación. La mayoría de los equipos ágiles están localizados en una simple oficina abierta, a veces llamadas "plataformas de lanzamiento" (bullpen en inglés). La oficina debe incluir revisores, escritores de documentación y ayuda, diseñadores de iteración y directores de proyecto. Los métodos ágiles también enfatizan que el software funcional es la primera medida del progreso. Combinado con la preferencia por las comunicaciones cara a cara, generalmente los métodos ágiles son criticados y tratados como "indisciplinados" por la falta de documentación técnica.

ejemplo : Programacion XP , SCRUM

PATRON DE SCRUM