is there any start stop boundary qa s role scrum
Quin és el paper de QA en Scrum: Activitats Scrum per als verificadors?
Aquest article no és només un tutorial sobre alguns processos o mètodes o instruccions sobre com funcionar com a control de qualitat. Més aviat, aquest és un article en el qual vull compartir la meva pròpia experiència de treballar com a QA sènior a SCRUM.
El meu anterior CTO sempre ho deia ‘Amb la llibertat arriba la responsabilitat’. Si se us dóna la llibertat de fer la vostra feina a la vostra manera, només vosaltres i vosaltres sou els responsables del vostre treball, tasques o activitats.
D’això es tracta Scrum !! Deixeu-me fer-vos una idea bàsica sobre Scrum a mesura que avancem.
Què aprendreu:
Visió general de Scrum
Scrum és un subconjunt de metodologia àgil i és un marc de procés lleuger que s'utilitza àmpliament.
Scrum ens ajuda a mantenir feliços els clients donant-los el producte en petits mòduls, i també manté al client conscient que els seus requisits que canvien sovint poden frenar les activitats. Les versions són curtes i es treballa segons la capacitat de l’equip implicat, de manera que es redueixen en gran mesura les possibilitats d’errades o de clients infeliços.
D’altra banda, els requisits (en aquest cas User Stories) s’acaben abans d’iniciar el Sprint per evitar la reelaboració i, per tant, es produeix un Sprint retardat o fallit (sempre hi ha excepcions).
Però el desafiament més gran per a un control de qualitat és que el període de llançament és curt, un Sprint sol ser un cicle de 15 dies. Per tant, lliurar un producte ‘gratuït’ d’errors en un màxim de 4 a 5 dies (tret del temps de desenvolupament) necessita molts esforços i un pensament intel·ligent.
Sóc el control de qualitat del meu equip:
Ah, sí, sóc el control de qualitat del meu equip i sóc un jugador important del meu equip. Per què?? Perquè els clients, BAs, Scrum Master i tothom són confusos sobre la qualitat, l’aspecte i el rendiment de l’aplicació o del producte.
A Scrum, com que la durada del sprint és curta, el control de qualitat ha de funcionar de manera intel·ligent i, per tant, la necessitat del control de qualitat d’implicar-se des del principi esdevé molt important. Hi ha ocasions en què un control de qualitat pot exercir el paper de propietari de producte proxy quan el PO no està disponible, ajudant així el BA a crear els escenaris / casos de prova dels criteris d’acceptació.
Els desenvolupadors també s’acosten al QA en moments en què tenen problemes amb la funcionalitat o les regles empresarials. A Scrum, l’objectiu només és tenir un llançament de Sprint suau i reeixit i no es tracta de 'El meu treball' o 'El vostre treball' per donar un cop de mà quan el vostre equip us acosti.
En la vinculació de l’equip Scrum, les relacions saludables entre els membres de l’equip tenen un paper molt crucial i, en ser un control de qualitat, hauríeu de tenir molta cura mentre comuniqueu la vostra opinió sobre les històries d’usuaris que esteu provant. La vostra comunicació hauria de versar sobre la història o la funcionalitat de l'usuari i no sobre la persona que hi va treballar.
A Scrum, el QA no és jutjat ni apreciat pel nombre d’errors que descobreix, sinó també per com interactua amb l’equip, ajuda l’equip i motiva l’equip fins i tot en moments difícils.
A part de provar les tasques de sprint, escriure plans de proves / casos de prova / documents de publicació també intenten implicar més perquè la durada de la versió de Sprint és curta i l'objectiu és el mateix per a tothom 'Per oferir un producte sense errors funcionant amb èxit ajudant-se mútuament'.
Un QA participa en gairebé totes les activitats realitzades en un Sprint i tècnicament no hi ha límits per a l’inici o l’aturada de les activitats de QA. A diferència del model tradicional de cascada, on el control de qualitat només es limita a provar el llançament, aquí el control de qualitat té moltes més responsabilitats. Per tant, suggeriria provar i fer més de les activitats següents.
Activitats a seguir
A continuació es detallen algunes activitats que us suggeriria que seguiu com a control de qualitat a Scrum.
pl sql preguntes d’entrevistes amb respostes
# 1) Dwell Deeper:
Amb això, vull dir que quan les històries dels usuaris i els seus criteris d’acceptació estiguin a punt, estudieu-les a fons i reflexioneu més sobre les dependències, els resultats ocults i si hi ha una manera millor de fer-ho.
Comunicar-se i col·laborar-hi amb el BA i l’equip de desenvolupament sobre això, perquè pot passar que tampoc s’ho hagin pensat. Comparteix les teves idees i troballes amb l’equip.
Si trobeu que hi ha obstacles ocults o impactes negatius, augmentar-los amb Scrum Master i els desenvolupadors els donarà temps per pensar i actuar en conseqüència. Aquesta activitat a Scrum esdevé molt crítica quan el projecte és gran i quan hi ha mòduls repartits entre els equips.
Ara, mentre estudieu les dependències, l’impacte és molt important per a un control de qualitat i fins i tot fa que l’equip de desenvolupament en tingui coneixement. Per fer-ho, discutiu amb els QA dels altres equips i preneu-los les aportacions.
# 2) Impliqueu les estimacions:
La pràctica habitual és incloure un control de qualitat en les estimacions, però moltes vegades a causa del petit sprint, és possible que no es demani al control de qualitat que provi les tasques i deixi-les amb 3/4/5 dies per a la prova.
No ho accepteu mai. Alceu la veu si cal, però assegureu-vos que proporcioneu la vostra estimació de proves, que hauria d’incloure el temps que necessiteu per a cada treball.
Pot incloure temps per a la investigació, temps per a configuracions, temps per recopilar dades històriques, etc., però ser estricte i específic sobre el temps necessari per dur a terme les activitats de prova i afegir aquests valors temporals a la història de l’usuari juntament amb el temps de tasques de desenvolupament. .
Això és molt important perquè si intenteu fer la vostra feina en el temps assignat i si no podeu completar-la, només seràs responsable del fracàs. Quan s’afegeix el temps de control de qualitat, el Scrum Master, l’OP serà conscient de les activitats de control de qualitat implicades i del temps necessari.
# 3) Emparellament de QA de desenvolupament:
L’ideal seria que a Scrum, les històries d’usuaris de Sprint es lliuressin a les proves un cop finalitzat el desenvolupament i un cop feta la prova de desenvolupament, però el problema aquí és que en el moment en què es lliura al control de qualitat per provar amb prou feines 4-5 dies resten a la demostració o revisió.
Ara, si, com a control de qualitat, detecteu fins i tot 4 bloquejadors o fallades funcionals, haureu de treballar a la nit o el cap de setmana per complir la data de llançament, ja que hi haurà proves funcionals, regressions, etc. Sembla el model tradicional de cascada que no és la millor manera de fer-ho, a Scrum la forma més intel·ligent és 'Prevenir defectes en lloc de trobar defectes'.
Per tant, la solució és fer un emparellament de QA de desenvolupadors i realitzar una ronda bàsica de proves a la configuració de desenvolupadors tan aviat com els desenvolupadors estiguin preparats amb les històries fins i tot abans d’una versió formal per a les proves.
Es poden tenir en compte els següents criteris per fer un BVT a la configuració del desenvolupador per a les històries de l'usuari:
- Criteris d'acceptació de cada història de l'usuari: BVT de les històries de l'usuari d'acord amb els criteris d'acceptació.
- Falta de confiança en els desenvolupadors: De vegades, els desenvolupadors no confien en algunes implementacions i, per tant, discuteixen sobre aquestes implementacions i fan un BVT per a aquells que tinguin la mateixa configuració de desenvolupadors.
- Proves de dependències / impacte: BVT de les dependències o impacte en / dels altres mòduls de les noves implementacions.
- Proves unitàries: Feu un BVT amb el desenvolupador de les proves unitàries que hagin creat, si cal ajudeu-les afegint o actualitzant les proves unitàries.
Això us ajudarà a reduir l’avanç i l’anada dels errors, estalviant el temps de tots, ja que abans del llançament a QA, la majoria dels errors funcionals o fallits ja estan solucionats. Recordeu que heu de registrar aquests defectes a les vostres eines abans de la revisió del sprint i fer-los passar fins a l'estat 'tancat'.
# 4) QA a la pissarra blanca:
Sempre he animat personalment el meu equip a incloure tasques de control de qualitat al tauler White Scrum, inclosos els errors. Això ajuda Scrum Master a esbrinar l’estat de control de qualitat d’una història d’usuari simplement mirant el tauler.
El núm. dels errors de la llista de tasques, els errors de la llista En curs, les activitats de control de qualitat de la llista De tasques, en curs i Fet parlen per si soles. Em resulta molt dolorós que algú vingui a preguntar sobre l'estat de la prova de les històries individuals per a un Sprint perquè he de dedicar més temps a treure el meu estat de les eines de compilació i mostrar-los o redactar un correu electrònic.
Simplement prefereixo assenyalar la persona al Scrum Board i deixar-la distingir per si mateixa. Preferiu un color brillant i excepcional per als fulls QA Sticky.
# 5) Documentació:
Aquest és un dels inconvenients o desavantatges de Scrum que, a causa de la petita mida de Sprint, no hi ha gaire temps per documentar-se i mai he vist cap escriptor tècnic en un equip de Scrum. És possible que Scrum Master / BA no actualitzi i no sempre els documents sobre la informació del producte.
El problema arriba si s’incorporen nous membres o, en el pitjor dels casos, si les regles, les funcionalitats i les funcions del negoci canvien i com fer-ne un seguiment, perquè cercar informació de les històries dels usuaris “Fet” serà com buscar una agulla en un paller.
La solució consisteix a crear una tasca independent en un sprint sempre que sigui possible (sobretot en períodes de descans o quan la càrrega de treball és molt inferior) per obtenir documentació, de manera que pugueu revisar els documents i actualitzar-los o fer que Scrum Master o BA els actualitzin.
Un control de qualitat és la persona adequada per ajudar a actualitzar els documents, ja que sou qui proveu, verifiqueu les històries dels usuaris i conegueu la funcionalitat dins i fora. Feu-ho vosaltres mateixos si no hi ha cap BA i si el vostre Scrum Master està ocupat per actualitzar-lo.
# 6) Sprint Review / Sprint Demo:
Sobretot, succeeix que el QA és l’escollit per donar la demostració a l’OP i als grups d’interès. però si no persuadeu el vostre Scrum Master perquè ho faci. Un QA és la persona adequada per fer la demostració ja que ha provat la història de l'usuari dins i fora.
Un QA pot demostrar des del punt de vista empresarial perquè coneix les funcionalitats, els fluxos i les regles del negoci. Prepareu-vos bé per a la demostració i intenteu respondre a totes i cadascuna de les preguntes que tinguin l’OP i els grups d'interès. Això us ajudarà a convertir-vos en el punt de contacte per a ells en absència de Scrum Master i BA.
# 7) Actua com un BA:
Aquesta no és una tasca habitual i ni tan sols s’espera d’un control de qualitat, però intenteu exercir aquest paper quan es produeix una oportunitat perquè un control de qualitat és la millor persona per obtenir un BA. Per exemple, intenteu pensar i visualitzar si els fluxos, les funcionalitats o les regles empresarials es poden modificar de manera que beneficiïn el client.
Penseu i cerqueu les tendències actuals de la interfície d’usuari, l’aspecte i l’aspecte de l’aplicació i com es pot beatificar, fer-la més fàcil d’utilitzar, etc. Si l’equip té algun problema, participeu i intenteu donar solució. Això donarà un impuls al vostre paper i serà un factor que contribuirà al vostre creixement professional.
Les possibilitats arriben a les trucades amb l’OP quan es discuteixen alguns problemes o en revisió / demostració on podeu donar suggeriments.
Conclusió
Scrum és una metodologia molt diferent del mètode normal de la cascada, i Scrum Master és un facilitador. Per tant, no espereu que ell / ella us defineixi les vostres activitats.
A Scrum, no hi ha cap límit d’inici i de finalització del paper d’una QA. QA necessita i ha d’estar involucrat en totes les activitats des del principi fins al final, des de la planificació prèvia fins a la revisió / demostració de l’esprint i ha de participar en totes les activitats.
Això ajudarà a entendre el producte o l’aplicació ja que (com he dit abans) no hi ha documentació adequada disponible quan es treballa a Scrum. S’espera que sigui responsable, motivat i proactiu. Per tant, no espereu que vingui ningú a dir-vos què o com heu de fer.
Heu de prendre iniciatives pel vostre compte, ajudar l’equip de totes les maneres possibles, mantenir una relació sana, fer un seguiment de les coses en curs a l’equip i, sobretot, tenir clar les vostres tasques en un sprint determinat.
Aquí no hi ha gestors que us supervisin o facin un seguiment de les vostres activitats. Estigueu sempre a punt amb la mà del vostre equip i obtindreu les millors oportunitats.
No dubteu a expressar els vostres suggeriments / suggeriments sobre aquest article informatiu a la secció de comentaris que hi ha a continuació.
Lectura recomanada
- El paper dels analistes de negocis a SCRUM i per què és millor un control de qualitat per a aquest paper?
- Preguntes en línia sobre Agile Scrum: proveu els vostres coneixements sobre Agile Scrum
- Instal·lació de l'aplicació al dispositiu i inici de proves des d'Eclipse
- Kanban vs Scrum vs Agile: una comparació detallada per trobar diferències
- Com oferir funcions de programari d’alt valor en un període curt de temps mitjançant el procés Agile Scrum
- Manifest àgil: comprensió de valors i principis àgils
- Triaging de defectes a Scrum: com s’organitza en una configuració de Scrum
- Les millors eines de prova de programari 2021 (Eines d'automatització de proves de control de qualitat)