• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
Capacitacitación Tester - QA 4
 

Capacitacitación Tester - QA 4

on

  • 163 views

Capacitacitación tester qa 4

Capacitacitación tester qa 4

Statistics

Views

Total Views
163
Views on SlideShare
163
Embed Views
0

Actions

Likes
0
Downloads
6
Comments
0

0 Embeds 0

No embeds

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

    Capacitacitación Tester - QA 4 Capacitacitación Tester - QA 4 Presentation Transcript

    • 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.  
    • Psicología  del  Tes6ng   “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“.  
    • Psicología  del  Tes6ng   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.      
    • Psicología  del  Tes6ng   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.  
    • Psicología  del  Tes6ng   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).  
    • Psicología  del  Tes6ng   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     Acceptance  Test     Acceptance     Requirements     Plan   Test     System  Test     System     Requirements   Technical     Specifica4on     Development   Levels   Program   System     Plan     Test   Integra4on   Integra4on     Test  Plan     Test   Unit  Test     Plan     Test Specifica4on     Coding   Test   Unit           Levels  
    • 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:   A B D C E F G
    • Pruebas  de  Integración  de   Componentes   Pruebas  Top-­‐Down:    Pro’s    Contras   ü Proporciona   un   sistema   limitado   para   ü T a l o n e s   s ó l o   p r o p o r c i o n a n   trabajar   al   inicio   en   el   proceso   de   s i m u l a c i o n e s   l i m i t a d a s   d e   diseño.   componentes   de   nivel   inferior   y   ü L a   p r i m e r a   i n t e g r a c i ó n   d e   podría  influir  en  los  resultados  falsos.   profundidad  muestra  las  funciones  de   ü La   extensión   significa   que   los   niveles   extremo   a   extremo   al   inicio   en   el   del   sistema   deben   ser   ar4ficialmente   proceso  de  desarrollo.   obligados   a   generar   una   salida   para   ü La   detección   temprana   de   errores   de   las  validaciones  de  prueba.   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.  
    • Pruebas  de  Integración  de   Componentes   Pruebas  BoSom-­‐Up:   A Igualmente   B   y   C   son   D r i v e r s   d e   o t r o s   componentes.   D B A  es  el  Driver  para  los   componentes  B  y  C.   C E F G
    • Pruebas  de  Integración  de   Componentes   Pruebas  BoSom-­‐Up:    Pro’s    Contras   ü Los   Drivers   que   u4lizan   en   lugar   de   ü Puede   que   un   componente   no   este   módulos   de   nivel   superior   para   disponible   desde   un   inicio   y   no   nos   simular   el   medio   ambiente   para   los   demos  cuenta  a  4empo.   módulos  de  nivel  inferior.   ü Detección   tardía   de   errores   en   la   ü Necesarios   para   los   componentes   estructura  del  sistema.   crí4cos,  de  bajo  nivel  en  el  sistema.   ü En   las   pruebas   se   puede   observar   en   los   componentes   a   probar   desde   el   principio.