context driven testing
7 Principii de bază ale testării bazate pe context, cu un exemplu:
cum se adaugă elemente ale unui tablou
Când conduc spre aeroport, de obicei iau autostrada care mă va duce acolo în timp minim și evită taxele. Dar în acea zi, am luat o rută rutieră locală mai lungă, cu taxă. Pentru că mi-am dorit câteva minute în plus cu prietenul meu aflat la volan, care a parcurs o distanță foarte mare pentru a petrece weekendul cu familia noastră. Cea mai proastă alegere normală, în acest caz, sa dovedit a fi cea mai bună.
Dar, ia în considerare acest lucru.
Ce se întâmplă dacă aș avea puțin gaz?
Ce se întâmplă dacă nu aveam bani?
Aș alege varianta diferită. De ce? Contextul.
[imagine credit ]
Atunci când luați decizii pe baza următoarelor, este o decizie bazată pe context:
- Oamenii implicați
- Împrejurări
- Obiective
- Optiuni Disponibile
- Emoții etc.
Deci, ce este testarea bazată pe context?
Context Driven Testing este o schimbare a mentalității (sau Școala de testare) dezvoltată de Cem Kaner, James Bach și Bret Pettichord. Detalii despre el pot fi găsite în celebra lor carte: Lecții învățate în testarea software-ului .
Există 7 principii de bază. Următoarele sunt selectate direct din cartea lor:
# 1) Valoarea oricărei practici depinde de contextul acesteia.
#Două) Există bune practici în context, dar nu există cele mai bune practici.
# 3) Oamenii, care lucrează împreună, sunt cea mai importantă parte a contextului oricărui proiect.
# 4) Proiectele se desfășoară în timp în moduri care deseori nu sunt previzibile.
# 5) Produsul este o soluție. Dacă problema nu este rezolvată, produsul nu funcționează.
# 6) Testarea software bună este un proces intelectual provocator.
# 7) Doar prin judecată și îndemânare, exercitate în mod cooperativ pe parcursul întregului proiect, suntem capabili să facem lucrurile corecte la momentul potrivit pentru a testa produsele noastre în mod eficient.
Nu am de gând să le explic pe fiecare dintre ele pentru că este făcut pentru noi de către experți înșiși aici .
Pur și simplu voi face o explicație bazată pe scenariu în ceea ce mă privește pe testarea bazată pe context.
Un exemplu de testare bazată pe context:
Să spunem că încep un proiect de testare - Proiectul A care include testarea de la capăt la cap pentru o aplicație bazată pe web.
Care ar fi strategia mea?
Conform proceselor standard, aceasta va fi succesiunea evenimentelor:
- Adunați cerințele și înțelegeți aplicația
- Creați un plan de testare
- Creați documentația de testare - scenarii de testare, cazuri de testare, matrice de trasabilitate etc.
- Solicitați revizuirea și aprobarea tuturor documentelor
- Configurați mediul QA și datele de testare
- Efectuați executarea testului
- Creați rapoarte de erori
- Generați și partajați rapoarte de stare de execuție a testelor etc.
Dacă îmi pun întrebarea: „Cum am decis că asta trebuie să fac?” Răspunsul meu ar fi cele mai bune practici, standardele de asigurare a calității, liniile directoare din industrie, liniile de bază ale experienței anterioare etc., nu?
Repet ce am fost învățat să fac sau ce am văzut făcând alții.
Acum, este ceva în neregulă cu asta? Deloc. Acest lucru ar putea funcționa chiar și pentru că există un anumit sentiment de repetabilitate și testare în timp a acestei abordări. Cu toate acestea, deschide calea pentru rezultate optime?
Îndoielnic. De ce?
Deoarece cu fiecare proiect veți face față unor circumstanțe diferite:
- Cerințe documentate vs. nedocumentate
- Lucrări strânse vs. echipe distribuite geografic
- Echipe de dezvoltare și testare care aparțin aceleiași companii vs. concurență
- Timp suficient vs. Programuri strânse
- Compoziția echipei tale - Noii veniți vs. cei cu experiență. Antrenat față de cei neinstruiți.
- Disponibilitatea instrumentelor - Manual vs. utilizarea instrumentelor de gestionare a testelor
- Tipul proiectului - Necesită respectarea strictă a regulilor (FDA sau bancare) vs. experimentale (cum ar fi social media)
- Tehnologia proiectului.De exemplu:nu ați testa web și o aplicație Windows în același mod
- Cerințele clienților (Unii doresc rapoarte zilnice detaliate, unii doresc doar cele mai importante)
- Proces urmat (Agile vs. Tradiționale, scripturi vs. teste exploratorii)
Această listă nu este exhaustivă și știți la fel de bine ca mine că există multe variabile pentru fiecare proiect.
Testarea bazată pe context este atunci când lăsați aceste circumstanțe să decidă practicile de testare, tehnicile și chiar definițiile, mai degrabă decât standardele percepute de industrie „ cele mai bune practici' .
Acum, să presupunem că acestea sunt detaliile cu care lucrez pentru Proiectul A:
- Lucrez cu o echipă formată din 5-4 noi și un tester cu experiență.
- Nu am cerințe documentate.
- Echipa mea este în India, iar echipa de dezvoltare este în SUA, așa că lucrăm cu fusuri orare opuse.
- Clientul dorește un raport de stare detaliat zilnic
- Folosim un instrument de urmărire a erorilor bazat pe web, cum ar fi Mantis sau Bugzilla și asta este tot ce avem.
- Trebuie să fac 2 runde de testare în 10 zile cu 3 zile pentru documentația de testare
Iată un plan de joc dur:
1) Întrucât mulți nou-veniți fac parte din echipă, avem nevoie de o mulțime de recenzii inter pares.
convertor de la youtube la wav online gratuit
2) De asemenea, avem nevoie de cel puțin 2 întâlniri de discuții cu echipa BA și Dev. Acest lucru trebuie să fie formal, deoarece echipele sunt amplasate în altă parte și nu prea am posibilitatea să merg până la ele cu întrebări.
3) Este o cronologie de testare agresivă pentru documentare. Cu cât scriem mai multe documente, cu atât avem nevoie de mai multe recenzii, ceea ce echivalează cu mai mult timp. Deci, va trebui să păstrăm documentația minimă. Vom documenta doar principalul TC de la capăt la cap iar restul vor fi testat explorator .
4) Rapoartele de stare zilnice în timpul execuției testului vor fi create și trimise EOD în fiecare zi.
5) Majoritatea testelor sunt exploratorii, deci sfătuiți timpul pentru a încerca să faceți o scurtă schiță a fiecărui test executat. Astfel știm ce este testat și ce nu.
6) Defectele vor fi raportate în timp real în Mantis. Deoarece echipa lucrează într-un alt fus orar, ar putea fi necesar să aștepte o zi întreagă înainte să audă de la echipa QA, în cazul în care au nevoie de o clarificare. Prin urmare, setați un apel zilnic la o echipă convenabilă, unde echipa QA va demonstra recreerea bug-urilor. În acest fel, nu va mai fi nevoie să așteptați sau să urmăriți.
Și așa mai departe.
După ce aveți o strategie generală, scrieți un plan de testare de bază care să explice aceste puncte. Acum, sunteți pregătiți să intrați într-un proiect de testare după o analiză atentă și personalizată a făcut o strategie de succes.
În concluzie:
Aceasta este Testare bazată pe context; făcând din circumstanțele dvs. (nu din standarde) principalele elemente de intrare și influențatori pentru strategia dvs. de testare. Ne îndeamnă să privim în jur și să luăm în considerare tot ceea ce te înconjoară.
Personal, sunt îndrăgostit de acest concept, deoarece prea des practicile de testare sunt percepute ca rigide și bazate pe imitație. Cineva a făcut-o și a reușit, așa că o voi face și eu. Acesta este genul de imagine care îi sperie pe oameni de a încerca și de a rămâne într-o carieră de testare.
Dar există o mulțime de posibilități pentru gândirea creativă, abilitățile analitice și luarea deciziilor. Pentru a afla mai multe, citiți subiectul în linkurile furnizate mai sus.
Testare fericită bazată pe context
Lectură recomandată
- Cele mai bune instrumente de testare software 2021 [Instrumente de automatizare a testelor de calitate]
- Descărcare eBook Descărcare Primer
- 20 de întrebări simple pentru a vă verifica software-ul Testarea cunoștințelor de bază [Test online]
- 7 sfaturi de bază pentru testarea site-urilor web multilingve
- Testarea încărcării cu tutoriale HP LoadRunner
- Diferența dintre Desktop, Client Server Testing și Web Testing
- Ce este testarea Gamma? Etapa finală de testare
- Ce este testarea conformității (testarea conformității)?