Menú

Com decidiu quins defectes són acceptables perquè el programari es publiqui?

how do you decide which defects are acceptable

Proveu El Nostre Instrument Per Eliminar Problemes

Software Go-Live sempre és un gran esdeveniment per a qualsevol producte de programari. És important assegurar-se absolutament que tot funciona i que ho som alliberant programari de qualitat als usuaris .

Un producte dolent, prematur o inestable o difícil d’utilitzar pot causar moltes pèrdues econòmiques i també pot fer perdre la confiança a l’usuari en la pròpia marca.

Sovint sentim que s’haurien de fer proves fins que no complim els criteris de sortida. També sentim que els defectes s'han de corregir a un nivell acceptable.

Tot i que aquestes són bones pautes de sonar, són vagues.

Criteris de programari

Per ser més específics:

  • Quin percentatge de defectes són acceptables perquè el programari es publiqui?
  • Com decidiu els defectes oberts amb què el programari pot publicar-se?
  • Què tipus de defectes són més greus que els altres?

Lectura recomanada => Quan deixar de provar?

Tens alguna vegada aquestes preguntes? A continuació, aquest article us ajudarà a respondre-hi. Segueix llegint…

El programari complex no és lliure de defectes i és una història sobre polls i ous sobre els defectes de tancament respecte al programari de treball.

Com més solucioneu els defectes, hi ha més probabilitats que s'hagi injectat un defecte nou mentre el tanqueu. Tan,

  • Com decidiu l'abast dels defectes i el tipus de defectes amb els quals podeu viure?
  • Com es basa el programari per implementar-lo?
  • Com fan els coordinadors de la UAT la crida per entrar en directe o no?
  • De quins paràmetres s’hauria de jutjar el programari?
  • Com responem: el programari és apte per al seu ús i aportarà valor als grups d'interès?

Entrar en directe a la producció és una fita important per al client i per al venedor, ja que sol estar lligada a fites de pagament. Tots dos tenen la mateixa responsabilitat a l’hora d’assegurar l’èxit dels grans projectes de transformació.

La meva experiència demostra que els clients volen la seva relació qualitat-preu i en tenen criteri de sortida perquè la UAT hi visqui.

Aquests criteris de sortida definirien més o menys l'abast acceptable dels problemes en totes les àrees de l'aplicació, com ara:

  1. Funcional
  2. Rendiment i càrrega
  3. Usabilitat
  4. Seguretat
  5. Integració amb sistemes externs
  6. Informes
  7. Migració de dades

Crec que cal explicar cada un d’aquests tipus de defectes. I això és exactament el que farem ara:

sql fa preguntes i respostes d’entrevistes durant 3 anys d’experiència

# 1. Defectes funcionals:

Si el programari es crea segons les especificacions donades pel client, ha de complir els requisits. Les desviacions es registren com a defectes funcionals.

Defectes funcionals es classifiquen segons severitat i prioritat .

Les següents són consideracions importants:

  • Els defectes de gran gravetat i prioritat solen ser els que afecten l’ús quotidià del programari. Aquest tipus de defectes són els que s’han de solucionar abans de començar a viure. Sense excepcions.
  • De vegades, els defectes funcionals es classifiquen com a sol·licituds de canvi, ja que no formaven part dels requisits indicats originalment. Aquests CR, imprescindibles perquè el negoci funcioni després de la publicació, també són imprescindibles per implementar.
  • La classificació dels defectes i la priorització dels defectes funcionals els fan els coordinadors de la UAT en col·laboració amb usuaris empresarials i analistes empresarials. Normalment, el client té un criteri de sortida del percentatge de defectes obert per a la publicació.

# 2. Defectes de rendiment i càrrega:

Defectes de rendiment són importants a tenir en compte per a la publicació, més encara si el programari ha de ser utilitzat per usuaris externs.

Si el programari és lent per a un nombre determinat d’usuaris, els usuaris evitarien utilitzar-lo, ja que triga molt de temps a carregar-se. Els usuaris tendeixen a desplaçar-se al lloc de la competència si el programari és molt lent i per tant perd la seva empresa.

