6 Errors de QA i com evitar-los

Elkling transmetent la seva saviesa

Set anys d’experiència a la branca d’Assegurament de la Qualitat en el desenvolupament de programari em proporciona la delirant confiança per seure a la meva balancí, reunir els pel·lícules al voltant i començar una història sobre com era en els bons vells temps, els errors que vaig cometre i molestament. Afegeix als joves per aprendre de les meves falles. Mentre miro tot el conscient pel foc cruixent (sí, ara hi ha un incendi, segueix amb la fantasia), adopto una mirada severa i emprenc la meva predicació. Aquí teniu sis errors de control de qualitat i com evitar-los!

1. Oblideu la imatge més gran

Quan es comença a fer un testador més jove i s’entusiasma un cadell retrobador d’or ben descansat, de vegades és inevitable oblidar la imatge més gran. És així quan un jove emplena el meu tauler de Jira amb millores, píxels incorrecte, icones que són lleugerament fora del centre i que falten punt i coma dos punts dos setmanes abans que hagi de presentar un candidat a l’edició final. També és la manera més ràpida de veure'm hiperventilar. El que necessito en aquesta fase és assegurar-se que les funcions principals funcionen, no es trenca res, els bloqueigs són una memòria llunyana i que l’aplicació és fàcil d’utilitzar i fàcilment accessible, no de comprovació gramatical i de perfecció d’UI.

El millor dels nous testers és el seu interminable afany de trobar el major nombre d'errors possibles i demostrar-se que són valuosos. Tanmateix, el pitjor dels nous testers és el seu interminable afany de trobar tants errors ... Ja sabeu com s’acaba. De vegades acostumen a centrar-se en detalls menors petits en els pitjors moments possibles. La priorització és una cosa que s’aprèn i amb el temps es comença a comprendre que hi ha un moment adequat per presentar trivials i probablement no s’arriba a la data límit.

2. Afegiu problemes en funció dels vostres sentiments

Crec que aquesta icona es veurà millor si fos taronja en lloc blava. Crec que aquesta lògica és una mica difícil d’entendre, així que crec que hem d’afegir almenys quatre finestres emergents més. No! Els provadors juvenils no arriben a fer suggeriments. És massa dur? D’acord, deixeu-ho de tornar a provar, els emprenedors juvenils aconsegueixen fer suggeriments en el moment adequat per a les persones adequades.

Quan comencem a desenvolupar una funció o un mòdul al començament dels projectes, normalment tots els suggeriments són ben rebuts. Pensem de manera creativa perquè hem de pensar en tots els casos possibles i escenaris d’usuaris per poder escriure casos de prova detallats i complets. És quan les solucions que els arquitectes o dissenyadors són més propenses a escoltar suggeriments i tenir en compte les nostres idees.

Si realment creieu que la vostra aportació és valuosa i heu fet la vostra investigació, seguiu endavant i ens enlluernen. Tanmateix, si els nostres fluxos de treball, renderitzacions i propostes ja estan aprovats, implementats i provats, normalment és massa tard per canviar les coses, per molt que siguin les idees. I mai mai arxivar errors basats només en les vostres preferències.

3. Oblideu de l’existència del vostre dissenyador

Parlant de renderitzacions, fluxos de treball i problemes sobre ells, no hi ha manera més ràpida de combatre el teu dissenyador enemic que passar-se pel cap i afegir millores en el seu treball o, encara pitjor, problemes sobre els seus dissenys. M'encanten els meus dissenyadors i confio molt en la seva competència que, si han dissenyat una funció d'una manera, tenen molt bons motius per fer-ho. Sé quant esforç investiguen en investigar diferents idees i sé que solen col·laborar molt estretament amb el client i probablement són més conscients de les exigències de la IU del client que jo.

Si he de ser completament sincer, de vegades encara m’equivoqueig i, en el moment actual, decideixo afegir alguna cosa a una funció sense consultar primer amb el meu dissenyador. Ho faig amb la millor intenció de millorar alguna cosa, però la meva millor intenció significa poc si estic pertorbat el procés acordat i afegint un retard inesperat.

4. Pixa els teus deds

