Com realitzar proves de post-llançament eficaçment i minimitzar l’impacte de la versió per als clients en directe

how perform post release testing effectively

Quan vaig començar la meva carrera com a QA, treballava amb una empresa que oferia els seus productes com a SaaS. Les versions de producció eren fonamentals i hi havia la possibilitat d’afectar la funcionalitat dels clients en directe.

A mesura que la nostra base de clients va créixer, per gestionar el risc i minimitzar l'impacte de la publicació en clients vius, va adoptar l'equip de control de qualitat la pràctica de proves post-llançament.

Tot era nou per a mi i tenia moltes preguntes i dubtes al cap:

• Què són les proves posteriors al llançament?
• Ho he provat tot correctament, per què hem de fer proves posteriors al llançament?
• Torne a provar-ho tot de nou? Què faig exactament en la verificació posterior al llançament?
• Què passa si trobo un problema? Etc.

Em complau admetre que he trobat totes les meves respostes a les meves primeres versions de producció.

Aquí estic compartint aquest coneixement amb tots vosaltres. Vaig escriure l'article en format de preguntes i respostes per mostrar-vos la manera com he descobert les respostes.

Què aprendreu:

• Què és la verificació de llançament després de la producció?
• Quines tasques i activitats s’inclouen a la fase de verificació posterior al llançament?
• He de tornar a provar-ho tot de nou?
• Com puc formular l'estratègia de verificació de la versió posterior a la producció?
• Qui crea el pla de proves de llançament després de la producció?
• Qui aprova el pla de proves de llançament després de la producció?
• Quan puc crear el pla de verificació de la versió posterior a la producció?
• He completat la verificació de la versió posterior a la producció. Que segueix?
• Què passa si trobo un problema?
• Què més he de saber sobre el procés de verificació de la versió posterior a la producció?
• Conclusió:
• Lectura recomanada

Què és la verificació de llançament després de la producció?

Per definició, Publicació significa Després , Llançament de la producció fa referència al desplegament a entorns LIVE / producció i Verificació inclou assegureu-vos que les funcions publicades compleixen els requisits .

Lectura recomanada=> Com es prepara de manera efectiva l ''entorn de prova' abans de començar a provar

L'objectiu és verificar el llançament en entorns de producció / EN DIRECTE.

subcadena (0,0) java

Però sorgeixen les preguntes:

• Per què hem de fer proves de llançament després de la producció quan he provat tot sobre un entorn de control de qualitat?
• Per què preveiem que es produeixin problemes a la producció, tot i que hem provat la versió a fons en l'entorn de prova?

Hi ha moltes raons per les quals tindríem problemes de producció tot i que podríem haver seguit completament Procés d’assegurament de la qualitat (és a dir, planificació de proves , revisió del pla de proves, cicle de proves, proves de regressió etc.)

Motius pels quals tindríem problemes de producció:

1) Emissió de dades - Les dades disponibles sobre entorns de producció i proves poden variar. Això pot provocar que es perdin alguns problemes de minúscules en entorns de prova.

2) Problema de desplegament - Si la vostra empresa té un procés de desplegament de compilació manual, és possible que la vostra versió sigui més propensa a problemes de desplegament. Alguns escenaris habituals poden ser: falta la configuració o la configuració del lloc, falten els scripts de base de dades, l'ordre de desplegament no seguit (primer el codi, després el DB, etc.), les dependències instal·lades incorrectament, etc.

Llegiu també=> Què ha de saber el verificador de control de qualitat sobre el procés de desplegament

3) Àrees d’impacte no identificades - Pot haver-hi alguns escenaris en què les àrees afectades poden no haver estat identificades correctament i completament per l’equip.

Per exemple, consideri a SaaS entorn.

Si l’equip no va identificar l’impacte d’una taula de bases de dades recompensades en un client mitjançant un esquema de taula anterior (per exemple, pèrdua de dades, migració de dades abans de la publicació, etc.), etc. Aquest problema és menys probable que es produeixi per a projectes ben planificats amb requisits precisos. Però, la possibilitat encara existeix.