De vegades, les parts de l’aplicació que no s’enfronten al client també poden afectar el rendiment.

Per exemple: Si hi ha un procés per lots que s’executa al final de cada dia i si el temps de resposta de l’aplicació pateix mentre això continua, el rendiment del lot també és un factor a tenir en compte.

  • El rendiment es mesura generalment en termes de temps de resposta de les pantalles per renderitzar-les i estar disponibles per als usuaris mentre hi ha un cert nombre d’usuaris concurrents al sistema.
  • Les proves de rendiment es fan mitjançant eines com LoadRunner , Càrrega web , Neoload, etc.
  • El rendiment del programari a una determinada càrrega i a una futura càrrega prevista normalment es documenta al contracte i s’ha de demostrar abans de la publicació.
  • Les pantalles o parts de l’aplicació que els usuaris menys utilitzen es posposen a les avaluacions després de la publicació.
  • El rendiment també depèn del tipus de maquinari i de les condicions de xarxa en què es desplegui el programari.
  • Les proves de rendiment es fan durant la UAT en el maquinari especificat mitjançant eines de rendiment i es fan un seguiment dels seus defectes de manera similar a la dels defectes funcionals. També es prioritzen i s’arriba a un consens sobre el compliment dels criteris de sortida per a la publicació.
  • Normalment, les proves de rendiment i càrrega a UAT es realitzen després que els usuaris empresarials completin la UAT funcional i s’assoleixi un criteri de sortida acceptable per a defectes funcionals.

# 3. Defectes d'usabilitat:

El programari creat haurien de ser fàcilment utilitzables pels usuaris finals mitjançant diferents tecles d'accés directe, dreceres, el nombre mínim de navegació per pantalla, paginació, etc. El programari ha de ser intel·ligent i intuïtiu.

Si hi ha massa moviments de la pàgina abans de passar a la pantalla adequada, els usuaris solen mostrar menys interès a utilitzar el programari.

  • Les pautes d’usabilitat es creen abans de construir el programari. El programari ha de complir aquestes directrius.
  • També pot haver-hi restriccions d’eines durant la creació del programari que s’ha de superar amb intel·ligència abans que els usuaris finals puguin utilitzar el programari.
  • Amb un programari molt útil, un usuari final pot introduir dades fins a cinc vegades el programari normal.
  • L’aspecte del programari ha de ser nítid i també s’han de resoldre els problemes legals abans d’entrar en funcionament.
  • Moltes vegades es designa un consultor d’usabilitat per garantir una experiència d’usabilitat fluida als usuaris.
  • La documentació que ha de sortir amb l’aplicació de programari també ha de complir unes pautes d’usabilitat estrictes, ja que es poden utilitzar legalment.
  • Els defectes d’usabilitat registrats pels verificadors UAT / verificadors externs també es prioritzen com a defectes funcionals i de rendiment i han de complir els criteris de sortida per a la publicació.

# 4. Defectes de seguretat:

Seguretat del programari és un problema candent, ja que es pot piratejar l’aplicació de programari i robar les dades sensibles al client en un termini breu.

Per tant, un programari fiable no hauria de permetre que ni un pirata informàtic molt competent pugui accedir a l’aplicació sense privilegis adequats.

  • Les proves de seguretat es fan a UAT amb entrades específiques al programari per assegurar-se que no sigui piratejable.
  • Les proves de seguretat les fan hackers legals que intenten piratejar el programari per comprovar si és vulnerable.
  • Cal tancar tots els defectes de seguretat abans que el sistema es posi en funcionament.
  • La seguretat també significa iniciar sessió i rols i privilegis per a diversos usuaris (externs i interns) per utilitzar diferents seccions de les aplicacions i també per crear i aprovar dades.

# 5. Integració amb sistemes de programari externs:

Normalment, una aplicació de programari que s’ha de desplegar al lloc del client ha de relacionar-se amb qualsevol programari existent que ja hi pugui haver.

