practical software testing qa process flow
Una visió general completa del flux de processos de proves de programari de control de qualitat complet:
Nota: tornem a publicar aquesta publicació útil amb contingut actualitzat.
La feina del professional de proves de programari no és fàcil. Està ple de reptes, que són igualment exigents. Se suposa que els verificadors estan alerta i entusiastes en totes i cadascuna de les fases del cicle de vida de l’aplicació.
Tot i que hi ha reptes, també hi ha diverses oportunitats enormes per aprendre i explorar els diversos aspectes de les metodologies de prova, els processos i, per descomptat, el programari en detall.
El paper d’un enginyer de proves comença molt aviat. I des de la conceptualització del projecte, els provadors participen en discussions amb el propietari del producte, el gestor del projecte i diverses parts interessades.
Aquest tutorial sobre 'Flux de processos de prova de programari' us proporciona una visió completa de les diverses fases de STLC juntament amb els reptes implicats i les millors pràctiques per superar aquests reptes d'una manera fàcilment comprensible.
Què aprendreu:
- Requisit per alliberar: una visió general completa
- Procés de proves de qualitat en un projecte real: mètode de cascada
- Passos dels requisits per alliberar
- Conclusió
- Lectura recomanada
Requisit per alliberar: una visió general completa
Des del requisit fins al llançament, cada fase s’explica amb claredat. Vegem-los detalladament.
# 1) Requisit
Un projecte no pot enlairar-se sense tenir un requisit clar. Aquesta és la fase més crucial en què cal escriure idees en un document ben entenedor i formatat. Si formeu part del projecte on participeu a la fase de recollida de requisits, considereu-vos afortunat.
quant es pot guanyar en fer proves d’usuari
Es pregunta per què? És perquè estàs assistint a un projecte fent des de zero. Tot i que hi ha orgull de ser des dels seus inicis, també comporta algunes responsabilitats i reptes.
Desafiaments
No es poden imaginar tots els requisits per reunir-se en una sola sessió. Sigues prou pacient.
Passaran moltes discussions, algunes de les quals poden ser simplement irrellevants per al vostre projecte, però fins i tot poden contenir informació vital per al vostre projecte. De vegades, la velocitat de les discussions pot superar les vostres capacitats de captació o simplement no prestareu atenció al propietari del producte.
La imatge següent ressalta els passos crucials que implica la recollida de requisits:
Tota informació que es perd té un gran impacte en la comprensió i proves generals del projecte. Per superar-ho, aquí teniu algunes de les millors pràctiques que s’han de seguir durant aquesta fase.
Millors pràctiques
- Mantingueu la ment oberta i presteu atenció a totes les paraules del propietari del producte.
- No només escolteu, elimineu el vostre dubte per petit que sembli.
- Utilitzeu sempre portàtils per tenir notes ràpides. Heu d’utilitzar un ordinador portàtil només si realment podeu escriure a una velocitat raonable.
- Repetiu les frases i aclariu-les a partir del PO que creieu que heu entès.
- Dibuixeu diagrames de blocs, text d'enllaç, etc. per fer més clars els requisits en un període de temps posterior.
- Si els equips es troben en ubicacions diferents, intenteu convertir-lo en un enregistrament WebEx o similar. Sempre us ajudarà quan tingueu dubtes després de finalitzar les discussions.
Tot i que no hi ha un mur separat com a tal per a cada fase, els requisits canvien fins i tot molt tard en els desenvolupaments. Per tant, la idea és agafar la major part del requisit i documentar-ho correctament.
Un cop s'hagi documentat amb tots els punts necessaris, distribuïu i discutiu tots els grups d'interès per tal que els suggeriments o canvis es detectin abans i abans de continuar, tothom es troba a la mateixa pàgina.
# 2) Estratègia de prova
Se suposa que els provadors presentaran una estratègia de prova que no només és suficient per provar millor el programari, sinó que també hauria d’inculcar confiança a totes les parts interessades quant a la qualitat del producte.
Desafiaments
L'aspecte més crucial d'aquesta fase és crear una estratègia que, quan es treballa, ha de lliurar un producte de programari lliure d'errors, sostenible i acceptat pels seus usuaris finals.
Les estratègies de prova són una cosa que no canviaràs cada dos dies. En alguns casos, també heu de parlar de les vostres estratègies de prova amb els clients. Per tant, aquesta part s’hauria de tractar amb molta importància.
Millors pràctiques
- A continuació, es detallen algunes de les millors pràctiques que, quan se segueixen, us poden proporcionar un gran alleujament i resultar en proves senzilles.
- Torneu a revisar el document de requisits. Ressalteu els punts d'importació respecte a l'entorn del programari de destinació.
- Feu una llista d’entorns on realment es desplegarà el programari.
- Els entorns es poden entendre com un tipus de sistemes operatius o dispositius mòbils.
- Si Windows és el sistema operatiu, enumereu totes les versions de la finestra on provareu el vostre programari. Si les versions és a dir. Windows 7, Windows 10 o Windows Server encara no estan definits al document de requisits; aleshores és el moment en què s’haurien de discutir.
- En una nota similar, obteniu els navegadors de destinació amb les versions discutides i documentades si l'AUT és un sistema basat en web.
- Feu una llista de tots els programes de tercers que necessitarà l’aplicació (si cal / s’admet). Aquests poden incloure Adobe Acrobat, Microsoft Office, qualsevol complement, etc.
Aquí la idea darrere és mantenir totes les plataformes, dispositius i programari necessaris i necessaris que la nostra aplicació haurà de funcionar davant nostre per poder formular una estratègia completa.
La figura següent us ajudarà a entendre l’esquema de l’estratègia de prova si esteu treballant en un projecte àgil:
# 3) Planificació de proves
Després que els provadors estiguin armats amb tota la informació relativa a la AUT, la fase de planificació és on s’implementa l’estratègia.
Igual que una estratègia de prova, la planificació de proves també és una fase crucial.
Desafiaments
Atès que l'èxit (o el fracàs) de l'AUT depèn en gran mesura de com es van dur a terme les proves, aquesta fase es converteix en un aspecte important de tot el cicle de vida de les proves. Per què? Perquè en aquesta fase es defineix una part de les proves.
Per superar alguns reptes, aquestes pràctiques recomanades poden ser útils.
Millors pràctiques
- Tingueu sempre present que no heu de deixar cap pedra a l’hora de provar la vostra aplicació.
- És hora de formular una estratègia de prova.
- Creeu una matriu de l'entorn perquè el programari es provi a totes les plataformes.
- Igual, Windows 10 + Internet Explorer 11+ Windows Office 2010+.
- Com el navegador Chrome Android 4.2.2+.
- Si l'aplicació funciona amb diverses bases de dades (si està documentada), mantingueu les bases de dades (MySQL, Oracle, SQLServer) a la matriu de prova de manera que estiguin massa integrades amb algunes proves.
- Configureu les màquines de prova en conseqüència i nomeneu-les com a SetUp1, SetUp2, etc.
- SetUp1 tindrà Windows 7+ IE 10+ Office 2007+.
- SetUp2 pot tenir Windows 10+ IE Edge + Office 2013+.
- És possible que SetUp3 tingui un telèfon Android amb el fitxer .apk instal·lat.
- Enhorabona! La configuració de la prova està a punt i també heu inclòs totes les combinacions possibles de plataformes que funcionaran amb la vostra aplicació.
# 4) Proves
Finalment, la compilació de la vostra aplicació ha finalitzat i esteu a punt per trobar errors. Ara és hora de treballar en la planificació de proves i trobar tants errors com sigui possible. Hi haurà algunes fases entremig si treballeu en un entorn àgil, i simplement seguiu aquests mètodes de scrum.
El diagrama següent mostra la classificació de diversos tipus de proves:
Desafiaments
Les proves són un procés feixuc i propi d’errors. Es troben molts reptes en provar una aplicació. A continuació es detallen algunes de les millors pràctiques per rescatar.
Millors pràctiques
Animeu-vos! Esteu intentant trobar defectes al codi. Cal parar atenció al funcionament general del programari.
- Sempre és aconsellable mirar l’aplicació amb un aspecte fresc, SENSE PASAR CASOS DE PROVA.
- Seguiu el camí de navegació del vostre programari (AUT).
- Familiaritzeu-vos amb l’aut.
- Ara llegiu els casos de prova (Tots) de qualsevol mòdul en particular (potser que trieu).
- Ara aneu a l’AUT i feu coincidir els resultats amb els esmentats a la secció esperada dels casos de prova.
- La idea darrere d’això és provar totes les funcions esmentades en totes les plataformes compatibles.
- Preneu nota de cada desviació per molt trivial que sembli.
- Escriviu els passos per arribar a qualsevol desviació, fer captures de pantalla, capturar registres d'errors, registres de servidor i qualsevol altra documentació de suport que pugui demostrar l'existència de defectes.
- No dubteu a preguntar-ho. Tot i que teniu el document de requisits, hi haurà moments en què tindreu dubtes.
- Contacteu amb els desenvolupadors (si es troben al vostre costat o s’hi pot arribar) en dubte abans d’arribar al propietari del producte. Comprendre la perspectiva del desenvolupador sobre el funcionament del programari. Enteneu-los. Si creieu que aquesta implementació no és d’acord amb el requisit, informeu-ho al gestor de proves.
# 5) Abans del llançament
Abans de llançar qualsevol producte al mercat, s’ha d’assegurar la qualitat del producte. Els programes es desenvolupen una vegada, però s’han provat fins que se substitueixen o s’eliminen.
Desafiaments
El programari ha de ser provat rigorosament per a molts dels seus paràmetres.
Els paràmetres no es poden limitar a:
- Funcionalitat / Comportament.
- Rendiment.
- Escalabilitat.
- Compatible amb les esmentades plataformes.
El repte també és predir la taxa d’èxit d’una aplicació que depèn de moltes iteracions de les proves realitzades.
Millors pràctiques
- Assegureu-vos que es provin totes les funcions de totes les plataformes.
- Ressalteu les àrees que no estan provades o la que necessita més esforços de prova.
- Conserveu una matriu de tots els resultats de la prova abans de la publicació. La matriu de prova donarà una visió general de l’estabilitat del producte. També ajudarà a la direcció a rebre trucades en les dates de llançament.
- Proporcioneu a l’equip les vostres aportacions / suggeriments sobre les vostres experiències mentre proveu el producte.
- La vostra opinió en considerar-vos l'usuari final beneficiarà en gran mesura el programari.
- A causa de la manca de temps o de qualsevol altra situació d’aquest tipus, ens perdem algunes proves o no aprofundim en això. No dubteu a comunicar l’estat de les proves al vostre gestor.
- Presentar la targeta sanitària de la sol·licitud als grups d'interès. Les targetes sanitàries haurien de tenir diversos defectes registrats, oberts, tancats i intermitents amb la seva gravetat i prioritat.
- Redacteu un document de llançament i compartiu-lo a tot l'equip.
- Treballeu al document de llançament preparat.
- Millorar les àrees suggerides per la direcció o l’equip.
La imatge següent mostra el mapa del cicle de vida de la versió del programari:
# 6) Alliberament
Finalment, arriba el moment en què hem de lliurar el producte als seus usuaris previstos. Com a equip, hem treballat molt per tancar el producte i deixar que el programari ajudés els seus usuaris.
Desafiaments
Els enginyers de proves de programari són els principals responsables de la publicació de qualsevol programari. Aquesta activitat requereix un flux de treball orientat al procés. Aquí hi ha algunes de les millors pràctiques que intervenen en aquesta fase.
Millors pràctiques
- Recordeu sempre que no esteu treballant en el document de llançament la data de la REALITZACIÓ REAL.
- Planifiqueu sempre l’activitat de llançament abans de la data de llançament real.
- Estandarditzeu el document segons les polítiques de l'empresa.
- El document de publicació hauria d’intentar establir expectatives positives del programari.
- Esmenteu clarament al document tots els requisits de programari i maquinari específics de les seves versions.
- Incloeu tots els defectes oberts i la seva gravetat.
- No amagueu les zones afectades més importants a causa de defectes oberts. Doneu-los un lloc al document Release.
- Obteniu el document revisat i signat digitalment (pot variar segons la política de l'empresa).
- Tingueu confiança i envieu el document de llançament juntament amb el programari.
Procés de proves de qualitat en un projecte real: mètode de cascada
Tinc una pregunta interessant d'un lector, Com es realitzen les proves en una empresa, és a dir, en un entorn pràctic?
Els que acaben de passar la universitat i comencen a buscar feina tenen aquesta curiositat: com seria l’entorn laboral real en una empresa?
Aquí m'he centrat en el procés de treball real de Proves de programari a les empreses .
Sempre que aconseguim algun projecte nou, hi ha una reunió inicial de familiaritat amb el projecte. En aquesta reunió, bàsicament discutim qui és el client? quina és la durada del projecte i quan es realitza? Qui participa en el projecte, és a dir, gerent, responsables tècnics, contactes de control de qualitat, desenvolupadors, verificadors, etc.?
A partir de l’especificació de requisits de programari (SRS) es desenvolupa el pla de projecte. La responsabilitat dels verificadors és crear un pla de proves de programari a partir d’aquest SRS i del pla de projecte. Els desenvolupadors comencen a codificar a partir del disseny. El treball del projecte es divideix en diferents mòduls i aquests mòduls del projecte es distribueixen entre els desenvolupadors.
Mentrestant, la responsabilitat d’un provador és crear un escenari de prova i escriure casos de prova d’acord amb els mòduls assignats. Intentem cobrir gairebé tots els casos de proves funcionals de SRS. Les dades es poden mantenir manualment en algunes plantilles de casos de proves Excel o eines de seguiment d'errors.
Quan els desenvolupadors acaben els mòduls individuals, aquests mòduls s'assignen als provadors. Es fan proves de fum en aquests mòduls i, si fallen en aquesta prova, els mòduls es reassignen als respectius desenvolupadors per a una solució.
Per als mòduls aprovats, es realitzen proves manuals a partir dels casos de proves escrites. Si es troba algun error que s'assigna al desenvolupador del mòdul i es registra a eina de seguiment d'errors . En la correcció d'errors, un provador fa verificació d'errors i proves de regressió de tots els mòduls relacionats. Si l'error passa la verificació, es marca com a verificat i es marca com a tancat. En cas contrari, el cicle d’errors esmentat es repeteix. (Cobriré el cicle de vida dels errors en una altra publicació)
Es realitzen diferents proves en mòduls individuals i proves d’integració en integració de mòduls. Aquestes proves inclouen proves de compatibilitat, és a dir, proves d’aplicacions en diferents maquinari, versions del sistema operatiu, plataformes de programari, diferents navegadors, etc.
També es realitzen proves de càrrega i esforç segons SRS. Finalment, la prova del sistema es realitza creant un entorn de client virtual. Un cop executats tots els casos de prova, es prepara un informe de prova i es pren la decisió d’alliberar el producte.
Passos dels requisits per alliberar
A continuació es detallen els detalls de cada pas de prova que es duu a terme en cada cicle de vida i proves de qualitat del programari i de prova Estàndards IEEE i ISO.
# 1) Revisió SRS : Revisió de les especificacions de requisits de programari.
# 2) Objectius estan configurats per a les versions principals.
# 3) Data objectiu previst per a les versions.
# 4) Pla detallat del projecte està construït. Això inclou la decisió sobre les especificacions de disseny.
# 5) Desenvolupeu un pla de proves es basa en les especificacions de disseny.
# 6) Pla de prova: Això inclou objectius, la metodologia adoptada durant la prova, les característiques que s'han de provar i no provar, els criteris de risc, el calendari de proves, el suport multiplataforma i l'assignació de recursos per a la prova.
# 7) Especificacions de la prova: Aquest document inclou detalls tècnics (requisits de programari) necessaris abans de la prova.
# 8) Redacció de casos de prova
- Fum ( BVT ) casos de prova
- Casos de prova de seny
- Casos de proves de regressió
- Casos de prova negatius
- Casos de proves ampliats
# 9) Desenvolupament: Els mòduls es desenvolupen un per un.
# 10) Enllaços dels instal·ladors: Els instal·ladors es construeixen al voltant del producte individual.
el millor tallafoc gratuït per a Windows 7
# 11) Procediment de construcció : Una versió inclou instal·ladors dels productes disponibles: diverses plataformes.
# 12) Proves: Prova de fum (BVT): prova bàsica d’aplicació per prendre una decisió sobre proves posteriors.
- Prova de noves funcions
- Navegador creuat i proves multiplataforma
- Proves d’esforç i proves de fuites de memòria.
# 13) Informe de resum de la prova
- Informe d'error i es creen altres informes
# 14) Congelació del codi
- En aquest moment no s’afegeixen més funcions noves.
# 15) Proves: Proves de compilació i regressió.
# 16) Decisió d’alliberar el producte.
# 17) Escenari posterior al llançament per a altres objectius.
Es tractava d’un resum d’un procés real de proves en un entorn empresarial.
Conclusió
La feina d’un provador de programari està plena de reptes, però divertits. Això és per a algú que és igualment apassionat, motivat i ple d'entusiasme. Trobar falles en algú no sempre és una feina fàcil. Això requereix moltes habilitats i un bon ull als defectes.
A més de totes les qualitats, un provador també ha d’estar orientat al procés. Com totes les altres indústries, els projectes de TI es treballen massa per fases, on cada fase té uns objectius ben definits. I cada objectiu té un criteri d’acceptació ben definit. Un enginyer de proves ha de portar moltes càrregues de qualitat de programari a les seves espatlles.
Mentre treballen en qualsevol fase del programari, se suposa que els provadors han de seguir les millors pràctiques i s’han d’alinear amb el procés implicat en les fases respectives. Seguir les millors pràctiques i un procés ben formulat no només ajuda a facilitar el treball dels verificadors, sinó que també ajuda a garantir la qualitat del programari.
Heu format part d'alguna de les fases anteriors? No dubteu a compartir les vostres experiències a continuació.
Lectura recomanada
- Les millors eines de prova de programari 2021 (Eines d'automatització de proves de control de qualitat)
- Curs de proves de programari: a quin institut de proves de programari m'he d'afegir?
- Prova de programari Treball d'assistent de control de qualitat
- 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
- Com millorar el procés de llançament de la prova per a la producció de programari lliure d'errors amb èxit