4) Àrees d’impacte desconegudes - Això pot passar si no es coneix l'abast i les zones afectades de la versió. Per exemple, en una empresa amb diversos productes de programari que comparteixen una base de dades i arquitectura comuns, fins i tot un petit canvi pot trencar la funcionalitat de molts productes.

Quines tasques i activitats s’inclouen a la fase de verificació posterior al llançament?

Les tasques i activitats de llançament de la producció generalment inclouen:

• Verificació de la versió posterior a la producció
• Informeu dels resultats de la verificació
• Informar de qualsevol problema trobat a la producció
• Neteja les dades de verificació posterior al llançament
• Supervisió posterior al llançament (si escau)

He de tornar a provar-ho tot de nou?

No necessàriament. Això depèn de la versió que es publiqui i de l'anàlisi d'impacte.

S'han de fer proves detallades durant el cicle regular de control de qualitat. La verificació posterior al llançament s'hauria de fer seguint un pla de prova de verificació posterior a la producció que hauria de ser una derivada del pla de prova complet per a aquesta versió.

Com puc formular l'estratègia de verificació de la versió posterior a la producció?

La planificació de la verificació de la versió posterior a la producció s’ha de fer d’una manera similar a la planificació de proves regulars.

L’estratègia hauria d’estar en les mateixes línies que el flux de prova seguit durant el cicle de control de qualitat. És important incloure els passos més importants i crítics que permetin la màxima cobertura de funcionalitats.

com puc obrir fitxers torrent

Una bona estratègia de llançament postproducció hauria de:

• Incloeu passos per provar les funcions noves, així com les principals funcions existents
• Verifiqueu les zones d’impacte important
• Permet la màxima cobertura de funcionalitats
• Opcional: incloeu qualsevol error crític que s'hagi trobat a l'entorn de prova
• Opcional: incloeu la prioritat dels casos de prova

Qui crea el pla de proves de llançament després de la producció?

Això variarà segons les empreses i dependrà de l'estructura de l'organització.

Prenguem un exemple de la següent organització de l’equip de control de qualitat.

En aquest escenari, el control de qualitat que treballa en el projecte específic formularà el pla inicial de prova de llançament posterior a la producció.

Qui aprova el pla de proves de llançament després de la producció?

Això variarà segons les empreses i dependrà de l'estructura de l'organització.

Considerant de nou la mateixa estructura organitzativa que es mostra a la pregunta anterior, el pla de proves de llançament de postproducció hauria de ser revisat i aprovat per el responsable de prova o gestor de control de qualitat .

Quan puc crear el pla de verificació de la versió posterior a la producció?

El pla de proves de llançament de postproducció es pot crear en qualsevol moment durant el cicle de desenvolupament de programari després d'identificar i bloquejar els requisits, l'abast de desenvolupament i les àrees d'impacte. Normalment és més fàcil per al control de qualitat crear el pla de proves de llançament de postproducció a mig camí del sprint. Això garanteix que hi hagi prou temps per revisar-los i aprovar-los.

És una bona pràctica incloure aquest pla de proves juntament amb qualsevol altre documents de tancament formal de control de qualitat abans que el projecte entri a la fase de desplegament i publicació.

He completat la verificació de la versió posterior a la producció. Que segueix?

Un cop finalitzada la verificació posterior al llançament, els passos següents serien

1) Comunicació dels resultats de la verificació - Els resultats de la verificació s’han de comunicar als grups d’interès, inclosos els problemes que s’hagin trobat en la producció.

2) Informar de qualsevol problema trobat en la producció a l'eina de gestió de defectes - Per a facilitar l'anàlisi de la causa arrel i traçabilitat .

3) Neteja les dades de verificació posterior a la versió - La neteja de les dades s’ha de fer un cop finalitzada la verificació.

Per exemple, consideri a versió per a una aplicació de comerç electrònic i digueu que heu creat una comanda de prova per a la producció. Aquesta ordre de prova s’ha de cancel·lar un cop finalitzada la verificació.

