capacitacitación tester - qa 4

Capacitación Tester QA

Junio, 2011

Psicología del Tes6ng Mentalidad del Tes6ng ü Inicialmente el Tes4ng fue considerado como una forma de validar si se sa4sfacían los requerimientos del so<ware.

ü Evolucionó al obje4vo de detectar fallas en lugar de demostrar la corrección. Un proceso destruc4vo.

ü Se puedes considerar como una crí4ca del producto y/o del autor.

ü Buscar fallas es construc4vo:

v Recuperar Tiempo. v Reducción de Costos. v Reducción de Riesgos. v Mejora de competencias.

Psicología del Tes6ng

Es importante que los obje4vos de las pruebas se en4endan claramente como seres humanos, será el moderador de su conducta en consecuencia (aunque de manera inconsciente): "Si el análisis se muestra que el sistema sa4sface sus requerimientos, sólo voy a producir las pruebas que lo demuestran.“ "Si la prueba 4ene el fin de encontrar fallas entonces se medirá en fallas, así que voy a poner esfuerzo en el diseño de pruebas que 4enen más probabilidades de encontrar las fallas.“ La mentalidad de prueba es diferente a la de un Desarrollador.


“La prueba es una tarea extremadamente crea4va e intelectualmente desafiante “ "Las pruebas deben ser escritas para inválidos e inesperados, así como válidas y esperadas las condiciones de entrada“.


Rasgos de un Buen Tester: Necesita: ü Habilidad para la Buena Comunicación. ü Habilidad para la Buena Observación. ü Habilidad para la Manipulación Personal. ü Curiosidad. ü Paciencia. ü Fiabilidad. ü Minuciosidad. ü Naturaleza Inquisi4va. ü Atención a los Detalles. ü Crea4vidad para la iden4ficación de posibles detalles. ü Experiencia.

Sin embargo, como con la mayoría de otras disciplinas, un equipo de prueba efec4va necesitará una combinación de habilidades por lo que es di^cil generalizar.

Psicología del Tes6ng Relación Tester VS Desarrollador Esta relación normalmente no es fácil por las siguiente razones: ü El tester señala problemas con el so<ware. ü Los desarrolladores suelen pensar que su so<ware es perfecto. ü Los tester son percibidos como factores que retrasan un proyecto. ü Cuando los desarrolladores se retrasan regularmente los tester deben realizar largas jornadas de trabajo para recuperar el 4empo.

