testing de software sesión n° 01

7/23/2019 Testing de Software Sesión N° 01

http://slidepdf.com/reader/full/testing-de-software-sesion-n-01 1/22

Testing de Software



TemarioIntroducción

¿Quién hace las Pruebas?

¿Cuándo se inicia el testing de software?

¿Cuándo finalizan las pruebas?

Verificación y validación

Mitos sobre el Testing de software

QA, QC y Testing

Auditoría e Inspección

Pruebas y depuración

Resumen



IntroducciónEs el proceso de evaluación de un sistema o de su componente(s) con la intenciónsi cumple los requisitos especificados.

La prueba se ejecuta en un sistema con el fin de identificar los vacíos, errores, ofaltantes en contra de las exigencias reales.

De acuerdo con la norma ANSI/IEEE 1059 el Testing se puede definir como:

◦ Un proceso de análisis de un elemento de software para detectar las diferencias entre

existentes y las requeridas( es decir defectos/errores/bugs ) y para evaluar las car

elemento de software.



¿Quién hace las Pruebas?Depende del proceso y de los grupos de interés asociados al(os) proyecto(s).

En la industria de TI, las grandes empresas tienen un equipo con responsabilidadesel software desarrollado en el contexto de los requisitos citados.

Los desarrolladores también llevan a cabo las pruebas llamadas Pruebas Unitarias.

En la mayoría de los casos, los siguientes profesionales participan en la prueba de udentro de sus respectivas capacidades:

◦ Tester de Software◦ Desarrollador de software

◦ Líder de Proyecto / Gerente

◦ Usuario final



¿Cuándo se inicia el testing de softwUn inicio temprano de las pruebas reduce el costo y el tiempo para corregir y produsoftware libre de errores que se entrega al cliente.

Sin embargo, en el ciclo de vida de desarrollo de software( SDLC ) , las pruebas se pdesde la fase de recopilación de requisitos y continuar hasta el despliegue del softw

También depende del modelo de desarrollo que se utiliza. Por ejemplo, en el modecascada, las pruebas formales se lleva a cabo en la fase de pruebas; pero en los moincrementales, las pruebas se realizan al final de cada iteración/incremento y toda

se prueba en el extremo.



Las pruebas se realizan en las diferentes formas en cada fase del CVDS:

Durante las fases de recopilación de requisitos, análisis y verificación de requisitos tconsideran como pruebas.

Revisar el diseño en la fase de diseño con la intención de mejorar el diseño tambiéncomo prueba.

Las pruebas realizadas por un desarrollador al finalizar el código también se clasific

pruebas.



¿Cuándo finalizan las pruebas?Es difícil determinar cuándo se terminan las pruebas de software, como las pruebasproceso que nunca termina y nadie puede pretender que un software este probado

Los siguientes aspectos son para ser considerados en la finalización del proceso de

◦ Plazos de pruebas.

◦ La finalización de la ejecución de los casos de pruebas.

◦ La finalización de la cobertura funcional y de código en cierto punto determinado.

◦ La tasa de Bug’s cae por debajo de cierto nivel y no hay errores de alta prioridad que se id

◦ Decisiones de gestión.



Verificación y validaciónEstos dos términos son muy confusos para la mayoría de la gente, que los utilizan dindistinta.

.



La siguiente tabla muestra las diferencias entre la verificación y validación.

N Verificación Validación

1 Verificación responde a la preocupación : "¿Se está

construyendo las cosas bien?“.

Validación responde a la preocup

construyendo lo correcto?“.

2 Asegura que el sistema software cumple con todas

las funcionalidades.

Asegura que las funcionalidades c

comportamiento previsto.

3 La Verificación tiene lugar primero e incluye la

comprobación de la documentación, código, etc.

La Validación se produce después

implica la comprobación del prod

4 Hecho por los desarrolladores. Hecho por los Testers.

5 Tiene actividades estáticas, que incluyen la recogida

de opiniones, tutoriales, y las inspecciones para

verificar el software.

Cuenta con actividades dinámicas

ejecución de software contra los

6 Es un proceso objetivo y ninguna decisión subjetiva

debe ser necesaria para verificar un software.

Es un proceso subjetivo e implica

