Menú

Com revisar el document SRS i crear escenaris de prova: formació en proves de programari en un projecte en directe: dia 2

how review srs document

Proveu El Nostre Instrument Per Eliminar Problemes

quin és el millor lloc de descàrrega de mp3 gratis?

Aquest és el segon tutorial del nostre 'Formació gratuïta sobre proves de programari en línia en un projecte en viu' sèrie. Si sou nou aquí, consulteu el primer tutorial d’introducció: Formació de proves de programari de punta a punta en un projecte en directe.

Anem ara a fer una anàlisi detallada de com passa una solució SRS, què és el que hem d’identificar a partir d’aquest pas, quins passos previs hem de fer abans de començar, quins són els reptes que podríem afrontar, etc. d'una manera detallada.

Com revisar el document SRS i crear escenaris de prova_

Fase de disseny de SDLC:

La següent fase del SDLC és 'Disseny': aquí es tradueixen els requisits funcionals en els detalls tècnics. Els equips de desenvolupament, disseny, entorn i dades participen en aquest pas. El resultat d’aquest pas sol ser un document de disseny tècnic (TDD).

L’entrada és el document SRS tant per a la creació del TDD com per a que l’equip de control de qualitat comenci a treballar en l’aspecte de control de qualitat del projecte, que és revisar el SRS i identificar l’objectiu de la prova.

Què aprendreu:

Què és una revisió de SRS?

SRS és un document creat per l’equip de desenvolupament en col·laboració amb Business Analysts i equips d’entorn / dades. Normalment, aquest document un cop finalitzat es compartirà amb l’equip de control de qualitat mitjançant una reunió on s’organitzarà un recorregut detallat.

De vegades, per a una sol·licitud ja existent, és possible que no necessitem una reunió formal i algú ens orienti a través d’aquest document. És possible que tinguem la informació necessària per fer-ho nosaltres mateixos.

La revisió de l’SRS no és altra cosa que passar pel document d’especificació de requisits funcionals i intentar entendre com serà l’aplicació objectiu.

El format formal i una mostra es van compartir amb tots vosaltres a l’article anterior. No vol dir necessàriament que tots els SRS es documentin d'aquesta manera exactament. Sempre, el el formulari és secundari al contingut .

Alguns equips escolliran escriure una llista amb pics, alguns equips inclouran casos d’ús, alguns equips inclouran captures de pantalla de mostra (com el document que teníem) i alguns només descriuen els detalls als paràgrafs.

Passos previs per a la revisió de les especificacions dels requisits de programari

Pas 1) Els documents passen per diverses revisions, així que assegureu-vos que tenim la versió correcta del document de referència, l’SRS.

Pas 2) Establir directrius sobre el que s’espera al final de la revisió de cada membre de l’equip. En altres paraules, decidiu quins lliuraments s’esperen d’aquest pas; normalment, la sortida d’aquest pas és identificar els escenaris de prova. Els escenaris de prova no són res més que un punt indicatiu de 'què provar' per a determinades funcionalitats.

Pas 3) Establiu també pautes sobre com es presentarà aquest lliurable, vull dir, la plantilla.

Pas 4) Decidiu si cada membre de l'equip treballarà tot el document o dividiu-lo entre ells. Es recomana que tothom ho llegeixi tot perquè això evitarà la concentració de coneixement amb determinats membres de l'equip.

Però en cas d’un projecte enorme, amb els documents SRS a prop de 1000 pàgines, és molt pràctic l’enfocament de trencar el mòdul de documents i assignar-lo a membres individuals de l’equip.

Pas 5) La revisió de SRS també ajuda a entendre millor si hi ha requisits previs específics necessaris per a la prova del programari.

Pas 6) Com a subproducte, una llista de consultes en què és difícil entendre alguna funcionalitat o si cal incorporar més informació als requisits funcionals o si s’identifiquen errors en SRS.

Què necessitem per començar?

  • La versió correcta del document SRS
  • Instruccions clares sobre qui treballarà sobre què i quant de temps tenen.
  • Una plantilla per crear escenaris de prova.
  • Altra informació sobre: ​​a qui contactar en cas de dubte o a qui informar en cas d’incongruència documental?

Qui proporcionaria aquesta informació?

Els responsables de l’equip són generalment responsables de proporcionar tots els elements que figuren a la secció anterior. Tot i això, les aportacions dels membres de l’equip sempre són importants per a l’èxit de tot aquest esforç.

Els líders d’equip solen preguntar-Quin tipus d’input? No seria millor assignar un mòdul determinat a algú interessat que a un membre de l’equip que no ho sigui? No seria bo decidir la data prevista en funció de l’opinió de l’equip que decidir-ne? A més, per a l’èxit d’un projecte, les plantilles són importants.

