Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Requirements Based Testing - webinar 27 giugno 2012

885 views

Published on

Published in: Business
  • Be the first to comment

  • Be the first to like this

Requirements Based Testing - webinar 27 giugno 2012

  1. 1. Requirement  based  tes/ng   27  Giugno  2012   Gian  Giacomo  Ermacora   So-ware  and  Product  Consultant  per  Emeraso5     EMEA  Presale  Engineer  per  Polarion  So5ware     giangiacomo.ermacora@emeraso-.com  
  2. 2. Webex    Webex Microfono in mute Per interventi e domande: chat o Q&A Se non sentite l’audio:
  3. 3. Emerasoft: solution areas
  4. 4. Partner & TechnologiesBusiness Intelligence ePublishing Polarion®  Application Lifecycle Management   Mainframe modernization Modeling   Configuration Management  
  5. 5. Alcuni cilenti
  6. 6. Agenda   §  Perché  è  criFco  avere  buoni  requisiF?   §  RBT  (Requirement  Based  Tes0ng),  cosè,  perché  adoNarlo   §  La  tracciabilità   §  Polarion  Requirement  e  Polarion  QA   §  TesFng  session:   ü  Definire  requisiF  e  test  case  in  Polarion   ü  Disegnare  i  test  case   ü  Creare  i  test  case   ü  Esecuzione  dei  test   ü  Verificare  i  risultaF  dei  test   ü  Verificare  la  test  coverage   ü  GesFre  e  tracciare  i  task  e  i  difeY   ü  GesFre  la  test  library   §  Domande  e  Risposte  6  
  7. 7. Perché  è  cri/co  avere  buoni  requisi/?   qualche  esempio  reale  7  
  8. 8. Perché  è  criFco  avere  buoni  requisiF?   qualche  esempio  reale   In  ingegneria,  un  requisito  è  una  singolare  e  documentata  necessità  fisica  e   funzionale  che  un  parFcolare  prodoNo  o  servizio  deve  possedere.       E‘  comunemente  usato  nel  senso  formale  nell’ingegneria  dei  sistemi,  del  so-ware   engineering,  o  ingegneria  aziendale.       Si  traNa  di  unistruzione  che  idenFfica  un  a:ributo  necessario,  capacità,   caraNerisFche,  o  la  qualità  di  un  sistema  per  produrre  un  valore.  8  
  9. 9. Perché  è  criFco  avere  buoni  requisiF?   qualche  esempio  reale   Saturn  V   Per  vincere  la  gravità  terrestre,  un  veNore     deve  raggiungere  quella  che  viene  chiamata     la  “velocità  di  fuga”.       Questa  velocità  equivale  a  11,2  km/sec.  9  
  10. 10. Perché  è  criFco  avere  buoni  requisiF?   qualche  esempio  reale   300  milioni  di  dollari  per  lo  sviluppo  e  manutenzione  so>ware     84  milioni  per  la  cancellazione  dei  progeY  mai  consegnaF   192  milioni  su  progeY  so-ware  la  cui  realizzazione  è  uscita  dai  tempi  e  budget  previs/    10  
  11. 11. Perché  è  criFco  avere  buoni  requisiF?   qualche  esempio  reale   Lo  Standish  Gruoup  ha  anche  evidenziato  le  tre  principali  ragioni  per  le  quali  i  progeY   so-ware  hanno  fallito:   ü  I  requisiF  e  le  specifiche  erano  incomple/;   ü  I  requisiF  e  le  specifiche  cambiavano  troppo  spesso;   ü  C’è  una  carenza  di  informazioni  da  parte  degli  utenF  finali  nei  requisiF.  11  
  12. 12. Perché  è  criFco  avere  buoni  requisiF?   qualche  esempio  reale   Il  processo  RBT  risponde  ad  ognuno  di  quesF  tre  punF:   ü  Si  introduce  durante  la  prima  fase  dello  sviluppo  so-ware,  dove  la  correzione  degli  errori  ha  un  costo   inferiore;   ü  Si  introduce  nella  fase  della  raccolta  dei  requisi0,  dove  la  maggior  parte  dei  difeY  hanno  effeYvamente   luogo;   ü  Risponde  in  modo  effeCvo  alla  crescita  della  qualità  dei  requisi0:  i  requisi/  inadegua/  sono  spesso  la   ragione  del  fallimento  del  progeNo.  12  
  13. 13. Perché  è  criFco  avere  buoni  requisiF?   qualche  esempio  reale   Distribuzione  dei  bug   Codice,  7%   Altro,  10%   Design,  27%   RequisiF,   56%  13  
  14. 14. Perché  è  criFco  avere  buoni  requisiF?   qualche  esempio  reale   Distribuzione  delleffort  per  correggere  i  bug   Altro,  4%   Codice,  1%   Design,  13%   RequisiF,   82%  14  
  15. 15. RBT  il  Requirement  Based  Tes0ng   cosè,  perché  adoNarlo  15  
  16. 16. RBT  il  Requirement  Based  Tes0ng   cosè,  perché  adoNarlo     Il  Requirement  Based  Tes/ng  è  un  processo  aNo  alla  risoluzione  due  grandi   problemi:   ü  la  validazione  dei  requisiF   ü  la  progeNazione  dei  casi  di  test  16  
  17. 17. RBT  il  Requirement  Based  Tes0ng   cosè,  perché  adoNarlo     Nel  disegnare  i  casi  di  test  è  necessario  affrontare  due  quesFoni:   ü  Avere  una  quan/tà  ragionevole  di  casi  di  test;   ü  Assicurarsi  che  quesF  test  siano  davvero  efficaci  per  verificare  i  requisi0.  17  
  18. 18. RBT  il  Requirement  Based  Tes0ng   cosè,  perché  adoNarlo     La   strategia  del  Requirement  Based  Tes/ng  è  quindi   di  integrare  la  definizione  dei  test  durante  il  ciclo  di  vita  e  di   sviluppo  del  progeNo  stesso,  avendo  costantemente  in  mente  le   specifiche  ed  i  requisi0.    18  
  19. 19. La  tracciabilità   traceability  19  
  20. 20. La  tracciabilità   traceability     tracciabilità   Per   (o  traceability)  si  intende  la  possibilità  di  ricostruire  la   relazione  tra  i  vari  item  prodoY  nel  corso  di  un  progeNo.     E’  la  possibilità  di  ricostruire  le  relazioni  degli  elemenF  di  un  progeNo  con  le   specifiche  dei  requisiF  iniziali,  viene  deNa  tracciabilità  dei  requisi/.         ü  La  tracciabilità  è  un  aspeNo  di  qualità  di  un  proge[o  fondamentale  per  una  vasta   gamma  di  aYvità,  come  lanalisi  degli  impaC  di  un  cambiamento  di  requisiF,  la   verifica  della  corre:ezza  di  unimplementazione  ed  il  tesFng.  20  
  21. 21. La  tracciabilità   traceability     Nel  Require  Based  TesFng  quindi  assolutamente  fondamentale  avere   uno  strumento  che  ci  evidenzi  la  tracciabilità.  21  
  22. 22. Polarion  Requirements  e  Polarion  QA   un  unico  tool,  dal  requisito  al  test  22  
  23. 23. Polarion  Requirements  e  Polarion  QA   un  unico  tool,  dal  requisito  al  test  23  
  24. 24. Polarion  Requirements  e  Polarion  QA   un  unico  tool,  dal  requisito  al  test  24  
  25. 25. Polarion  Requirements  e  Polarion  QA   un  unico  tool,  dal  requisito  al  test   Configura/on   Cer/ficazioni  di   Test   Management   Qualità  e   Management   Conformità   Ges/one   Ges/one   Requisi/   Documentale   Ges/one   Repor/s/ca   Fornitori   Direzionale   Process   Polarion   E-­‐Collabora/on   Governance   So-ware  25  
  26. 26. Polarion  Requirements  e  Polarion  QA   un  unico  tool,  dal  requisito  al  test  •  CollaboraFon   ü  GesFone  fornitori  ed  integrazione  dei  processi  fra  aziende  partner   ü  efficienza  e  controllo  del  processo,  tempesFvità  delle  comunicazioni   ü  l’individuazione  degli  aNori  e  la  definizione  delle  azioni  che  debbono  svolgere  a  fronte  di  ciascun  evento   ü  ges0one  ordinata  e  controllata  dei  processi  aziendali   ü  possibilità  di  verificare  in  ciascun  momento  lo  stato  del  flusso  di  lavoro  •  Asset  Management   ü  cosFtuiscono  una  ricchezza  per  l’azienda,  è  importante  gesFre    il  loro  ciclo  di  vita,  in  ogni  momento  il  loro   stato  e    le  correlazioni  fra  essi.  •  Service  Delivery  e  Change  Management   ü  requisiF,  configurazioni,  codice  so5ware,  testcase,  rilasci  integraF   ü  iter  evolu0vo,  nuove  versioni,  regressioni,  autorizzazioni,  dismissioni   26  
  27. 27. Polarion  Requirements  e  Polarion  QA   un  unico  tool,  dal  requisito  al  test  •  GesFone  Documentale   ü  documenF  in  formato  eleNronico   ü  workflow  per  il  controllo  delle  fasi  di  processo   ü  classificazione  avanzata  dei  documenF   ü  consultazione  e  lavorazione  mulFutente/concorrente  di  Word  documents   ü  Firma  digitale  •  ReporFsFca  Direzionale   ü  monitorare  processi  e  ciascuna  Fpologia  di    informazione   ü  classificazione,  approvazione  e  archiviazione  dei  documenF   ü  strumenF  di  sFma  budget,  analisi  pre/post    valutazioni  progeNuali  •  CerFficazioni  di  Qualità  e  Conformità   ü  Modelli  CMMI,  ISO,  Medical  Standard  IEC  62304   ü  Reports  automaFci  e  live   27  
  28. 28. Polarion  Requirements  e  Polarion  QA   un  unico  tool,  dal  requisito  al  test  28  
  29. 29. Polarion  Requirements  e  Polarion  QA   un  unico  tool,  dal  requisito  al  test   Workitem descrive un artifact che vogliamo gestire e controllare in un progetto: Può essere in relazione Segue un processo con altri Work item Può avere una Può cambiare pianificazione e mantenere la storia29  
  30. 30. Polarion  Requirements  e  Polarion  QA   un  unico  tool,  dal  requisito  al  test   Document Requirement Change Request Task Test30  
  31. 31. Tes/ng  session       ü Definire  requisiF  e  test  case  in  Polarion   ü Disegnare  i  test  case   ü Creare  i  test  case   ü Esecuzione  dei  test   ü Verificare  i  risultaF  dei  test   ü Verificare  la  test  coverage   ü GesFre  e  tracciare  i  task  e  i  difeY   ü GesFre  la  test  library  31  
  32. 32. What’s  next ContenuF  disponibili  su:   Canale  youtube  di  Emeraso-       Canale  slideshare  di  Emeraso-     Gruppo  linkedin  Polarion  Italy     www.emeraso-.com   www.polarion.com     Q& A ?
  33. 33. Grazie!   27  Giugno  2012   Gian  Giacomo  Ermacora   So-ware  and  Product  Consultant  per  Emeraso5     EMEA  Presale  Engineer  per  Polarion  So5ware     giangiacomo.ermacora@emeraso-.com   Emeraso5  University   Marcella  Arrabito   marcella.arrabito@emeraso-.com     011.19879273  33  

×