subjetivas sobre qué tan bien fun



Mitos sobre el Testing de softwareA continuación se presentan los mitos más comunes acerca de las pruebas de softw

Mito 1: Las pruebas son demasiado costosas

Realidad: Hay un dicho, pagar menos por las pruebas durante el desarrollo de softwmás por el mantenimiento o corrección posterior. Las primeras pruebas ahorran tieen muchos aspectos, sin embargo la reducción del costo sin pruebas puede resultarinadecuado de una versión inútil del producto software.

Mito 2: Las pruebas consumen mucho tiempo

Realidad: Durante las fases del CVDS, las pruebas no son procesos que consuman tiembargo diagnosticar y solucionar los errores detectados durante las pruebas adecactividad que consume tiempo, pero productivo.



Mito 3: Sólo Productos completamente desarrollados se prueban

Realidad: Sin duda, la prueba depende del código fuente, pero la revisión de los reqdesarrollo de casos de prueba es independiente del código desarrollado. Sin embarenfoque iterativo/incremental como un modelo de CVDS pueden reducir la dependpruebas en el software desarrollado completamente.

Mito 4: La Prueba completa es Posible

Realidad: Se convierte en un problema cuando un cliente o tester piensa que la prues posible. Es posible que todos los caminos hayan sido probados por el equipo, peocurrencia de pruebas completas nunca es posible. Puede haber algunos escenarioejecutados por el equipo de pruebas o el cliente durante el CVDS y puedan ejecutarque el proyecto ha sido implementado.



Mito 5: El Software Probado está libre de errores

Realidad: Esto es un mito muy común que los clientes, gerentes de proyecto y el eqdirectivo crean. Nadie puede afirmar con absoluta certeza que una aplicación de so100 % libre de errores , incluso si un probador con excelentes habilidades de pruebla aplicación..

Mito 6: Los defectos no detectados se deben a los

Realidad: No es un enfoque correcto culpar a los Testers para los bugs que quedan aplicación, incluso después de la prueba que se ha realizado. Este mito se refiere alcosto, restricciones y requisitos cambiantes. Sin embargo, la estrategia de prueba tapuede resultar en errores que no son detectados por el equipo de prueba.



Mito 7: Los Testers son Responsable de la Calidad del Producto

Realidad: Es una mala interpretación muy común que sólo los Testers o el equipo dedeben ser responsables de la calidad del producto. Las responsabilidades de los tesla identificación de los bugs a stakeholders y es entonces su decisión si van a reparaliberar el software. Liberar el software en el momento pone más presión en los Testserán culpados por cualquier error.

Mito 8: La automatización de Pruebas se debe utilizar siempre que sea posible paraduración del proyecto

Realidad: Sí, es cierto que la automatización de Pruebas reduce el tiempo de pruebposible iniciar la automatización de pruebas en cualquier momento durante el desasoftware. La automatización de pruebas debe iniciarse cuando el software ha sido pforma manual y es estable hasta cierto punto. Por otra parte, la automatización de se puede utilizar si los requisitos siguen cambiando.



Mito 9: Cualquiera puede probar una aplicación de software

Realidad: La gente fuera de la industria de TI piensa y cree que cualquiera puede prsoftware y que las pruebas no son un trabajo creativo. Sin embargo los Testers sabees un mito. Se debe pensar en escenarios alternativos, tratar de quebrar un softwaintención de explorar errores potenciales no es posible para la persona que lo desa

Mito 10: La única tarea de un Tester es encontrar errores

Realidad: Encontrar errores en un software es la tarea de los Testers, pero al mismoexpertos en el dominio del software en particular. Los desarrolladores sólo son resla componente o área específica que se les asigna, pero los Testers deben de entenfuncionamiento general del software, lo que las dependencias hacen, y las repercumódulo en otro módulo.



QA, QC y TestingLa mayoría de la gente se confunde cuando se trata de precisar las diferencias entre

Aseguramiento de la Calidad, Control de Calidad y Testing.

A pesar de que están relacionados entre sí y hasta cierto punto, pueden ser considelas mismas actividades, pero existen puntos distintivos que los diferencian.