Com a norma general, les plantilles tenen una taxa d’eficiència més alta quan s’adapten a la comoditat i comoditat de l’equip específic. Per tant, cal tenir en compte que els líders de l’equip són més que res de membres de l’equip. La incorporació del vostre equip en les decisions del dia a dia és crucial per al bon funcionament del projecte.

Cal plantilla per als escenaris de prova?

Per què una plantilla per a escenaris de prova: no n’hi ha prou si només fem una llista?

Segur que sí. Tanmateix, els projectes de programari no són espectacles 'unipersonals'. Impliquen treball en equip .

Imagineu-vos un equip de 4 persones, si cadascun d'ells decideix revisar un mòdul de l'especificació de requisits de programari cadascun. El membre de l’equip A ha fet una llista en un full de paper. El membre de l'equip 2 va utilitzar un full Excel. El membre de l’equip 3 va utilitzar un bloc de notes. El membre de l’equip 4 va utilitzar una paraula doc. Com consolidem tota la feina feta per al projecte al final del dia?

A més, com podem decidir quin és l’estàndard i com podem dir què és correcte i què no si no vam crear les regles, per començar?

Això és el que és la plantilla: Un conjunt de pautes i un format acordat per a la uniformitat i la concurrència de tot l’equip.

Com es crea una plantilla per als escenaris de prova de control de qualitat?

Plantilles no han de ser complicats ni inflexibles.

Tot el que han de ser són un mecanisme eficient per crear un artefacte de prova útil. Una cosa senzilla com la que veiem a continuació:

plantilla d

La capçalera d'aquesta plantilla conté l'espai necessari per capturar informació bàsica sobre el projecte, el document actual i el document de referència.

La taula següent ens permetrà crear escenaris de prova. Les columnes incloses són:

Columna 1) Identificador d'escenari de prova
Totes les entitats del nostre procés de proves han de ser identificables de manera única. Per tant, a cada escenari de prova se li ha d’assignar un identificador. Cal definir les regles que cal seguir durant l’assignació d’aquest identificador.

Per aquest article, seguirem la convenció de noms com TS (prefix que significa Test Scenario) seguit de ‘_’, nom del mòdul MI (El mòdul My Info del projecte Orange HRM) seguit de '_' i després la subsecció ( Per exemple, Jo per al mòdul My Info, Pàg per a fotografia, etc.) seguit d’un número de sèrie. Un exemple seria: 'TS_MI_MIM_01'.

Columna # 2) Requisit
Ajuda que quan creem un escenari de prova, puguem assignar-lo a la secció del document SRS on l’hem triat. Si els requisits tenen identificadors, podríem utilitzar-los. Si no, els números de secció o fins i tot els números de pàgina del document SRS des d'on vam identificar un requisit comprovable farà.

Columna núm. 3) Descripció de l'escenari de prova
Un full que especifica 'què s'ha de provar'. També ens referiríem a això com a objectiu de la prova.

Columna # 4) Importància
Això és per donar una idea de la importància que tenen certes funcionalitats per a l’automàtica. Es poden assignar valors com ara alt, mitjà i baix a aquest camp. També podeu triar un sistema de punts, com ara 1-5, 5 són els més importants i 1 són menys importants. Sigui quin sigui el valor que pugui tenir aquest camp, s’ha de decidir prèviament.

Columna núm. 5) Nombre de casos de prova
Una aproximació aproximada de quants casos de prova individuals podríem acabar escrivint aquell escenari de prova. Per exemple, Per provar l'inici de sessió, incloem aquestes situacions: Corregiu el nom d'usuari i la contrasenya. Corregiu el nom d'usuari i la contrasenya incorrecta. Corregiu la contrasenya i el nom d'usuari incorrecte. Per tant, validar la funcionalitat d’inici de sessió donarà lloc a tres casos de prova.

Nota: Podeu ampliar aquesta plantilla o eliminar els camps com convingueu.

Per exemple , podeu afegir 'Revisat per' a la capçalera o eliminar la data de creació, etc. També a la taula podeu incloure un camp 'Creat per' per designar el provador responsable d'un determinat escenari de prova o eliminar el 'No. de casos de prova ”. L’elecció és vostra. Seguiu el que funcioni millor per a tot l’equip.

Revisem ara el nostre document Orange HRM SRS i creem els escenaris de prova

Consell professional: consulteu la taula de continguts de la mostra SRS que hem proporcionat als primers tutorials per tenir una bona idea de com fluirà qualsevol document i de la quantitat de treball que pot implicar.

