Menú

Implementació pràctica en 7 passos de les proves manuals abans del llançament de la producció

7 step practical implementation manual testing before production release

Proveu El Nostre Instrument Per Eliminar Problemes

A la publicació anterior d’aquesta sèrie al voltant de les proves manuals, vaig intentar llançar tanta llum com fos possible sobre els conceptes bàsics de les proves manuals.

Si t'ho vas perdre, el podeu llegir aquí .

Espero que tingués èxit en apropar-vos el més a prop possible de les respostes que buscàveu.

En aquest cas, no us agradaria saber més sobre la implementació pràctica de les proves manuals, com familiaritzar-vos-hi i com iniciar-hi una carrera?

Aquest article donarà llum a tots aquests aspectes.

Implementació de proves manuals

Comencem.

Què aprendreu:

Cicle de proves manuals

Entendre Cicle de proves manuals o Software Test Life Cycle (STLC), primer de tot, hem d’entendre el cicle de vida de desenvolupament de programari (SDLC), que estic segur que ja coneixeu.

La gent els fa referència per separat, però no està segur de si poden coexistir realment. Són tan estretament integrats entre si. Bé, fins i tot aquests cicles tenen tantes versions creades i flotants a l’espai d’Internet, que varien majoritàriament segons el model de desenvolupament seleccionat.

Com la majoria dels el món va Agile aquests dies, mantindré les meves coses simplificades al voltant d’Agile.

7 passos pràctics de proves manuals abans del llançament de la producció

Aquí vaig.

Recordeu que estic parlant tant de SDLC com de STLC.

# 1) Reunió de requisits

Fase de reunió de requisits

Business Analyst (persona / equip responsable de la reunió de requisits) documenta els requisits. Documenten els requisits, això és el més destacat, només podeu mantenir el focus en això. On es documenta importa menys.

La gent utilitza qualsevol cosa per documentar-los que els convingui, però no es limita a plataformes tradicionals com MS Word doc, plataformes modernes com Jira / Rally i eines de la nova era com Trello.

# 2) Discussió / Compartir requisits

Fase de discussió de requisits

Business Analyst hauria de compartir requisits documentats amb l’equip de desenvolupament, l’equip de proves i l’equip UX (si cal). Això sol passar mitjançant una reunió formal on SPOC (punt únic de contactes o tot un equip, depèn) de les tres funcions compleixen i entenen tot el requisit.

En una cultura del treball saludable, els requisits es discuteixen des de tots els angles i cada membre de la reunió pot fer preguntes i dubtes. Una vegada que es responguin a totes les preguntes i es faci la modificació necessària del requisit, aquesta fase es pot considerar com Feta. Una vegada més, el que hom anomena aquesta reunió / pas en concret i la seva documentació difereixen d'una empresa a una altra.

Per llegir més=> Com revisar el document SRS

Un cop respostes a totes les preguntes i realitzades les modificacions necessàries en el requisit, aquesta fase es pot considerar com a Fet .

Una vegada més, el que hom anomena aquesta reunió / pas en concret i la seva documentació difereixen d'una empresa a una altra.

Per exemple, la documentació es denomina o es descompon com a SRS (System Requirement Specification), Document de requisits, Epic, User Story, Story point (possiblement, la unitat de requisit més petita), etc. Requisit Reunió de debat, preparació, reunió de perforació, etc., espero que obtingueu el meu punt?

Prement aquestes terminologies perquè recordeu sempre la idea principal, independentment dels diferents noms.

Publicar aquesta reunió es desencadenen dos passos al mateix temps, sense cap ordre concret, consulteu els dos passos següents.

# 3) Disseny

L'equip de desenvolupament comença amb el seu disseny tècnic tan aviat com es discuteixen els requisits i quan no hi hagi punts pendents importants. El que es fa en aquesta fase torna a diferir d’empresa en empresa.

Aquesta fase pot implicar, entre d'altres, les tasques següents:

  • Decidir l'enfocament del desenvolupament
  • Preparació del document de disseny
  • Disseny dels diagrames de flux
  • Estimació dels esforços
  • Esbrinar l'impacte d'aquest nou requisit en qualsevol funcionalitat existent
  • Necessitat de pegar dades existents, etc.

