1. Análisis
2. Diseño
3. Codificación
4. Estructura aplicada al desarrollo del software
4.1. Norma Iso 9126
5. Definición de necesidades
5.1. Obtener los requisitos y/o analisis
5.1.1. DOCUMENTO: Especificación funcional
6. Pruebas
6.1. ¿Porqué son importantes las pruebas?
6.1.1. Es necesario siempre evaluar los riesgos, un software mal probado puede probar muertes, daños irreparables en personas, y diseños de programas costos
6.1.2. Se debe siempre generar una adecuada planeación de las pruebas contemplando los riesgos para cada caso de prueba
6.2. Objetivo
6.2.1. El objetivo de las pruebas es aportar calidad al producto que se está desarrollando
6.2.2. Según
6.2.2.1. Según ISO 9000: Es un conjunto de normas sobre calidad y gestión de calidad, que corresponde al grado en el que un conjunto de características inherentes cumple con los requisitos
6.2.2.2. Según ISO 25000: Es un conjunto de normas, que tiene por objetivo la creación de un marco de trabajo común para evaluar la calidad de un producto de software
6.2.2.3. Armand V. Feigenbaum [13]: Quién diseño el concepto de control total de la calidad del software y lo define como “Satisfacción de las expectativas del cliente”.
6.3. Conceptos relevantes
6.3.1. Error
6.3.1.1. Es provocado por la acción humana
6.3.2. Defecto
6.3.2.1. Provocado por un error de implementación
6.3.3. Fallo
6.3.3.1. Problema que se presenta en el software, al momento de probar dichos casos, y que los legados o componentes estén fallando.
6.4. TÉCNICAS DE CAJA NEGRA
6.4.1. ejecutar el software sin considerar ningún detalle sobre como fue implementado.
6.4.2. Esta estrategia se basa en seleccionar los casos de prueba analizando la especificación o modelo del programa, en lugar de su implementación.
6.4.3. calcula los casos de prueba partiendo del documento de requerimientos
6.5. TÉCNICAS DE CAJA BLANCA
6.5.1. El testing esta guiado fundamentalmente por la existencia de sentencias tipo if, case, while, etc.
6.5.2. Los casos de prueba quedaran generados en la finalizacion del codigo fuente
6.6. Proceso general del testing
6.6.1. Testing de componentes
6.6.1.1. testing de unidad, testing de modulos,
6.6.2. testing de integración
6.6.2.1. Testing de subsistemas, testing del sistemas
6.6.3. Testing de usuario
6.6.3.1. Testing de aceptación
6.7. CLASIFICACIÓN
6.7.1. PRUEBAS UNITARIAS
6.7.1.1. caja blanca, pruebas estructural ligada al codigo
6.7.1.2. pruebas de flujo de control
6.7.1.3. pruebas de flujo de datos
6.7.1.4. pruebas de bifurcación branch testing
6.7.1.5. pruebas de caminos basicos
6.7.2. PRUEBAS DE INTEGRACIÓN
6.7.2.1. Técnica, Bing Bang
6.7.2.2. Técnica, Top Down
6.7.2.3. Técnica Bottom Up
6.7.2.4. Técnica midle Out
6.7.2.5. Estrategias combinadas
6.7.3. FUNCIONALES, CAJA NEGRA
6.7.3.1. Partición de equivalencia
6.7.3.2. Analisis de valores limite
6.7.3.3. Prueba de trasición de estado
6.7.3.4. Tablas de decisión
6.7.3.5. Pruebas de casos de uso
6.7.3.6. NO FUNCIONALES
6.7.3.6.1. usabilidad, facilidad de uso, Operacion entorno, seguridad, almacenamiento, documentación, recuperación comunicaciones, rendimiento, estres, soak testing, sping testing
6.7.3.7. • Se entiende como las funcionalidades del Sistema cómo “lo que el sistema hace”, por lo cual las funcionalidades pueden estar descritas en las especificaciones de requerimientos, especificaciones funcionales, casos de uso e inclusive no estar documentadas, (Graham, 2008)
6.7.4. PRUEBAS DE ACEPTACIÓN
6.7.4.1. Alfa, Beta, pruebas de regresión
6.8. RETESTING
6.8.1. Analizar el error - analizar la solución, Reparar el error, retestear,
6.8.2. ejecuta un defecto con los mismos datos y el mismo entorno con diferentes entradas con nueva compilación.
6.9. Prueba de pareto
6.9.1. • 80% de sus ganancias provienen del 20% de sus clientes. • 80% de sus quejas provienen del 20% de sus clientes. • 80% de sus ganancias provienen del 20% del tiempo que pasan. • 80% de sus ventas provienen del 20% de sus productos. • El 80% de sus ventas se realizan en un 20% de su personal de ventas.
6.9.1.1. El 80 porciento de los fallos de un software es generado por un 20% del código de dicho software, mientras que el otro 80 porciento genera un 20% de fallos”
6.10. Estructurales
6.10.1. Las pruebas estructurales permiten medir la totalidad de las pruebas mediante la evaluación de tipo estructura. En estas pruebas se aplican las técnicas de diseño de caja blanca y el ISTQB utiliza el término ‘prueba estructural’ para las pruebas de caja blanca
7. Mantenimiento y despliegue
7.1. DESPLIEGUE: cuando ha sido probado en su totalidad
7.1.1. Entorno de producción
7.2. ENTRENAMIENTO y soporte
7.2.1. Fundamental instruir a futuros usuarios
7.3. MANTENIMIENTO: o mejora
7.3.1. Puede requerir mas tiempo que el desarrollo inicial
7.3.2. Incorporar codigo que no se ajusta el diseño original
7.3.3. Incorporar codigo que no se ajusta el diseño original
7.3.4. Ampliar la funcionalidad para el cliente
7.3.5. Si los costos de mantenimiento son elevados
7.3.5.1. Rediseñar el sistema
7.3.5.2. Poder contener los costes de mantenimiento
8. Validación
8.1. ¿Estamos construyendo el producto correcto? oValidación significa corroborar que el programa satisface las expectativas del usuario, “La debería realizar el usuario teniendo en cuenta lo que el espera del programa y el programa en sí
8.2. VERIFICACIÓN
8.2.1. ¿Estamos construyendo el producto correctamente? oLa verificación consiste en corroborar que el programa respeta su especificación, es desarrollada por ingenieros teniendo en cuenta un modelo del programa y el programa en sí
9. CALIDAD DEL PRODUCTO DE SOFTWARE
9.1. Adecuación funcional
9.1.1. Completitud Funcional *Corrección Funcional, * Pertinencia funcional.
9.2. Eficiencia de desempeño
9.2.1. Comportamiento temporal, Utilización de los recursos, Capcidad,
9.3. Compatibilidad
9.3.1. Coexixtencia, interoperabilidad
9.4. Usabilidad
9.4.1. Inteligibilidad, aprendizaje, operabilidad, protección frente a errores de usuario, estetica, accesibilidad.
9.5. Fiabilidad
9.5.1. Madurez, disponibilidad, tolerancia a fallos, capacidad de recuperación.
9.6. Seguridad
9.6.1. confidencialidad, integridad, no repudio, autenticidad, reponsabilidad,
9.7. Mantenibilidad
9.7.1. Modularidad, reusabilidad, Analizabilidad, capcidad de ser modificado, capacidad de ser probado,
9.8. Portabilidad
9.8.1. Adaptabilidad. fácil Instalación, capacidad de ser reemplazado.
10. TÉCNICAS DE PRUEBAS
10.1. TÉCNICAS DE PRUEBAS ESTÁTICAS
10.1.1. detectan las causas de los defectos.
10.1.2. No ejecutan la aplicación
10.1.3. No ejecutan código, pero si un análisis a el
10.2. ANÁLISIS ESTÁTICO
10.2.1. Detectar defectos en el código fuente del software y en los modelos de software,
10.2.2. Permiten identificar defectos que no se encuentran fácilmente mediante las técnicas dinámicas.
10.3. REVISIONES
10.3.1. permiten la detección y corrección temprana de posibles defectos así como la reducción de tiempo y dinero invertido en el desarrollo y pruebas de software.
10.3.2. -Defectos de requisitos. -Desviaciones de los estándares. -Defectos de diseño. -Especificaciones de interfaz incorrectas.
10.3.3. REVISIÓN INFORMAL
10.3.3.1. Normalmente este tipo de revisiones se llevan a cabo por parte del líder técnico de los diseños y el código.
10.3.4. REVISIÓN GUIADA
10.3.4.1. Son llevadas acabo por el autor de un documento del proyecto y el objetivo principal es encontrar defectos y establecer un entendimiento común
10.3.5. REVISIÓN TÉCNICA
10.3.5.1. Es un proceso documentado donde se realizará un informe de revisión.
10.3.6. INSPECCIÓN
10.3.6.1. Es la técnica de revisión más formal. Se basa en el examen visual de documentos para detectar defectos como puede ser el no cumplimiento de estándares de desarrollo.
10.3.7. PERSONAS INVOLUCRADAS EN LAS REVISIONES: Revisor, escriba, Moderador.
10.3.8. WALKTHOUGHT
10.3.8.1. Es una técnica de revisión de producto, conducido por uno o más personas con el mismo nivel de conocimiento.
10.4. TÉCNICAS DE PRUEBAS DINÁMICAS
10.4.1. Es una técnica de revisión de producto, conducido por uno o más personas con el mismo nivel de conocimiento.
10.4.2. TÉCNICAS DE CAJA BLANCA
10.4.2.1. Es una técnica de diseño de casos de prueba que usa la estructura de control para obtener los casos de prueba.
10.4.2.2. -Garantizan que todas las rutas del código se revisan al menos una vez. -Revisan las condiciones lógicas. -Revisan estructuras de datos.
10.4.2.3. PRUEBAS DE RUTA BÁSICA
10.4.2.3.1. es un método de prueba de caja blanca, que inicialmente propuso Tom McCabe.
10.4.2.3.2. se basa en diseñar un caso de prueba por cada camino independiente del programa
10.4.2.3.3. Notación de grafo de flujo
10.4.3. TÉCNICAS DE CAJA NEGRA
10.4.3.1. También llamadas pruebas de comportamiento, son las que utilizan el análisis de la especificación, tanto funcional como no funcional, sin tener en cuenta la estructura interna del programa para diseñar los casos de prueba.
10.4.3.2. A partir de esta técnica se encuentran funciones incorrectas o faltantes, errores de inicialización y terminación,
11. Clasificación de pruebas en el proceso de pruebas
11.1. PRUEBAS UNITARIAS
11.1.1. CAJA BLANCA
11.1.1.1. Las pruebas de caja blanca (también conocidas como pruebas de caja de cristal o pruebas estructurales) se centran en los detalles procedimentales del software, por lo que su diseño está fuertemente ligado al código fuente.
11.1.2. PRUEBAS DE FLUJO DE CONTROL
11.1.2.1. En estas pruebas se quiere encontrar errores en la parte lógica del programa, utilizando las condiciones simples operador-relación o con condiciones complejas.
11.1.2.2. Pasos: Representación del programa como grafo de flujo. Cálculo de la complejidad ciclomática. Determinación de un conjunto básico de caminos linealmente independientes. Derivación de los casos de prueba.
11.1.3. PRUEBAS DE FLUJO DE DATOS
11.1.3.1. Por medio de esta herramienta se hace la selección mas adecuada del flujo de datos, para llegar a una resolución correcta, esto para probar las variables y definiciones en el programa.
11.1.4. PRUEBAS DE BIFURCACIÓN
11.1.4.1. Como lo dice su titulo, es ligado a una bifurcación o para bucles. Con ella podemos definir si algún bucle esta correctamente implementado y si las lineas de código donde exista una condición es la mejor opción o si debería ser cambiada. Pruebas de caminos básicos:
11.1.5. PRUEBAS DE CAMINOS BASICOS
11.1.5.1. Esta prueba lo que demuestra es el conjunto de pasos base del programa, lo que quiere lograr es que cada sentencia de código se ejecute mínimo una vez.
11.2. PRUEBSA DE INTEGRACIÓN
11.2.1. TÉCNICA BING BANG
11.2.1.1. Pruebas tipo big-bang son un tipo de prueba de integración en el que los elementos software, elementos hardware ó ambos son combinados de forma simultánea en un componente o un sistema global en lugar de hacerlo por fases.
11.2.2. TÉCNICA TOP DOWN
11.2.2.1. se formula un resumen del sistema, sin especificar detalles. Cada parte del sistema se refina diseñando con mayor detalle. Cada parte nueva es entonces redefinida, cada vez con mayor detalle, hasta que la especificación completa es lo suficientemente detallada para validar el modelo.
11.2.3. TÉCNICA BOTTOM UP
11.2.3.1. Las estrategias basadas en el flujo de información "bottom-up" se antojan potencialmente necesarias y suficientes porque se basan en el conocimiento de todas las variables que pueden afectar los elementos del sistema.
11.2.4. TÉCNICA MIDDLE OUT
11.2.5. ESTRATEGIAS COMBINADAS
11.2.5.1. A menudo es útil aplicar las estrategias anteriores conjuntamente. De este modo, se desarrollan partes del sistema con un enfoque “top-down“, mientras que los componentes más críticos en el nivel más bajo se desarrollan siguiendo un enfoque “bottom-up“. En este caso es necesaria una planificación cuidadosa y coordinada de modo que los componentes individuales se “encuentren” en el centro.
11.2.6. PRUEBAS FUNCIONALES
11.2.6.1. PARTICIÓN DE EQUIVALENCIA
11.2.6.1.1. Los datos de entrada y los resultados de salida se agrupan en clases diferentes, en las que todos los miembros de dicha clase están relacionados Cada una de estas clases es una partición de equivalencia en la que el programa se comporta de la misma forma para cada miembro de la clase Se supone que la prueba de un valor representativo de cada clase sea equivalente a la prueba de cualquier otro valor
11.2.6.2. VALORES LIMITE
11.2.6.2.1. Técnica que prueba la habilidad del programa para manejar datos que se encuentren en los limites acptables.
11.2.6.3. PRUEBAS DE TRANSICIÓN DE ESTADO
11.2.6.3.1. Pruebas de transición de estado es la técnica de diseño de pruebas de caja negra en la cual los casos de prueba son diseñados para ejecutar transiciones de estado válidas e inválidas.
11.2.6.4. TABLAS DE DECISION
11.2.6.4.1. Una tabla de decisiones es una entrada de lógica de reglas planificadas, en formato de tabla, que se compone de condiciones, representadas en las cabeceras de columna y fila, y acciones, representadas como puntos de intersección de los casos condicionales de la tabla. Las tablas de decisiones son especialmente idóneas para las reglas de negocio que tienen varias condiciones. Añadir otra condición es tan fácil como añadir otra fila o columna.
11.2.6.5. PRUEBAS DE CASOS DE USO
11.2.6.5.1. Pruebas de caso de uso es la técnica de diseño de prueba de caja negra en la que los casos de prueba están diseñados para ejecutar escenarios de usuario.
11.3. PRUEBAS DE ACEPTACIÓN
11.3.1. En ingeniería de software y pruebas de software, las pruebas de aceptación (User Acceptance Testing, UAT) pertenecen a las últimas etapas previas a la liberación en firme de versiones nuevas a fin de determinar si cumplen con las necesidades y/o requerimientos de las empresas y sus usuarios.1 Al finalizar las pruebas automatizadas, que garantizan los requisitos tecnológicos del diseño inicial, se pasa a las pruebas manuales.
11.3.2. ALFA
11.3.2.1. realizadas cuando el sistema está en desarrollo y cuyo objetivo es asegurar que lo que estamos desarrollando es probablemente correcto y útil para el cliente.
11.3.3. BETA
11.3.3.1. se realizan cuando el sistema está teóricamente correcto y pasa a ejecutarse en un entorno real. Es la fase siguiente a las pruebas Alpha. No importa lo bueno que sea nuestro proceso de desarrollo, siempre habrá fallos que no han sido descubiertos por los desarrolladores ni por el equipo de pruebas.
11.3.4. PRUEBAS DE REGRESIÓN
11.3.4.1. Se denominan pruebas de regresión a cualquier tipo de pruebas de software que intentan descubrir errores (bugs), carencias de funcionalidad, o divergencias funcionales con respecto al comportamiento esperado del software, causados por la realización de un cambio en el programa.