4) Supervisió del llançament posterior a la producció (si escau) - Algunes versions requereixen un control de la producció.

Per exemple, si l'equip feia millores per millorar els temps de càrrega de la pàgina a l'aplicació, caldria supervisar-lo durant algun període de temps per garantir que la millora es veiés efectivament després de la publicació. S’ha d’identificar i comunicar clarament a les persones responsables del control.

Què passa si trobo un problema?

Qualsevol problema s'hauria d'informar a Eina de gestió de defectes i comunicat als grups d'interès. Si es produeixen problemes crítics en la producció, la comunicació dels resultats hauria de produir-se immediatament, ja que caldria prendre una decisió si cal recuperar la versió per investigar més el problema.

És important que tots els problemes trobats s’informin a l’Eina de seguiment de defectes. Es recomana que es plantegin com a tipus de problema separat (per exemple, error de postproducció) per mostrar la separació dels errors normals del cicle de control de qualitat. Aquests problemes es poden filtrar fàcilment si es requereixen per a l'anàlisi de la causa arrel.

Què més he de saber sobre el procés de verificació de la versió posterior a la producció?

A més del procés, pla i estratègia de verificació de la versió posterior a la producció, es detallen a continuació alguns indicadors:

• És important establir expectatives clares quant a l'abast i el propòsit de la verificació posterior al llançament. Cal que els grups d'interès (interns i externs) siguin conscients del següent
  • L’equip no ho pot provar tot en producció
  • L’equip no pot esprémer els dies que val la pena fer proves en poques hores reservades per a la verificació posterior al llançament

Per tant, les proves de producció es basarien bàsicament en un pla de proves de llançament aprovat després de la producció.

Limitacions:

identificació intel·ligent en qtp amb exemple

S’ha de tenir la precaució necessària mentre es decideix l'abast de les proves de llançament de postproducció. Hi ha limitacions en què i quant podem provar realment en producció. L’entorn de producció té dades de clients en directe i s’ha de tractar amb molta cura. Cal fer una planificació addicional per als canvis que impliquin migració, actualització, supressió de dades, etc.

Exemple 1): Per a una empresa eSurvey, si fer proves implica respondre i enviar l'enquesta, QA hauria d'enviar una sol·licitud de supressió de l'enquesta de prova després de la verificació per tal de no afectar les dades de recopilació d'enquestes dels clients i les seves estadístiques.

ÉS exemple 2): Per a una empresa de comerç electrònic, suposem que una actualització de preus del treball SQL s’executa a mitjanit tots els dies i penja el preu definitiu al lloc web. No podem executar aquest SQL a la carta diverses vegades amb el propòsit de verificar després del llançament, ja que això pot provocar la transmissió de dades sense finalitzar a la producció.

A més, pot augmentar les possibilitats de Punts morts de DB i un alt consum de recursos de memòria i CPU durant les hores laborals màximes que poden afectar el rendiment de l'aplicació client.

• L'esforç necessari per a les proves posteriors al llançament i totes les activitats relacionades hauria de ser incorporat i inclòs al pla del projecte. Depenent de les regles de negoci i de les especificitats del projecte, es pot considerar com a despesa general del projecte o inclosa al cicle de control de qualitat o inclosa com a part del pla de gestió de versions.
• Per als problemes que s’informen durant la verificació posterior al llançament, s’haurien de fer anàlisis de causes arrelades per esbrinar el motiu pel qual no es va detectar el problema al principi i què es pot fer millor la propera vegada per evitar afrontar el problema. L’anàlisi de les causes arrel pot ajudar l’equip a aprendre d’aquests problemes passats i omplir qualsevol buit de la implementació. Basat en l’estructura de l’organització, el responsable de prova o el gestor de control de qualitat poden completar l’anàlisi de la causa arrel amb l’entrada de l’equip del projecte. Algunes de les causes arrels més habituals poden ser un problema de codificació, un requisit, un disseny, un problema de dades, limitacions de tercers, un escenari de prova que falta, etc. Es poden crear i fer un seguiment de les accions correctives i preventives corresponents.
• Registres de servidor també es pot utilitzar per supervisar la compilació després de la versió. Registre del servidor pot contenir esdeveniments o problemes que potser no siguin visibles per al client, però que causin problemes al dorsal. Aquest seguiment es pot assignar com a element d'acció a l'equip de Dev Devs i DevOps.

