martes, 19 de febrero de 2013

Principios - ¿Por qué es necesario el proceso de pruebas? (K2 - entender, explicar , razonar)

Objetivos:

  1. Definir por medio de ejemplos el concepto o forma en la que un defecto de software puede dañar a una persona, al medio ambiente o a una empresa (K2).
  2. Distinguir entre la causa raíz de un defecto y sus consecuencias (K2).
  3. Explicar mediante ejemplos por qué es necesario el proceso de pruebas (K2).
  4. Describir por qué el proceso de pruebas forma parte de los procedimientos de garantía de calidad y dar ejemplos de cómo las pruebas contribuyen a una mayor calidad (K2).
  5. Explicar y comparar mediante ejemplos los términos de error, defecto, falta, fallo y lo correspondientes términos de error y bug (K2).
Términos usados en este artículo: BUG, DEFECTO, ERROR, FALLO, FALTA, ERROR, CALIDAD, RIESGO.

  • Contexto de los Sistemas de Software (K1).
Si miramos a nuestro al rededor, podemos constatar que los sistemas de software forman parte integrante de nuestras vidas, desde aplicaciones comerciales (cajeros automáticos) hasta los productos de consumo (fabricación de autos). Sin embargo no siempre un software funciona según lo previsto. Por lo tanto, un software que no funciona correctamente puede dar lugar a muchos problemas, desde pérdida de dinero, tiempo o renombre, daños personales hasta la muerte.
  • Causas de los defectos de software (K2).
Como vemos en la imagen, una persona puede cometer un error (IEEE 610 "Acción humana que produce un resultado incorrecto") que a su vez puede producir un defecto (IEEE 610 "Desperfecto en un componente o sistema que puede causar que el componente o sistema falle en desempeñar las funciones requeridas") en el código de programa o en un documento. Al ejecutar un defecto en el código, el sistema puede no hacer lo que debiera (especificación de requerimientos), lo que provocaría un fallo (IEEE 610 , "Manifestación física o funcional de un defecto encontrado durante la ejecución"). Algunos defectos de software, sistemas o documentos pueden dar lugar a fallos pero, no todos los defectos lo hacen.

Los defectos suceden porque las personas suelen equivocarse y porque existen factores como presión, códigos complejos, infraestructuras complejas, tecnologías cambiantes y/o muchas interacciones del sistema.

Los fallos también pueden venir provocados por condiciones medioambientales. así por ejemplo, la radiación, el magnetismo, los campos electrónicos y la contaminación pueden provocar faltas en sistemas o afectar a la ejecución de un software al modificar las condiciones del hadware.

Preguntas para el examen:

1 When what is visible to end-users is a deviation from the specific or expected behavior,
this is called:
a) an error
b) a fault
c) a failure
d) a defect
e) a mistake

1.- Cuando lo que es visible para los usuarios finales es una desviación de la conducta específicada o comportamiento esperado ,
se llama:

a).- Un error
b).- Un fallo  (Error-->Defecto-->Fallo)
c).- Un fracaso
d).- Un defecto
e).- Un error

La respuesta correcta es la b) porque, Un error, lleva a un defecto en el cpódigo, y cuando en ejecutado produce un fallo

  • Función del proceso de pruebas en el desarrollo, mantenimiento y operaciones de software (K2).
El hecho de someter los sistemas y la documentación a pruebas rigurosas puede ayudar a reducir el riesgo de complicaciones  durante las operaciones y contribuir a la calidad del sistema de software, siempre que los defectos detectados se corrijan antes de que el sistema se ponga a disposición para su uso operativo.

Las pruebas se software también pueden servir para cumplir requisitos contractuales o legales, o estándares específicos del sector.
  1. Mejora de la calidad de un producto software.
  2. Reducción del riesgo de detectar errores.
  3. Satisfacer compromisos.
  • El costo en los defectos.
  1. La eliminación de los defectos es incremental en el tiempo.
  2. Al detectar errores en etapas tempranas permite la corrección de los mismos a costos reducidos.
Pregunta de examen:

36 The cost of fixing a fault:
a) Is not important
b) Increases as we move the product towards live use-->OK
c) Decreases as we move the product towards live use
d) Is more expensive if found in requirements than functional design
e) Can never be determined

36 El costo de arreglar un fallo:
a) no es importante
b ) Aumenta a medida que avanzamos hacia el uso del producto en vivo-->OK
c ) disminuye a medida que nos movemos hacia el uso del producto en vivo
d ) ¿Es más caro si se encuentra en los requisitos que el diseño funcional
e) no se puede determinar
  • Proceso de pruebas y calidad (K2).
Gracias a las pruebas, se puede medir la calidad  de un software ((ISO/IEC 9126, "La totalidad de la funcionalidad y prestaciones de un producto de software que contribuye con su capacidad de satisfacer necesidades explicitas o implícitas") en términos de los defectos detectados por lo que respecta a requisitos y características funcionales y no funcionales (tales como fiabilidad, usabilidad , eficiencia, mantenibilidad y portabilidad).

¿Qué significa Fiabilidad?

Las pruebas de software (IEEE 610 , "Programas de ordenador, procedimiento y posiblemente documentación y datos pertenecientes a la operación de un sistema basado en un oredenador") pueden aportar fiabilidad a la calidad de software cuando se detectan pocos o ningún defecto. Siempre y cuando nuestro plan de prueba ha considerado todos los escenarios y casos cubriendo los requerimientos establecidos por el Cliente. No encontrar errores o defectos puede significar que nuestro plan de prueba no es correcto.

Pasar una prueba diseñada correctamente reduce el nivel general de riesgo de un sistema. Sin embargo, si las pruebas detectan defectos, su corrección incrementará la calidad del sistema de software.

La experiencias de proyectos anteriores permiten entender las causas raíz de los defectos detectados en el presente.  Permiten mejorar procesos, los que a su vez debería evitar que se repitieran en dichos defectos y, en consecuencia , mejoraría la calidad (IEEE std 610, "Grado en el cual un componente, sistema o proceso satisface requisitos especificados y/o necesidades y expectativas del usuario/cliente")de sistemas futuros (garantía de calidad).

Las pruebas deben estar integradas como una actividad más del proceso de garantía de calidad (es decir, deben estar al mismo nivel que el desarrollo de estándares, formación y análisis de defectos)

¿Cuáles son los atributos funcionales de calidad?
  1. Corrección, que permite que la funcionalidad satisfaga los atributos / capacidades requeridas.
  2. Completitud, que permite que la funcionalidad satisfaga todos los requisitos.
¿Que significa Funcionalidad según ISO/IEC 9126?

Funcionalidad, se define como un conjunto de atributos que atañen a la existencia de un conjunto de funciones y sus propiedades específicas. Estas funciones son las que satisfacen las necesidades implícitas y establecidas. Estas características del software puede ser desglosada en varias características:
  1. Adecuación, capacidad del software de proporcionar un conjunto apropiado de funciones para tareas específicas y objetivos del usuario. 
  2. Exactitud, capacidad del software para proporcionar resultados correctos o que necesitan un determinado grado de precisión.
  3. Interoperabilidad, capacidad del software de interaccionar con uno o más sistemas especificados.
  4. Seguridad, capacidad del software de proteger la información y los datos.
  5. Adherencia a normas, capacidad del software relacionada con el grado de conformidad con estándares, convenciones o regulaciones existentes.
¿Cuáles son los atributos no funcionales de calidad?

Fiabilidad, conjunto de atributos que atañen a la capacidad del software para mantener su nivle de prestación bajo condiciones durante un tiempo establecido. Se descomponen en las siguientes características:
  1. Madurez.- capacidad del software para evitar fallos como resultados de defectos del software,
  2. Tolerancia a Fallos.- capacidad del software para mantener un nivel especificado de rendimiento en casos de fallos del software.
  3. Capacidad de recuperación.- capacidad para restablecer el nivel de rendimiento y de recuperación de datos afectados directamente en el caso de un fallo.
  4. Adherencia a normas, capacidad del software relacionada con el grado de conformidad con estándares, convenciones o regulaciones existentes en leyes o prescripciones similares.
Usabilidad, capacidad del producto software de ser entendido, aprendido, usado y atraer al usuario, cuando es utilizado bajo ciertas condiciones específicas. se descompone en:

  1. Fácil comprensión.- la capacidad del software que permite al usuario si el producto es aceptable y cómo puede ser usado para  tareas particulares y determinadas condiciones de uso.
  2. Fácil aprendizaje.- capacidad del producto software que permite al usuario aprender la aplicación de software.
  3. Operatividad.- capacidad del producto de software que permite al usuario controlar y usar la aplicación de software.
  4. Software atractivo.- capacidad del producto de software de ser atractivo al usuario.
  5. Adherencia a normas.- capacidad del software relacionada con el grado de conformidad con estándares, convenciones o regulaciones existentes en leyes o prescripciones similares.
Eficiencia. Capacidad del producto software para proporcionar un rendimiento apropiado
relacionado con el total de recursos utilizados bajo condiciones establecidas. Se subdivide en las
siguientes características:
  1. Comportamiento frente al tiempo. -capacidad del producto software para proporcionar una respuesta y un tiempo de procesamiento apropiados al desarrollar sus funciones bajo condiciones establecidas.
  2. Uso de recursos.- capacidad del producto software para utilizar un apropiado número de recursos y tiempo de ejecución cuando el software desarrolla sus funciones bajo condiciones establecidas
  3. Adherencia a normas.- capacidad del software relacionada con el grado de conformidad con estándares, convenciones o regulaciones existentes en leyes o prescripciones similares.
Mantenibilidad. Capacidad del producto software para ser modificado. Se descompone en las
siguientes características:
  1. Facilidad de análisis.-  capacidad del producto software para diagnosticar deficiencias o causas de fallos en el software 
  2. Capacidad para cambios.- capacidad del producto software que permite la ejecución de una modificación específica en ella misma.
  3. Estabilidad.- capacidad del producto de software para evitar defectos no esperados debidos a modificaciones en el mismo.
  4. Facilidades para pruebas.- capacidad del producto software que permite al software que ha sido modificado ser evaluado.
  5. Adherencia a normas.- capacidad del software relacionada con el grado de conformidad con estándares, convenciones o regulaciones existentes en leyes o prescripciones similares.
Portabilidad. Capacidad del producto software para ser transferido de un entorno a otro. El entorno se interpreta tanto a nivel software y hardware, como aquel entorno relacionado con la organización. Se divide en:
  1. Adaptabilidad.- capacidad del producto software para ser adaptado a diferentes entornos especificados sin aplicar acciones alejadas de aquellas que el propio software proporcione.
  2. Facilidad de instalación.- capacidad del producto software para ser instalado en un entorno específico 
  3. Coexistencia.- capacidad del producto software de coexistir con otros programas independientes en un entorno común y compartiendo recursos también comunes.
  4. Facilidad de reemplazo.- capacidad del producto software de ser utilizado en lugar de otro producto software específico para el mismo propósito que éste y en un entorno similar.
  5. Adherencia a normas. capacidad del software relacionada con el grado de conformidad con estándares, convenciones o regulaciones existentes en leyes o prescripciones similares.
  • Tipos de Aseguramiento de la Calidad (QA).
Existen actividades constructivas cuyo fin es prevenir defectos. Una manera es aplicando métodos apropiados de ingeniería de software como scrum, spring iterativos, demos, etc.
El QA Constructivo, está compuesto por dos actividades, una parte Organizacional  y otra Técnica.

  • En la organización se deben realizar tareas como, generar guías, usar estándares  llevar listas de comprobación como planes de prueba, considerar las reglas de proceso y normas y requisitos legales.
  • Técnicamente se deben aplicar métodos, herramientas, lenguajes, listas /planillas y entorno de desarrollo integrado (IDE). 
Y otras actividades como las analíticas que permite detectar defectos a través de pruebas conducentes a la corrección de defectos y prevención de fallos, incrementando de esta forma la calidad del software.
El QA Analítico, está compuesto por dos importantes ramas que son Qa analítico dinámico (caja negra y caja blanca) y Qa analítico estático.

  • El análisis dinámicos se divide en tres partes: Caja Negra que está compuesto de Partición de equivalencia, análisis de valores límites, pruebas de transición de estado, tablas de decisión y pruebas de casos de uso.
  • También es bueno considerar las técnicas adquiridas por la propia experiencia.
  • El análisis de Caja Blanca se deben considerar las actividades de cobertura de sentencia, cobertura de rama, cobertura de condición y cobertura de camino.
  • En el análisis Estático se considerar las revisiones/ revisiones guiadas, análisis de flujo de control, análisis de flujo de datos y métricas de compilador/analizador. 



  • ¿Con cuantas pruebas es suficientes? (K2).
Para determinar la cantidad de pruebas a realizar se debe tener en cuenta tanto los niveles de riesgos, incluyendo los riesgos técnicos, de seguridad y comerciales, como las limitaciones del proyecto, tales como el tiempo y el presupuesto. 

Las pruebas permiten pronosticar decisiones como un lanzamiento de un software o de un sistema probado, pasar a la siguiente fase de desarrollo o para su entrega final a los clientes.

Pregunta de examen:

1. Which of the following is true?
a. Testing is the same as quality assurance
b. Testing is a part of quality assurance-->OK
c. Testing is not a part of quality assurance
d. Testing is same as debugging

1. ¿Cuál de las siguientes afirmaciones es cierta ?
a. La prueba es la misma que la garantía de calidad
b. Las pruebas o testing es parte del aseguramiento de calidad.-->OK
c. Las pruebas no son parte del aseguramiento de calidad
d. La prueba es igual que la depuración

No hay comentarios:

Publicar un comentario