what is software testing
Una guia completa de proves de programari amb més de 100 tutorials de proves manuals amb definició de proves, tipus, mètodes i detalls del procés:
Què són les proves de programari?
La prova de programari és un procés de verificació i validació de la funcionalitat d’una aplicació per saber si compleix els requisits especificats. És el procés de trobar defectes en una aplicació i comprovar on funciona l’aplicació segons els requisits de l’usuari final.
Què és la prova manual?
La prova manual és un procés en el qual es compara el comportament d'un fragment de codi desenvolupat (programari, mòdul, API, característica, etc.) amb el comportament esperat (requisits).
Què aprendreu:
- Llista de tutorials manuals sobre proves de programari
- Introducció a les proves manuals de programari
- Conclusió
Llista de tutorials manuals sobre proves de programari
Aquesta és la sèrie de tutorials més profunda sobre proves de programari. Consulteu detingudament els temes esmentats en aquesta sèrie per aprendre les tècniques bàsiques i avançades de proves.
Aquesta sèrie de tutorials enriquirà els seus coneixements i, al seu torn, millorarà les seves habilitats de prova.
Practicar proves manuals extremes a la formació gratuïta en un projecte en directe:
Tutorial # 1: Conceptes bàsics de la prova manual de programari
Tutorial # 2: Introducció del projecte en directe
Tutorial # 3: Prova d’escriptura d’escenaris
Tutorial # 4: Escriviu un document de pla de prova des de Scratch
Tutorial # 5: Redacció de casos de prova a partir de documents SRS
Tutorial # 6: Execució de la prova
Tutorial # 7: Seguiment d'errors i tancament de prova
Tutorial # 8: Curs de proves de programari
Cicle de vida de proves de programari:
Tutorial # 1: STLC
Web Testing:
Tutorial # 1: Proves d'aplicacions web
Tutorial # 2: Proves de navegadors creuats
Gestió de casos de prova:
millor programari per amagar l'adreça IP
Tutorial # 1: Casos de prova
Tutorial # 2: Exemple de plantilla de cas de prova
Tutorial # 3: Requisits de la traçabilitat de la matriu (RTM)
Tutorial # 4: Cobertura de la prova
Tutorial # 5: Gestió de dades de proves
Gestió de proves:
Tutorial # 1: Prova d’Estratègia
Tutorial # 2: Plantilla de pla de prova
Tutorial # 3: Estimació de la prova
Tutorial # 4: Eines de gestió de proves
Tutorial # 5: HP ALM Tutorial
Tutorial # 6: Jira
Tutorial # 7: Tutorial de TestLink
Proves tècniques:
Tutorial # 1: Utilitzeu proves de casos
Tutorial # 2: Proves de transició d'estat
Tutorial # 3: Anàlisi del valor límit
Tutorial # 4: Particionament d'equivalències
Tutorial # 5: Metodologies de proves de programari
Tutorial # 6: Metodologia Àgil
Gestió de defectes:
Tutorial # 1: Cicle de vida d'errors
Tutorial # 2: Informes d'errors
Tutorial # 3: Prioritat de defecte
Tutorial # 4: Tutorial de Bugzilla
Proves funcionals
Tutorial # 1: Proves unitàries
Tutorial # 2: Proves de seny i fum
Tutorial # 3: Proves de regressió
Tutorial # 4: Proves del sistema
Tutorial # 5: Proves d'acceptació
Tutorial # 6: Proves d’integració
Tutorial # 7: Proves d’acceptació d’usuaris de la UAT
Proves no funcionals:
Tutorial # 1: Proves no funcionals
Tutorial # 2: Proves de rendiment
Tutorial # 3: Proves de seguretat
Tutorial # 4: Proves de seguretat d'aplicacions web
Tutorial # 5: Proves d’usabilitat
Tutorial # 6: Proves de compatibilitat
Tutorial # 7: Proves d'instal·lació
Tutorial # 8: Proves de documentació
Tipus de proves de programari:
Tutorial # 1: Tipus de proves
Tutorial # 2 : Proves de caixa negra
Tutorial # 3: Proves de bases de dades
Tutorial # 4: Prova de punta a punta
Tutorial # 5: Proves exploratòries
Tutorial # 6: Proves incrementals
Tutorial # 7: Proves d’accessibilitat
Tutorial # 8: Proves negatives
Tutorial # 9: Proves de backend
Tutorial # 10: Proves alfa
Tutorial # 11: Prova beta
Tutorial # 12: Proves Alpha contra beta
Tutorial # 13: Prova de gamma
Tutorial # 14: Proves ERP
Tutorial # 15: Proves estàtiques i dinàmiques
Tutorial # 16: Proves adhoc
Tutorial # 17: Proves de localització i internacionalització
Tutorial # 18: Proves d'automatització
Tutorial # 19: Proves de caixa blanca
Carrera de proves de programari:
Tutorial # 1: Triar una carrera de proves de programari
Tutorial # 2: Com obtenir un treball de prova de control de qualitat: guia completa
Tutorial # 3: Opcions professionals per als provadors
Tutorial # 4: Commutador de proves no informàtiques a programari
Tutorial # 5: Comenceu la carrera professional de proves manuals
Tutorial # 6: Lliçons apreses dels deu anys de proves
Tutorial # 7: Sobreviure i avançar en el camp de proves
Preparació de l’entrevista:
Tutorial # 1: Preparació del currículum QA
Tutorial # 2: Preguntes d'entrevistes de proves manuals
Tutorial # 3: Preguntes d’entrevistes de proves d’automatització
Tutorial # 4: Preguntes sobre entrevistes de qualitat
Tutorial # 5: Gestioneu qualsevol entrevista laboral
Tutorial # 6: Obteniu proves de feina com a frescor
Prova de diferents aplicacions de domini:
Tutorial # 1 : Proves d'aplicacions bancàries
Tutorial # 2: Proves d’aplicacions d’atenció mèdica
Tutorial # 3: Prova de passarel·la de pagament
Tutorial # 4: Sistema de prova de punt de venda (TPV)
Tutorial # 5: Proves de llocs web de comerç electrònic
Prova de la certificació de control de qualitat:
Tutorial # 1: Guia de certificació de proves de programari
Tutorial # 2: Guia de certificació CSTE
Tutorial # 3: Guia de certificació CSQA
Tutorial # 4: Guia ISTQB
Tutorial # 5: ISTQB Avançat
Temes avançats de proves manuals:
Tutorial # 1: Complexitat ciclomàtica
Tutorial # 2: Proves de migració
Tutorial # 3: Proves al núvol
Tutorial # 4: Proves ETL
Tutorial # 5: Mètriques de proves de programari
Tutorial # 6: Serveis web
Prepareu-vos per fer una ullada al primer tutorial d'aquesta sèrie de proves manuals !!!
Introducció a les proves manuals de programari
La prova manual és un procés en el qual es compara el comportament d'un fragment de codi desenvolupat (programari, mòdul, API, característica, etc.) amb el comportament esperat (requisits).
I com sabreu quin és el comportament esperat?
El coneixereu llegint o escoltant els requisits amb atenció i entenent-lo completament. Recordeu, és molt important entendre els requisits completament.
què és la prova de regressió a la prova de programari
Penseu-vos com a usuari final del que provareu. Després d'això, ja no estareu lligats al document de requisits de programari ni a les paraules que conté. A continuació, podeu comprendre el requisit bàsic i no només comprovar el comportament del sistema contra el que s’escriu o s’explica, sinó també contra la vostra comprensió i contra coses que no s’escriuen ni s’expliquen.
De vegades, pot ser un requisit oblidat (requisit incomplet) o un requisit implícit (una cosa que no necessita menció separada, però que hauria de complir-se), i també heu de provar-ho.
A més, un requisit no necessàriament ha de ser documentat. Podeu tenir coneixement de la funcionalitat del programari o fins i tot podeu endevinar i provar un pas a la vegada. Generalment en diem proves ad-hoc o proves exploratòries.
Fem una ullada a fons:
En primer lloc, entenem el fet: Ja sigui que compareu provant una aplicació de programari o una altra cosa (posem per cas un vehicle), el concepte continua sent el mateix. L’enfocament, les eines i les prioritats poden diferir, però l’objectiu principal continua sent el MATEIX i és SIMPLE, és a dir, comparar el comportament real amb el comportament esperat.
En segon lloc - Les proves són com una actitud o mentalitat que hauria de venir des de dins. Es poden aprendre habilitats, però només podreu provar amb èxit quan tingueu algunes qualitats per defecte. Quan dic que es poden aprendre habilitats de prova, em refereixo a una educació centrada i formal al voltant del procés de proves de programari.
Però, quines són les qualitats d’un provador amb èxit? Podeu llegir-ne al següent enllaç:
Llegiu-lo aquí => Qualitats dels provadors altament efectius
Us recomano passar l'article anterior abans de continuar amb aquest tutorial. Us ajudarà a comparar les vostres característiques amb les que s’esperen en la funció del provador de programari.
Per a aquells que no tinguin temps de revisar l'article, aquí teniu una sinopsi:
“La vostra curiositat, atenció, disciplina, pensament lògic, passió pel treball i capacitat per disseccionar les coses són importants per ser un provador destructiu i amb èxit. Va funcionar per a mi i crec fermament que també funcionarà per a vosaltres. Si ja teniu aquestes qualitats, també us haurà de funcionar '.
Hem parlat dels requisits previs bàsics de convertint-se en un provador de programari. Ara entenem per què les proves manuals tenen i tindrien sempre la seva existència independent amb o sense el creixement de les proves d’automatització.
Per què cal fer proves manuals?
Sabeu què és el millor de ser un provador, que també és un provador manual?
És el fet que aquí no es pot dependre només de les habilitats. Heu de tenir / desenvolupar i millorar el vostre procés de pensament. Això és una cosa que realment no es pot comprar per pocs diners. Vostè mateix ha de treballar-hi.
Haureu de fer-ho desenvolupar l’hàbit de fer preguntes i els haureu de preguntar cada minut quan feu la prova. La majoria de les vegades us heu de fer aquestes preguntes a vosaltres mateixos que als altres.
Espero que hagueu llegit l'article que us recomano a la secció anterior (és a dir, les qualitats dels provadors altament eficaços). Si és així, sabríeu que les proves es consideren un procés de pensament i que l'èxit que obtindreu com a provador depèn completament de les qualitats que tingueu com a persona.
Vegem aquest flux senzill:
- Fas alguna cosa ( realitzar accions ) mentre l’observeu amb certa intenció (comparant-lo amb l’esperat). Ara el vostre observació habilitats i disciplina aquí apareix la imatge per fer coses.
- Voila! Què ha sigut això? Has notat alguna cosa. Ho vas notar perquè donaves perfecte atenció als detalls davant teu. No el deixaràs anar perquè ho estàs curiós . Això no estava en el vostre pla que passés alguna cosa inesperat / estrany, ho notareu i ho investigareu més. Però ara ho estàs fent. Pots deixar-ho anar. Però no ho hauríeu de deixar anar.
- Esteu contents, heu descobert la causa, els passos i l’escenari. Ara ho comunicareu correctament i constructivament a l’equip de desenvolupament i a la resta d’interessats del vostre equip. Podeu fer-ho mitjançant alguna eina de seguiment de defectes o verbalment, però heu d'assegurar-vos que ho sou comunicant-ho de manera constructiva .
- Vaja! I si ho faig així? Què passa si entro un enter com a entrada, però amb espais en blanc principals? I si ... I si? ... I si? No s’acaba fàcilment, no s’ha d’acabar fàcilment. Ho faràs imagina’t moltes situacions i escenaris i, de fet, també tindreu la temptació de realitzar-les.
El diagrama que es mostra a continuació representa la vida d’un provador:
Torneu a llegir els quatre punts vius esmentats anteriorment. T’has adonat que l’he mantingut molt curt, però que ha destacat la part més rica de ser un provador manual? I us heu fixat en l’atrevit ressaltat d’unes poques paraules? Aquestes són precisament les qualitats més importants que necessita un comprovador manual.
Ara, de debò creieu que aquests actes es poden substituir completament per qualsevol altra cosa? I la tendència actual: es pot substituir mai per automatització?
A SDLC amb qualsevol metodologia de desenvolupament, poques coses sempre es mantenen constants. Com a provador, consumireu els requisits, els convertireu en escenaris de prova / casos de prova. A continuació, executareu aquests casos de prova o els automatitzareu directament (sé que ho fan algunes empreses).
Quan l’automatitzeu, el vostre enfocament és constant, que és automatitzar els passos escrits.
Tornem a la part formal, és a dir, executant els casos de prova escrits manualment.
Aquí, no només us centreu en l'execució dels casos de proves escrites, sinó que també feu moltes proves exploratòries mentre ho feu. Recordeu, teniu curiositat? I t’ho imaginaràs. I no podràs resistir, de fet faràs el que t’imaginaves.
La imatge que es mostra a continuació mostra com es simplifica l'escriptura de casos de prova:
Estic omplint un formulari i ja he acabat d’omplir el primer camp. Em fa mandra anar al ratolí per canviar el focus al següent camp. Vaig prémer la tecla 'tabulador'. També he acabat d'emplenar el següent i l'últim camp, ara he de fer clic al botó Envia, el focus continua en l'últim camp.
Vaja, he accedit accidentalment a la tecla 'Retorn'. Permeteu-me comprovar què ha passat. O hi ha un botó d'enviament, hi faré doble clic. No satisfet. Hi faig clic diverses vegades, massa ràpid.
T'has adonat? Hi ha tantes accions possibles de l'usuari, tant les previstes com les no previstes.
No aconseguirà escriure tots els casos de prova que cobreixin al 100% la vostra sol·licitud sota prova. Això ha de passar d'una manera exploratòria.
Continuareu afegint els vostres nous casos de prova mentre proveu l'aplicació. Aquests seran casos de prova d’errors que heu trobat i que anteriorment no hi havia cap cas de prova escrit. O, mentre proveu, alguna cosa va desencadenar el vostre procés de pensament i teniu alguns casos de prova més que voldríeu afegir i executar al vostre conjunt de casos de prova.
Fins i tot després de tot això, no hi ha cap garantia que no n’hi hagi errors ocults . El programari amb zero errors és un mite. Només podeu orientar-vos a aproximar-vos a zero, però això no pot passar si una ment humana no s’orienta contínuament al mateix, de manera similar, però no limitada, al procés d’exemple que hem vist anteriorment.
Almenys a partir d’avui no hi ha cap programari que pensi com una ment humana, observi com un ull humà, faci preguntes i respongui com un ésser humà i, a continuació, realitzi accions previstes i no previstes. Fins i tot si passa tal cosa, de qui imitarà la ment, els pensaments i els ulls? Vostè o meu? Nosaltres, els humans, tampoc no tenim el mateix dret. Tots som diferents. Aleshores?
Necessitat de proves manuals quan l'automatització és al voltant:
Actualment, les proves d’automatització tenen la seva pròpia glòria i en tindran encara més en els propers anys, però simplement no pot substituir les proves manuals de control de qualitat (llegiu les proves humanes / exploratòries).
Deu haver escoltat abans ... No automatitzeu les proves, automatitzeu la comprovació ’. Aquesta frase parla molt sobre la posició de les proves manuals de control de qualitat amb les proves d’automatització. Molts grans noms de tot el món han escrit i parlat sobre aquest tema, de manera que no m’insistiré gaire en això.
L'automatització no pot substituir les proves humanes perquè:
- Exigeix judicis en temps d'execució sobre tot el que passa davant dels vostres ulls (mentre proveu) i en alguns casos també entre bastidors.
- Exigeix una observació clara i constant.
- Exigeix qüestionament.
- Exigeix una investigació.
- Exigeix raonaments.
- Exigeix accions no planificades segons sigui necessari durant les proves.
Les proves es poden substituir per una eina / màquina que serà capaç d’absorbir els detalls, processar-les, manar accions i realitzar-les com una ment humana i humana, i tot això en temps d’execució i en tots els contextos possibles. Aquesta eina ha de tornar a ser com tots els humans possibles.
Per tant, en resum, les proves humanes no es poden substituir. Potser alguna pel·lícula de ciència ficció de Hollywood d’aquí a uns anys se la vegi a prop, però a la vida real no puc veure-la venir durant uns centenars d’anys, que puc imaginar. No ho reduiré per sempre, ja que crec en infinites possibilitats.
En una nota diferent, fins i tot si realment passa després d’uns quants centenars d’anys, la imatge que puc imaginar és la d’un món aterrador segur. Era dels transformadors. :)
= >> Lectura recomanada - Millors empreses de serveis de proves manuals
Com l’automatització complementa les proves manuals?
Ja he dit abans i torno a dir que ja no es pot ignorar l'automatització. Al món on la integració contínua, el lliurament continu i el desplegament continu són obligatoris, les proves contínues no poden estar inactives. Hem d’esbrinar maneres de com fer-ho.
La majoria de les vegades, desplegar més i més personal no ajuda a la llarga a aquesta tasca. Per tant, el provador (cap de prova / arquitecte / gerent) ha de decidir amb precaució sobre què automatitzar i què s’ha de fer encara manualment.
S’està convertint en molt important tenir escrites proves / comprovacions molt precises perquè es puguin automatitzar sense cap desviació de l’espera original i que puguin utilitzar-se mentre es regressi el producte com a part de les 'proves contínues'.
Nota: La paraula contínua del terme 'Proves contínues' està sotmesa a trucades condicionals i lògiques similars als altres termes que hem utilitzat anteriorment amb el mateix prefix. Continuar en aquest context significa cada vegada més sovint, més ràpid que ahir. Si bé en sentit, pot molt bé significar cada segon o nanosegon.
Sense tenir una combinació perfecta de verificadors humans i controls automàtics (proves amb passos precisos, resultat esperat i criteris de sortida de la prova documentada), aconseguir proves contínues és molt difícil i això, al seu torn, farà que la integració contínua, el lliurament continu i el desplegament continu més difícil.
He utilitzat a propòsit el terme criteris de sortida d'una prova anterior. Els nostres vestits d’automatització ja no poden ser similars als tradicionals. Hem d’assegurar-nos que, si fracassen, fallin ràpidament. I per fer-los fracassar ràpidament, també s’han d’automatitzar els criteris de sortida.
Exemple:
Diguem que hi ha un defecte de bloqueig en què no puc iniciar la sessió a Facebook.
La funcionalitat d’inici de sessió ha de ser la primera comprovació automàtica i la vostra suite d’automatització no hauria d’executar la següent comprovació en què l’inici de sessió és un requisit previ, com publicar un estat. Sabeu molt bé que segur que fracassarà. Per tant, feu que falli més ràpidament, publiqueu els resultats més ràpidament perquè el defecte es pugui resoldre més ràpidament.
El següent és de nou alguna cosa que haureu d'haver sentit abans - No es pot ni s'ha d'intentar automatitzar tot.
Seleccioneu casos de prova que si s’automatitzen beneficiaran considerablement a Human Testers i té un bon retorn de la inversió. En aquest cas, hi ha una regla general que diu que heu d’intentar automatitzar tots els casos de prova de prioritat 1 i, si és possible, la prioritat 2.
L’automatització no és fàcil d’implementar i requereix molt de temps, per la qual cosa s’aconsella evitar automatitzar casos de baixa prioritat almenys fins al moment en què hagueu acabat els casos elevats. Seleccionar què voleu automatitzar i centrar-vos-hi millora la qualitat de l’aplicació quan s’utilitza i es manté contínuament.
Conclusió
Espero que a hores d’ara hagueu entès per què i fins a quin punt es requereixen proves manuals / humanes per lliurar productes de qualitat i com l’automatització ho complementa.
Acceptar la importància de les proves manuals de control de qualitat i saber per què és especial, és el primer pas per ser un provador manual excel·lent.
En els nostres propers tutorials de proves manuals, tractarem un enfocament genèric per fer proves manuals, com coexistirà amb Automation i molts altres aspectes importants.
Estic segur que obtindreu un immens coneixement de les proves de programari un cop hàgiu revisat tota la llista de tutorials d’aquesta sèrie.
com puc obrir fitxers apk
Ens encantaria tenir notícies vostres. No dubteu a expressar els vostres pensaments / suggeriments a la secció de comentaris de sota.
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
- Proves alfa i proves beta (guia completa)
- Proves funcionals contra proves no funcionals
- Els millors serveis de proves de programari de control de qualitat de SoftwareTestingHelp
- Curs de proves de programari: a quin institut de proves de programari m'he d'afegir?
- Tipus de proves de programari: diferents tipus de proves amb detalls
- Selecció de proves de programari com a carrera professional