Menú

Què és la prova primerenca: prova primerenca, prova sovint PERUT com? (Una guia pràctica)

what is early testing

Proveu El Nostre Instrument Per Eliminar Problemes

Què és la prova primerenca?

Les proves de programari haurien de començar a principis del cicle de vida del desenvolupament de programari. Això ajuda a captar i eliminar defectes en les primeres etapes de la fase de disseny i recollida de requisits de SDLC. Un començament primerenc de les proves ajuda a reduir el nombre de defectes i, finalment, el cost de la reelaboració al final.

Els diversos aspectes de Proves primerenques aquí s'explica el que ajudaria els responsables i els responsables de control de qualitat a desenvolupar o idear el document d'Estratègia de proves en SDLC.

L’adopció d’una prova anticipada donarà com a resultat un lliurament satisfactori d’un producte de qualitat.

proves primerenques (1)

Al final d'aquest tutorial, els lectors, gestors de control de qualitat, clients potencials i verificadors tindran un coneixement raonable dels conceptes següents:

provant preguntes i respostes d’entrevistes amb experiència
  • Per què proves inicials en SDLC (projecte o versió de programari)?
  • Abast de l'esforç de proves primerenques
    • Què provar aviat?
    • Inici i sortida
  • Pros i contres

Explorem ara els matisos amb detall !!

Què aprendreu:

Principis de les proves

Figura 1 - Vista simplificada dels principis de les proves

1. Principis de les proves

Per a un llançament de programari o sistema o producte determinat en SDLC, hi ha diverses metodologies o estratègies ben definides per a la majoria dels principis de prova següents.

  • Què són les proves?
  • Per què fer proves?
  • Què provar?
  • Com provar?

Tanmateix, algunes de les preguntes més persistents que molts lectors, verificadors, clients potencials i gestors de control de qualitat es farien o voldrien obtenir més claredat sobre la inclusió (zona gris a figura 1 )

  • Quan comencen les proves en una versió de programari o Quan han de començar les proves en un projecte?
  • Quan començar a provar i quan deixar de provar?
  • Per què les proves haurien de començar aviat a SDLC?
  • Què és una prova inicial del desenvolupament de programari?

Per facilitar la comprensió de l’audiència, he inclòs totes les preguntes sobre la “zona gris” sota un paraigua anomenat Proves primerenques.

Per què fer proves primerenques en SDLC?

Parlem d'alguns esdeveniments i activitats que formen part de les proves.

Normalment, l’equip de gestió de programes assigna un gestor de programes (PM) a una versió de programari o a un projecte determinats. El primer ministre, en col·laboració amb tots els grups d'interès, inclosos els equips de màrqueting, desenvolupament, control de qualitat i assistència, ofereix un calendari de llançament

En aquest tutorial, he triat Calendari d’alliberament trimestral utilitzant el model Waterfall per explicar el Conceptes de proves primerenques en detall.

Programa de proves de llançament de programari

La majoria de les organitzacions segueixen el tradicional Alliberament basat en el temps Models (TBR) en què les versions del programari o del producte estan previstes per a la seva entrega trimestral, semestral o anual.

Principalment, el model Waterfall s'utilitza per executar aquestes versions de programari. En alguns casos, per a un cicle de llançament més curt, s’adopta el model Agile / Scrum.

Figura 2 - Calendari de proves de llançament trimestral típic (no es tracta del projecte ni de la programació general)

Calendari de proves trimestrals d’alliberament

Impacte de defectes crítics o d’alta gravetat

Figura 3 - Impacte típic dels defectes crítics

Impacte típic dels defectes crítics

Principalment , durant el curs de les proves, s'espera que

  • Els provadors identificen i registren defectes crítics o d’alta gravetat.
  • Els desenvolupadors hauran de solucionar aquests defectes.
  • Posteriorment, els verificadors hauran de verificar les correccions.

En segon lloc , és àmpliament reconegut per moltes organitzacions d’enginyeria de productes i programari que la correcció i verificació d’errors crítics o d’alta gravetat en un nombre molt gran és

  • Consumidor de temps
  • Recollida de recursos (humans + màquina)
  • Propensos a la garantia, la solució d’errors crítics afecta principalment una gran part del codi, incloses les zones d’intersecció.

Per últim , si es troba un gran nombre d'errors crítics al final d'una versió donada, es produirà un o més dels següents desenvolupaments negatius.

  • Alta probabilitat d’ampliació del cicle de proves.
  • Alta probabilitat que es perdi el termini de llançament.
  • És possible que una característica particular que tingui un gran nombre de defectes sigui necessàriament extreta d’aquesta versió concreta.
  • S'han perdut els compromisos dels clients.

Què tal els altres defectes?

Hi ha defectes de prioritat mitjana i baixa que els verificadors identificaran i registraran. Aquests també han de ser gestionats adequadament per l’equip de desenvolupament i control de qualitat. Per tant, en general és un exercici voluminós.

No hi ha bala de plata

És ben sabut que cap quantitat de proves pot desenterrar tots els defectes que té un producte de programari o el sistema. És a dir, pràcticament, ni hi ha finalització de les proves ni el producte està lliure de defectes.

Tanmateix, des del ‘ Facilitat de servei Segons el punt de vista d’un model Competitive and Time To Market (TTM), cal trencar la mentalitat típica per desenterrar els defectes màxims al principi d’un cicle de llançament, especialment la identificació de defectes crítics i d’alta gravetat.

Qualsevol o tots els anteriors tindran un impacte negatiu en el negoci de l’organització. En aquest context, adoptar « Proves primerenques 'Tenir un activitat de prova independent serà beneficiós per a la gestió global de SDLC per a un determinat projecte o llançament.

L'abast de l'esforç de proves primerenques

Després d’haver entès l’objectiu de provar a principis de la secció anterior titulada « Per què les proves primerenques? ', Parlem ara de' Abast de l'esforç de prova primerenca ' en detall.

Com que introduïm Testing Early com una nova activitat que es farà un seguiment exclusivament durant l'execució de la prova, es recomana practicar l'abast de l'esforç de prova, tal com s'explica a continuació.

Supòsit:

  • S’aprova tot el calendari de llançament del projecte o del programari i es posa a disposició de totes les parts interessades.
  • Tots els grups d'interès desenvolupen, revisen i aproven el document global de l'Estratègia de proves.
  • Les funcions de prioritat alta, mitjana i baixa que cal provar estan ben documentades.
  • Tots els grups d'interès desenvolupen, revisen i aproven els plans de prova i els casos de prova de totes les funcions.
  • Tots els plans i casos de prova es carreguen en un dipòsit central per fer un seguiment de l'execució de les proves.
  • Tots els recursos humans, equips d'infraestructura i eines estan disponibles per configurar els bancs de proves i executar els plans de prova.

Què provar aviat?

Figura 4 - Enfocament general de l’abast de les proves primerenques

4. Què provar en proves inicials?

Aproximació

  • Prenem un Exemple de la versió XYZ amb 3 funcions d'alta prioritat A, B i C, 10 funcions de prioritat mitjana i 15 funcions de prioritat menor (o de baixa prioritat).
  • Les funcions d’alta prioritat són aquelles que generen ingressos elevats i / o conformitat amb els estàndards i / o recuperació de competidors i / o competència única i tots aquests.
  • Les funcions d'alta prioritat solen implicar una codificació complexa, afegint un gran nombre de noves línies de codi.
  • Un gran nombre de noves línies de codi també pot significar una alta probabilitat d’àrees d’intersecció.
  • Normalment, les funcions d’alta prioritat i / o funcions que tenen un gran nombre de línies de codi noves són les millors candidatures per fer proves precoçs.
  • No cal que hi hagi un pla de proves separat desenvolupat per a l'activitat de proves primerenques.
  • Els proveïdors o verificadors de control de qualitat juntament amb els potencials de desenvolupament o les pimes (experts en matèria) han de discutir i acordar la cobertura del codi / proves per a aquesta activitat de prova.
  • Identifiqueu els casos de prova d’alta prioritat adequats i fins i tot alguns casos de prova de prioritat mitjana si creieu que és necessari de cadascun dels plans de prova A, B i C.
  • Un cop identificades les funcions i el subconjunt adequats dels casos de prova, assegureu-vos que es facin un seguiment mitjançant l'eina de seguiment de proves adoptada per l'organització.

Consell: la col·laboració és clau. Durant l'activitat de proves inicials, tant els equips de desenvolupament com els de control de qualitat han de col·laborar estretament per assegurar-se que els objectius establerts s'assoleixen amb resultats de qualitat.

Inici i sortida de la prova inicial

És important que tant l’equip de desenvolupament com l’equip de control de qualitat facin una pluja d’idees i estiguin d’acord amb tots els enfocaments de tota l’activitat de la prova inicial, incloses les dates d’inici i sortida, de manera que tots estiguin a la mateixa pàgina.

Criteris d’entrada per a l’inici

  • Percentatge de finalització de les proves d’integració
  • Nombre d'errors oberts
  • No hi ha bloquejadors per iniciar la prova anticipada

Fase d'activitat

  • Seguiment del progrés
  • Nombre de baixades de codi durant aquesta prova
  • Enfocament de correcció d'errors
  • Enfocament de verificació d'errors
  • Registre els resultats de les proves

Criteris de sortida

  • Activitats de transferència a la següent fase de proves (normalment proves de funcions).
  • Resolució d'errors no resolts trobats durant la prova inicial.
  • Resolució de bloquejadors si n'hi ha per a la següent fase de proves.
  • Publicar els primers resultats de les proves.

Pros i contres

Tota nova iniciativa o activitat té els seus propis mèrits i desavantatges.

Explorem els avantatges i els inconvenients d’aquest enfocament de proves.

Pros

  • Ideal per al model Waterfall.
  • Ajuda a descobrir errors crítics al principi del cicle de proves.
  • Identificació d'errors crítics al començament d'un cicle de llançament.
  • Ajuda l’equip de desenvolupament a estabilitzar el codi abans d’hora.
  • Ajuda a minimitzar la garantia deguda a la correcció d’errors.
  • Ajuda a l’equip de desenvolupament a identificar amb detall les vulnerabilitats de les zones d’intersecció al començament del cicle de llançament.
  • L'equip directiu pot prendre les decisions empresarials adequades amb la deguda diligència sobre els errors crítics no resolts en aquesta versió en concret o en un projecte.
  • Ajuda a estendre’s cobertura de la prova i cicle eficaçment.
  • Ajuda a distribuir recursos de desenvolupament i proves de manera eficient i eficaç.

Contres

  • No és ideal per al model Agile / Scrum. Tanmateix, aquests models poden adoptar Early Test en Sprints amb un ajust adequat.
  • Hi ha una possibilitat de reducció Proves d’integració per l’equip de desenvolupament.

Conclusió

Els clients o els usuaris finals compren o adopten un producte o un sistema o solució de manteniment. El requisit principal és validar un programari que s’executa en aquest sistema o productes per a la seva funcionalitat

Components clau dels principis de les proves, com Per què provar? Què són les proves? Què provar? Com provar? estan sobretot ben definits i entesos. No obstant això, hi ha algunes preguntes persistents que continuen apuntant-se a la ment dels lectors, provadors, clients potencials i gestors sobre conceptes com les proves primerenques.

L’adopció de proves inicials com a activitat integral de la programació general de proves per a qualsevol projecte de programari o llançament determinat beneficia enormement a l’Organització per lliurar un producte o un sistema robust.

Us heu adonat mai de la importància de les proves primerenques a la vostra carrera? No dubteu a compartir els vostres pensaments i experiències a la secció de comentaris de sota !!

Lectura recomanada

^