2.2 Pruebas de Software

Son los procesos que permiten verificar y revelar la calidad de un producto software.

Las pruebas de software se integran dentro de las diferentes fases del Ciclo del software dentro de la Ingeniería de software. Así se ejecuta un programa y mediante técnicas experimentales se trata de descubrir que errores tiene.

Para determinar el nivel de calidad se deben efectuar unas medidas o pruebas que permitan comprobar el grado de cumplimiento respecto de las especificaciones iniciales del sistema.

Objetivos
– Encontrar defectos en el software
– Una prueba tiene éxito si descubre un defecto
– Una prueba fracasa si hay defectos pero no los descubre

La prueba de software es el proceso de ejecutar el software de manera controlada. Y usualmente se usa en conjunto con los términos verificación y validación.

Pruebas de Verificación
– Ver si cumple las especificaciones de diseño
Pruebas de Validación
– Ver si cumple los requisitos del análisis

Tipos de Pruebas

Pruebas de unidad
Es una forma de probar el correcto funcionamiento de un módulo de código. Esto sirve para asegurar que cada uno de los módulos funcione correctamente por separado. Luego, con las Pruebas de Integración, se podrá asegurar el correcto funcionamiento del sistema o subsistema en cuestión.
La idea es escribir casos de prueba para cada función no trivial o método en el módulo de forma que cada caso sea independiente del resto.
Características
• Automatizable: no debería requerirse una intervención manual. Esto es especialmente útil para integración continúa.
• Completas: deben cubrir la mayor cantidad de código.
• Repetibles o Reutilizables: no se deben crear pruebas que sólo puedan ser ejecutadas una sola vez. También es útil para integración continua.
• Independientes: la ejecución de una prueba no debe afectar a la ejecución de otra.
• Profesionales: las pruebas deben ser consideradas igual que el código, con la misma profesionalidad, documentación, etc.
Ventajas
• Fomentan el cambio: Las pruebas unitarias facilitan que el programador cambie el código para mejorar su estructura (lo que se ha dado en llamar refactorización), puesto que permiten hacer pruebas sobre los cambios y así asegurarse de que los nuevos cambios no han introducido errores.
• Simplifica la integración: Puesto que permiten llegar a la fase de integración con un grado alto de seguridad de que el código está funcionando correctamente. De esta manera se facilitan las pruebas de integración.
• Documenta el código: Las propias pruebas son documentación del código puesto que ahí se puede ver cómo utilizarlo.
• Separación de la interfaz y la implementación: Dado que la única interacción entre los casos de prueba y las unidades bajo prueba son las interfaces de estas últimas, se puede cambiar cualquiera de los dos sin afectar al otro, a veces usando objetos mock (mock object) para simular el comportamiento de objetos complejos.
• Los errores están más acotados y son más fáciles de localizar: dado que tenemos pruebas unitarias que pueden desenmascararlos.
Limitaciones
Es importante darse cuenta de que las pruebas unitarias no descubrirán todos los errores del código. Por definición, sólo prueban las unidades por sí solas. Por lo tanto, no descubrirán errores de integración, problemas de rendimiento y otros problemas que afectan a todo el sistema en su conjunto. Además, puede no ser trivial anticipar todos los casos especiales de entradas que puede recibir en realidad la unidad de programa bajo estudio. Las pruebas unitarias sólo son efectivas si se usan en conjunto con otras pruebas de software.

Pruebas de integración
Son aquellas que se realizan en el ámbito del desarrollo de software una vez que se han aprobado las pruebas unitarias. Únicamente se refieren a la prueba o pruebas de todos los elementos unitarios que componen un proceso, hecha en conjunto, de una sola vez.
Consiste en realizar pruebas para verificar que un gran conjunto de partes de software funcionan juntos.
Las pruebas de integración (algunas veces llamadas integración y testeo I&t) es la fase del testeo de software en la cual módulos individuales de software son combinados y testeados como un grupo. Son las pruebas posteriores a las pruebas unitarias y preceden el testeo de sistema.

Pruebas de validación
Son el proceso de revisión que el sistema de software producido cumple con las especificaciones y que cumple su cometido. Es normalmente una parte del proceso de pruebas de software de un proyecto, que también utiliza técnicas tales como evaluaciones, inspecciones, y tutoriales. La validación es el proceso de comprobar lo que se ha especificado es lo que el usuario realmente quería.
Se trata de evaluar el sistema o parte de este durante o al final del desarrollo para determinar si satisface los requisitos iniciales. La pregunta a realizarse es: ¿Es esto lo que el cliente quiere?.