Per exemple: Amb el sistema d'impressió, tenen en ús o poden tractar-se de sistemes externs, com ara una aplicació de facturació o sistemes de pantalla de dades. L'aplicació de programari que s'està implementant s'hauria d'integrar perfectament amb aquests sistemes externs. Totes les entrades i sortides d’aquests sistemes haurien de funcionar de manera sincronitzada. Actualment, la tecnologia inclou aplicacions mòbils i diferents plataformes de programari que ha de ser l'aplicació compatible amb .

La comprovació de la interfície del sistema extern s'hauria de dur a terme durant les etapes del sistema i de la UAT. Hauria de ser imprescindible en els criteris de sortida que s’haurien de complir abans d’entrar en directe.

# 6. Informes:

Els informes de l’aplicació de programari són una forma crítica de demostrar que les dades de l’aplicació no coincideixen.

Per exemple: totes les dades relacionades amb la facturació han de comptar en els saldos de crèdit i de dèbit.

  • Totes les dades del programari s’han de conciliar. Aquesta conciliació de dades dins del programari es mostra a través d’informes i han de funcionar tal i com s’ha previst.
  • Això és especialment cert si la migració de dades d'un sistema antic a un sistema nou és la intenció principal de la versió actual.

# 7. Migració de dades:

Si se substitueix un sistema antic per un de nou, les dades del sistema antic es traslladen al nou (després d'arribar a una data límit mitjançant el sistema nou). Les dades migrades haurien de ser compatibles pel nou sistema tal com es defineix durant la recollida de requisits.

És possible que totes les dades antigues no estiguin disponibles al nou sistema; tanmateix, una nova imatge de les dades antigues podria estar disponible al nou sistema. Aquestes dades haurien d’estar disponibles tal com s’ha acordat.

Nota : La llista anterior no és exhaustiva. Depenent del tipus d'aplicació, és possible que hagueu de validar més coses o que no sigui aplicable tot el que apareix més amunt. Per tant, és imprescindible una comprensió exhaustiva del programari, el propòsit comercial, les expectatives dels usuaris i les dependències arquitectòniques o de maquinari per desenvolupar criteris de sortida complets.

Un exemple de criteris de sortida per a la publicació:

Aquest és només un exemple. Pot variar d'un projecte a un altre.

  • El 100% dels defectes de la prioritat 1 estan tancats (severitat crítica i prioritat 1)
  • El 90% dels defectes de prioritat 2 es tanquen (severitat alta i prioritat 2) i hi ha disponible una solució lògica per a la resta del 10% dels defectes. I hi ha disponible un pla per tancar la resta del 10% dels defectes.
  • El llançament de la producció i la llista de comprovació del seny estan a punt.
  • L’equip de suport a la producció s’ha format i està a punt per tancar els tiquets.
  • El 70% dels defectes de prioritat 3 es tanquen i hi ha un pla per tancar la resta del 30% dels defectes baixos.

Alguns punts a tenir en compte:

  • Totes les definicions de gravetat i prioritat es decideixen durant les reunions de negocis entre el client i el proveïdor al començament del programa.
  • Després de registrar tots els defectes de la UAT i tancar la resta de defectes, els coordinadors de la UAT i els patrocinadors empresarials es reuneixen per fer un balanç dels defectes pendents i oberts. Si es tanquen tots els defectes necessaris per a la publicació del primer dia, els patrocinadors empresarials veuen la seva disposició a la publicació i fan que el programari es produeixi.

En conclusió

Esperem que aquest article us doni algunes idees sobre algunes de les consideracions importants que suposa la creació de criteris de sortida sòlids que protegeixen el programari de possibles fallades en les produccions.

Sobre l'autor: Aquest és un article de Krishnan Venkatraman. Té gairebé 18 anys d’experiència en proves de programari. Ha treballat en molts projectes de proves de programari grans i complexos.

No dubteu a publicar les vostres consultes / comentaris a continuació.

Lectura recomanada

^