Your SlideShare is downloading. ×
  • Like
Capacitacitación Tester - QA 5
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×

Now you can save presentations on your phone or tablet

Available for both IPhone and Android

Text the download link to your phone

Standard text messaging rates apply

Capacitacitación Tester - QA 5

  • 140 views
Published

Capacitacitación Tester - QA 5

Capacitacitación Tester - QA 5

Published in Technology
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
No Downloads

Views

Total Views
140
On SlideShare
0
From Embeds
0
Number of Embeds
1

Actions

Shares
Downloads
18
Comments
0
Likes
1

Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide

Transcript

  • 1. Capacitación  Tester     QA       Julio,  2011  
  • 2. 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.  
  • 3. 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.  
  • 4. 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.  
  • 5. 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.  
  • 6. 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.  
  • 7. 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.  
  • 8. 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.  
  • 9. 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.   ü R esolver   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.  
  • 10. 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.  
  • 11. 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.  
  • 12. 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.  
  • 13. 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.  
  • 14. Proceso  de  la  Revisión  Formal   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.  
  • 15. Proceso  de  la  Revisión  Formal   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.  
  • 16. 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.  
  • 17. 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.  
  • 18. Proceso  de  la  Revisión  Formal   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).  
  • 19. 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.  
  • 20. 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.  
  • 21. 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.