Secció 1 és la finalitat del document. No hi ha requisits verificables allà.

Secció 2.1 : Visió general del projecte: públic: tampoc hi ha requisits verificables.

Secció 2.2 : Maquinari i allotjament: en aquesta secció es parla de com s’allotjarà el lloc d’Orange HRM. Ara bé, aquesta informació és important per als verificadors? La resposta és sí i no, sí, perquè quan fem la prova hem de tenir un entorn similar a l’entorn en temps real.

Això ens dóna una idea de com ha de ser. No, perquè no és un requisit que es pugui comprovar; és una mena de requisit previ perquè es produeixin les proves.

Secció 3: Aquí hi ha una pantalla d’inici de sessió i els detalls del tipus de compte que hem de tenir per accedir al lloc. Aquest és un requisit comprovable. Per tant, ha de formar part dels nostres escenaris de proves.

Consulteu el document dels escenaris de prova on s’han afegit els escenaris de prova per a algunes seccions del SRS. Per a la pràctica, afegiu la resta d’escenaris de manera similar. Tot i això, vaig a la secció 4 del document.

mostra de casos de proves per a proves manuals

Secció 4: Directrius i requisits estètics / HTML: en aquesta secció s’explica millor com alguns requisits poden no tenir sentit per a l’equip de prova en el moment de la revisió de l’SRS, però l’equip hauria de fer-ne una nota com a requisits verificables.

La manera de provar-los i si necessitem una configuració específica / ajuda d’algun equip per validar-lo són detalls que potser no sabríem en aquest moment. Però convertir-los en una part del nostre abast de proves és el primer pas per assegurar-nos que no els enyorem.

Exemples d'escenaris de prova per a l'aplicació OrangeHRM: (feu clic per ampliar la imatge)

plantilla d

=> Consulteu i descarregueu el document Escenaris de proves per obtenir més informació.

Algunes observacions importants sobre la revisió de SRS

# 1) No es deixa cap informació descoberta.
# 2) Realitzeu anàlisis de viabilitat sobre si un determinat requisit és correcte o no i també si es pot provar o no.
# 3) Llevat que existeixi un equip de prova o un rendiment o seguretat diferent, és la nostra feina assegurar-nos que cal tenir en compte tots els requisits no funcionals.
# 4) No tota la informació està dirigida als verificadors, per tant, és important entendre què cal tenir en compte i què no.
# 5) La importància i no. Els casos de prova per a un escenari de prova no han de ser precisos i es poden omplir amb un valor aproximat o es poden deixar buits.

En resum, la revisió de SRS té com a resultat:

  • Llista d'escenaris de prova
  • Resultats de la revisió: errors de documentació / requisits trobats mitjançant la comprovació o verificació estàtica del document SRS
  • Una llista de preguntes per a una millor comprensió, en cas que n’hi hagi
  • La idea preliminar de com se suposa que és l'entorn de prova
  • Identificació de l'abast de la prova i una idea aproximada de quants casos de prova podríem acabar tenint, per tant, quant de temps necessitem per a la documentació i, finalment, per a l'execució.

Punts importants a tenir en compte:

# 1) Els escenaris de prova no són objectes de lliurament externs (no es comparteixen amb Business Analysts o equips de desenvolupament), però són importants per al consum intern de control de qualitat. Són el nostre primer pas cap a un objectiu de cobertura del 100%. Els escenaris de prova un cop finalitzats se sotmeten a una revisió per parells i, un cop fet això, es consoliden tots.

Per obtenir més informació sobre com es revisen els documents de control de qualitat, consulteu l'article: Com es realitzen ressenyes de documentació de prova en 6 passos senzills.

# 2) Podríem utilitzar una eina de gestió de proves com HP ALM o bé qProva per crear els escenaris de prova. Tot i això, la creació d’escenaris de prova en temps real és una activitat manual. Al meu entendre, és més convenient manualment. Com que és el primer pas, no cal que sortim encara les grans armes. Els fulls Excel excel·lents són la millor manera d’aconseguir-ho.

El següent pas d’aquesta sèrie és que - treballarem en la creació de casos de prova i ens endinsarem en la fase de disseny de la prova. Abans, també ens endinsarem en ... Què és la planificació de les proves?On s’adapta a tot el projecte de control de qualitat? Com sempre, treballeu amb nosaltres per obtenir els millors resultats.

Dia 3 d'entrenament de control de qualitat: Com escriure un document SRS des de zero.

Si us plau, mantingueu les vostres preguntes i comentaris. Agraïm els vostres lectors un munt!

Lectura recomanada

^