Código ético del testeador (K2 - entender, explicar , razonar)

Objetivos:

1. Entender, explicar y razonar cuales son los participantes en el proceso de software y sus responsabilidades.

Términos usados en este artículo: PÚBLICO, CLIENTE Y EMPLEADOR, PRODUCTO,CRITERIO,  JUICIO, GESTIÓN, PROFESIÓN, COMPAÑEROS, NIVEL INDIVIDUAL.

Código Ético.

El hecho de participar en el proceso de prueba de software da acceso a información confidencial y privilegiada. El establecimiento de un código ético es necesario, entre otras cosas, para garantizar que la información no se utiliza de manera indebida.

Reconociendo el código ético para ingenieros ACM e IEEE, se detallan los siguientes conceptos:

PÚBLICO.- Los probadores o testeadores certificados actuarán en coherencia con el interés de su cliente (usuarios finales) y empleadores. Y también conforme al interés público, por ejemplo en software relacionados con sistemas de seguridad como las tarjetas bancarias.

CLIENTE Y EMPLEADOR.- Los probadores de software certificados actuarán en el mejor de los intereses de su cliente y empleador (no filtración a internet información interna o privada del cliente o empleador), en coherencia con el interés público.

PRODUCTO.- Los probadores de software certificados garantizarán que los productos entregables que proporcionan (por lo que respecta a los productos y sistemas que prueban) se ajustan a los más altos estándares profesionales.

JUICIO.- Los probadores de software mantendrán su integridad e independencia en su juicio profesional. Esto quiere decir que se debe trabajar con entera transparencia tanto hacia el cliente o empleador como al equipo de trabajo. No permitir ocultar defectos o fallos.

CRITERIO.- Los probadores de software certificados mantendrán la integridad y la independencia en su criterio profesional.

GESTIÓN.-  Los  jefes y líderes de pruebas de software certificados suscribirán y fomentarán un enfoque ético en la gestión de las pruebas de software.

PROFESIÓN.- Los probadores de software certificados aumentarán la integridad y la reputación de la profesión en coherencia con el interés público.

COMPAÑERISMO.- Los probadores de software certificados serán equitativos y apoyarán a sus compañeros fomentando la cooperación con los desarrolladores de software.

NIVEL INDIVIDUAL O AUTO RETROALIMENTACION.- Los probadores de software certificados participarán en un aprendizaje constante a lo largo de la vida por lo que respecta a la práctica de su profesión y fomentarán la adopción de un enfoque ético en la práctica de su profesión.

La psicología de las pruebas (K2 - entender, explicar , razonar)

Objetivos:

1. Retener los factores psicológicos que influyen en el éxito de las pruebas (K1).
2. Constatar la mentalidad de un probador y la de un desarrollador (K2).

Términos usados en este artículo: PREDICCIÓN DE ERROR, INDEPENDENCIA.

Antecedentes.

La actitud que debe adoptarse durante la realización de las pruebas y la revisión difiere de la actitud que requiere el desarrollo del software. Si mantienen la actitud correcta, los desarrolladores pueden probar sus propios códigos. Sin embargo, normalmente esta responsabilidad se transfiere a un probador independiente con vistas a contribuir a centralizar los esfuerzos y obtener mayores beneficios, tales como una visión independiente de recursos formados y profesionales del ámbito de las pruebas. Las pruebas independientes pueden llevarse a cabo en cualquier nivel del proceso de pruebas.

 Su determinado nivel de independencia a menudo hace del probador la figura más efectiva a la hora de detectar defectos y fallos. No obstante, la independencia no constituye un sustituto del conocimiento, y los desarrolladores también pueden detectar muchos defectos y fallos. No obstante, la independencia no constituye un sustituto del conocimiento, y los desarrolladores también pueden detectar muchos defectos en su propio código de manera eficiente. Pueden establecerse varios niveles de independencia según se muestra a continuación de menor a mayor:

• Pruebas diseñadas por las mismas personas que escribieron el software probado (bajo nivel de independencia).
• Pruebas diseñadas por terceros (por ejempo, por miembros del equipo de desarrollo).
• Pruebas diseñadas por una persona procedente de otro grupo de organización (por ejemplo, un equipo de pruebas independiente) o especialista de pruebas (por ejemplo, especialista en pruebas de usabilidad o rendimiento).
• Pruebas diseñadas por personas de otra organización o empresa (es decir, externalización o certificación por parte de un organismo externo). 