L'equip UX també pot participar en aquesta fase quan es produeixi un canvi de interfície d'usuari o es desenvolupi una nova pantalla. L'equip UX ajuda l'equip de desenvolupament i l'equip de proves amb el prototip de la IU per a la funcionalitat / funció del debat. Pot ser un document de Photoshop, una imatge simple, una presentació de PowerPoint o qualsevol altra cosa que faci que l'equip de desenvolupament entengui com s'han de desenvolupar les pantalles.

Nota: L’ideal és que aquestes pantalles o, com a mínim, les seves versions esborranys, es mostrin a la sessió de debat sobre requisits només per ajudar l’equip a entendre millor. S'etiqueta segons el requisit original perquè es pugui fer referència en qualsevol moment.

# 4) Escenari de prova / Disseny de casos de prova

Fase de disseny de l

Paral·lelament a la fase de disseny, l'equip de proves comença amb la creació d'escenaris de prova i / o casos de prova en funció dels requisits discutits. Si els escenaris de prova sempre s’escriuen primer i després es divideixen en casos de prova és una cosa que de nou no és constant.

Al meu entendre, tant si documenteu els escenaris de prova com si no, sempre hi són abans dels casos de prova. Test Scenario és el vostre punt bàsic, podeu dir, que us guien per aprofundir en les coses. Un cop finalitzada l’escriptura de casos de prova, es pot compartir amb l’equip de desenvolupament per donar-los una idea de l’abast de les proves i també poden assegurar-se que el desenvolupament que ha passat o està satisfent els casos de prova escrits.

Un cop finalitzada l’escriptura de casos de prova, es pot compartir amb l’equip de desenvolupament per donar-los una idea de l’abast de les proves i també poden assegurar-se que el desenvolupament que ha passat o està satisfent els casos de prova escrits.

Els casos de prova un cop escrits són ideals per a ser revisats per un responsable de proves o parells des de molts angles, com ara:

  • Cobertura de requisits
  • Gramàtica ortogràfica
  • Provar estàndards d'escriptura de casos (res més que una plantilla que segueix un equip / empresa)
  • Compatibilitat amb versions anteriors
  • Compatibilitat de plataformes
  • Proves de referències de dades
  • Tipus de proves orientades, etc.

Per llegir més=> Escriptura de casos de prova a partir del document SRS

Idealment, només després de la revisió i la modificació necessària, es transmetran a l'equip de desenvolupament.

Quan vaig dir 'un cop finalitzada l'escriptura de casos de prova', volia dir que 'tots els casos de prova s'escriuen basant-se en el coneixement complet del requisit donat i dels possibles escenaris de prova descoberts fins a aquell moment concret'. És gairebé impossible tenir una cobertura del 100% dels casos de prova al primer cop.

Hi haurà defectes que trobareu en accions aleatòries (però previstes), en accions purament aleatòries (proves de mico) i en alguns casos poc freqüents. Hi ha possibilitats que en perdeu algunes. I en algun moment potser us en perdrà fins i tot d’altres de bàsics, al cap i a la fi, sou humans. Però aquí, com a mínim, una bona revisió de casos de prova i una manera estructurada d’escriure casos de prova us poden estalviar.

El més freqüent és que un provador o un equip de proves segueixi afegint cada cop més casos de prova al fragment existent a mesura que descobreixen la veritat o pensen més sobre els requisits.

Bé, a hores d’ara alguns de vosaltres heu de dubtar del meu coneixement de les proves de programari, ja que alguna paraula (que s’ha convertit en una norma en les proves de programari) encara no l’utilitzo. Pla de proves, oi?

Deixeu-me dir alguna cosa sobre això. Crec fermament en la necessitat de la major part de la informació que s’esmenta al pla de proves, però documentar-la al mateix lloc i fer-la absoluta obligatòria és una cosa que em sembla discutible.

De totes maneres, aquest és un tema independent per discutir. Compartir una informació que “s’adapti a tothom” és difícil, però permeteu-ho.

Tant vosaltres, vosaltres, amb el cap de prova o el cap de prova, prepareu el pla de proves o bé documenteu la informació necessària en diferents llocs.

Per llegir més=> Com escriure un document de pla de prova

