Întrucât mediul de business se schimbă foarte rapid și e posibil să descoperim că ceea ce a fost crucial ieri ar putea să nu fie atât de important astăzi, soluțiile concepute pentru a susține afacerea ar putea necesita să fie construite cât mai flexibil posibil.
“Cum se schimbă testarea într-o lume dinamică?
Cum poate fi validată schimbarea continuă?”
Adaptarea flexibilității în soluția dvs. ar putea să nu fie ceva atât de neobișnuit în zilele noastre, deoarece experiența ne-a învățat că o soluție foarte rigidă poate deveni un blocaj la un moment dat. Cu toate acestea, implementarea unei schimbări continue în soluția dvs. poate deveni dificilă de-a lungul ciclului de viață al software-ului, chiar dacă ați proiectat cea mai flexibilă soluție. Atunci, viziunea clară este ceea ce aveți nevoie pe termen lung pentru a face ca toate aceste lucruri să funcționeze și pentru a susține afacereadumneavoastră.
Dar, deocamdată, să ne ducem chiar la sfârșitul ciclului de viață al software-ului – așa cum odată era cunoscută ca faza de testare.
Cum se schimbă testarea într-o lume dinamică?
Cum poate fi validată schimbarea continuă?
Vă puteți baza pe rezultatul testului dacă construiți o soluție flexibilă, mereu în schimbare?
Mai este nevoie de testare sau nu aduce nicio valoare?
Răspunsul la toate aceste griji și la multe altele similare ar fi că testarea, așa cum era cunoscută odată doar ca o fază, ar trebui să fie acum și mai flexibilă. Faza de testare rigidă, foarte clară, este înlocuită de colaborare continuă și contribuții din perspectiva testării, începând de la planificarea soluției până când primele teste pot fi efectiv efectuate. Construirea unei soluții „testabile” vă va oferi oportunitatea de a avea încredere în rezultatul testării și de a adapta schimbarea de care aveți nevoie, în timp ce construiți o soluție foarte dificil de testat, cel mai probabil vă va lăsa cu câteva semne de întrebare.
A vorbi despre validarea unei funcții de bază a soluției dvs. înseamnă că puteți efectua serii de tehnici de testare diferite pentru a avea încredere că ceea ce este „în construcție” se va potrivi în peisajul general. În teorie, cineva va avea o viziune foarte clară despre ceea ce își dorește sau are nevoie, dar în practică nu este întotdeauna cazul. Un tester s-ar putea găsi în situația de a valida o soluție fără specificații clare sau fără a avea o viziune clară asupra nevoilor reale. În timp ce în vechea fază de testare ai avea întreaga livrare pe masă și nu ai atinge-o până la sfârșitul ciclului de viață al software-ului, în abordarea dinamică agilă, rolul unui tester s-a schimbat, iar input-ul poate și este încurajată să fie dată cât mai curând posibil.
Puteți testa ceva când o soluție este în construcție?
Nu. Dar puteți oferi informații din perspectiva testării, puteți construi o strategie de testare, vă puteți documenta despre soluție, peisajul arhitectural, cerințele, nevoile. Doar implicarea în ciclurile de livrare vă va oferi posibilitatea ca tester de a fi informat și de a participa la activitățile curente. Puteți aborda problemele mai devreme, deoarece sunteți educat mai devreme pentru a face acest lucru.
Întrucât un profesionist în testare este implicat în ciclurile de livrare, acesta își poate și își va exprima părerea cu privire la soluția dezvoltată – cum găzduiește testarea în mod corespunzător contribuția celorlalți participanți? În ipoteza că testarea este de fapt o fază izolată, este dificil să vezi din exterior cum se desfășoară testarea și chiar și tu s-ar putea să nu înțelegi complet ce a fost testat și ce nu. Dacă testarea este complet transparentă pentru toți și poate primi și găzdui informații și feedback, o alegere educată a testelor care trebuie efectuate va crește încrederea în produs și vă va scuti de cheltuieli inutile. Abordarea are modificări, dar scopul este același – testarea ar trebui să ofere încredere și asigurare că produsul este fiabil și calitatea nu este afectată.
