my unexpected journey becoming software tester
'Construeixes una vida d'èxit ... Un dia a la vegada ...'
El meu viatge com a provador de programari va començar una mica inesperadament.
Vaig aparèixer a les primeres rondes d’entrevistes assumint que era una oportunitat de desenvolupament. Per ser sincer, com tots els graduats en informàtica, era una mica escèptic quant a seguir endavant amb les proves.
Però finalment, vaig decidir provar-ho. Només amb l’esperança que la meva naturalesa curiosa m’ajudi en aquest camp.
No podria acceptar l'oferta sense fer aquesta pregunta: tindré l'oportunitat de canviar a Desenvolupament en cas que les proves no m'interessin? :)
Creieu-me, ni tan sols vaig pensar en deixar Testing després.
com obrir un fitxer .bin al Windows 10
Quan vaig aparèixer a la ronda tècnica, no estava preparat per res més que el concepte bàsic de proves de programari . Suposo que l’únic que em va portar va ser pensar que se m’està avaluant lògicament i no teòricament ”.
Aquest va ser el meu primer aprenentatge en proves: vaig entendre com ( frescors ) es van avaluar.
Encara avui faig servir tècniques similars mentre contracto perfeccionistes per al meu equip. Comprovo la seva lògica, tenacitat i enfocament davant d’un problema per sobre de qualsevol altra cosa.
Lectura recomanada => 4 coses importants que vaig aprendre al meu viatge com a gestor de proves de control de qualitat
Em vaig unir a Zycus com a alumne de QA i em vaig assignar un producte algun tercer o quart dia. Era un dels productes més grans i ambiciosos de l’empresa (en aquell moment en concepte). Després d’establir-me durant les primeres setmanes, no em va donar cap volta enrere.
Vam començar com un equip de control de qualitat de dos i poc després de pocs mesos vaig ser l’únic a impulsar els esforços de proves. Durant els primers 2 - 2,5 anys, havia registrat prop de 3000 defectes en diferents categories, com ara Funcional, Rendiment, Seguretat, IU, Usabilitat, Multilingüe , Multi-Tenancy, etc.
Durant un temps considerable abans de les noves incorporacions a l’equip de proves, em vaig enfrontar a un fort equip de desenvolupament de 15 a 16 membres. Fins i tot després de les incorporacions, la relació QC: Dev no era molt saludable i puc dir amb orgull que va ser un viatge amb èxit tenint en compte tot el que vam provar, lliurar i gestionar.
El punt important que vull destacar aquí és: Tot això va ser a partir de la comprensió de les proves a la pràctica i no només de la teoria.
Fa gairebé sis anys que sóc al camp de les proves de programari. Ha estat un viatge increïble amb moltes experiències diferents i un munt d'aprenentatge fructífer.
Actualment, estic treballant com a gerent sènior de control de qualitat atenent uns 5-6 productes i mòduls. Però el que em dóna alegria i felicitat és dirigir un equip de més de 30 testers feliços i apassionats.
Per descomptat, molta gent ha contribuït al meu aprenentatge, però encara puc dir que la major part de la meva experiència i coneixements han recorregut el camí més difícil (i probablement la millor manera), és a dir, aprendre / resoldre-ho tot sol.
'L'experiència és el millor professor'.
Tot i que dic això, no vull dir en absolut que no se us beneficiarà aprenent o seguint teories documentades sobre les proves de programari. El que crec és que tot això segurament ajudarà res no pot superar entendre el concepte fonamental i afrontar els problemes amb valentia.
Crec que les coses documentades no us ensenyaran proves reals , tot i que us pot donar una certa direcció i després esteu sols. Almenys en el meu cas, hi va haver problemes que poden no estar documentats per resoldre els meus problemes exactes o que no els he pogut trobar a temps. La meva única elecció va ser entendre el problema / la situació fonamental i reaccionar-hi amb l’enfocament que vaig trobar bé.
Exemples: com em vaig plantejar en diferents situacions
Deixeu-me explicar-ho amb l'ajut de problemes / situacions amb què em trobava i com els vaig abordar.
# 1) La comprensió empresarial és molt superior a la comprensió de les proves
Bé, tots ho sabeu. La prova no és només provar poques validacions i fer una verificació.
Com a provador, se suposa que hem de visualitzar tots els escenaris possibles, fins i tot el més rar dels pocs escenaris sense fallar. Se suposa que hem de tenir en compte totes les dades de prova possibles que l'usuari real podria utilitzar.
Per tot això, se suposa que hem d’entendre el negoci al màxim.
No equivocarà si dic que hauríem d’entendre el negoci i la base d’usuaris tant o fins i tot més del que ho fa un Business Analyst.
M’enfrontava a probabilitats similars.
Se suposava que sí entendre escenaris empresarials complexos al domini de l’adquisició, feu una pluja d’idees sobre els nous requisits i penseu-los des de la perspectiva de l’usuari. No només se suposava que havia de treballar els meus casos, sinó que també havia de contribuir a les fases de requisits i disseny de cada iteració. Fins i tot aquí, no hi va haver cap referència a punt per salvar-me, a part de la meva capacitat de pensar i raonar.
Per entendre millor el negoci i dissenyar millor els vostres casos / casos, res no funciona com el bolígraf i el paper.
Llegiu també => 5 Ha de tenir eines que no siguin de prova perquè els provadors facin la vida més fàcil
Abans d’anar-hi Debat sobre requisits reunió, abans anotava possibles dubtes / correccions / punts poc clars. Abans anotava els escenaris en què vull provar o construir casos de prova; de vegades, fins i tot dibuixar els vostres escenaris funciona com un encant.
Quan escriviu / dibuixeu, entra a la vostra ment amb una major claredat i, després, la vostra ment treballa aquesta informació i produeix més escenaris i proporciona una millor claredat. Això continua fins que obtingueu la sensació de FET !!!
# 2) Rendint contra la probabilitat i la pressió
Treballava en un producte que era / és prou enorme i complex per fer que un equip de 30 enginyers treballés contínuament durant tres llargs anys per aconseguir un nivell venible.
Durant la major part de la fase inicial, vaig estar enfrontat (en solitari) a un equip de 15 a 20 desenvolupadors que anaven des del nivell júnior, mitjà sènior i sènior, o anava acompanyat d’un o dos altres provadors. Tots afegia noves funcions al producte sense parar, cosa que requeria una atenció igual i paral·lela per part de les proves.
Formar part de reunions de requisits, escriure casos, executar-los, rondes exploratòries, mantenir servidors, desplegaments, res era opcional.
Aleshores no era conscient de cap metodologia, millors pràctiques , per descomptat o un llibre que em pugui mostrar solucions a aquests problemes. Encara avui no estic segur de si hi ha alguna cosa que us pugui ajudar precisament a combatre les realitats terrestres mentre les enfronteu.
El que feia més aviat és, agressiu i rondes ràpides de proves exploratòries (Aleshores no era conscient del nom) de cada funció una per una i després repetiu. Aquesta solució funciona únicament en la rapidesa amb què podeu canviar els vostres pensaments i enquadrar situacions / escenaris.
Per descomptat, això requeria un treball realment ràpid i agressiu, però em va funcionar.
El que vull dir amb una ronda agressiva és, apunteu una cosa a la vegada (Digueu un element d'una forma a la vegada) i proveu-ho independentment i en associació amb altres elements / coses vinculades.
Lectura recomanada => Com ser un consumidor de productivitat (sobretot com a provador)
Per exemple. Com provar un quadre de text.
com obrir un fitxer bin Windows 10
El que podeu provar aquí és:
- Si accepta i emmagatzema les dades tal qual
- Validació del tipus de dades
- Validació de longitud màxima
- Maneig especial del personatge
- Manipulació XSS
- Maneig de dades multilingües
- Manipulació d'espais buits / sense dades
- Comportament de les tecles de pestanya i d'introducció
- Gestió d'errors (navegador creuat)
- Alineació de la IU (navegador creuat)
- Copieu les dades d'enganxar / arrossegar les dades dels enllaços al quadre de text
- El més important: el comportament d’aquest camp w.r.t. altres elements enllaçats (qualsevol expectativa empresarial vinculada a aquest camp, com ara omplir alguna cosa en algun altre camp basat en les dades d’aquest camp)
Pensar en les proves anteriors us confia que res de molt pot sortir malament en aquest camp?
Bé, l’orientació a una cosa a la vegada sempre va funcionar per a mi i també solia acabar la feina.
# 3) Quan et trobes amb l’inesperat
Quin llibre creieu que de sobte us ajudarà amb 'Com fer-ho' quan se suposa que heu de fer alguna cosa que no havíeu fet mai?
Si parlem específicament aleshores- Cap.
Recordo el moment en què, en absència del nostre cap de producte, se suposava que junt amb pocs altres membres júnior i mitjà sènior havíem de desplegar la nostra aplicació a la demostració (per a nosaltres llavors era producció) per primera vegada. Va ser molt crític per a la primera demostració del nostre producte.
Bé, ho vam fer, però amb un munt de proves i errors. Per raó, cap de nosaltres tenia experiència Linux i scripts de shell . Recordo que el nostre departament de TI (de bona fe) va plantejar-me preocupacions (tot de bona fe) al meu director d’aleshores sobre que executés ordres incorrectes als servidors de producció. Potser això era només un catalitzador i el script de shell / Linux era el meu interès natural, però al cap de poc temps vaig acabar assumint la responsabilitat de mantenir i actualitzar de cinc a sis entorns simultàniament.
Shell i Linux em van cridar tant l’interès, que aviat vaig ser qui vaig començar a fer-hi sessions d’entrenament intern.
# 4) Quan es mesura el vostre rendiment, la vostra experiència no ho és
Molt aviat a la meva carrera, em vaig comparar i mesurar amb els provadors molt evolucionats i experimentats. Crec que molts de vosaltres heu hagut de viure una situació similar i saber què us fan aquestes expectatives addicionals.
El remei aquí era Empeny-me i evoluciona .
L’únic camí a seguir era no pensar en la menys experiència que tinc, no limitar-me a les normes mundials de mesurar la lentitud / rapidesa que hauria de créixer / aprendre. No em limito als criteris mundials de quant de temps s’ha de començar a liderar i el títol que cal abans d’aconseguir-ho.
Bé, en aquest punt, he de dir, independentment de quin camp pertanyi, us recomano que llegiu El líder que no tenia cap títol de Robin Sharma. Us ajudarà a desencadenar allò que hi ha dins vostre. Us dirà que ningú, excepte vosaltres, us pot retenir.
Si he de vincular la meva experiència en poques frases, és així:
“La vostra curiositat, atenció als detalls, disciplina, pensament lògic, passió pel treball i capacitat per disseccionar les coses és el que importa ser un provador destructiu i amb èxit. Va funcionar per a mi i crec fermament que funcionarà per a vosaltres. Si teniu aquestes qualitats, us ha de funcionar '.
Bé, llegint fins aquí si esteu pensant que estic promovent qualitats humanes bàsiques per sobre de coneixements teòrics més profunds, això no és del tot cert. Crec que per començar amb alguna cosa i per provar-ne l’èxit, depèn una mica més de les vostres qualitats incorporades que de la informació que heu après. Tot i això, per anar lluny en qualsevol camp, heu d’aprendre lliçons, principis i experiències.
En el meu cas també, vaig haver d’aprendre les terminologies, els conceptes i les teories fins a cert punt a mesura que anava avançant en la meva carrera. La raó és que, com a provador, haureu d’interactuar amb diverses persones que parlaran en aquests termes i ho heu d’entendre.
Com a candidat principal o co-provador, tindreu un provador nou procedent d’alguna part del món amb el seu propi coneixement de fets, definicions i terminologies. Aquí també no es pot mantenir passiu cap a aquestes coses; heu de tenir coneixements previs sobre el màxim de coses possibles que s’utilitzen / diuen per aquí.
L’aprenentatge és inevitable.
Vaig haver d’aprendre més sobre diferents tipus de proves, com executar-les i maneres d’explicar-ho a la gent del meu equip en el moment adequat. Vaig haver d’avaluar noves idees, eines i implementar-les. L’aprenentatge de nous conceptes i metodologies esdevé igual d’important a mesura que avança per l’escala.
Llegiu-ne més => La Guia de la A a la Z per seleccionar la millor automatització
Conclusió
Tot i que és gairebé impossible escriure totes les coses importants i minucioses que he après al llarg dels anys, aquest és el meu intent de resumir-ho en una llista amb vinyetes.
- Les proves són molt difícils de definir. Algú pot fer proves excel·lents i pot ser que no sigui capaç de definir-ho amb paraules. És com ho veieu.
- Tothom pot tenir la seva pròpia definició de proves. El meu era senzill- 'Se't dóna una cosa: troba falles i millora-la.'
- No necessiteu teories grans, matrius complexes ni ISTQB per ser un provador destructiu. Has de ser-ho curiós , centrat i apassionat, pensa lògicament i té capacitat de dissecció. Tanmateix, saber més no perjudica, però a costa de perdre el quid.
- Els enfocaments / conceptes tradicionals també tenen la seva pròpia importància i els tinc el mateix respecte tenint en compte que hi ha una bona part del món on aquests són una necessitat justa. Les proves per si soles no poden evolucionar; els voltants també han d’evolucionar per a això.
- Com a provador, esdevé igualment important per a aprendre de nou eines, tècniques i metodologies a mesura que avança . Planificació de proves, millors enfocaments per realitzar diferents tipus de proves.
- Com que les proves són fluides, la definició de ser un ajust adequat també difereix enormement d’organització en organització. Ser un avaluador destructiu o excel·lent pot ser prou bo per obtenir un xec de sou si té sort o pot exigir coneixements addicionals sobre com funcionen les proves a les empreses tradicionals. Tots dos es troben al seu propi lloc.per exemple.Contracto persones segons la meva definició de proves (que varia una mica segons l'experiència del candidat i el perfil, per descomptat).
- Com hi ha un estil de codificar, conduir, cuinar; també hi ha un estil de proves. És possible que no ho gaudiu tret que ho feu a la vostra manera. El que vull dir és que les proves puguin tenir directrius, però no haurien d’estar lligades pels microprocessos.
- El plom efectiu hauria de fer que el seu equip triés la feina en lloc d’assignar-la. De tant en tant pot alterar-lo per millorar el producte.
- Intenteu formar la vostra gent a la seva àrea d’interès i juntament amb on voleu que es formin. Alineeu els pensaments i els esforços del vostre equip amb l'objectiu final, que és 'La millor qualitat'.
- No intenteu gestionar la vostra gent, conduïu-la. Sigui amable i accessible, facilita molt la feina.
- Tots els membres del vostre equip haurien d’encantar la feina que fan, tenir un vincle amb el producte i ser afectuosos amb la gent que els envolta. Aleshores només sortirà el millor d’ells.
- El món de les proves ha d’evolucionar. Una part considerable de World es dirigeix a enfocaments més pràctics com les proves exploratòries, les proves basades en el context (que moltes persones fan sense saber-ho), que fins i tot altres haurien d’intentar desenvolupar més tècniques com la
- S’haurien de formar més comunitats de proves i les persones afins haurien de reunir-se a una escala més gran. Hi ha molt per compartir, aprendre, adaptar-se i innovar.
Espero que la meva experiència i troballes us ajudi a ser un millor provador o us ajudi a comprendre millor les proves.
Lectures addicionals => De principiant a professional: una guia completa per al viatge amb èxit d’un professional de proves
Sobre l'autor: Aquest article està escrit per Mahesh C., membre de l'equip de STH. Actualment treballa com a gerent principal d'assegurament de la qualitat amb experiència al capdavant de proves de múltiples productes i components complexos.
M’encantarà tornar a escoltar. Comenteu aquí o contacteu amb nosaltres. Moltes gràcies per llegir.
Lectura recomanada
- Les millors eines de prova de programari 2021 (Eines d'automatització de proves de control de qualitat)
- Prova de programari Treball d'assistent de control de qualitat
- Curs de proves de programari: a quin institut de proves de programari m'he d'afegir?
- Selecció de proves de programari com a carrera professional
- Prova de programari Treball freelance d'escriptor de contingut tècnic
- Algunes preguntes d’entrevistes de proves de programari interessants
- Opinions i ressenyes sobre cursos de proves de programari
- Guia de currículums de proves de programari perfectes (amb mostra de currículum de proves de programari)