Es importante que trabajen juntos. Es m{as importante que el respeto sea mutuo. La colaboración es el enfoque correcto, !trabajamos para un obje6vo común¡. Comunicar los resultados de las pruebas de manera obje4va y no subje4va.


Tes6ng Independiente El derecho de pensar podría permi4r a los desarrolladores para probar el código. Sin embargo, pasar esta responsabilidad a los recursos de prueba profesionales 4ene muchos beneficios (como una mayor tasa de defectos encontrados). Los autores 4enden a suponer al desarrollar el so<ware. Ellos son menos propensos a escribir las pruebas para mostrar fallas en su propio so<ware (la naturaleza humana). Con las pruebas realizadas por evaluadores independientes, el esfuerzo está enfocado a las pruebas y no se ve comprome4do por el esfuerzo de desarrollo y los prejuicios. En general se cree que en las pruebas independientes el obje4vo es más eficaz.


Tes6ng Independiente Hay varios niveles en de la independencia (de menor a mayor):

ü Pruebas diseñadas por la persona(s) que escribió el so<ware bajo prueba.

ü Pruebas diseñadas por otra persona(s) (por ejemplo, el equipo de desarrollo).

ü Pruebas diseñadas por una persona(s) de un grupo diferente a la organización (por ejemplo, un equipo de pruebas independiente).

ü Pruebas diseñadas por una persona(s) de una organización o empresa diferente (por ejemplo, la subcontratación a una empresa o ins4tución externa especialista en pruebas).

Modelo V User/Business

Requirements

System

Requirements

Technical

Specifica4on

Program

Specifica4on

Coding

Unit

Test

Integra4on

Test

System

Test

Acceptance

Test

Development

Levels

Test

Levels

Acceptance Test

Plan

System Test

Plan

Integra4on

Test Plan

Unit Test

Plan

Modelo V

Beneficios: ü A las fases de prueba se les da el mismo nivel de atención por parte de la administración y el compromiso como las fases de desarrollo correspondientes.

ü Los resultados de las fases de desarrollo son revisados � � por el equipo de pruebas para garan4zar su capacidad de prueba.

ü Verificación y validación (y diseño de la prueba an4cipada) puede llevarse a cabo durante el desarrollo de los productos de so<ware .

ü La planificación inicial y el diseño preliminar de pruebas ofrece comentarios adicionales de revisión en las salidas de la fase de desarrollo.

Modelo V

Los niveles de desarrollo y pruebas que se muestra en el modelo varían de

proyecto a proyecto. Por ejemplo, es posible que los niveles de prueba adicionales, tales como Pruebas de Integración de Sistema, ubicadas entre las pruebas de sistema y las pruebas de aceptación de usuario. Los productos de trabajo que salen de cualquier nivel de desarrollo se puede u4lizar en una o más niveles de prueba. Por ejemplo, mientras que la fuente principal para las pruebas de aceptación es el requisito de negocio, los requisitos del sistema (por ejemplo, casos de uso) también pueden ser necesarios para apoyar el diseño detallado de las pruebas.

Modelo V

"El modelo V proporciona una herramienta potente de ges4ón y control del

riesgo en el componente de prueba de un proyecto.

El proceso de armonización de la planificación de pruebas y diseño en el

proceso de desarrollo permite iden4fica los riesgos lo antes posible y permite

que se ejecuten las estrategias para eliminar o mi4gar riesgos a su debido

4empo."

Modelo de Desarrollo Itera6vo e Incremental El desarrollo itera4vo-‐incremental: ü Establecer los requisitos. ü Diseño del Sistema. ü Construcción del sistema. ü Prueba del Sistema. Obtenidos con la evolución de pequeñas -‐ iteraciones y / o incrementos (posiblemente en iteraciones). Como iteraciones / incrementos se han desarrollado y probado los crecimientos del sistema. Necesidad de más pruebas de regresión sumadas. Por ejemplo RAD, RUP son modelos de desarrollo ágil. Desarrollo ágil: ü Obje4vo es ofrecer so<ware temprano y con frecuencia. ü Producción rápida y "4me to market “. ü Puede manejar (y se an4cipa a) las necesidades cambiantes en todas las fases de desarrollo y pruebas.

Modelo de Desarrollo Itera6vo e Incremental Rapid Applica4on Development:

Requerimientos de Usario

Codigo

Pruebas de Aceptación

Modelo de Pruebas dentro del Ciclo de Vida Caracterís4cas de las buenas pruebas en cualquier modelo de ciclo de vida: ü Un nivel de pruebas existe para cada nivel de desarrollo. ü Cada nivel de pruebas 4ene obje4vos específicos. ü Análisis y de diseño de pruebas para cada nivel de prueba se inicia durante el correspondiente nivel de desarrollo. ü Par4cipación temprana y ac4va de testers en la revisión de resultados de desarrollo -‐ beneficia ambas partes. Niveles de prueba deben ser adaptados en función de la naturaleza del proyecto. Puede ser mejor para combinar los niveles de prueba.

Pruebas de Componente ü Componente -‐ Un arfculo del so<ware mínimo que se puede probar de forma aislada. ü Pruebas de Componentes -‐ Pruebas de componentes individuales de so<ware. ü A veces se conoce como pruebas unitarias, pruebas de modelo o pruebas de programa. ü Un Componente se puede probar de forma aislada -‐ se pueden emplear controladores . ü Los casos de prueba son derivados de las especificaciones de componentes (módulo / especificaciones del programa). ü Pruebas Funcionales y Pruebas No Funcionales. ü Por lo general realizadas por el desarrollador, con la herramienta para debugging. ü Solución de Defectos Rápido e Informal.

Pruebas de Componente Enfoque de las Pruebas Iniciales / Ensayo -‐ crear las pruebas para el diseño y la construcción del código!. En lugar de crear un diseño que le diga cómo estructurar el código, se crea una prueba que define como una pequeña parte del sistema debe funcionar. Tres pasos: 1)  Diseño de la prueba es definido en base a cómo crees que una pequeña

parte del so<ware debe comportarse (desarrollo incremental).

2)  Haga la prueba de funcionamiento con la misma facilidad y rapidez posible. No se preocupe sobre el diseño de código, sólo preocúpese por conseguir que funcione!.

3)  Limpiar el código. Ahora que el código funciona correctamente, de un paso atrás y elimine cualquier duplicación o cualquier otro problema que se presentó para ejecutar de nuevo las pruebas.

Pruebas de Integración Pruebas de Integración – Son las pruebas realizadas para exponer los defectos de las interfaces y las interacciones entre los componentes integrados o sistemas. Los componentes pueden ser módulos del código, sistemas opera4vos, hardware, incluso sistemas completos. Hay dos niveles de Pruebas de Integración: ü Pruebas de Integración de Componentes. ü Pruebas de Integración de Sistema.

Pruebas de Integración de Componentes ü Pruebas de Integración de Componentes: Son las pruebas realizadas para exponer los defectos de las interfaces y la interacción entre los componentes integrados.

ü Por lo general realizadas por el desarrollador, pero podrían involucrar formalmente al equipo de pruebas (registros de diseño de la prueba y de la ejecución).

ü Todos los componentes individuales deben ser probados en integración para hacer después hacer pruebas de sistema.

Pruebas de Integración de Componentes Planeación: Para considerar -‐ El enfoque de las pruebas de integración: ¿Iniciaremos del Nivel Superior de componentes hacia abajo? ¿Iniciaremos del Nivel Inferior de componentes hacia arriba? ¿U4lizaremos el método del big bang? ¿Nos basaremos en grupos funcionales? ¿Iniciaremos con los componentes crí4cos? ¿Nos basaremos en la secuencia de negocios? El conocimiento de la arquitectura del sistema es importante. Cuanto mayor sea el alcance del enfoque de integración, más di^cil es aislar defectos. Requisitos de pruebas no funcionales pueden empezar por aquí -‐ por ejemplo, especificaciones de rendimiento.

Pruebas de Integración de Componentes Pruebas Top-‐Down:

B C

D E F G

A

Pruebas de Integración de Componentes Pruebas Top-‐Down: Pro’s

ü Proporciona un sistema limitado para trabajar al inicio en el proceso de diseño.

ü L a p r i m e r a i n t e g r a c i ó n d e profundidad muestra las funciones de extremo a extremo al inicio en el proceso de desarrollo.

ü La detección temprana de errores de diseño hasta la implementación al inicio de la estructura del diseño.

ü Las pruebas de control de los puntos de decisión.

ü Este enfoque puede permi4r a un e m p a l m e c o n p r u e b a s d e componentes.

Contras ü T a l o n e s s ó l o p r o p o r c i o n a n s i m u l a c i o n e s l i m i t a d a s d e componentes de nivel inferior y podría influir en los resultados falsos.

ü La extensión significa que los niveles del sistema deben ser ar4ficialmente obligados a generar una salida para las validaciones de prueba.

Pruebas de Integración de Componentes Pruebas BoSom-‐Up:

B C

D E F G

A A es el Driver para los componentes B y C.

Igualmente B y C son D r i ve r s de o t ro s componentes.

Pruebas de Integración de Componentes Pruebas BoSom-‐Up: Pro’s

ü Los Drivers que u4lizan en lugar de módulos de nivel superior para simular el medio ambiente para los módulos de nivel inferior.

ü Necesarios para los componentes crí4cos, de bajo nivel en el sistema.

ü En las pruebas se puede observar en los componentes a probar desde el principio.

Contras ü Puede que un componente no este disponible desde un inicio y no nos demos cuenta a 4empo.

ü Detección tardía de errores en la estructura del sistema.

capacitacitación tester - qa 4

Technology