vineri, mai 11, 2012

A/B Tests (Lean)

Testele A/B (Split Tests) sunt foarte putin cunoscute. Pentru mine a fost o mare mirare cand am auzit de ele. Ca o recapitulare. Exista teste unitare (in izolare). Exista mocks, stubs, dummy objects. Exista teste de integrare (integration tests). Teste functionale (automate sau nu). Exista TDD. Exista BDD. Exista acoperire cu teste. Existe test case-uri. Exista teste de regresie. Exista UAT -  user acceptance tests. Exista teste de performanta si load. Exista biblioteci Java: JUnit, TestNG | JMock,Mockito | DBUnit, HTTPUnit | JBehave | JMeter, etc.

De unde vin A/B Tests? Din alta lume! Daca setul de practici enumerat mai sus vin din metodologiile agile (incluzand Scrum si XP) in care testatea unitara/automata constituia o practica de baza, A/B tests vin din lean, metodologia la baza careia sta eliminarea pierderii de timp (en. eliminate waste). Ce e WASTE intr-un proiect, orice consuma resurse si nu aduce valoare. Unul din principalele motive de pierdere de timp este implementarea de functionalitati pe care nu le foloseste nimeni. Cazul extrem este cel al unui intreg produs pe care nu il foloseste nimeni.

Cum e posibil sa creezi un produs pe care nu il foloseste nimeni? Una din cele mai comune situatii este aceea in care clientul este necunoscut - adica nu iti cunosti inca cllientii (alta posibilitate este ca cel ce reprezinta clientul in agile, sa nu il reprezinte de fapt). Te adresezi unei piete in care tu crezi ca exista o problema care merita rezolvata - care ti-ar putea  permite sa construiesti ceea ce se cheama un "self sustenable business". In acest caz nu are cine sa-ti mai spuna care din story-uri aduc valoare, nu are cine sa mai vada demo-urile, etc. Practic esti gata sa construiesti un  produs pe care nimeni nu il vrea.

Deci suntem gata sa implementam o noua functionalitate (feature) in aplicatia noastra (incremental - o adaugam unui set de functionalitati pe care le-am implementat deja - toate legate incontinuu prin integrate continua). Daca folosim Agile, reprezentantul clientului care sta on site cu tine ar trebui sa aleaga dintr-un backlog of features pe cea mai valoroasa. In stil agile se implementeaza si se livreaza clientului la demo pentru a o valida - UAT. Dar ce se intampla in cazul in care nu-ti stii clientii? Ar trebui facut acelasi lucru - ar trebui validata intr-un fel.  Iar validarea in acest caz o faci cu A/B tests - pentru ca acestea iti ofera posibilitatea de a vedea daca festure-ul tau aduce valoare sau nu clientilor.

Putem spune in acest caz ca nu avem o functionalitate de implementat ci o ipoteza de testat = experiment de facut (daca o ipoteza cade la teste se elimina functionalitatea din spate). Avem deci un experiment care are mai multe ipoteze (una din ipoteze este aplicatia ta fara noua functionalitate) - fiecare ipoteza cu un procent de  utilizatori/vizitatori care iau parte la el. Se urmaresc in site o serie de metrici care spun clar cum a influentat acel experiment experienta utilizatorilor/vizitatorilor cu aplicatia.

Deci se ia functionalitatea si se face asa (un exemplu in care se experimenteaza o a doua pagina de landing cu un alt continut:  UVP schimbat, design, etc.):
String[] firstHypothesis = { "landing_1", "50" };
String[] secondHypothesis = { "landing_2", "50" };

Hypothesis hypothesis = cohortsManager.setupVisitorsExperiment("LANDING PAGE",
getRequest().getRemoteHost(), firstHypothesis, secondHypothesis);

Se creaza pe loc experimentul daca nu exista (se salveza in baza de date cu tot cu ipoteze asociate si si cu procentele lor). Se returneaza ipoteza in care e utilizatorul curent - daca face deja parte din experiment se returneaza ipoteza pe care o avea. Daca e nou i se asociaza o ipoteza astfel incat sa se respecte procentele stabilite per experiment. Ipoteza se foloseste in redirectarea vizitatorului spre o pagina de landing sau alta.

Mergand la extrem in a compara/deosebi Agile cu Lean: story-urile se transforma in experimente (ipoteze care trebuie testate). Testele de acceptanta clientului se transforma in split (A/B) teste. Integrarea continua se tranforma in livrare continua (continous delivery) - functionalitatile implementate se expun repede in fata clientului pentru a fi validate. Scrum Board se transforma in Kanban - limitare clare de task-uri care se implementeaza la un moment dat pentru a nu creea functionalitati pe care nu le folosesc nimeni = maximixare de pierdere de timp. Deci daca se infunda pe undeva board-ul, trebuie desfundat pentru a merge mai departe - nu continuam sa il infundam. Dezvoltatorul este implicat de la un capat la altul in dezvoltarea task-ului - incluzand validarea care e o interactiune indirecta cu clientii.

Actionable Metrics