Traducere. Olga Alifanova
M-am gândit o mulțime de controale și teste și cum să-i facă să coexiste armonios, și m-am gândit că ne lipsește ceva important, creând un test. Mă voi concentra pe controale automate, dar cred că gândurile mele sunt de asemenea aplicabile la non-automate.
Unele echipe au ajuns acum un progres în crearea de controale automate. Ei adopta cele mai bune practici. Clase, metode și obiecte numit în mod corect, și este clar ceea ce fac. Termeni articulat, iar în cazul în care nu sunt îndeplinite, acest lucru se raportează în mod clar și distinct. Verificările sunt create cu un nivel bun de abstractizare și reutilizarea codului, acestea sunt destul de productivi și îndeplinite rapid și fiabil. Toate acestea arata foarte cool.
Dar de ce este acest control minunat, bine scris și ușor de înțeles de toate? De ce nu există? De ce a fost ales dintre toate opțiunile cecuri? Pot să-l citesc (așa cum am spus, este bine scris), văd că ea verifică, dar aceste informații despre ea epuizat. Așa cum am înțeles că pașii și verificarea condițiilor legate de scopul său inițial? Ce este despre acest test sau comportamentul acestui sistem le-a făcut candidați demni de automatizare? Nu știu.
De ce ar trebui să ne pese de întrebarea „de ce acest test?“ Din punctul meu de vedere, rezultatele testelor automate afectează cursul testelor noastre, mai ales în echipe de lucru pe integrarea continuă. Înainte de a începe testarea manuală (presupunem pentru comoditate, care începe de îndată ce codul este gata), vom rula auto-teste, si au raportat „bun“ construi avansat sau „rele“. Sunt generalizând, pentru că ei sunt încă gândesc la asta, dar dacă a construi un „rău“, ne concentrăm imediat asupra provocărilor și să depună eforturi pentru a face un „bun“. Ne uităm la alte controale în zonele cu probleme pentru a afla ce a fost acoperit, iar apoi a crea și conduce noi teste pentru a afla mai multe. După aceea, trecem la noile provocări. În cazul în care construi este „bun“, atunci, de regulă, ne concentrăm asupra unor noi sarcini imediat. Așa cum am spus, eu sunt generalizatoare, știu că acest lucru nu este întotdeauna, dar cred că mesajul este clar.
Mi se pare, nu ne dăm seama întotdeauna cât de mult avem încredere Autotest nostru - și încredere orbește, fără să știe de ce întotdeauna un control acolo și de ce este important pentru noi. Tot ce știm despre produsele lor foarte mult, iar această cunoaștere este atât de complicat și ingenios împletesc că, fără testele automate, noi nu - nu putem păstra în minte absoyutno toate. cunoașterea implicită este de a merge în mod explicit. Din același motiv, vom crea hărți mentale și liste de verificare ne ajută să ne amintim de informații și să-l în considerare.
Aici sunt mai multe moduri de a indica obiectivul de testare:
Tocmai am început să mă gândesc la asta, dar nu cred că pentru a adăuga test de justificare - este foarte dificil. Dacă creați un test, stii deja de ce ai nevoie de ea - doar cauza creației sale este pierdut și uitat-a lungul timpului. Sau nu este disponibil pentru incepatori. Sau disponibil pentru oricine. Eu cred că studiul poate juca un rol important în îmbunătățirea procesului de testare - mai ales în Revista Autotest și proiectare de testare.