- testarea
- Organizarea muncii
- seleniu
Bună ziua!
Există o mică companie în care există două tipuri de angajați - dezvoltatori și implementatori. Dezvoltatorii fac un designer, implementatorii îl personalizează pentru client, care vede doar interfața web.
Dezvoltatorii fac o revizuire a codului unul de altul, încearcă să actualizeze funcționalitatea și să corecteze erorile prin scrierea testelor de unitate. După acumularea unui set de modificări, acesta este transmis pentru testarea implementatorilor. Ei încearcă și testați-l și dacă nu există erori vizibile, atunci se eliberează o eliberare a designerului, care poate fi transferată clientului după setare.
Cele mai frecvente locații de apariție a erorilor: o comună a subsistemelor și o interfață web.
Noi credem că, pentru a face lucrurile în regulă, sistemul ar trebui să fie acoperit cu teste de integrare. Ne gândim în direcția de seleniu (ar fi recunoscător dacă în comentarii sfătui altceva) că el a fost doar a face același lucru care face acum implementatori - interfață protykival și dacă este de așteptat reacția, cred că totul este în regulă (desigur, noi înțelegem, că testele nu garantează absența erorilor).
Vedem următoarele probleme când organizăm o nouă divizie:
1) Marea varietate de opțiuni pentru construirea de produse din blocuri ale designerului - care funcționează pentru un singur client, poate să nu funcționeze pentru altul din diferite motive. Pe ce configurație a designerului să efectueze testele?
2) Proiectantul este o specificație clară (și nu în acest moment), o listă de sarcini în bug tracker, și, prin urmare, nu este testere clar că testul. Puteți încerca să scrieți teste pentru noi sarcini și, treptat, acestea vor acoperi totul, adăugând în liniște teste pentru funcții care nu intră în sarcini noi. Va funcționa?
3) Depășirea capacității unității de a menține actualizarea testelor. Mai degrabă, problema este exagerată, dar cu toate acestea, dacă se dovedește că testele ar fi prea mult, iar când o versiune nouă a testere de produs nu va avea timp să actualizeze testele de sub platforma schimbat?
„1) O mare varietate de opțiuni pentru produse de construcții din blocuri de construcție - ceea ce funcționează pentru un client poate să nu funcționeze într-un alt din diverse motive pe un designer de configurare pentru a efectua teste.?“
Dacă intenționați să creați o echipă normală de testeri care să facă testele și să nu testeze (adică să scrie automatizări), atunci ce diferență există în câte opțiuni - testați totul. Principalul lucru este că resursele suficiente pentru suma corectă de virtuale.
2) Proiectantul este o specificație clară (și nu în acest moment), o listă de sarcini în bug tracker, și, prin urmare, nu este testere clar că testul. Puteți încerca să scrieți teste pentru noi sarcini și, treptat, acestea vor acoperi totul, adăugând în liniște teste pentru funcții care nu intră în sarcini noi. Va funcționa?
Mai întâi, trebuie să configurați procesul de testare în sensul că aplicația este implementată, un test de sănătate a trecut și acest lucru a fost notificat în continuare de CI. Când sistemul va funcționa, puteți adăuga teste, actualiza testele. Dar un astfel de sistem ar trebui proiectat și dezvoltat de un lider cu experiență în domeniul calității, care va înțelege mai întâi produsul și va putea să facă un sistem suficient de flexibil în care toate testele și toate configurațiile pot fi mai apoi zapizcate.
3) Depășirea capacității unității de a menține actualizarea testelor. Mai degrabă, problema este exagerată, dar cu toate acestea, dacă se dovedește că testele ar fi prea mult, iar când o versiune nouă a testere de produs nu va avea timp să actualizeze testele de sub platforma schimbat?
Ar trebui să existe teste care depind puțin de versiune. Ar trebui să fie posibilă oprirea rapidă a testelor irelevante. Testele nu sunt un scop în sine, ele reprezintă o măsură suplimentară a calității produselor și simplificarea dezvoltării prin automatizare. La urma urmei, ceva nu poate fi testat, dar va funcționa, deoarece a fost testat de dezvoltator în testarea unităților.
Ei bine, este clar că, din experiență, vor ajunge să înțeleagă cât de mult și ce trebuie să fie testate pentru a ține pasul. Vor fi mulți - aruncați partea necritică.
Experiența arată că, în ciuda tuturor testelor posibile - care acoperă UI cu teste - este necesar. Ce se întoarce în funcție nu înseamnă că interfața va afișa și va afișa corect)
Evgeniy _. Care este problema cu scrierea testelor UI automate?
Sabotor. Este scris în tine "La urma urmei, ceva nu poate fi testat, dar va funcționa, pentru că a fost testat de dezvoltator în testări unitare". Nu cu mine.
Dezvoltator de automatizare de testare
primul gând care a avut loc: dacă apar probleme la joncțiunea componentelor, poate să lucreze în primul rând asupra arhitecturii?
Testarea, la urma urmei, constată numai o manifestare a erorilor. Și este de dorit eliminarea cauzelor care au dus la apariția lor. În caz contrar, veți cheltui mai mulți bani pentru a găsi erori, eliberarea va fi amânată, clienții vor fi nemulțumiți de întârzierile actualizărilor.
Citiți bugtracker-ul pe subiect, care sunt cauzele erorilor descoperite. De regulă, există mai multe rădăcini de rău. Aceasta este ceea ce trebuie să acordați atenție.
Ne place programul ModelView strat oferă cel puțin o treime eroare, noi de automatizare, e scump, iar tu doar nenorocit arunci instrument pe care o facem UI și du-te la ceva care este de validare de la dezvoltator pe computer, mai degrabă decât în dimineața pe server, după un plin asamblare. Un alt lucru este că șefii nu pot face un astfel de pas, sunt în robie cu vânzătorul acestui instrument. Ie migrarea este posibilă, dar nu brusc.
Trimiteți-le prietenilor: