Menú

Què cal fer quan no hi ha prou temps per provar?

what do when there isn t enough time test

Proveu El Nostre Instrument Per Eliminar Problemes

A mitja part del cicle de proves, us adoneu sovint que no teniu prou temps per fer la prova? Per començar, ho teníeu tot controlat, però aviat arribareu al pla de contingència 'Què fer quan no hi ha prou temps per fer la prova?' secció.

Jo també hi he estat i no és divertit. :)

Vaig pensar en això llarg i dur. Com pot una cosa que va començar tan bé, baixar tan malament, tan ràpidament? I aquí teniu la meva anàlisi.

=> Feu clic aquí per obtenir una sèrie completa de programes de proves

Què aprendreu:

On va anar el meu temps de proves?

No hi ha prou temps per provar

casos de prova de mostra per a aplicacions bancàries

En primer lloc, per què passa això?Moltes raons, algunes de les quals són:

# 1) Estimació incorrecta :

Si heu començat amb una expectativa inexacta, les coses probablement fracassaran. Una bona estimació de la prova ha de tenir en compte el següent:

  • Temps per a les tasques preparatòries - Estem parlant de tasques com:
    • Identificar i configurar una suite de regressió
    • Creació de dades de prova
    • Temps per determinar la preparació de la prova (per exemple: Prova de fum / seny), etc.
  • Manteniment de casos : Els casos de prova són recursos d’ús a llarg termini. Segur que se sotmetran a actualitzacions menors durant l’execució. Es recomana assignar fins a un nou producte fins a un 30% del temps d'execució de la prova per a aquestes tasques de manteniment menors. És possible que tots els equips i projectes no necessitin el 30%, però sí que dediquen una mica de temps i esforç a aquesta tasca.
  • A això / Proves exploratòries - El recompte de proves amb guió és un denominador important per als números d’estimació de proves. Tanmateix, cap equip de prova d’aquest món no negarà explorar el vostre programari encara que el model estigui escrit de manera dominant.
  • Informes / Comunicació - Inclou reunions de triatge / stand up, actualització d’eines de gestió de treballs, etc.
  • Factor de contingència: Les normes recomanen un 25-30% de memòria intermèdia a les vostres estimacions originals. Però els equips poques vegades s’ho poden permetre. Fins i tot llavors, deixeu una petita sala de respiració, quan sigui possible.
  • Equip i les seves capacitats: Si teniu un equip nou o si utilitzeu una eina per primera vegada, és possible que hàgiu de reservar un temps per a la formació. Adapteu les vostres estimacions en funció del vostre equip amb el qual esteu treballant.

Lectura recomanada=> Consulteu això per obtenir més informació sobre els mètodes i l'èxit de l'estimació de proves

# 2) Construccions inestables i altres problemes tècnics:

  • Error de prova de fum / seny : Quan les proves bàsiques de l’automàtica fallen després del desplegament a l’entorn de control de qualitat, l’equip de control de qualitat no pot fer res per a l’execució de les proves. És cert que podem treballar en altres tasques mentre això succeeixi, però tot i així no ho completarà cicle de prova temps. Per tant, aquest és un dels principals contribuents a perdre el temps.
  • Dades de prova no disponible : Les dades semblants a la producció són imprescindibles per a cada projecte de prova. No aconseguir això a l’entorn de control de qualitat a temps també és un altre factor de bloqueig. De vegades, els provadors poden solucionar-ho creant i gestionant les seves pròpies dades de prova , però consumeix molt de temps i pot ser que no sempre sigui puntual.
  • Problemes ambientals - Les desplegaments que no funcionen a la compilació, el servidor segueix esgotant el temps d’espera; molts altres problemes d’aquest tipus us mengen el cicle de prova. Això probablement es deriva del fet que, algunes empreses (no totes) soscaven la importància d’un bon entorn viu per obtenir un control de qualitat eficaç. Sovint intenten allunyar-se de servidors de baixa capacitat i configuracions de maquillatge. Això és realment una solució de poc temps i no fa cap favor a ningú. De fet, els podria costar la qualitat de les proves i la pèrdua d’un valuós temps de prova.

# 3) Falta d'acord entre totes les parts implicades:

Pot ser un problema poc freqüent amb els equips que segueixen Agile o Caixa forta a causa dels cercles propers en què treballen, però molts equips segueixen sent desacords o mal comunicats quant a quan Dev, Ops i QA se suposa que han de rebre lliuraments els uns dels altres. Per tant, els retards.

Per comprendre les subtileses de la comunicació, comproveu-ho => Com poden treballar junts negocis, desenvolupament i control de qualitat per aconseguir que el projecte es completi

Ara que coneixem els problemes, aquí teniu algunes maneres de solucionar-ho.

Com es pot obtenir el temps suficient per provar-los?

# 1) Feu una estimació precisa. En cas de dubte, se sobreestimi per un marge raonable, però no se subestima. No oblideu fer ajustos estimatius en funció del vostre equip, eines i processos. Quan hàgiu acabat, busqueu la sessió oficial perquè tothom en tingui coneixement i estigui al corrent.

# 2) Tingueu en compte les dades històriques: L’eina de gestió de proves és el vostre millor amic .

  • Quant van trigar els cicles de proves de llançament anteriors?
  • Quin tipus de problemes van causar interrupcions del cicle de proves anterior?
  • Quantes proves van passar la majoria dels casos de prova abans de passar?
  • Quins defectes es van notificar?
  • Quins defectes van provocar la interrupció de les proves?

# 3) Feu aquestes preguntes i planifiqueu-les en conseqüència en temps de crisi:

  • Esbrineu la funcionalitat important del vostre projecte?
  • Coneixeu el mòdul d’alt risc del projecte?
  • Quina funcionalitat és més visible per a l'usuari?
  • Quina funcionalitat té el major impacte en la seguretat?
  • Quina funcionalitat té el major impacte financer en els usuaris?
  • Quins aspectes de l'aplicació són més importants per al client?
  • Quines parts del codi són més complexes i, per tant, més subjectes a errors?
  • Quines parts de l'aplicació es van desenvolupar en mode precipitat o pànic?
  • Quins pensen els desenvolupadors que són els aspectes de major risc de l'aplicació?
  • Quins tipus de problemes causarien la pitjor publicitat?
  • Quins tipus de problemes causen més queixes al servei d'atenció al client?
  • Quins tipus de proves poden cobrir fàcilment múltiples funcionalitats?

Tenint en compte aquests punts, podeu reduir considerablement el risc de llançament de projectes amb menys restricció de temps.

# 4) Utilitzeu una eina de gestió de proves. Això reduirà significativament la quantitat de temps i esforç de preparació, informes i manteniment.

=> Per obtenir la llista de les eines de gestió de proves més populars , fes una ullada aquí :

# 5) No hi ha molt que puguem fer sobre compilacions / problemes tècnics incorrectes, però l’únic que pot ajudar és mirar els resultats de les proves de la unitat. Això ens donarà una idea de si la construcció va ser un èxit o no i de quin tipus de proves va fallar, de manera que no reinventem la roda.

Si el teu Suport de l'eina de gestió de proves Integració CI , teniu aquesta informació disponible sense cap mena de dubte per entendre millor l'estabilitat de l'aplicació.

# 6) Mesureu la vostra productivitat i progrés sovint . No deixeu que els informes d'estat siguin lliurables només per al benefici dels equips externs. Assegureu-vos que superviseu de prop els vostres objectius diaris i la vostra capacitat per assolir-los.

A més, assegureu-vos de no entrar en el clàssic enigma de 'Velocity vs. Quality'. Perquè, en informar, per exemple, de 50 errors al dia, pot semblar que estigueu sent superproductiu. Però si la majoria d'ells tornen a ser invàlids, us poseu un problema.

Així doncs, superviseu, superviseu i superviseu una mica més :)

Conclusió:

Finalment, malgrat totes les precaucions i mesures si encara us trobeu restringit per temps, demana ajuda .

La majoria d’equips estan disposats a participar en una sessió de sala de guerra per recuperar les coses.

Preguntes i respostes d’entrevistes d’oracle dba

Sobre l'autor: Aquests consells útils de proves els proporciona Swati S., membre de l'equip de STH.

Ara, quins són els vostres trucs per mantenir-vos a temps i oferir un servei de proves de qualitat? A més, quins punts de l’article anterior us ressonen?

Agraïm els vostres comentaris i valorem els vostres lectors. Gràcies per llegir!

=> Visiteu aquí per obtenir la sèrie completa de programes de proves

Lectura recomanada

^