Las personas y los proyectos se mueven por objetivos. Las personas tienden a ajustar sus planes a los objetivos establecidos por la dirección y demás personas interesadas, por ejemplo, para detectar errores o para confirmar que el software cumple sus objetivos. Por lo tanto es importante establecer claramente cuáles son los objetivos de las pruebas.

Identificar fallos durante las pruebas puede percibirse como criticas contra el producto y contra el autor. En consecuencia, el proceso de pruebas a menudo se considera una actividad destructiva, a pesar de que es muy constructiva para la gestión de los riesgos del producto. La búsqueda de fallos en un sistema requiere curiosidad, pesimismo profesional, ojo crítico, atención al detalle, buena comunicación con los compañeros de desarrollo y experiencia sobre la que basar la predicción de error. 

Para evitar malos entendidos al momento de reportar un error, se debe contar con la mejor manera de comunicar los defectos o fallos. La idea es dar a conocer estos defectos o fallos de una manera constructiva para el equipo de desarrollo (analistas, diseñadores y desarrolladores). Esta es la actitud que se debe tener  a lo largo de las revisiones y pruebas.

El testeador y el líder de pruebas deben disponer de buenas aptitudes interpersonales para comunicar  información objetiva sobre los defecto, el progreso y los riesgos de una manera constructiva. EL autor del software o del documento puede aprovechar la información sobre defectos para mejorar sus propias habilidades. El hecho de localizar y corregir defectos durante el proceso de pruebas ahorrará tiempo y dinero en el futuro y reducirá riesgos.

 Los problemas de comunicación pueden surgir, en particular, si los probadores se ven así mismos como mensajeros de malas noticias sobre defectos. Esta no es la mejor actitud que se debe adoptar, se debe tener presente (todo el equipo de trabajo) que mientra más defectos (de negocio, funcionales, cosméticos, etc.) encuentran nuestros partner de Qa, más sólido es el código. 

Por esto es importante que tanto el equipo de Desarrollos como el equipo Qa deben estar comprometidos con las estrategias a utilizar para llevar a cabo el control del proyecto. Hay un dicho chileno que dice "una mano lava la otra" es así como debemos actuar , comunicarnos y sentirnos comprometidos con el trabajo que realizamos, sentirnos un sólo equipo. 

Algunos tips para mejorar la comunicación entre Desarrolladores y QA.

• Empezar juntos en lugar de enfrentados - recordar a todo el mundo el objetivo común de conseguir sistemas de mejor calidad.
• Comunicar los hallazgos del producto de una manera neutral y centrada en los hechos, sin criticar a las personas que lo crearon, por ejemplo, redactando informes de incidencias objetivos y revisando las conclusiones.
• Confirmar que la otra persona ha entendido lo que usted ha dicho y viceversa.

Proceso básico de pruebas a lo largo del proceso de desarrollo de software (K1 , recordar, reconocer y retener)

Objetivos:

1. Retener las cinco actividades fundamentales y sus respectivas tareas desde la planificación hasta el cierre (K1).

Términos usados en este artículo: PRUEBAS DE CONFIRMACIÓN, REPETICIÓN DE PRUEBAS, CRITERIOS DE SALIDA, INCIDENCIA, PRUEBAS DE REGRESIÓN, BASE DE PRUEBA, CONDICIÓN DE PRUEBAS, DATOS DE PRUEBA, EJECUCIÓN DE PRUEBAS, REGISTRO DE PRUEBAS, PLAN DE PRUEBAS, PROCEDIMIENTO DE PRUEBAS, POLÍTICA DE PRUEBAS, JUEGO DE PRUEBA, INFORME RESUMEN DE PRUEBAS, PRODUCTO DE SOPORTE DE PRUEBA.

Antecedentes

La parte más visible del proceso de pruebas es la ejecución de prueba. No obstante, para ser efectivos y eficientes, los planes de pruebas también deben indicar el tiempo necesario para planificar las pruebas, diseñar los casos de prueba, preparar la ejecución y evaluar los resultados.

El proceso de pruebas básicos consta de las siguientes principales:

1. Planificación y Control. 
2. Análisis y diseño. 
3. Implementación y ejecución. 
4. Evaluación de los criterios de salida e informes. 
5. Actividades de cierre de pruebas.

A pesar de tener una secuencia lógica, las actividades del proceso pueden solaparse o realizarse a la vez. Normalmente es necesario adaptar estas actividades al contexto del sistema y del proyecto.

El proceso de pruebas incluye superposición y vuelta atrás (backtracking). Cada fase del proceso de pruebas tiene lugar de forma concurrente con las fases del proceso de desarrollo de software.

Planificación y Control de Pruebas (K1).


La planificación de pruebas es la actividad de definir los objetivos de las pruebas y la especificación de las actividades de pruebas con vistas a cumplir los objetivos y la misión establecidos.

• Determina el alcance de riegos ,
•  Identifica los objetivos y los criterios de salida,
• Determina el enfoque :técnicas de pruebas, coberturas de pruebas, equipo de pruebas,
• Implementa el método de pruebas / estrategia de pruebas.
• Adquirir /obtener y programar recursos requeridos por las pruebas , presupuesto de pruebas.

El control de pruebas es la actividad constante de comparar el progreso real con el plan previsto, e informar sobre el estado de las pruebas, incluyendo la existencia de desviaciones con respecto a lo que se había planificado. Implica la adopción de las medidas necesarias para cumplir la misión y los objetivos del proyecto. A efectos del control de pruebas, las actividades de pruebas deben monitorizarse a lo largo del proyecto. La planificación de pruebas tiene en cuenta el feedback de las actividades de control y seguimiento.
 
Análisis y diseño de pruebas (K1).

El análisis y el diseño de pruebas es la actividad durante la cual los objetivos de las pruebas generales se transportan en condiciones de prueba y casos de prueba tangibles.

La actividad de análisis y diseño de pruebas consta de las siguientes tareas principales:

Revisar la base de pruebas 1 ( especificación de requisitos,el nivel de integridad del software es decir; nivel de riesgo, informes de análisis de riesgos, arquitectura, el diseño y las especificaciones de interfaz).

• Evaluar las testabilidad de la base de prueba y de los objetos de prueba. 
• Identificar y priorizar las condiciones de prueba en base al análisis de los elementos de prueba, la especificación, el comportamiento y la estructura del software. 
• Diseñar y priorizar los casos de prueba de alto nivel. 
• Identificar los datos de prueba necesarios para soportar las condiciones de prueba y los casos de prueba. 
• Diseñar la configuración del entorno de pruebas e identificar cualquier infraestructura y herramientas necesarias. 
• Crear una trazabilidad bidireccional entre la base de pruebas y los casos de prueba.

Implementación y ejecución de pruebas (K1).

La implementación y ejecución de pruebas es la actividad en la que se especifican los procedimientos o guiones de prueba mediante la combinación de los casos de prueba en un orden determinado y la inclusión de cualquier otra información necesaria para la ejecución de las pruebas, se configura el entorno y se ejecutan las pruebas.

La implementación y ejecución de pruebas incluye las siguientes tareas principales:

• Finalizar , implementar y priorizar los casos de prueba (incluyendo la identificación de los datos de prueba). 
• Desarrollar y priorizar procedimientos de prueba, crear datos de prueba y, de manera opcional, preparar arneses de pruebas y redactar guiones de pruebas automatizados. 
• Crear juegos de pruebas a partir de los procedimientos de prueba para lograr una ejecución de pruebas eficiente. 
• Verificar que el entorno de pruebas ha sido correctamente configurado. 
• Verificar y actualizar una trazabilidad bidireccional entre la base de pruebas y los casos de prueba. 
• Ejecutar los procedimientos de prueba manualmente o recurriendo a herramientas de ejecución de pruebas, conforme a la secuencia prevista. 
• Registrar los resultados de la ejecución de las pruebas y registrar las identidades y las versiones del software probado, así como, las herramientas de prueba y los productos de soporte de pruebas. 
• Comparar los resultados reales con los resultados esperados. 
• Reportar las discrepancias en forma de incidencias y analizar con vistas a establecer sus causas (ejemplo, un defecto en el código o en los datos de pruebas especificados o en el documento de prueba, o un error en la forma en que se ha ejecutado la prueba). 
• Repetir las actividades de pruebas como resultado de una medida adoptada para cada discrepancia, por ejemplo, la repetición de una prueba que ha fallado anteriormente con vistas a confirmar que su corrección (pruebas de confirmación), la ejecución de una prueba corregida y/o la ejecución de pruebas con vistas a garantizar que los defectos no se han introducido en áreas no modificadas del software o que la subsanación del defecto no ha revelado la existencia de otros defectos (pruebas de regresión). 

Evaluación de los criterios de salida e informes (K1).

La evaluación de los criterios de salida es la actividad que evalúa la ejecución de pruebas contra los objetivos definidos. Esta evaluación debería hacerse para cada nivel de prueba.

Los criterios de de salida consta de las siguientes tareas principales:

1. Comprobar los registros de pruebas con los criterios de salida previstos en la planificaicón de la prueba. 
2. Evaluar si se requieren más pruebas o si deberían modificarse los criterios de salida especificados. 
3. Elaborar un resumen de las pruebas para las partes interesadas. 

Actividades de cierre de pruebas (K1).

Durante la fase de cierre de pruebas de un proceso se recopilan los datos e aquellas actividades de pruebas finalizadas con el objetivo de consolidar la experiencia, los productos de soporte de pruebas, los hechos y las cifras. Las actividades de cierre de pruebas tienen lugar en los hitos del proyecto, tales como el lanzamiento de un sistema de software, la finalización (o anulación) de un proyecto de pruebas, la consecución de un hito, o la finalización de una versión de mantenimiento.

Las actividades de cierre de pruebas incluyen las siguientes tareas principales:

• Comprobar cuáles de los productos entregables previstos han sido efectivamente entregados. 
• Cerrar los informes de incidencias o aportar modificaciones a aquellos que siguen abiertos. 
• Documentar la aceptación del sistema. 
• Finalizar y archivar los productos de soporte de prueba, el entorno de pruebas y la infraestructura de pruebas para su posterior uso. 
• Entregar los productos de soporte de prueba a la organización de mantenimiento. 
• Analizar las lecciones aprendidas para determinar los cambios necesarios en futuras versiones y proyectos. 
• Utilizar la información recopilada para mejorar la madurez de las pruebas.

Pregunta de examen:

10 What is the purpose of test completion criteria in a test plan:
a) to know when a specific test has finished its execution
b) to ensure that the test case specification is complete
c) to set the criteria used in generating test inputs
d) to know when test planning is complete
e) to plan when to stop testing-->OK


10 ¿Cuál es el propósito de los criterios de terminación de prueba en un plan de pruebas :
a) en saber cuándo una prueba específica ha terminado su ejecución
b ) asegurarse de que la especificación de caso de prueba se ha completado
c ) establecer los criterios utilizados en la generación de entradas de prueba
d ) en saber cuándo se ha completado la planificación de la prueba
e) para planificar cuándo parar las pruebas-->OK

35 The standard that gives definitions of testing terms is:
a) ISO/IEC 12207
b) BS7925-1-->OK
c) BS7925-2
d) ANSI/IEEE 829
e) ANSI/IEEE 729

35 El estándar que proporciona definiciones de términos de prueba es:
a) ISO/IEC 12207
b) BS7925-1-->OK
c) BS7925-2
d) ANSI/IEEE 829
e) ANSI/IEEE 729

Para profundizar ir a :
http://in2test.lsi.uniovi.es/gt26/presentations/ISO29119-Presentacion-GT26-20140618.pdf

Los sietes principios para las pruebas (K2 - entender, explicar , razonar)

Objetivos:

1. Explicar los sietes principios del proceso de pruebas (K2).

Términos usados en este artículo: PRUEBAS EXHAUSTIVAS.

• Principios

En los últimos 40 años se han propuesto una serie de principios que establecen pautas generales comunes a todas las pruebas.

Principio 1 - Las pruebas demuestran la presencia de defectos.

1. Las pruebas pueden demostrar que hay defectos, pero no pueden probar que no los hay.
2. Las pruebas reducen la probabilidad de que haya defectos ocultos en el software pero, aunque no se detecte ningún defecto , no constituyen una evidencia de corrección.

Principio 2 - Las pruebas exhaustivas no existen.

