Una dintre cele mai mari provocări ale echipelor Agile este o planificare a activităților de testare care să respecte următoarele condiții:
BDD (Behavioral Driven Development) rezolvă prima parte prin crearea unui limbaj comun între Product Owner și echipă oferindu-i _Product Owner-_ului o vizibilitate cât mai bună și o mapare cât mai curată între criteriile de acceptanță și scenariile given-when-then, care mai departe pot fi testate automat sau manual.
Pentru a rezolva însă a treia parte avem nevoie de ceva care să prezinte clar Product Owner-ului într-un mod non-tehnic și foarte ușor de înțeles care scenarii de testare sunt automatizate, ajutându-l astfel să poată lua decizii bazate pe risc pe partea de testare și să decidă împreună cu echipa ce merită a fi automatizată. Aceasta permite în același timp o mai bună aliniere pe testele de regresie și optimizează modul în care Product Owner-ul înțelege pachetele de regresie ajutându-l spre exemplu să reducă lungimea fazei de UAT.
Spider este o aplicație pe care am scris-o pentru a rezolva această a treia parte. Creează un raport al testelor automate cu o mapare clară între scenariile de testare scrise în format BDD și testele automate efective. Folosind acest raport, Product Owner-ul poate decide mai departe dacă vrea să ridice nivelul de acoperire al testelor automate în ariile de business mai riscante, să tragă un semnal de alarmă dacă user story-uri cu impact scăzut sunt tratate cu o importanță prea mare.
Spider se bazează pe convenții. Criteriile de acceptanță din User Stories sunt transformate în scenarii given-when-then (GWTs). Aceste GWTs se regăsesc în JIRA (aplicația pe care o folosim pentru Agile Project Management) într-un task de testare legat de story. Fiecare GWT are un id. Convenția este ca acest id să identifice în mod unic un scenariu GWT dintr-un story. În cadrul testelor de Selenium vom marca scenariile acoperite de acel test folosind o adnotare Java numită @Covers.
Spider va genera un raport precum cel de mai jos:
Raportul generat va prezenta grafic cât de mult dintr-un user story este acoperit de testele de Selenium. Partea verde va spune valoare exactă a procentului de acoperire (lungimea totală a unei bare reprezintă numărul total de story points). Partea albastră nu are o conotație negativă (motiv pentru care nu am ales roșul). Spune doar ca _Product Onwer-ul este confortabil cu faptul că anumite scenarii nu vor fi automatizate.
Spider va calcula și acoperirea la nivel de sprint folosind o medie ponderată în raport cu numărul de _story points, luând în considerare doar User Story-urile cu valoare funcțională, nu și pe cele pur tehnice. Spre exemplu, dacă avem:
Media ponderată va fi: (550+2100+8*60)/(5+2+8)=62%.
Raportul generat va conține și o pagină cu maparea detaliată dintre GWT id și testul de Selenium care acoperă acel scenariu.
Spider poate fi rulat în orice moment pentru orice Sprint. Va considera doar acele user stories care au scenariile GWT deja create. Pentru a produce însă rezultate relevante, recomandarea este să se ruleze chiar la finalul Sprint-ului.
Spider nu este încă o aplicație open source și momentan poate fi folosită doar în cadrul Endava. Sunt planuri pentru a transforma acest proiect într-unul open source.
de Ovidiu Mățan
de Mircea Vădan