Ahhhh, els devs poden ser intimidatoris, els devs poden ser irritants, els devs poden ser arrogants i malhumorats. Però els devs són sempre el teu millor amic, sempre! Així que proveu el possible i estableix una relació de confiança. Tu vas i mola fins que et toleren, atrevir-te a dir fins i tot com tu. Perquè devs feliços = QAs feliços. Tot i que heu d’escoltar 1.000 vegades “no és un error, és una característica”, us mossegueu la llengua i persevereu. Si no creieu alguna cosa que us diu el vostre devorador, podeu anar a una persona gran i demanar una segona opinió. Però l’ideal és que sigui millor si mantingueu una associació de confiança. Heu de confiar en la seva experiència i després confiaran en la vostra competència. És una simbiosi bonica però fràgil.

Els desenvolupadors han de confiar que tinguis l’esquena, que tot i que vulguis trencar el seu codi, ho fas amb la millor intenció i pel bé més gran. I cal confiar que, de vegades, molt rarament, un error és, efectivament, una característica. :)

La manera més ràpida d’enyorar un btw de dev és quan prova un mòdul mig fet i afegeix un munt d’errors sobre coses que ni tan sols s’han implementat. Doneu-los temps, no apureu-los i intenteu mantenir el vostre entusiasme fins que no s'acabi amb la seva part i la vostra part pugui començar.

5. Suposeu que sou massa bons per a la documentació

Ahhh, això sóc en poques paraules. La tasca més tediosa per a mi és escriure casos de prova o modificar els existents amb nous escenaris i informació que he revelat durant la prova. Quan reuneix una mica d’impuls i prova de confiança, comenceu a ometre els fonaments bàsics. El temps et sembla pressionar per molestar-se en seguir una plantilla de llista de comprovació per fer-ho de memòria sense deixar rastre dels resultats. Esteu tan segurs de la vostra capacitat que oblideu que totes les proves han de tenir una petjada visible. Especialment si gestioneu un projecte tot sol i coneixeu tots els detalls al respecte, oblideu la necessitat de documentar-vos, i això us pot tornar fàcilment i mossegar-lo a la pell.

Estic culpable d’això i durant molt de temps he saltat alguns passos per poder disposar de més temps per a altres tasques. Però, en alguns casos, la teva paraula honesta no importa tret que teniu un document que us faci una còpia de seguretat. Si dius, per exemple, que alguna cosa és una regressió, perquè abans funcionava perfectament i algú et demana que els demostri i no ho pots fer, sembla poc professional. Mai se sap quan passaràs a un altre projecte o algú altre haurà de fer-se càrrec de la teva feina i algú altre es perdrà totalment tret que hagis fet el teu paper.

6. No fer les bases

Suposem que el vostre projecte és una aplicació mòbil compatible amb Android i iOS. Un testador més jove està comprovant un telèfon Android i veu un accident. Junior és extàtic, un accident és una gran quantitat, així que es pressen per afegir-lo a Jira tan aviat com sigui possible i aixecar l'alarma. El que obliden són tots els altres passos que cal fer abans d’afegir un error, especialment un important. Hi ha una mica de treball de base abans d’afegir un problema. El primer és comprovar el sistema de fitxers, sigui quin sigui, per duplicats. A ningú li agraden els duplicats i et fan semblar descuidat. El segon és consultar alguns llocs més per veure si el problema és específic del dispositiu, específic de la plataforma o general. De manera que comproven millor una tauleta Android i després un dispositiu iOS, etc. També seria útil reunir alguns registres per tal que el desenvolupador pugui estalviar temps per intentar reproduir-se i comprovar ràpidament els registres. També és útil veure amb quina freqüència es pot reproduir el problema, es produeix cada cop o una mica més a l’atzar. Aïlla els passos exactes del problema i comprova també les versions anteriors i versions anteriors per veure si es tracta d’una regressió de nova introducció o bé hi ha estat allà fora i s’ha perdut tot el temps.

Aquests errors són una part comuna del viatge d'una QA i són un pas natural en el procés d'aprenentatge. Ara que he passat aquesta preciosa càrrega d'un llegat pel camí, informeu-me als comentaris que hi ha a continuació si sou culpables d'algun d'aquests errors o potser hi ha pecats QA imperdonables que he perdut.