Probar todo (todas las combinaciones de entradas y pre condiciones  es imposible, salvo en caso triviales. En lugar de pretender hacer pruebas exhaustivas, se deben realizar análisis de riesgos y prioridades para centralizar los esfuerzos de las pruebas.

Principio 3 - Pruebas tempranas.

Para identificar los defectos en una etapa temprana, las actividades de pruebas se iniciarán lo antes posible en el ciclo de  vida del software o del desarrollo del sistema, debiendo centrarse en objetivos definitivos.

Principio 4 - Agrupación de defectos.

Las pruebas deben concentrarse de manera proporcional en la densidad esperada, y más tarde observada, de los defectos de los módulos: Normalmente la mayor parte de los defectos detectados durante las pruebas al lanzamiento y la mayoría de los fallos operativos se concentran en un número reducido de módulos.

Principio 5 -  Paradoja del pesticida.

Si repetimos las mismas pruebas una y otra vez eventualmente la misma serie de casos de prueba dejará de encontrar defectos nuevos. Para superar esta "paradoja del pesticida", los casos de prueba deben revisarse periódicamente y deben escribirse pruebas nuevas y diferentes para ejercitar distintas partes del software o del sistema con vistas a poder detectar más defectos.

Principio 6 - Las pruebas dependen del contexto.

Las pruebas se llevan a cabo de manera diferente según el contexto. Así por ejemplo, la forma de probar un software crítico para la seguridad variará de la de un sitio de comercio electrónico.

Principio 7 - Falacia de ausencia de errores.

La detección y corrección de defectos no servirá de nada si el sistema construido no es usable y no cumple las expectativas y necesidades de los usuarios.

Pregunta de examen

6 Consider the following statements about early test design:
i. early test design can prevent fault multiplication
ii. faults found during early test design are more expensive to fix
iii. early test design can find faults
iv. early test design can cause changes to the requirements
v. early test design takes more effort

a) i, iii & iv are true. ii & v are false-->OK
b) iii is true, I, ii, iv & v are false
c) iii & iv are true. i, ii & v are false
d) i, iii, iv & v are true, ii us false
e) i & iii are true, ii, iv & v are false

6 Considere las siguientes afirmaciones sobre diseño de la prueba temprana

i. El diseño de la prueba temparana puede prevenir la multiplicación de fallos.-->OK
ii.las fallas encontradas durante el diseño de la prueba temprana son más costosos de arreglar.-->NOK
iii.El diseño de la prueba temprana puede encontrar fallas-->OK
iv.El diseño de la prueba temprana puede causar cambios en los requisitos-->OK
v. El diseño de la prueba temprana requiere más esfuerzo-->NOK

a) i, iii & iv son verdaderas. ii & v son falsas false-->OK
b) iii es verdadera, I, ii, iv & v son falsas
c) iii & iv son vrdaderas. i, ii & v son falsas
d) i, iii, iv & v son verdaderas, ii es falsa
e) i & iii son veraderas, ii, iv & v son falsas

¿En qué consiste el proceso de pruebas? (K2 - entender, explicar , razonar)

Objetivos:

1. Retener los objetivos comunes de las pruebas (K1).
2. Poner ejemplos de los objetivos de las pruebas en las distintas fases del ciclo de vida del software (K2).
3. Diferenciar las pruebas de depuración (K2). 

Términos usados en este artículo: DEPURACIÓN, REQUISITO, REVISIÓN, CASO DE PREUBA, PRUEBAS, OBJETIVO DE PRUEBA.

• Antecedentes

La mayoría de las personas piensan que el proceso de pruebas consiste exclusivamente en "ejecutar pruebas", es decir, ejecutar el software. Claro, es una parte muy importante que realizar pero, la ejecución de pruebas forma parte del proceso de pruebas y no representa la totalidad de las actividades incluidas en él.

Las actividades de pruebas se dan antes y después de la ejecución de la prueba. Entre estas actividades se encuentran:

1. Planificar y controlar.
2. Seleccionar las condiciones de las pruebas.
3. Diseñar y ejecutar casos de pruebas.
4. Comprobar los resultados.
5. Evaluar los criterios de salida.
6. Elaborar informes sobre proceso de pruebas y sobre el sistema probado.
7. Finalizar o completar actividades de cierre una vez finalizada una fase de prueba.
8. revisión de documentos (incluyendo el código fuente) y la realización de análisis estático.

También se puede recurrir a la realización de pruebas dinámicas y estáticas para lograr objetivos similares, las cuales generarán información que podrá utilizarse para mejorar tanto el sistema probado como el desarrollo y los procesos de prueba.

Los procesos de prueba pueden tener los siguientes objetivos:

• Identificar defectos.
• Aumentar la confianza en el nivel de calidad.
• Facilitar información para la toma de decisiones.
• Evitar la aparición de defectos.

El proceso de reflexión y las actividades implicadas en el diseño de las pruebas al inicio del ciclo de vida del software (comprobando la base de prueba a través del diseño de pruebas) puede ayudar a evitar la introducción de defectos en el código. La revisión  de documentos (por ejemplo, los requisitos) y la identificación y subsanación de problemas también pueden ayudar a evitar la aparición de defectos  en el código.

