6 basic skills that every tester should have
Les proves de programari o control de qualitat són la millor plataforma perquè els nouvinguts accedeixin a la indústria de les TI, malgrat les idees errònies que es tracta d’un treball amb menys o menys remuneració.
L'habilitat més important que necessita un provador és la capacitat de trobar errors . I, si sou el tipus de persona que estima trobar insectes, us encantarà i créixer en aquest camp.
Dit això, hi ha poques habilitats més que us poden ajudar a trobar errors i treballar millor amb els processos de control de qualitat.
Aquest és l'article que mostrarà el procés de control de qualitat, ja que se segueix a la majoria de les empreses i donarà aclariments als provadors dels nous provadors.
com escriure casos de prova en Excel
En detall, coneixeu el procés de documentació i els estàndards, el treball previ del provador, les proves basades en restriccions, les proves durant el desenvolupament parcial i, finalment, el procés de tancament de sessió.
Anem a començar.
Què aprendreu:
- # 1. Documentació
- # 2. Preparació de la prova
- # 3. Procés de prova: quines proves cal realitzar?
- # 4. Proves en fase de desenvolupament parcial
- # 5. Document d'informe d'errors
- # 6. Procés d’inici de sessió
- Conclusió
- Lectura recomanada
# 1. Documentació
La documentació és essencial per a les proves. La majoria de les empreses assignen aquesta tasca als nouvinguts. Per tenir èxit, hauríeu de tenir-ho bon vocabulari perquè la resta de coses, com ara estàndards de documentació, etc., no estan al vostre control i depenen dels processos de l’equip i de l’empresa.
A més, assegureu-vos que vegeu el valor del procés de documentació. Els avantatges són molts: us ajuden a fer un seguiment dels canvis de requisits, a seguir els passos de la prova, a registrar el vostre treball, etc.
Lectura recomanada=> Per què la documentació és important a les proves de programari
# 2. Preparació de la prova
De tots els documents disponibles, no es pot deixar de banda el següent. També s’anomenen documents lliurables i permeten entendre la comprensió entre client, desenvolupador i comprovador.
a) Pla de proves: mostra el flux de proves de principi a fi .
El pla de proves mostra l'abast i les activitats de la fase de proves. Creat pel líder de control de qualitat, l’equip ha de contribuir i estar al dia de tot el que està escrit al pla de proves.
Alguns equips tenen diversos nivells de plans de prova: pla director i plans de fase.
Un pla de prova ha de tenir:
- Nom i versió del projecte
- Identificadors del pla de prova: creador, núm. D'esborrany, data de creació, etc.
- Introducció: visió general del projecte, objectiu i restriccions
- Referències: llista de referències utilitzades com a entrada (assegureu-vos que utilitzeu les versions més recents i precises)
- Elements de prova: mòduls, versió, abast, fora d'abast, etc.
- Enfocament general de la prova / Estratègia de prova: eines per utilitzar, procés de seguiment de defectes, nivells de proves a realitzar, etc.
- Criteris d'aprovació / error: directrius d'execució de la prova
- Criteris de suspensió i represa
- Entregues lliurables: cas de prova, informes de proves, informe d'errors, mètriques de prova, etc.
- Comproveu els detalls de l'entorn
- Llista d’equips amb informació sobre el punt de contacte. per a cada mòdul o tipus de prova
- Estimacions de proves: temps i esforç. Els detalls del pressupost són confidencials i no els trobareu aquí
- Riscos i plans de mitigació
- Aprovacions
- Altres pautes
Llegiu també=>
com obrir el fitxer .java
- Com escriure un document de pla de prova des de zero
- Format del pla de prova
- Exemple de pla de proves reals (pdf) [descarregar]
b) Escenaris de prova:
Uns indicadors de línia sobre 'què s'ha de provar' en funció de cada requisit i que normalment es documenten i fan un seguiment a través de fulls de càlcul.
La majoria contenen:
- Nom del mòdul / component / funció (inici de sessió, administrador, registre, etc.)
- L'identificador d'escenari és de referència (per exemple: TS_Login_001)
- Descripció de l'escenari: 'Què cal provar', per exemple: Valideu si l'inici de sessió permet als usuaris amb credencials vàlides iniciar la sessió correctament
- Importància de l’escenari: prioritzar en cas de temps insuficient: alt / mitjà / baix
- Identificació del requisit: per a la traçabilitat
Per llegir més=>
c) Casos de prova:
Els casos de prova precisos donen resultats de prova precisos. Els fulls de càlcul segueixen sent el mitjà més popular per escriure casos de proves, especialment per a principiants, tot i que algunes empreses adapten les eines de gestió de proves. La base per escriure casos de prova és el document SRS / FRD / Req. Però, sovint no n’hi ha prou, de manera que haureu d’utilitzar moltes hipòtesis i debats amb els equips de BA / Dev.
Redacció de casos de proves efectius és la qualificació més important que ha de tenir un verificador. Normalment, tots els casos de prova es classifiquen en positius / negatius. Cas de prova positiu proporciona aportacions vàlides i obté resultats positius. Cas de prova negatiu proporciona entrades no vàlides i rep el missatge d’error exacte.
Per obtenir més informació, consulteu:
Alguns dels atributs habituals que tenen tots els casos de prova són:
- Identificador d'escenari: extret d'un document d'escenari de prova
- Identificador de cas de prova: per identificar i fer un seguiment únic. Per exemple: TC_login_001
- Descripció de la prova: breu explicació de l’estat de la prova provat
- Passos a executar: instruccions detallades pas a pas sobre com provar
- Dades de prova: dades subministrades als passos de prova
- Resultat esperat - Resultat esperat
- Resultat real: resposta de l’automàtica quan s’executa la prova
- Estat: aprovat / fallit / sense execució / incomplet / bloquejat: descriu el resultat de la prova
- Comentaris: a detalls addicionals
- Executat per: nom del provador
- Data d'execució: data en què s'executa la prova
- Identificador de defecte: defecte registrat al cas de prova, en cas de fallada de la prova
- Detalls de configuració: sistema operatiu, navegador, plataforma, informació del dispositiu (opcional)
Lectura recomanada=>
# 3. Procés de prova: quines proves cal realitzar?
Hi ha un gran nombre de tipus de proves, però no es poden dur a terme tots en aquest AUT. El temps, el pressupost, la naturalesa de l’empresa, la naturalesa de l’aplicació i l’interès del client són els actors clau en l’elecció de les proves que es fan a l’aplicació.
Per exemple: Si es tracta d'un portal de comerç en línia, és obligatori fer proves de tensió i proves de càrrega. No obstant això, alguns dels tipus de proves que no s’han de perdre són:
- Proves de caixa negra
- Proves de caixa grisa
- Proves d’unitat (Si es aplicable)
- Proves d'integració
- Proves d’integració incremental
- Proves de regressió
- Proves funcionals
- Prova de nou
- Proves de seny
- Proves de fum
- Proves d'acceptació
- Proves d’usabilitat
- Proves de compatibilitat
- Proves d'extrem a extrem
- Proves alfa
- Prova beta
# 4. Proves en fase de desenvolupament parcial
En general, amb empreses de nivell mitjà i empreses emergents, hi ha un temps i recursos limitats. Els provadors aquí podrien iniciar el procés de proves abans de la integració del mòdul, cosa que significa que podríem fer proves d’integració d’unitat i intermediaris.
És important tenir en compte que els resultats d’aquestes etapes no es poden comptar com a exactes, de manera que és possible que hagueu de planificar una prova global de caixa negra un cop tot estigui a punt. Mirar aquesta peça pot resultar costós i ineficaç.
# 5. Document d'informe d'errors
Mans a mà, aquest és el document de control de qualitat més crític que mai faràs.
Els següents són els camps que ha de tenir un bon informe d'errors:
- Identificador de defecte: normalment és un número de sèrie
- Descripció del defecte: una línia explicativa del problema
- Ubicació: mòdul / àrea de l’automàtica on es troba el problema
- Número de compilació: versió i codi de compilació núm.
- Passos per reproduir: llista de passos que us condueixen al problema
- Gravetat: estableix un nivell per descriure la gravetat del problema: baix, mitjà, alt, bloquejador, etc.
- Prioritat: establert pels desenvolupadors per determinar l'ordre en què es solucionarà el defecte (P1, P2, P3, etc. P1: més alt)
- Assignat a: propietari del defecte en aquest moment
- Informat per: nom del provador
- Estat: estat diferent per representar l'etapa del cicle de vida dels errors
- Novetat: es detecta un error i s’acaba d’informar
- Obert: validat pel client de control de qualitat
- Assignat: enviat al responsable de desenvolupament per assignar-lo al desenvolupador respectiu
- En curs / Treball en curs: Dev va començar a treballar-hi
- Corregit / resolt: el desenvolupador ha acabat treballant-hi
- Verificat / tancat: l'equip de control de qualitat ha tornat a provar i ha trobat l'error solucionat
- Torna a provar: l'equip de control de qualitat no està d'acord amb la resolució de Dev i avança encara més l'error per a la seva reelaboració
- Duplicat: ja existeix un error similar
- Diferit: error vàlid, però es corregirà en versions posteriors
- No vàlid: no és un error o no es pot reproduir o no hi ha prou informació
Per llegir més=>
- Com escriure un bon informe d'errors
- Exemple d'informe d'errors
- Com comercialitzar i solucionar els vostres errors
- Per què la notificació d’errors és un art
# 6. Procés d’inici de sessió
Tanca la sessió i l’enviament de la documentació final és la tasca del responsable o responsable del control de qualitat. Tot i això, l’equip ha d’enviar els documents anteriors (escenari de prova, cas de prova i registre de defectes) per a les revisions i auditories finals.
Assegureu-vos de revisar-los tots i enviar-ne les versions finals.
Llegiu també=>
- Com escriure un informe de resum eficaç de la prova
- Com informar de l'execució de la prova de manera intel·ligent
- Exemple d’informe resum [descarregar]
Conclusió
Aquest és el procés que he estat testimoni i experimentat de primera mà quan feia proves i espero que això us hagi donat algunes indicacions útils.
Finalment, la carrera de proves ha estat una alegria absoluta per a mi i espero que també ho sigui per a vosaltres.
què és la prova beta en proves de programari
Tot el millor per a la teva carrera!
Lectura recomanada
- Les millors eines de prova de programari 2021 [Eines d'automatització de proves de control de qualitat]
- Proves alfa i proves beta (guia completa)
- Prova de descàrrega de llibres electrònics
- Proves funcionals contra proves no funcionals
- 20 preguntes senzilles per comprovar el vostre programari Provant coneixements bàsics [Concurs en línia]
- Guia de currículums de proves de programari perfectes (amb mostra de currículum de proves de programari)
- Guia completa de proves de verificació de compilació (proves BVT)
- 7 consells bàsics per provar llocs web multilingües