Menú

Com fer front als mals requisits com a provador

how deal with bad requirements

Proveu El Nostre Instrument Per Eliminar Problemes

La silenciosa sala de conferències s’ofegava i tothom que estava dins d’ella estava confós. Com ho podríem trobar a faltar , es reflectia la pregunta de la cara de tothom.

Al cap i a la fi, no aparèixer amb cap error rellevant quan l'usuari intenta duplicar el registre existent i permetre-li fer-ho no va ser un petit error, això també per a una companyia d'assegurances.

Després de decidir resoldre el problema, tothom es va dispersar. I mentre s’excavava, es va observar que el client mai no esmentava res sobre la duplicitat de registres al document de requisits i, per tant, ningú no feia preguntes rellevants ni hi pensava.

mals requisits

Aquest va ser només un exemple.

En una carrera de més de 10 anys , He observat molts casos en què els projectes van patir a causa de males o males necessitats.

Però, com es diu, res no és perfecte en aquest món i hauràs de fer-hi front i fer front a projectes que no requereixen requisits ni són requisits deficients és un tipus de malson.

Deixa'm explicar -

Què aprendreu:

Com de dolents, pobres i conflictius requereixen problemes:

# 1) Sense requisits - Cap requisit implica suposicions i suposicions i, per tant, no hi ha confiança. És molt difícil provar un producte / aplicació sense cap base. I això comporta més treball, més errors del client i més patiment pel projecte.

  • Com ho faríeu? informar d’un problema sobre la caiguda del sistema quan no hi ha cap definició de com s'ha de gestionar el comportament?
  • Com transmetríeu que el temps de càrrega de 100 segons per a la pàgina inicial és inacceptable quan no hi ha cap requisit rellevant per al rendiment?

En l'article publicat anteriorment es pot trobar més informació sobre Sense requisits i sobre com gestionar la situació durant les proves. Com provar una aplicació sense requisits?

# 2) Requisits deficients: La cita, Conèixer alguna cosa incompleta és perillós que no saber-la en absolut , és molt cert a l’hora d’afrontar un requisit deficient.

Interpretar un requisit deficient i aplicar-lo és un gran risc.

  • Com confirmaríeu que la finestra emergent que mostra els resultats de la cerca sigui vàlida o no quan l’únic requisit esmentat era: els resultats de la cerca haurien de ser adequats i no esteu segur de quins criteris s’haurien de tenir en compte durant la cerca.
  • Com interpretaria això: s'hauria d'implementar la contrasenya oblidada per facilitar a l'usuari regenerar / restablir la contrasenya oblidada. Es desconeix el flux de treball que el client vol oblidar la contrasenya, el desenvolupador implementa el que creu que és millor i comencen els conflictes.

# 3) Requisits conflictius: Demanar a algú que faci dues coses diferents alhora és confondre-ho i el sistema tampoc no és una excepció.

  • Com es provaria una aplicació amb els requisits esmentats a continuació:
    • L'aplicació sempre s'ha d'obrir a la pàgina d'inici.
    • S'espera que els usuaris iniciïn la sessió per accedir a l'aplicació.
  • Quina seria la vostra prioritat quan el document de requisits sigui el següent:
    • L'aplicació de joc hauria de promoure l'usuari al següent nivell si l'usuari obté 1.000.
    • L'usuari hauria de ser redirigit a la pàgina de subscripció gratuïta un cop obtingui 1.000.

I és així com els mals, pobres i conflictius requisits creen molèsties.

Com que es troba en la indústria del programari, hauria de formar part del projecte, ja que de vegades fins i tot el client no està segur de què volen exactament i de com el redacten.

Des de la perspectiva de les proves, tot i que és difícil gestionar aquests requisits ambigus o vagues, no és del tot impossible.

Vegem les possibles solucions:

Requisits incorrectes i com gestionar-los com a provador:

Mètode 1)Explorar i aprendre:

Explorar altres aplicacions, conèixer el comportament general esperat, entendre el flux de treball, pensar en la comoditat de l’usuari i aplicar la lògica és una manera de fer front a la situació. A més, basant-se en proves exploratòries seria útil en aquest tipus de situacions en què els requisits no estan clars.

La majoria de les vegades, és una bona aposta prioritzar l’experiència i la comoditat de l’usuari quan els requisits no estan clars.

Mètode 2)Utilitzeu l'experiència:

Utilitzeu l’experiència

Experiència de domini , experiència global de proves, problemes enfrontats al passat i estadístiques personals poden ajudar a solucionar situacions i requisits confusos.

Mètode 3)Consulteu els wireframes:

Els marcs metàl·lics són un tipus de requisit visual on es poden trobar petits detalls i aquests detalls poden ser molt útils per crear la imatge esperada del producte o de l’aplicació i ajudar a cobrir aspectes de proves d’una manera millor.

Llegeix més => Marcs metàl·lics: s’han de provar realment? I si és així, com?

Mètode 4)Discussió entre iguals:

convertidor de youtube a mp3 sense virus

Discussió entre iguals

No importa quina sigui la confusió, si es discuteix amb un munt de persones adequades, les coses s’aclareixen. Tothom té experiències diferents, expectatives, visió de l’usuari i visió d’anàlisi i discutir amb els companys aquests deficients requisits servirà per cristal·litzar la comprensió i augmentar la confiança en un mateix.

Mètode 5)Aclariment del client:

El client és el propietari del producte / aplicació i sempre és aconsellable acostar-se a ell quan es tracta de la claredat dels requisits. Però recordeu, no és recomanable atacar el client amb centenars de preguntes. Abans de fer-ho, cal fer deures.

Proveu de conèixer les pràctiques recomanades disponibles, enteneu els avantatges de la implementació i, a continuació, poseu-vos en contacte amb el client per obtenir preguntes i possibles solucions.

Conclusió

Finalment, els requisits poc definits o indefinits formen part de la vida del comprovador i els hem d’acceptar, però intentem ser optimistes i determinar-ne les solucions. Al cap i a la fi, som provadors, ajudem a mantenir les aplicacions en bon camí i a evitar que caiguin de pla. YAY a nosaltres :)

Sobre l'autor: Aquesta publicació inspiradora està escrita pel membre de l'equip de STH Bhumika M. Ella és cap de projecte, amb més de deu anys d'experiència en proves de programari.

Bones proves, com de costum ... ... esperant les vostres opinions, comentaris i opinions.

Lectura recomanada

^