Informació que hauria d’estar absolutament congelada en aquesta etapa:

  • L'abast de les proves: Requisits, compatibilitat amb versions anteriors, plataformes, dispositius, etc.
  • Persona / equip que farà la prova
  • Estimació de l'esforç de prova
  • Limitacions: Qualsevol supòsit o limitació acceptada per endavant.
  • A més, la gent documenta els criteris d’entrada, els criteris de sortida, el risc, etc., que crec que no necessiten mencions separades, ja que hauria de ser una comprensió normal.
    • Criteris d’entrada (Quan es comença a provar): pocs comencen quan hi ha una part de funcionalitat comprovable disponible per provar. Pocs esperen que tota la funcionalitat es pugui provar. Quan es constata que el flux bàsic funciona, comencen les proves.
    • Criteris de sortida (Quan s’ha d’aturar): quan no hi ha cap bloquejador, es poden aturar defectes crítics i majors (sotmesos a un impacte) en proves en fase oberta. O a mig camí, quan hi ha massa defectes que s’enfronten a les proves, poden ser detinguts per les parts interessades adequades.
    • Risc : Risc empresarial o funcional si les proves no es realitzen segons el pla documentat.

# 5) Fase de desenvolupament

Fase de desenvolupament de programari

Després de la fase de disseny, l’equip de desenvolupament comença amb el desenvolupament real i les proves d’unitats a mesura que s’acaba amb el desenvolupament de trossos de requisits testables. Poden transmetre la funcionalitat per provar-la en trossos a mesura que s’implementi o poden passar tota la funcionalitat alhora.

En un escenari ideal, es realitza la revisió formal del codi i les proves de caixes blanques abans de passar la funcionalitat desenvolupada per a les proves. idealment, l'equip de desenvolupament també hauria de fer referència als casos de prova proporcionats per l'equip de proves, a més dels requisits i dels documents de disseny.

# 6) Fase de proves

Com s'ha esmentat anteriorment, l'inici d'aquesta fase difereix d'una empresa a una altra, d'un equip a un altre.

L’equip de proves comença a provar quan es desenvolupa una part de tot el requisit que es pot provar (quelcom que es pot provar independentment) o bé quan es desenvolupa tot el requisit.

què és l'aplicació d'una sola pàgina a angularjs

Permeteu-me aprofundir en aquesta fase i parlar de les tasques importants:

  • L’equip de proves / proves comença amb una ronda de proves (proves exploratòries i execució de casos de proves escrites) i defectes de registre
  • L’equip de desenvolupament els resol segons la prioritat.
  • Es pren una nova versió (codi) sobre l'entorn on s'estan realitzant proves
  • Els provadors / equips de proves verificen els defectes resolts i es marquen com a solucionats
  • Aquest cicle continua fins que s’assoleixen els criteris de sortida horària.
  • Tingueu en compte que, si cal, els defectes també es marquen com a invàlids, duplicats i també es poden classificar com a millores.

Una altra cosa que diferencia l'empresa a l'empresa és la quantitat de proves que cal fer. Igual que en alguns casos, la primera ronda de proves es produeix en peces de característiques petites ja que estan llestes, seguida d'una ronda de proves de punta a punta en un altre entorn un cop desenvolupats tots els requisits. Però, de nou, també he sentit a parlar de gent que fa tres rondes de proves completes adequades i la quarta ronda com a seny / fum.

La primera agenda darrere de fer diverses rondes de proves és provar la funcionalitat en diferents entorns i la segona per fer proves de punta a punta un cop desenvolupats tots els punts de la història. Normalment, la ronda de seny guanya confiança ràpida un cop totes les històries d’una versió es desenvolupen i es proven de forma independent.

Llegiu els passos detallats=> Fase d’execució de la prova

# 7) Revisió de Business Analyst (BA)

Un analista empresarial revisa la funcionalitat que es demana referint-se al resultat de la prova o fent referència al resultat de la prova, a més de jugar amb l'aplicació per obtenir una sensació real. Aquest pas torna a estar sotmès a diferents accions entre empreses.

El BA pot revisar l'abast de tota la versió d'una sola vegada o en trossos. Depenent del mateix, aquest pas pot arribar abans de la prova final de seny o després de la ronda final de proves de seny per part de l'equip de proves.

