how improve test release process
Vegem el procés típic que implica el lliurament de programari des de la 'fase de desenvolupament' fins a la 'fase de proves' per a llançament amb èxit de programari lliure d'errors a la producció / client .
Aquests processos són ignorats o omesos per les empreses de programari, cosa que resulta en una mala gestió de les proves i, per tant, 'a' buggy 'Llança el programari al client, cosa que condueix a' clients insatisfets '.
Encara que L'equip de proves proporciona molt de temps i un gran esforç per a cada versió , quan el programari llançat no té la qualitat definida o està marcada com a benchmark o no compleix els criteris esperats, no només afectarà la reputació de l’empresa amb els clients, sinó que també desmotivarà i desmoralitzarà l’equip del projecte i, sobretot, l’equip de proves en general .
Si formeu part d'un equip de proves en aquest escenari, podeu continuar pensant 'com millorar les meves capacitats de proves i hi ha alguna manera millor de superar aquesta situació'.
Vull donar alguns consells i suggeriments, basats en la meva experiència amb diversos equips de proves implicats en aplicacions de programari i versions de productes empresarials amb diversos dominis i plataformes i amb diversos marcs de proves, a com millorar els processos de llançament de la prova , que us simplificarà la vida professional com a enginyer de proves o gestor de proves per oferir programari de primer nivell.
Què aprendreu:
- Procés de llançament de la prova
- Millora del procés de llançament de proves:
- Gestió i control del contingut de la versió de prova
- Plantilla d'informe de llançament de mostra:
- Conclusió:
- Lectura recomanada
Procés de llançament de la prova
La taula següent proporciona una visió general del procés de llançament de proves amb tres fases universals com Entrada, Procés i Sortida.
punteres de llista enllaçats c ++
| ENTRADA | PROCÉS | SORTIDA |
|---|---|---|
| 7 | La llista de comprovació de revisió de codi s'ha actualitzat i està disponible a VSS? | |
| Procés previ Desenvolupament | El procés comença amb • Instal·lació del programari llançat al servidor de proves | Necessitats del següent procés • Programari que ha passat les proves de fum / seny |
| Referència d'informació / document • Document de requisits de l'usuari • Especificacions de requisits de programari • Pla de proves unitàries • Normes de codificació • Llista de comprovació de revisió de codi • Pla de desenvolupament • Pla d'assegurament de la qualitat • Assignació de tasques • Paquet de treball • Programació del projecte • Pla del projecte • Pla de gestió de configuracions • Pla de gestió de riscos. | Subprocessos • Preparació de casos de prova per a totes les unitats • Desenvolupament i proves unitàries • Gestió de procediments de no conformitat • Implementació del pla de gestió de configuracions. • Implementació del pla de gestió de riscos • Seguiment del progrés del projecte • Correcció d'errors i ressenyes | Necessitats internes del client • Creació de programari amb número de versió • Informe de llançament • Casos de prova / Document de proves • Planificació de l'execució de proves • Matriu de traçabilitat • Dades de prova |
| Verificació de l'entrada entrant • Els documents del projecte són revisats i aprovats? • Els estàndards de codificació, la llista de comprovació de revisió de codi estan disponibles per a referència? • Tasca assignada i paquet de treball actualitzat? • Es revisen i aproven les especificacions funcionals, el pla de desenvolupament i el pla de qualitat? • El pla de gestió de riscos té mitigació i contingència per gestionar el risc? • Eficàcia de la programació del projecte per lliurar el producte a temps? | Especificació del procés • Els casos de prova unitària han de constar de tots els criteris d’entrada i sortida • Compliment del codi amb les normes de codificació • El NCP s’ha de gestionar segons la Guia • Els passos de gestió de la configuració han de complir el pla de gestió de configuracions • La gestió del risc s’ha d’adherir al pla de gestió de riscos • Les proves de fum superen totes les funcions i funcions principals | Necessitats externes del client • Programari lliure d’errors |
| Processos de suport • Humà / Maquinari / Programari / Assignació de recursos • Manteniment per avaria del maquinari • Formació als membres de l'equip | El procés finalitza amb • Execució de proves de fum / seny a l’edifici publicat | Paràmetres d'eficiència • Cada unitat hauria de passar la primera ronda de proves • Tasques a completar segons la Programació del Projecte • La prova de fum s’ha de passar abans de l’alliberament • Prova de la passió de l'equip per provar el programari |
Tots els equips de proves haurien de crear un fitxer únic llista de comprovació per al llançament de programari, segons el domini i la plataforma del programari i la metodologia de gestió de projectes (com Agile Scrum, etc.) i segons el marc de proves manuals / automatitzades, per acceptar la versió llançada, abans d’iniciar l’execució de la prova per estalviar temps i esforç.
Aquest és un dels paràmetres d’eficiència més importants en la fase de llançament de la prova.
Millora del procés de llançament de proves:
1) Reviseu l'informe de llançament per a la nova funcionalitat, personalització / modificació de la funcionalitat existent, correcció d'errors de la versió anterior, que decidirà començar a executar les proves de fum o proves de seny o una combinació d'ambdues.
2) Reviseu l'actualització Documents de prova segons la nova funcionalitat i les correccions d'errors, si encara no s'han actualitzat. Normalment, durant el cicle de vida del desenvolupament de programari, l’equip de proves actualitza aquests documents en funció de les reunions setmanals de revisió de projectes.
3) Reviseu la compilació de programari al dipòsit de configuració s'actualitza per al número de compilació, número de versió, etiquetat o comentat amb el nom de la versió segons els estàndards definits al pla de projecte. A més, assegureu-vos que la compilació es compila i s’instal·la correctament al servidor de proves.
4) Programa una reunió ràpida de revisió del projecte després del llançament per discutir els pros i els contres de la versió llançada, els errors coneguts i la funcionalitat crítica, etc., per evitar qualsevol mala comunicació i revisar els requisits importants del client. Eviteu estrictament qualsevol comunicació oral entre els equips de desenvolupament i proves, ja que afecta altament la qualitat de la versió del programari.
5) Assegureu-vos que l'eina de seguiment d'errors estigui configurada correctament , per a l’equip de proves i l’equip de desenvolupament assignats del projecte, els números de compilació i publicació de programari, així com els mòduls / funcionalitats del programari, que ajudaran a registrar els errors de manera eficient. En cas contrari, hauríeu de dirigir-vos al cap de projecte o cap de proves amb una alta prioritat.
6) Torneu la compilació a l'equip de desenvolupament sense cap compromís, si la compilació falla a les proves de fum o de seny. Estrictament, les proves no s'han de continuar quan el sistema falla a la prova de fum. Això estalviarà molt de temps i esforç i millorarà la qualitat del programari publicat a les versions posteriors.
7) Programa la versió del projecte a l'1cDia de la setmana cosa que ajudarà el gestor de proves a planificar el proper cicle de proves en funció de l'estabilitat de la compilació i també a enviar un informe de prova ràpid al gestor de projectes que escalarà la qualitat del programari amb molta antelació. Si l’equip de desenvolupament programa la versió del divendres, el cap de setmana es pot utilitzar per a qualsevol deslliurament, així com per a qualsevol problema de construcció en un marc de construcció manual o automatitzat.
8) Assegureu-vos que els verificadors estiguin formats correctament al domini cosa que ajudarà l'equip de proves a complir el calendari de proves i a recollir el temps per a la propera ronda de proves. A més, l’equip de proves ha d’estar format i tenir l’exposició a la tecnologia necessària, com ara Scripting i SQL, si el projecte requereix caixa blanca.
9) Eviteu l'assignació de verificadors en diversos projectes ja que afecta molt la qualitat de l'execució de la prova en temps real. A la pràctica, fins i tot els verificadors experimentats passen per alt les funcions i la funcionalitat, a més de saltar-se els casos de prova suposant que alguns casos de prova mai fallen, quan es sobrecarreguen de feina o s’assignen en diversos projectes amb terminis.
10) Agraïu que l'equip de proves tingui passió ja que els verificadors no han de treballar durant el 'Dia' ni comentar 'Truca'l un dia'. Quan el programari té diversos mòduls i el funcionalista està completament o parcialment integrat o interrelacionat, els provadors haurien de tenir la passió d’escriure / executar els casos de prova amb una gran matriu de cobertura i traçabilitat, orientant-se a la qualitat del programari / producte final. Perquè fins i tot un problema de cosmètica és un 'error' i es considera '1 error'.
11) Assegureu-vos que la instal·lació del programari sigui fàcil i senzilla ja que ajuda l'equip de proves a tornar a instal·lar el programari quan sigui necessari en lloc d'esperar que el gestor de desenvolupament o un gestor d'instal·lacions facin la mateixa feina, cosa que matarà innecessàriament el temps de prova disponible. Per exemple, tot i que la instal·lació basada en Windows és fàcil, però quan es tracta de diversos servidors web i xarxes d'àrea àmplia en un entorn de proves de diversos nivells, els verificadors poden trigar hores a instal·lar el programari. Si el cobertes i instal·lació de proves de programari, desinstal·lació , pedaços o actualitzacions de programari, és més probable que es discuteixi detalladament el procés d’execució dels casos de prova amb l’equip de proves.
12) Assegureu-vos que les eines automatitzades estiguin disponibles amb llicència per a un marc de proves d'automatització . L'execució de casos de prova en un marc automatitzat és fàcil en comparació amb un escenari de proves manuals, sempre que les eines automatitzades estiguin configurades i llicenciades adequadament per a diversos usuaris. Especialment, quan el pla de proves implica proves de rendiment i càrrega, a part de l'execució regular de proves de prova i de regressió, els verificadors haurien de cobrir l'execució de casos de prova en diversos entorns, com ara diversos servidors, diversos navegadors, diversos usuaris, etc.
13) Assegureu-vos que les màquines Ghosted estiguin configurades per provar-les abans de començar l'execució de la prova. Les màquines fantasmes són màquines amb un entorn de proves diferent. Per exemple, es pot planificar un programari d'aplicació web per provar-lo en diversos entorns com Windows 7 i Access DB o Windows 2008 i SQL Server o Windows 8 i Oracle o Mainframe i DB2, etc., amb tots els navegadors com Chrome, Firefox, Internet Explorer , Safari, etc., Algunes 'proves de sistema' fins i tot requereix formatar completament el disc dur i instal·lar un programari nou o actualitzar el programari existent amb pedaços i actualitzacions, etc.
14) Eviteu implementar les funcions noves / sol·licitud de canvi en aturar l'execució de la prova i tornar a llançar el programari per indicar de nou la fase de prova. Aquesta és una pràctica molt dolenta en moltes organitzacions de programari segons els requisits empresarials per satisfer els clients externs o, almenys, per satisfer les demandes del comitè de direcció de gestió o, de vegades, dels equips de vendes / màrqueting. Tot i que les peticions de canvi dels clients sempre es fomenten en un entorn de projecte “Àgil”, s’hauria de planificar i implementar correctament abans de llançar el programari a l’equip de proves.
Gestió i control del contingut de la versió de prova
La gestió i control del contingut de la versió de prova és molt important per a qualsevol programari de TI o fins i tot per a qualsevol entorn de programari que no sigui de TI que es mostrarà a la figura següent.
- Els gestors del projecte i / o el comitè directiu del projecte depenen de la matriu d’autoritat de l’organització, són els responsables de seleccionar el contingut de cada versió.
- Un cop identificats i aprovats els errors i / o les noves funcions i la sol·licitud de canvi dels clients, serà implementat per l’equip de desenvolupament que hauria de ser comunicat als grups d'interès del projecte abans de començar el desenvolupament / implementació.
- En funció de la versió final implementada, l'equip de proves actualitzarà els documents relacionats i es prepararà per a la prova en conseqüència.
- L’equip de proves iniciarà les proves de fum / seny segons els requisits definits a l’informe de publicació.
- Un cop superat Sanity, l'equip de proves iniciarà l'execució de la prova segons el calendari i les tasques assignades, a saber, proves funcionals, proves no funcionals, proves de seguretat, proves del sistema, proves de rendiment, proves de càrrega, proves d'acceptació d'usuaris, etc.
- Un cop finalitzada la primera ronda del cicle de proves, s'enviaran informes de proves a tots els grups d'interès i al gerent de l'equip de desenvolupament per planificar la propera iteració de l'execució de la prova.
- Depèn de l'estat dels informes de prova i de la gravetat i complexitat dels errors, es planificarà un cicle complet d'una segona ronda d'execució de proves o proves de regressió juntament amb les proves d'acceptació de l'usuari.
- Després de completar els cicles d’execució de prova previstos, els informes de proves s’enviaran a tots els grups d’interès del projecte per passar / fallar / perdre les funcions, la funcionalitat i les correccions d’errors.
Plantilla d'informe de llançament de mostra:
Nota : La plantilla de mostra de MS Word per a l'informe de llançament també està disponible per baixar-la a continuació.
Trobeu a continuació un ' Exemple d'informe de llançament 'Que cobreix els principals aspectes del procés de llançament, cosa que fa que la vida professional de tot l'equip del projecte sigui molt més feliç que mai.
GPSNavigation_Release_Report_Ver_1.0.7_Release_14.0_Build_105.25.03
# 1) Abast
S’està publicant la navegació GPS per XYZ Company Limited per a proves internes. La versió publicada és 1.0.7, el número de versió és 14.0 i el número de compilació 105.25.03. Aquesta versió del programari inclou les noves funcions i les principals correccions d'errors de la versió anterior. Les proves de fum es passen des de la fase de desenvolupament, però es necessita un fum i un seny abans de passar a les proves de regressió.
# 2) Referències
GPSNavigation_URD_1.0.12, GPSNavigation_FFD_2.17, GPSNavigation_BusinessUseCases_1.23.10, GPSNavigation_TestPlan_1.44, GPSNavigation_TestSuites_2.10, GPSNavigation_UnitTesting_23.3
# 3) Descripció de la versió
Aquesta versió és una versió controlada de navegació GPS i conté les funcions i funcions següents.
Les funcions marcades amb * són noves en aquesta versió.
Les funcions següents no s'han implementat en aquesta versió.
1. Mòdul 1
1.1 Característica 1
1.1.1 Funcionalitat 1
# 4) Gestió de la configuració
Estem utilitzant Visual Source Safe com a eina de gestió de configuracions. La compilació està disponible al camí següent.
Enllaç intern: http://234.23.45.111/internalbuild/gpsnavigation/release1.0.13
Enllaç extern: https: // 234.23.45.111/externalbuild/gpsnavigation/release1.0.13
# 5) Instruccions i passos d'instal·lació
Doneu la informació detallada per a la instal·lació de la compilació a l’equip de proves de control de qualitat.
# 6) Problemes / errors corregits
L'estat dels errors s'actualitza al sistema de seguiment de defectes.
# 7) Problemes / errors per solucionar
# 8) Lliurables
# 9) Errors / problemes coneguts
# 10) Llista de comprovació de llançaments
| Sl.No/ | Descripció | I / N |
|---|---|---|
| 1 | S'han comprovat tots els fitxers a Visual Source Safe? | |
| 2 | S'ha posat l'etiqueta a la carpeta adequada de VSS segons els estàndards interns? | |
| 3 | La versió es pot identificar com a versió 'externa' / 'interna' a VSS? | |
| 4 | Als comentaris, s’ha mencionat la versió a VSS? | |
| 5 | Als comentaris, s’ha mencionat una breu descripció a VSS? | |
| 6 | El codi s'ha revisat i els problemes de revisió del codi s'han registrat a Clear Quest? | |
| 8 | S'ha preparat i revisat el document de prova unitària? | |
| 9 | S’han executat casos de proves unitàries i s’han actualitzat els resultats de l’estat? | |
| 10 | Hi ha disponible un document de casos de prova unitària actualitzat a VSS? | |
| 11 | S'han resolt / tancat tots els problemes de Clear Quest d'aquest llançament? | |
| 12 | Totes les tasques del paquet de treball completades i actualitzades a VSS? | |
| 13 | Es fan i s’han aprovat les proves de fum? |
=> descarregar: Feu clic aquí per descarregar una plantilla d'informe de llançament de mostra en format MS Word.
Conclusió:
Com millorar el procés de llançament de la prova contínuament
Consell 1) Configureu un equip d’enginyeria de versions que s’encarregui dels factors crítics del manteniment de les versions i versions de programari i responsable dels sistemes de gestió de configuració de programari centralitzats.
Consell núm. 2) Motiveu i agraïu els equips del projecte per seguir el procés implicat en el cicle de vida de desenvolupament de programari, cicle de vida de desenvolupament de productes i cicle de vida de proves de programari. Podem definir el procés, però fins que, a no ser que el segueixin les persones implicades, no serveix definir el procés.
Consell núm. 3) Calculeu l’esforç de les proves basant-vos en les experiències i la història anterior. Escriure casos de proves és totalment diferent d’executar-los. Els comprovadors haurien d’entendre què provar, com provar i quan provar; en cas contrari, els esforços realitzats al cicle de prova es perden, tot i que es van produir diverses rondes de cicle de prova.
Consell núm. 4) Finalment, si és possible i factible, automatitzeu la fase de proves mitjançant algunes eines de prova universalment acceptades. L’ús d’eines de construcció automatitzades i eines de proves automatitzades redueix els esforços de proves en més d’un 50% millorant la qualitat del programari i assegura un 100% de qualitat si el marc d’automatització està dissenyat correctament.
Consell núm. 5) Per últim, però no menys important, el llançament de proves no és només un treball, sinó que és un art de fer la vida de tots els grups d’interès fàcils i més còmodes.
Sobre l'autor: Balu A. és un experimentat professional de TI tecno-funcional amb més de dues dècades d’experiència en programari de TI i una dècada d’experiència en gestió de projectes i proves que ofereix aplicacions empresarials i solucions de mobilitat en diversos dominis mitjançant tecnologies Microsoft, Oracle, Java i mòbils. Bàsicament és un líder amb passió per promoure que les persones es converteixin en líders amb l’actitud adequada i li encanta treballar en un entorn orientat al procés i creu que el procés millora l’eficiència, la qualitat i la productivitat dels empleats.
Ensegüent tutorial, aprendrem - Com fer-ho Millorar l’eficiència dels casos de proves.
Feu-nos saber els vostres pensaments / consultes als comentaris següents.
Tingueu la versió del programari segons el procés.
Prova completa en horari amb una gran productivitat i esforços.
Intenteu aconseguir un lliurament de programari garantit de qualitat sense errors.
Si t’agrada aquest article, pensa en compartir-lo amb els teus amics.
Lectura recomanada
- Curs de proves de programari: a quin institut de proves de programari m'he d'afegir?
- 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
- Què és la prova de mico en la prova de programari?
- Selecció de proves de programari com a carrera professional
- Prova de programari Treball freelance d'escriptor de contingut tècnic
- Exemple d’informe d’errors
- Prova pràctica de programari Flux de procés de control de qualitat (requisits per alliberar)