Un exemple:

Descripció general del projecte:

Cal fer els canvis següents a una aplicació de xarxes socials, específicament al procés d’inscripció

1. Cal eliminar la validació del camp de cognom. Anteriorment es va implementar com a 'El cognom hauria de tenir un mínim de 4 caràcters' (millora per al camp existent)
2. Implementar el botó d'activació al costat de l'adreça de correu electrònic perquè l'usuari pugui configurar la configuració de privadesa de l'adreça de correu electrònic que es mostrarà al seu perfil (sol·licitud de nova funció)
3. L'usuari hauria de poder triar el seu avatar (sol·licitud de nova funció)
4. Reduïu les trucades a l'API durant el procés de registre per millorar el rendiment de l'aplicació (millora)

Pla de verificació de la versió posterior a la producció:

Conclusió:

Amb la majoria de les empreses de programari ara adoptant la metodologia Agile , el nombre de llançaments de producció ha augmentat.

Per exemple, mentre s'utilitza Model de cascada , un equip pot tenir una versió de producció cada 1,5 mesos, però, amb el procés Agile, el mateix equip ara pot tenir una versió de producció cada 2-3 setmanes.

Amb cada llançament de producció, tenim la possibilitat d’impactar conscientment o sense adonar-nos de la funcionalitat dels clients en directe. L'adopció de la verificació de la publicació de postproducció immediatament després de la publicació pot proporcionar una confiança addicional en la publicació al mateix temps, proporcionant la xarxa de seguretat de recuperar la publicació abans que els nostres clients en directe es trobin amb alguns problemes.

Per a projectes d’alt impacte / risc , el pla de verificació de la versió de postproducció es pot estructurar en funció de la prioritat de l'escenari de prova. La prova de prioritat crítica es pot executar primer i es pot enviar comunicació als grups d'interès sobre els resultats i qualsevol problema. Si no es troben problemes crítics, es pot continuar amb la verificació de la versió posterior a la producció, en cas contrari, cal prendre la decisió de retrocés per minimitzar el temps d'inactivitat de l'aplicació i afectar els clients en viu.

A més, es poden automatitzar les proves de llançament de postproducció i els scripts de prova es poden executar sota demanda després de cada versió com a prova de regressió. Una vegada més, s’ha de tenir la precaució necessària mentre s’executen els scripts de prova automatitzats durant la producció, ja que poden afectar les dades i la funcionalitat del client en directe.

La verificació posterior a la producció és la última línia de defensa per a qualsevol empresa de programari. Si no detectem els problemes, els nostres clients ho faran i això pot ser devastador per a la reputació de qualsevol empresa de programari.

Per mantenir la fiabilitat del producte, és fonamental verificar els canvis implementats a la producció immediatament després del desplegament.

Sobre l'autor: Aquest útil article l’ha escrit Neha B. Actualment treballa com a gerent d’assegurament de la qualitat i s’especialitza en dirigir i gestionar equips de control de qualitat interns i externs.

Compartiu la vostra estratègia / consells / experiència de proves de llançament de postproducció amb els nostres lectors.

Lectura recomanada

• Les millors eines de prova de programari 2021 (Eines d'automatització de proves de control de qualitat)
• Prova de descàrrega de llibres electrònics
• Implementació pràctica en 7 passos de les proves manuals abans del llançament de la producció
• Prova de càrrega amb tutorials HP LoadRunner
• Prova pràctica de programari Flux de procés de control de qualitat (requisits per alliberar)
• Diferència entre la prova d'escriptori, el servidor de clients i la prova web
• Què és la prova de gamma? Fase de proves finals
• Què és la prova primerenca: prova primerenca, prova sovint PERUT com? (Una guia pràctica)