Enfoques a la verificación
• Dinámica de verificación, también conocido como ensayos o experimentación.
• Estática de verificación, también conocido como análisis.
Tipos
• Pruebas de aceptación: desarrolladas por el cliente.
• Pruebas alfa realizadas por el usuario con el desarrollador como observador en un entorno controlado (simulación de un entorno de producción).
• Pruebas beta: realizadas por el usuario en su entorno de trabajo y sin observadores.
Características
Comprobar que se satisfacen los requisitos:
• Se usan la mismas técnicas, pero con otro objetivo.
• No hay programas de prueba, sino sólo el código final de la aplicación.
• Se prueba el programa completo.
• Uno o varios casos de prueba por cada requisito o caso de uso especificado.
• Se prueba también rendimiento, capacidad, etc. (y no sólo resultados correctos).
• Pruebas alfa (desarrolladores) y beta (usuarios).

Pruebas de sistema
Cualquier pieza de software completo, desarrollado o adquirido, puede verse como un sistema que debe probarse, ya sea para decidir acerca de su aceptación, para analizar defectos globales o para estudiar aspectos específicos de su comportamiento, tales como seguridad o rendimiento.
• recuperación
• seguridad
• resistencia
• rendimiento

Técnicas de pruebas
Ayudan a definir conjuntos de casos de prueba aplicando un cierto criterio
Los casos de prueba quedarán determinados por los valores a asignar a las entradas en su ejecución

Técnicas de caja blanca
• Criterios basados en el contenido de los módulos
• El criterio de selección de casos de
- prueba buscará cierta cobertura
- caminos independientes
- valores de las condiciones
- bucles dentro y fuera de sus límites operacionales
- estructuras de datos
- los errores se esconden en los rincones y se acumulan en las fronteras

Técnicas de caja negra
• Criterios basados en las interfaces y las especificaciones de los módulos
• Permiten detectar
- funcionamiento incorrecto o incompleto
- errores interface
- errores accesos estructuras de datos externas
- problemas de rendimiento
- errores de inicio y terminación
Cobertura
- valores representativos de conjuntos de datos
- fronteras, valores o combinaciones de valores conflictivos
- capacidad de proceso

Pruebas de regresión
Intentan descubrir las causas de nuevos errores (bugs), carencias de funcionalidad, o divergencias funcionales con respecto al comportamiento esperado del software, inducidos por cambios recientemente realizados en partes de la aplicación que anteriormente al citado cambio no eran propensas a este tipo de error. Esto implica que el error tratado se reproduce como consecuencia inesperada del citado cambio en el programa.

Tipos de regresión
• Clasificación de ámbito
- Local: los cambios introducen nuevos errores.
- Desenmascarada: los cambios revelan errores previos.
• Remota: Los cambios vinculan alguna otra parte del programa (módulo) e introducen errores en ella.
• Clasificación temporal
- Nueva característica: los cambios realizados con respecto a nuevas funcionalidades en la versión introducen errores en otras novedades en la misma versión del software.
- Característica preexistente: los cambios realizados con respecto a nuevas funcionalidades introducen errores en funcionalidad existente de previas versiones.
Usos
Pueden usarse no solo para probar la corrección de un programa, sino a menudo usarse para rastrear la calidad de su salida. Por ejemplo en el diseño de un compilador, las pruebas de regresión deben rastrear el tamaño del código, tiempo de simulación, y el tiempo de compilación de las suites de prueba. Cuando quiera que aparece un nuevo build, el proceso de regresión aparece.

La importancia de la detección oportuna de errores en el sistema

En la cadena de valor del desarrollo de un software específico, el proceso de prueba es clave a la hora de detectar errores o fallas. Conceptos como estabilidad, escalabilidad, eficiencia y seguridad se relacionan a la calidad de un producto bien desarrollado. Las aplicaciones de software han crecido en complejidad y tamaño, y por consiguiente también en costos. Hoy en día es crucial verificar y evaluar la calidad de lo construido de modo de minimizar el costo de su reparación. Mientras antes se detecte una falla, más barato es su correción.

2.1 Evaluacion y seleccion de software

Perspectiva general del problema

