Introducció
Bona tarda, habitants de Khabrovsk. Ara mateix estava resolent una tasca de prova per a una vacant de QA Lead per a una empresa fintech. La primera tasca, crear un pla de proves amb una llista de verificació completa i exemples de casos de prova per provar un bullidor elèctric, es pot resoldre de manera trivial:
És difícil pensar en un millor pla de proves amb una llista de verificació completa.
Però la segona part va resultar ser una pregunta: "Hi ha problemes comuns a tots els provadors que els impedeixin treballar de manera més eficient?"
El primer que em va venir al cap va ser enumerar tots els problemes més o menys notables que vaig trobar durant les proves, eliminar les petites coses i resumir la resta. Però ràpidament em vaig adonar que el mètode inductiu respondria a una pregunta que no s'aplicava a "tots", sinó, en el millor dels casos, només a "la majoria" dels provadors. Per tant, vaig decidir abordar-lo des de l'altra banda, deductivament, i això és el que va passar.
Definicions
El primer que acostumo a fer quan resolc un problema nou és intentar entendre de què es tracta, i per fer-ho necessito entendre el significat de les paraules que el plantegen. Les paraules clau per entendre són les següents:
- un problema
- provador
- feina de provador
- eficiència del provador
Anem a la Viquipèdia i el sentit comú:
(grec antic πρόβλημα) en un sentit ampli: una qüestió teòrica o pràctica complexa que requereix estudi i resolució; en ciència - una situació contradictòria que apareix en forma de posicions oposades en l'explicació de qualsevol fenomen, objecte, procés i que requereix una teoria adequada per resoldre'l; a la vida, el problema es formula d'una forma comprensible per a la gent: “Sé què, no sé com”, és a dir, se sap què cal obtenir, però no se sap com fer-ho. . Ve de tard. lat. problema, del grec. πρόβλημα “llençat cap endavant, posat davant”; de προβάλλω “llenceu endavant, poseu-vos davant; culpa".
No té gaire sentit, de fet, "problema" = "qualsevol cosa que s'hagi de tractar".
- un especialista (no dividirem en tipus, ja que estem interessats en tots els verificadors) que participa en la prova d'un component o sistema, el resultat del qual és:
— un conjunt d'activitats relacionades amb les proves.
(lat. effectivus) - la relació entre el resultat assolit i els recursos utilitzats (: 2015).
- una conseqüència d'una cadena (sèrie) d'accions (resultat) o esdeveniments, expressats qualitativament o quantitativament. Els possibles resultats inclouen avantatge, desavantatge, guany, pèrdua, valor i victòria.
Igual que amb el "problema", hi ha poc sentit: quelcom que va sortir com a resultat del treball.
- la possibilitat mesurable quantitativament de realitzar qualsevol activitat d'una persona o persones; condicions que permeten utilitzar determinades transformacions per obtenir el resultat desitjat. El provador és una persona i, d'acord amb la teoria dels recursos vitals, cada persona és propietari de quatre actius econòmics:
l'efectiu (ingressos) és un recurs renovable;
l'energia (força vital) és un recurs parcialment renovable;
el temps és un recurs fix i fonamentalment no renovable;
el coneixement (informació) és un recurs renovable, forma part del capital humà que pot créixer i ser destruït.
M'agradaria assenyalar que la definició d'eficiència en el nostre cas no és del tot correcta, ja que com més coneixement fem servir, menor serà l'eficiència. Per tant, redefiniria l'eficiència com "la relació entre els resultats aconseguits i els recursos gastats". Aleshores, tot és correcte: el coneixement no es malgasta durant el treball, però redueix els costos de l'únic recurs fonamentalment no renovable del provador: el seu temps.
decisió
Per tant, busquem problemes globals dels provadors que perjudiquin l'eficàcia del seu treball.
El recurs més significatiu que es dedica a la feina d'un verificador és el seu temps (la resta es pot reduir d'una manera o altra), i per tal que parlem del càlcul correcte de l'eficiència, el resultat també s'ha de reduir al temps. .
Per fer-ho, considereu un sistema la viabilitat del qual garanteixi el provador a través del seu treball. Aquest sistema és un projecte l'equip del qual inclou un provador. El cicle de vida del projecte es pot representar aproximadament amb l'algorisme següent:
- Treballant amb els requisits
- Elaboració de les especificacions tècniques
- Desenvolupament
- Proves
- Alliberament en producció
- Suport (anar a l'element 1)
En aquest cas, tot el projecte es pot dividir de forma recursiva en subprojectes (característiques), amb el mateix cicle de vida.
Des del punt de vista del projecte, com menys temps hi dediquem, més efectiva serà la seva implementació.
Així, arribem a la definició de la màxima eficiència possible d'un provador des del punt de vista del projecte: aquest és l'estat del projecte quan el temps de prova és zero. Un problema comú per a tots els provadors és la incapacitat d'aconseguir aquest temps.
Com fer front a això?
Les conclusions són força òbvies i molts han estat utilitzades per molt de temps:
- El desenvolupament i les proves haurien de començar i acabar gairebé simultàniament (acostuma a fer-ho el departament ). L'opció ideal és quan tota la funcionalitat que s'està desenvolupant ja està coberta per autotests en el moment en què està llesta, organitzada en proves de regressió (i, si és possible, precommit) mitjançant algun tipus de .
- Com més característiques tingui un projecte (com més complex sigui), més temps s'haurà de dedicar a comprovar que la nova funcionalitat no trenca l'antiga. Per tant, com més complex sigui el projecte, més automatització es necessita .
- Cada vegada que perdem un error en producció i un usuari el troba, hem de dedicar temps addicional a recórrer el cicle de vida del projecte a partir del punt 1 (Treballant amb requisits, en aquest cas, usuaris). Com que els motius de la pèrdua d'un error són generalment desconeguts, només ens queda una ruta d'optimització: tots els errors trobats pels usuaris s'han d'incloure a les proves de regressió per assegurar-nos que no tornarà a aparèixer.
Font: www.habr.com