Menú

Com provar una aplicació sense requisits?

how test an application without requirements

Proveu El Nostre Instrument Per Eliminar Problemes

Tècnicament no hi ha aplicacions sense requisits. Imagineu-vos un programari que no fa res específic, sinó que simplement s’estén línia rere línia. Serà una escala que no portarà enlloc.

Tot el programari té requisits i està dirigit a una tasca concreta; específicament, és una solució a un problema. Tan sense requisits el programari no és una possibilitat.

No obstant això, el programari sense requisits documentats és una realitat que malauradament la majoria de nosaltres ens enfrontem amb més freqüència ens agrada. L'únic pitjor podria ser que la documentació és insuficient, imprecisa o terriblement obsoleta. Malauradament, això també passa.

prova sense requisits

Sincerament, realment no hi ha substitució d’un document de requisits funcionals / de sistema ben documentat amb casos d’ús elaborats i pantalles de simulació. Tot i que hem d'admetre que això s'està convertint en una raresa en la indústria a causa dels cicles de desenvolupament ràpids i d'un canvi de paradigma cap a la documentació mínima o nul·la.

Per tant, aquest article és un intent d’algunes pràctiques que hem seguit quan ens trobem en aquestes situacions.

Llegiu també:

com inscriure's a les proves de productes

Vegem primer uns quants raons per les quals potser no hi ha documentació, per començar:

  1. Es reobre el projecte del prestatge
  2. Documentació menys format de treball- Procés
  3. És possible que hi hagi documentació, però que no sigui detallada ni completa
  4. Les versions contínues i la informació relacionada amb la versió anterior no s'han arxivat, cosa que provoca un buit en la comprensió de com reacciona la funcionalitat existent amb la nova

Tots aquests són impediments que els verificadors hem de travessar amb valentia i sortir amb èxit. Com exactament, però, oi?

Aquests són els 3 mètodes principals per provar una aplicació sense requisits:

Mètode 1:

Treballeu amb la poca documentació que pugueu aconseguir. Podria tractar-se d’un retard senzill bàsic (en projectes àgils), un fitxer d’ajuda, un correu electrònic, una versió anterior del BRD / FRD o casos de prova antics (comproveu-los a les vostres eines ALM i és possible que els trobeu), etc.

Investigueu, pregunteu-hi i sempre hi ha algun judici documentat, fins i tot si es tracta d’una prova fina.

Si això no funciona, no descompteu la vostra experiència com a usuari de programari.Per exemple, si heu de provar una operació de transferència d’un compte bancari, ningú no ens ha de dir com fer-ho, oi? Perquè, com a clients de banca en línia, tots sabem que necessitem des de i cap a comptes amb diversos fons disponibles per transferir.

Acordem que no totes les situacions seran tan senzilles, però, de nou, també ho podrien ser.

Mètode 2:

Utilitzeu la versió anterior / actual de l’aplicació com a referència per provar la versió futura d’un producte de programari. Ara, admeto que això nega la regla: 'No escriviu mai casos de prova utilitzant l'aplicació com a referència'. No obstant això, quan treballem en una situació menys que perfecta, hem de modelar les regles per adaptar-les a les nostres necessitats.

Ajuda a mantenir en perspectiva els aspectes següents en fer-ho:

  • L'aplicació pot contenir errors; per tant, si després del registre, el sistema us porta directament a Screen1 (una determinada pantalla hipotètica pel bé del nostre exemple), no suposeu mai que sigui el comportament correcte. A més, si un camp pren caràcters alfanumèrics i és un número de telèfon, és una pregunta i assegureu-vos de no prendre l'aplicació com a exemple concedit per a la funcionalitat esperada.
  • En les situacions anteriors, utilitzeu el vostre criteri i feu servir l’ajuda de l’aplicació per iniciar-vos ràpidament, però sigueu crítics amb això per qüestionar-vos que funciona.

Mètode 3:

Parleu amb els membres de l'equip del projecte:

  • Oferiu-vos d’assistir a les seves reunions.
  • Pregunteu si podeu participar en les fases de proves d’unitat i integració.
  • En cas contrari, pregunteu si l'equip de desenvolupadors pot compartir els resultats de les proves de la unitat i de la integració.
  • Organitzeu un temps per a la transferència de coneixement en un moment convenient.

Ara, apliquem els mètodes en un exemple:

Suposem que hi ha un lloc de compres on podeu afegir articles al carretó de la compra. Idealment, si hi havia documentació, ens ha de dir com afegir-hi articles, quants articles pot tenir en un moment determinat, què passa quan l'article que heu afegit es queda esgotat de sobte, quin és el nombre màxim dels mateixos articles que podeu comprar al mateix temps, etc. La nostra situació és que en aquest moment no hi ha cap disponible.

Apliqueu el mètode núm. 1:

Cerqueu qualsevol documentació que pugueu. Pregunteu al vostre equip de desenvolupadors si tenen pantalles de maquetes / mireu a l'eina ALM o res. Si trobeu alguna cosa, seria un bon punt de partida. Però si aquest mètode no resulta res, podeu utilitzar el vostre judici / intuïció del provador.

Tots sabem com funcionen els carros de la compra, així que feu les vostres suposicions i arribeu a alguns escenaris bàsics com ara:

  • Els articles es poden afegir al carretó de la compra després d’haver-los explorat o cercat
  • Un cop he afegit articles al carretó de la compra, s'hauria d'actualitzar la llista d'articles
  • L'usuari hauria de poder continuar comprant fins i tot després d'afegir pocs articles al carretó
  • Si afegiu el mateix element dues vegades, s’incrementarà el recompte dels elements afegits
  • Els elements es poden actualitzar
  • Els elements es poden eliminar
  • El total hauria de ser equivalent a la suma de tots els preus afegits
  • Els impostos s'han de calcular en funció del codi postal introduït
  • S'han d'afegir les despeses d'enviament en conseqüència

Podem continuar endavant, però estic segur que obtindreu la imatge.

Apliqueu el mètode núm. 2:

Si hi ha disponible una versió anterior de l’aplicació, pot ser útil per escriure els casos de prova, ja que haureu d’escriure els passos exactes d’on fer clic, d’on introduir l’entrada, què comprovar, etc. Captures de pantalla / maquetes / wire- marcs: si estan disponibles, també poden ser excel·lents substituts.

Com podeu veure a la pantalla següent, aquestes coses són evidents: els noms dels camps, els botons o altres elements presents, etc. (feu clic a la imatge per ampliar-la)

prova sense requisits

Ara, en aquest moment, els verificadors tenen algunes preguntes com ara:

  1. Què passa quan dono un caràcter al quadre de l'import?
  2. Quan puc afegir massa elements?
  3. Quin és el màxim no? d'articles que pot trigar? Etc.

Apliqueu el mètode núm. 3 :

Porteu la vostra llista de preguntes al BA, al desenvolupador o fins i tot al client i busqueu aclariments. Un cop fet el mètode 3, gairebé hauríeu d’estar equipat amb tota la informació que necessiteu per escriure casos de proves detallats i realitzar les proves amb tanta confiança com ho faríeu quan hi hagués documentació elaborada.

Acordem que es tracta de molts més passos i molt més seguiment, però per garantir la prova de qualitat, aquests passos són inevitables.

En conclusió, no es perd tot quan la documentació no existeix o és insuficient. Encara hi ha esperança! Comparteix les teves experiències en situacions similars.

Sobre l'autor: Aquest missatge útil l’ha escrit Swati S., membre del nostre equip de STH.

Com sempre, els vostres comentaris, preguntes i suggeriments són benvinguts.

Lectura recomanada

^