pentru orice tester solo acolo am recomanda conduce un bug Bash regulat/activitate de testare mob. Este o activitate pe care o puteți rula la sfârșitul unui ciclu Sprint/feature dev. Invitați echipa, luați câteva gustări/băuturi împreună și faceți ca toată lumea să testeze aproximativ o oră.
Setup
s-ar putea dori să vă asigurați că aveți bun dispozitiv/browser acoperire prin asigurarea toată lumea este configurat cu date/dispozitive înainte de mână. S-ar putea să doriți, de asemenea, să pregătiți câteva documente de ajutor pentru a ajuta oamenii să înceapă. Îmi place să am o mindmap pe idei de acoperire pregătite înainte de mână, astfel încât oamenii să aibă un indicator vizual a ceea ce testează. S-ar putea crea, de asemenea, o grămadă de conturi de testare înainte de mână și să le distribuie echipei.
Light Bug de raportare
ar trebui să încurajeze raportarea bug greutate de lumină;
- poate că oamenii scriu bug-uri pe note lipicioase
- adăugați bug-uri la o foaie de calcul partajată
- sau ridicați bug-uri Jira direct de la Slack folosind o /jirio create bug shortcut
accentul ar trebui să fie pe găsirea de bug-uri, nu pe a fi prins în modul de raportare a acestora. Puteți clarifica întotdeauna problemele în continuare după Bug bash dacă aveți nevoie de mai multe informații.
ce să testați într-un bug bash
am o euristică în 3 pași pentru a decide ce să testați (gândiți-vă; ghid sau regulă generală):
- ce s-a schimbat recent? Schimbarea introduce un nou risc. ce caracteristici au fost construite? Ce cod a fost refactorizat? Ce biblioteci au fost actualizate? Concentrați echipa pentru a testa mai întâi aceste zone
- testarea regresiei. Aveți o listă de verificare cu cel mult o duzină de scenarii de funcționalitate de bază (poate în jurul înregistrării, plăților și principalele lucruri pe care le fac oamenii cu produsul dvs.). Cereți oamenilor să ia în considerare aceste cazuri în timp ce faceți 1), poate cereți oamenilor să pună acolo Nume lângă un caz atunci când îl testează, astfel încât să vă puteți face o idee despre acoperire
- ce alte teste ar trebui/am putea face? Uneori ar putea avea sens să faceți o sesiune de testare a erorilor pen sau o sesiune de testare a performanței sau o sesiune de testare a browserului încrucișat, dar nu trebuie să se întâmple de fiecare dată
Test în producție
dacă puteți; test în producție. Nu există un mediu asemănător.
dar dacă nu poți testa în producție, asigură-te că mediul tău de testare este stabil, datele tale sunt configurate și ai dat echipei tale solicitarea „nu atinge, cu excepția testării Bug bash”.
postați Bug Bash
asigurați-vă că mulțumiți oamenilor pentru timpul lor, numărați bug-urile și dați kudos celui mai bun vânător de bug-uri. Testarea / calitatea este o responsabilitate a echipei până la urmă. Trimiteți un e-mail de mulțumire cu rezultate și trofee de premiere. Am înmânat acest trofeu al unui bug de rinocer în rășină pe o bază de trofee vânătorului nostru de bug-uri numărul unu înainte:
