capacitacitación tester - qa 5

Capacitación Tester QA

Julio, 2011

Revisiones

Propagación: ü Los Errores y/o Fallas se propagan en los Requerimientos al Diseño y luego al Código.

ü Los Errores y/o Fallas en el Diseño se propagan al Código.

ü El Código 8ene sus propios Errores y/o Fallas.

ü La corrección de los Errores y/o Fallas en los Requerimientos también se transmiten a la corrección en Diseño y en el Código.

Revisiones

% de Errores producidos por etapa: ü  Requerimientos: 8% aprox.

ü  Diseño Funcional: 17% aprox.

ü  Diseño Lógico: 30% aprox.

ü  Codificación: 25% aprox.

ü  Otras: 20% aprox.

Revisiones Una revisión podría hacerse enteramente como una ac8vidad manual. Si no hay soporte de herramientas disponibles. La ac8vidad manual principal es examinar un producto de trabajo y hacer comentarios al respecto. Cualquier entregable de soTware puede ser revisado��, incluyendo: ü Requisitos y especificaciones de diseño de código fuente. ü Planes de prueba, casos de prueba, scripts de prueba. ü Documentación para el usuario. ü Aplicación de administración y material de apoyo. ü Páginas web.

Un entregable de soTware puede ser revisado � �una o más veces y se puede u8lizar uno o más 8pos de revisión. Revisar todo lo más pronto posible.

Revisiones

En la Revisiones se encuentran Defectos y en las Pruebas Dinámicas se encuentran Fallas. En las Revisiones los defectos \picos son fácilmente encontrados y en las Pruebas Dinámicas son encontrados: ü Desviaciones de los Estándares. ü Defectos en los Requerimientos. ü Defectos del Diseño. ü Insuficiencia en el Mantenimiento. ü Especificaciones incorrectas de interfaces.

Revisiones Beneficios: ü Detectar fallas, introducidas. ü Reducir el riesgo de propagación de errores / fallas. ü Detectar los defectos que la ejecución de la prueba dinámica poco pueda encontrar, por ejemplo, los errores de especificación de requisitos. ü Acortar los plazos de desarrollo. ü Reducir los niveles de fallas en el soTware entregado. ü Menor costo y acortar los plazos las pruebas. ü Menor costo durante la vida ú8l del soTware. ü Crear mejoras en el desarrollo de la produc8vidad. ü Fiable evalúa el progreso y la capacidad. ü Educa y entrena a los par8cipantes. ü Mejorar la comunicación entre los equipos de proyecto.

Revisión Informal ü No hay proceso formal de revisión por empleados.

ü “Revisión de Escritorio", en busca de posibles problemas.

ü El autor del material es su propio control de calidad, posiblemente con otro compañero (Peer Review).

ü Es posible que un jefe de diseño realice una revisión técnica del código.

ü Por lo general, indocumentada, pero ú8l, barata y ampliamente u8lizada.

ü Esta técnica puede ser aplicada en situaciones de bajo riesgo.

ü No hay cifras de los resultados de la revisión.

ü Debilidades -‐ no encuentra defectos hasta revisiones formales.

Revisión Formal -‐ Tutoriales ü Un Tutorial es una revisión del material escrito por el autor y la par8cipación de un grupo de compañeros del autor (por lo general 2 a 6 pares). El Obje8vo Principal es la educación.

ü El material es presentado por el autor para el grupo de pares, que se centran en el aprendizaje de la materia, mejorarla y corrección de defectos.

ü Grupo de pares debe incluir el desarrollo, representantes de la operación, el público obje8vo, etc. ü Las sesiones pueden ser formales o informales.

ü Sesiones de revisión a menudo abiertas.

ü Pre-‐encuentro de preparación con los involucrados.

ü Debilidades -‐ no encuentra tantos defectos como en las revisiones técnicas y en las inspecciones.

Revisión Formal – Peer Review Se pueden realizar los Peer Review sin la par8cipación del gestor. Preferentemente dirigido por un moderador capacitado (no el autor). Pre-‐Encuentro, se requiere preparación. Obje8vo principal es: ü Discu8r. ü Tomar decisiones. ü Evaluar las alterna8vas. ü Encontrar defectos. ü Resolver problemas técnicos y comprobar la conformidad con las especificaciones y normas. Grado de formalidad varía. Revisores traen una lista de cues8ones técnicas para el examen. El uso opcional de listas de comprobación y un informe de revisión. Durante la reunión los revisores formulan objeciones, las ambigüedades e incoherencias en el diseño o aspectos técnicos en discusión. Los problemas son aclaradas y documentadas -‐ se buscan soluciones después de que la revisión ha concluido. Debilidades -‐ no encuentra tantos defectos como en las inspecciones.

Revisión Formal – Inspecciones ü Revisiones formales y sistemá8cas de los materiales. Obje8vo principal es encontrar fallas y mejora de procesos. ü Dirigido por un moderador independiente preparado (pero no el autor). ü Principal obje8vo -‐ encontrar defectos. ü Asiste el autor y sus compañeros (generalmente de 3 a 6) que actúan en roles definidos. ü Preparación de la reunión previa, esencial. ü Seguir un formato estricto. ü Señalar los criterios de inclusión y criterios de salida. ü La búsqueda y registro de los defectos. ü Uso de reglas estandarizadas, listas de control y técnicas. ü Métricas. ü Opcionalmente mejora las consideraciones del proceso en revisión. ü Debilidades -‐ rendimiento caro y consume 8empo.