Por lo general cuando una empresa busca implementar una nueva solución de software nombra a un equipo de accionistas, evalúa procesos internos, determina las necesidades y luego envía la solicitud de información (RFI) y finalmente, la solicitud de propuestas (RFP) a una lista de selección de vendedores. Con frecuencia se invita a los vendedores a demostrar sus soluciones, y de ahí comienzan las ofertas y se toma una decisión. Infortunadamente, a lo largo de este proceso, los equipos de selección enfrentan un gran número de dificultadas en sus proyectos.

Primero, debido a la gran apreciación de la funcionalidad del producto y a los requisitos tecnológicos del producto, se descartan otros criterios que pueden determinar el éxito o el fracaso de un nuevo sistema. Por ejemplo, la estrategia corporativa del vendedor, las capacidades de soporte y servicio, la viabilidad financiera, las medidas cualitativas y de costos con respecto al encaje del proceso, a la facilidad de uso /navegación, a la retroalimentación del mercado, a la diligencia del vendedor, y a la flexibilidad del producto son importantes, pero son muy difíciles de medir.

En segundo lugar, cuando el equipo de selección organiza y clasifica los criterios necesarios y mide la funcionalidad del producto, por lo general crea un RFI, utilizando hojas de cálculo. A pesar de los mejores esfuerzos de los diseñadores de hojas de cálculo, la elección entre proporcionar flexibilidad y facilidad de uso para los evaluadores y los clientes, mientras se mantiene la integridad al proteger campos puede llevar a intercambios riesgosos en el diseño de las hojas de cálculo. Las hojas de cálculo no se pueden ajustar ni analizar de forma efectiva para proporcionar resultados razonables. También tienen fama de difundir errores de cálculo: con frecuencia se esconden las fórmulas, lo que causa errores cuando se mueven las celdas o por accidente se sobrescriben ciertos campos. Los enlaces quebrantados entre hojas de cálculo pueden invalidar los resultados. Son comunes los errores simples, como copiar o volver a escribir una fórmula en una celda diferente. Además, la naturaleza del modelo de las hojas de cálculo hace que sea más fácil para las compañías dañinas tomar ventaja. Esto conlleva a retrasar el proceso, a volver a entrenar al personal del cliente, y a añadir seguridad en el proceso de auditoría de datos, al igual que a debilitar la relación entre los consultores y el cliente.

Tercero, debido a que los equipos de selección de software por lo general no tienen mucho acceso a la calidad, a información imparcial, sus metodologías de evaluación están encaminadas a tener defectos serios desde el principio. Como resultado, les es difícil o imposible justificar la razón detrás de la selección de la solución de un vendedor en particular. La mayoría de los que toman las decisiones confían en su “intuición”, en mandatos ejecutivos, o en compilaciones tediosas de hojas de cálculo que fallan al discernir entre las mejores soluciones, por lo tanto la mayoría de las evaluaciones tecnológicas empresariales caen en costos acumulados mucho mayores del presupuesto esperado. Cuando finalmente son seleccionadas, la mayoría de estas implementaciones de software fallan en cubrir las expectativas funcionales, el rendimiento del capital invertido (ROI) y el costo total de propiedad (TCO).

Para resumir, durante el proceso de selección del software empresarial, los clientes prospecto por lo general luchan con los siguientes problemas:

• Equipos de selección de proyecto que no tienen una forma efectiva para determinar sus requisitos comerciales y no pueden identificar bien al vendedor y las preguntas del producto (criterios) de todos los accionistas.
• Reunir todos los criterios necesarios de los accionistas consume mucho tiempo y se convierte en un problema en la primera etapa del proyecto. Existe una presión de que el proyecto se lleve a cabo y que tenga una implementación rápida ya que los retrasos significan pérdida de ingresos y pérdidas de aprovisionamiento del cliente.
• Cuando se seleccionan los criterios y se le presentan al vendedor, el equipo del proyecto con frecuencia no tiene la habilidad de priorizar de forma efectiva los distintos criterios relativos a sus requisitos comerciales de soporte. Como resultado, las prioridades se derivan de agendas políticas internas en lugar de las verdaderas necesidades de la compañía. Sin tener una herramienta de soporte de decisión profesional para organizar y mantener las prioridades, y para conducir simulaciones y análisis del desempeño de los vendedores o para cubrir los propósitos una vez que se cambian las prioridades, las "necesidades" de un departamento pueden contribuir sin razón en gran volumen a ciertos criterios en la decisión
• Los equipos de proyecto no tienen la capacidad de obtener datos objetivos en las soluciones disponibles del vendedor. Las demostraciones del vendedor con frecuencia son ganchos de mercadotecnia que fallan en enfocarse en la habilidad de la solución para satisfacer las necesidades de los usuario y con frecuencia son engañosos. Infortunadamente, la mayoría de los equipos de proyecto no tienen la capacidad de separar los hechos de la publicidad, en especial debido a que la selección estratégica de tecnología es el primer intento de su clase, o el primero en un largo periodo dentro de una organización específica. El problema está claro: tener la información inadecuada (como se identificó antes) para la fase de selección significa la falta de capacidad de planificar y ejecutar adecuadamente la implementación.