Los distintos puntos de vista asociados al proceso de pruebas tienen en cuenta varios objetivos. así por ejemplo, en las pruebas de desarrollo (pruebas de componentes, integración y sistemas), el principal objetivo puede ser provocar el máximo número de fallos al objeto de identificar y subsanar los defectos del software. 

En las pruebas de aceptación, el principal objetivo puede ser confirmar que el sistema funciona según lo  esperado o corroborar que se ajusta a los requisitos previstos. En algunos casos, el principal objetivo de las pruebas puede ser evaluar la calidad del software (sin intención alguna de arreglar posibles defectos) o facilitar información a las partes interesadas  sobre el riesgo de lanzar el sistema en un momento dado.

En las pruebas de mantenimiento a menudo incluyen pruebas para verificar que no han surgido nuevos defectos durante el desarrollo de los cambios.

En las pruebas operativas, el principal objetivo puede ser evaluar características del sistema, tales como la fiabilidad o las disponibilidad.

Hay diferencias entre el proceso de depuración y el proceso de pruebas. 

• Las pruebas dinámicas pueden identificar aquellos fallos que han sido provocados por defectos.
• La depuración, es la actividad de desarrollo que localiza , analiza y elimina la causa del fallo.

La posterior repetición de las pruebas por parte de un probador garantiza que la corrección llevada a cabo realmente elimina el fallo. La responsabilidad de cada un de estas actividades corresponde generalmente a los probadores, en el caso de las pruebas  y a los desarrolladores, en el caso de la depuración. 

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

Niveles cognitivos para el estudio de certificación básica (QA)

Para llevar un control sobre los objetivos de aprendizaje para cada sección de estudio en el mundo de certificación del aseguramiento de calidad, es necesario comprender los distinto niveles como parte del proceso de madurez que debemos alcanzar.

Es por esto que detallaremos como se clasifican cada uno de ellos y es que consisten.

K1: Es recordar, reconocer y retener.

El estudiante reconocerá, recordará y retendrá un término o concepto.

Ejemplo: Definición de "fallo":

1. "Es la no prestación de servicio a un usuario final o a otra parte interesada" o
2. "Una desviación real del componente o sistema de su entrega, servicio o resultado esperado"

K2: Es entender, explicar , razonar, comparar , clasificar, categorizar, dar ejemplos y resumir. 

El estudiante puede seleccionar los motivos o explicaciones de las afirmaciones asociadas al tema, y es capaz de resumir, comparar, clasificar , categorizar y poner ejemplos del conceptos de pruebas.

Ejemplo: ¿Por qué las pruebas deben diseñarse lo antes posible?

1. Para localizar defectos y eliminarlos, de esta manera abaratamos costos.
2. Localizar en primer lugar los defectos más importantes.

¿Puede explicar las similitudes y diferencias entre integración y las pruebas de sistemas?

Similitud: En las pruebas de sistemas e integración se prueban más de un componente, y pueden probarse aspectos no funcionales (ejemplos pruebas de stress)

Diferencias: Las pruebas de integración se centran en interfaces e interacciones. En cambio las pruebas de sistemas se centran en aspectos globales del sistema, tales como procesos extremo a extremo, por ejemplo:  

Causa

"El cliente intenta conectarse a través de canalizaciones con nombre y el servidor no está configurado para permitir conexiones remotas que utilicen canalizaciones con nombre."

Solución

"Establezca la conexión con TCP/IP o utilice el Administrador de configuración de SQL Server para habilitar las conexiones remotas a través de canalizaciones con nombre."

K3: es aplicar, utilizar, implementar, ejecutar, seguir un procedimiento o aplicar un procedimiento. 

El estudiante puede seleccionar la aplicación correcta de un concepto o técnica y aplicarla en un contexto dado.

Ejemplo:

1- Identificar valores límite para particiones válidas y no válidas.
2.- Seleccionar casos de prueba a partir de un diagrama dado de transición de estados con vistas a cubrir todas las transiciones.

K4: Analizar. 

El estudiante puede clasificar la información sobre un procedimiento o técnica en diferentes partes para su mejor entendimiento, y es capaz de distinguir entre hechos e inferencias. La aplicación típica es analizar un documento , software o situación de proyecto y proponer las acciones pertinentes a adoptar para resolver un problema o tarea.

 Ejemplo:

1. Analizar riesgos de producto y proponer medidas de mitigación preventivas y correctivas.
2. Describir qué partes de un informe de incidencias son factuales (efctivo, concreto) y qué partes son inferencias (conclusiones) de los resultados.