Proceso de la Revisión Formal Planeación: ü Definir los criterios de entrada y salida (para una revisión más formal).

ü Asegúrese de que el volumen de material a ser revisado es apropiado.

ü Iden8ficar los roles, los par8cipantes y establecer un 8empo y lugar para la revisión.

Proceso de la Revisión Formal Kick Off: ü Distribuir el material a los par8cipantes.

ü Explicar los obje8vos, procesos y materiales a ser revisados.

ü Obtener copias de las plan8llas de revisión per8nentes.

ü Crear listas de control de las áreas a cubrir y distribuir listas de verificación pueden hacer las revisiones más eficaces y eficientes.

ü Por ejemplo; una lista de verificación sobre la base de puntos de vista como usuario, desarrollador, probador o de las operaciones o una lista de los problemas de los requisitos \picos para centrarse en hacer que los criterios de entrada ha sido / serán recibidos.

Proceso de la Revisión Formal

Overview (Opcional): Necesidades para el nuevo material o de dikcil visión general:

ü Educar a los par8cipantes. ü Permiten a los par8cipantes centrarse en el contenido técnico. ü Describe el lugar donde el material se integra en el sistema y en el proceso de desarrollo. ü Se centran en la funcionalidad compleja. ü Señala los cambios y explica la necesidad de estos cambios.


Preparación: Cada par8cipante revisa el material para: ü Aprender sobre el material.

ü Tener en cuenta la sospecha de los defectos.

ü Registro de las preguntas.

ü En algunas circunstancias, dependiendo de la experiencia de los par8cipantes, el moderador puede preguntar a algunos par8cipantes aspectos par8culares del material durante la preparación.


Reunión: ü Materiales se leen a los par8cipantes.

ü Los defectos son planteados por los par8cipantes y registrados.

ü Los par8cipantes pueden tomar decisiones sobre la clasificación y manejo de los defectos, aunque por lo general se evita la "solución”.

ü Entregables pueden incluir actas de las reuniones.

ü Para Inspecciones -‐ Pase o no, repe8r las decisiones de revisión.

ü El 8empo de preparación y el 8empo real puede ser registrado.

Proceso de la Revisión Formal Re-‐trabajo: ü El autor debe resolver todos los defectos encontrados durante la revisión para re-‐trabajar el material según las recomendaciones del informe de revisión.

ü Tenga en cuenta, el costo de reproceso no está incluido en el costo de las revisiones.

Proceso de la Revisión Formal Seguimiento: ü Comprobar la corrección del material y dar cuenta de todos los defectos registrados.

ü Si es necesario, haga una nueva revisión del material corregido.

ü Informar a la dirección del material corregido.

ü Agregue los defectos en la base de datos de estadís8cas del proyecto -‐ permite la mejora del proceso!.

ü Completar y firmar el informe de revisión y formularios (inspecciones).

ü Garan8zar los criterios de salida.


Otros Qpos: ü Revisiones por la dirección -‐ Los comentarios de los planes, programas, avances.

ü Auditorías -‐ evaluación independiente de conformidad con las normas, planes y procedimientos.

ü Posteriores a la implementación -‐ revisión del enfoque del proyecto (incluyendo el enfoque de la prueba).

Análisis EstáQco Es el Análisis de los artefactos de soTware, por ejemplo, requisitos o código, llevado a cabo sin la ejecución de estos artefactos de soTware. ObjeQvo -‐ encontrar defectos en el código fuente del soTware y modelos de soTware. El análisis está8co se realiza sin ejecutar el soTware, siendo examinado por la herramienta, mientras que las pruebas dinámicas se ejecuta el código del soTware. El análisis está8co puede localizar los defectos que son dikciles de encontrar en las pruebas. Como con las revisiones, el análisis está8co encuentra defectos en vez de las fallas. Las Herramientas de análisis está8co analizan el código del programa (por ejemplo, gráficos con control de flujo y técnicas de análisis de flujo de datos), así como la salida generada como HTML y XML.

Análisis EstáQco ü La detección temprana de los defectos antes de la ejecución de las pruebas. ü Alerta a 8empo sobre los aspectos sospechosos del código o el diseño. ü Cálculo de los indicadores como una medida de alta complejidad. ü Iden8ficación de los defectos que no se encuentran fácilmente en las pruebas dinámicas. ü Dependencias de la detección e inconsistencias en los modelos de soTware, tales como enlaces. ü Mantenimiento mejorado de código y de diseño. ü Prevención de los defectos, si las lecciones se aprenden en el desarrollo. ü Rentable -‐ los problemas encontrados anteriormente son más baratos para arreglar. ü El análisis está8co es más eficaz y menos costoso que la prueba dinámica. ü El análisis está8co demuestra encontrar el 45% de errores esperados antes de que la prueba realmente inicie.

capacitacitación tester - qa 5

Technology