Asigne prioridades y compare resultados

Para empatar de forma efectiva las necesidades del usuario con las soluciones de los vendedores, los usuarios asignan prioridades de tal manera que le dan mayor importancia a los criterios que consideran más importantes. Los promedios ponderados (WA), son técnicas utilizadas comúnmente en proyectos de selección ya que son fáciles de calcular. Sólo parece estimar el desempeño de forma razonablemente bien, debido a que no indica qué patrón es el ideal para las necesidades de una empresa, ni tampoco identifica o mide estos patrones como un riesgo inherente a la elección. WA falla al discernir las verdaderas capacidades de un vendedor, ya que utiliza un número para describir un patrón de criterios, sin compensar ningún desequilibrio. Sin embargo, un índice compuesto de promedio ponderado (WACI) es el cálculo que toma en cuenta la constancia de las valoraciones a lo largo de todos los criterios, además del promedio ponderado de los vendedores. Un índice compuesto se puede utilizar para entender mejor los datos que el WA obscurece WACI combina el índice compuesto y el WA y mide el desempeño general de un vendedor contra la unión de patrones. Los usuarios establecen sus necesidades utilizando una escala. Por ejemplo, la escala en el sistema de evaluación de TEC es:

Crítico (10+ una condición umbral para el valor mínimo aceptado)
Obligatorio (10)
Muy importante (8)
Importante (6)
Recomendable (4)
No es importante (2)
No es necesario (2)

Los números en paréntesis representan el valor numérico equivalente (que se utiliza en los cálculos) de los artículos listados. Las prioridades necesitan agruparse de forma adecuada dentro de una jerarquía para poder determinar mejor sus ponderaciones permitiéndoles a los usuarios y de lo general a lo particular en los detalles de cada módulo y cada sub-módulo. Uno de los aspectos más importantes del proceso de evaluación del software es la gestión. Dado el gran gasto y el impacto que un sistema empresarial puede representar para una organización, es muy importante que haya un gran soporte para justificar la selección de un vendedor en particular, y para ilustrar que el proceso de selección involucró un análisis comercial riguroso. La información valiosa que se ha recopilado durante este proceso está disponible en un número de reportes que se pueden imprimir y entregar a la gestión superior y a las personas que toman las decisiones. Como resultado, el equipo de selección tendrá información cuantificable para justificar la selección. Por consiguiente, el equipo de selección puede validar aún más su selección. Las organizaciones se benefician del software empresarial sólo cuando toman la selección adecuada. Al utilizar criterios relevantes y precisos en la funcionalidad del software empresarial, las organizaciones están mejor informadas acerca de sus opciones. Al evitar los cálculos de las hojas de cálculo, el equipo de selección puede hacer evaluaciones precisas acerca de qué tan bien puede el vendedor satisfacer las necesidades de la organización, que asegurará que se seleccione el software empresarial más adecuado.

Los servicios de selección de software incluyen:

Análisis de necesidades
• Definición de procesos de negocios
• Información requerida
• Reportes

Evaluación y selección de software
• Definición de criterios de selección
• Búsqueda de soluciones

2.1 Evaluación y selección de Software para el desarrollo del proyecto.

Para los compradores IT corporativos es aterrorizante discernir las verdaderas capacidades, fuerzas y debilidades de una serie de aplicación empresarial dada. Los equipos de proyecto del
comprador están inundados con información de mercadotecnia de vendedores que luchan por diferenciarse a sí mismos.

Evaluar y seleccionar un software empresarial es un proceso complejo caracterizado tanto por el
impresionante potencial como por riesgos dramáticos. Cuando se ejecuta de manera correcta, este proceso y sus resultados pueden dar beneficios excepcionales. Si no se ejecuta de forma adecuada, los resultados pueden ser desde decepcionantes hasta devastadores. Las organizaciones que seleccionan el hardware, middleware y software equivocado aprenderán a la mala que el dinero que han perdido es el resultado de la información inadecuada y de un mal proceso de evaluación del vendedor.