La siguiente tabla muestra los puntos que diferencian a Aseguramiento de la calidad, contry pruebas.

Aseguramiento de la Calidad Control de Calidad Prue

Incluye actividades que aseguren

la implementación de procesos,

procedimientos y normas en el

contexto de la verificación delsoftware desarrollado y los

requisitos previstos.

Incluye actividades que garanticen la

verificación de un software

desarrollado con respecto a los

requisitos documentados (o no enalgunos casos).

Incluye actividad

aseguren la iden

bugs/errores/de

software.

Se centra en los procesos y

procedimientos en lugar de la

realización de pruebas reales en

el sistema.

Se centra en las pruebas reales

ejecutando el software con el

objetivo de identificar bug/defecto a

través de la implementación de los

procedimientos y procesos.

Se centra en las

reales.

Actividades orientadas a los

procesos.

Actividades orientadas al producto. Actividades orie

producto.

Las actividades preventivas. Es un proceso correctivo. Es un proceso pr

Es un subconjunto del Ciclo de

Vida de Pruebas del

software(CVPS).

Se puede considerado como

subconjunto de Aseguramiento de la

Calidad.

Es un subconjun

de Calidad.



Auditoría e InspecciónAuditoría: Es un proceso sistemático para determinar cómo se lleva a cabo el proce

real dentro de una organización o un equipo.

En general, es un examen independiente de los procesos que intervienen durante lun software.

Según IEEE, es una revisión de los procesos documentados que las organizaciones imy siguen.

Tipos de auditoría incluyen a Auditoría de Cumplimiento Legal , Auditoría Interna y sistema.



Inspección: Es una técnica formal que implica revisiones técnicas formales o inform

cualquier artefacto mediante la identificación de cualquier error o hueco.

Según IEEE94, inspección es una técnica de evaluación formal en el que se examinarequisitos de software, diseños o códigos en detalle por una persona o un grupo quautor para detectar fallas, violaciones de las normas de desarrollo y otros problema

Las Reuniones formales de inspección pueden incluir los siguientes procesos : PlaniInformación general de Preparación, Reunión de inspección, revisiones y seguimien



Pruebas y depuraciónPruebas: Se trata de identificar bug/error/defecto en un software sin corregirlo.

Normalmente profesionales con experiencia en aseguramiento de la calidad están ien la identificación errores.

Las pruebas se realizan en la fase de pruebas.



Depuración: Se trata de identificar, aislar, y corregir los problemas/errores.

Los desarrolladores que codifican el software llevan a cabo la depuración al enconterror en el código.

La depuración es una parte de Pruebas de Caja Blanca o pruebas unitarias.

La depuración se puede realizar en la fase de desarrollo, mientras que la realizaciónunitarias o en fases, mientras se corrigen los errores reportados.



ResumenTesting: Un proceso de análisis de un elemento de software para detectar las difere

las condiciones existentes y las requeridas.

¿Quién hace las Pruebas?: según la dimensión: Tester, Desarrollador, Líder de ProyeGerente, Usuario final

¿Cuándo se inicia el testing de software?: Mientras más temprano es mejor. Se hacedesde la captura de requerimientos.

¿Cuándo finalizan las pruebas?: nunca hay software probado al 100%, según el proy

ser: Plazos de pruebas, finalización de los casos de pruebas, finalización de la coberfuncional, reducción de la tasa de Bug’s a cierto nivel, decisiones de gestión.

Verificación y validación: la validación se hace posterior a la verificación.



Mitos en el testing de software: existen muchas presunciones sobre las pruebas de s

van desde la parte operacional, los costes del proyectos y las funciones, papeles yresponsabilidades de los testers de software.

QA, QC y Testing: el Aseguramiento de la Calidad engloba al Control de Calidad y és

Auditoría: Es un proceso sistemático para determinar cómo se lleva a cabo el procereal dentro de una organización o un equipo.

Inspección: Es una técnica formal que implica revisiones técnicas formales o inform

cualquier artefacto mediante la identificación de cualquier error o hueco.

Pruebas: Se trata de identificar bug/error/defecto en un software sin corregirlo.

Depuración: Se trata de identificar, aislar, y corregir los problemas/errores.

testing de software sesión n° 01

Documents