Més de 7 passos succeeixen perquè es compleixin totes les històries / requisits dels usuaris, en particular la versió (enviament). Un cop finalitzats tots aquests passos per a tots els requisits, es diu que la versió està preparada per a l'enviament.

# 8) Enviament / alliberament

El llançament està etiquetat com a Llest per a l’enviament després de la revisió realitzada per Business Analyst.

Lectura recomanada=> Procés de llançament de la prova

Tipus de proves manuals (llegiu en humans)

Doncs bé, si hem de parlar dels tipus generals de proves en números, en algun lloc que he trobat 100 tipus de proves amb noms diferents . Per ser sincer, no sóc prou intel·ligent per entendre la distinció entre tots aquests tipus (joc de paraules).

És recte i senzill: Prova de la funcionalitat de l’aplicació contra el requisit donat amb intel·ligència i esforços humans. A més, es divideix en pocs tipus segons l’abast i l’agenda de les proves. Tipus que figuren al paràgraf següent.

A més, es divideix en pocs tipus segons l’abast i l’agenda de les proves. Tipus que figuren al paràgraf següent.

Si se'm permet, deixeu-me parlar de poques línies de proves humanes (cosa que animo a tots els provadors a fer només proves funcionals manuals). Ara no us confongueu; al meu entendre, les proves manuals de funcionament són un subconjunt de les proves humanes. Perquè hi ha tantes coses que només la ment humana pot fer.

A continuació es mostra la llista amb alguns dels tipus de proves populars i importants que es poden classificar en Proves humanes:

  • Proves funcionals manuals : Prova de la funcionalitat de l’aplicació contra el requisit donat amb intel·ligència i esforços humans. A més, es divideix en força tipus segons l’abast i l’agenda de proves, com ara proves de sistemes, proves d’unitats, proves de fum, proves de seny, proves d’integració, proves de regressió, proves d’interfície d’usuari, etc.
  • Proves de rendiment : Això es classifica en proves no funcionals, oi? Però, de nou, és l'humà qui ho implementa, tot i que l'execució la fa un humà o una eina. El provador hauria de fer aquesta prova almenys pel que fa al temps de resposta (per veure si és acceptable) si se suposa que no utilitza cap eina per provar la càrrega i tot.
  • Navegador / Prova de compatibilitat de la plataforma: L'aplicació en proves hauria de tenir un aspecte i funcionar com s'esperava (òbviament, pot haver-hi una diferència menor segons el motor del navegador) entre navegadors i plataformes (o dispositius si es tracta d'una aplicació mòbil).
  • Proves d’usabilitat : Permeteu-me estar d’acord en primer lloc que aquest és un tema enorme en si mateix i que solen pertànyer a especialistes en proves d’usabilitat. Encara crec que, com a provador, hauríem d'informar o ressaltar almenys si trobem alguna cosa menys utilitzable o hauríem de compartir la nostra opinió.
  • Proves de seguretat : De nou, un tipus de prova molt enorme i, per descomptat, requereix molts coneixements pràctics. El provador hauria d’intentar aprendre i executar almenys proves bàsiques com la manipulació d’URL, la creació de scripts entre llocs, la injecció SQL, el segrest de sessions, etc., segons el coneixement disponible i sempre que sigui aplicable.
  • Proves de lloguer múltiple: Si la vostra aplicació és multiarrendatària, és a dir, una única instància que conté dades de diversos clients, aquesta prova és imprescindible. Independentment de l’esment explícit en els requisits, s’hauria de fer. Les dades d’un client que es mostren a un altre són una mena de delicte de desenvolupament i proves.

Nota: A sobre de les vistes hi ha les meves opinions personals. També us recomano que feu una ullada a la llista extensa de tipus de proves per al vostre coneixement i que els seguiu / utilitzeu si ho creieu necessari. Al llarg dels anys he entès que, tant si utilitzeu alguna cosa com si no, creieu en alguna cosa o no, encara heu de tenir coneixement de conceptes àmpliament utilitzats en el vostre camp.

Això és tot per aquesta part. Gràcies per llegir. Comparteix les teves opinions / comentaris als comentaris.

A la següent i última part d’això sèries de tutorial de proves manuals , Intentaré ajudar-vos a tots quina preparació hauríeu de fer si voleu entrar al camp de proves i quines són les maneres possibles d’entrar-hi.

Lectura recomanada

^