test scenario vs test case
Diferència entre l'escenari de prova i el cas de prova.
Fa 6 anys , mentre treballava amb un MNC de mida mitjana, quan vaig suggerir documentar escenaris de proves en lloc de perdre el temps en preparar el document de prova complet anomenat casos de prova, tots els caps es van dirigir a mi amb molèstia.
L’aspecte de les cares transmetia clarament que vaig cometre un gran error suggerint-ho. Tot i que ningú no va negar la idea, ningú ni tan sols va acceptar. Tothom sentia que seguir la tradició, és a dir, escriure documents de casos de proves, seria més segur. No podria discutir.
Després de 4 anys , l'empresa va rebre un projecte de proves, on l'única restricció era el temps i l'única expectativa era la prova completa proves.
Vam tornar a estar a la reunió i vam estar discutint idees per complir el termini límit. L’aplicació consistia principalment en cercar i generar diferents informes mitjançant diferents elements del menú. La documentació de casos de prova se suposava que arrabassava la major part del temps i no estàvem segurs de quant utilitzaria el document per al client.
Vaig suggerir documentar els escenaris de proves i, d'alguna manera, amb certes vacil·lacions, tothom va estar d'acord. No cal esmentar que podríem estalviar temps preciós de documentació i utilitzar-lo per provar-lo.
Què aprendreu:
- Els casos de prova s'estan substituint ràpidament per escenaris de prova?
- Quan és important la documentació de casos de prova?
- Diferències entre l'escenari de prova i el cas de prova en format tabular
- Conclusió
- Lectura recomanada
Els casos de prova s'estan substituint ràpidament per escenaris de prova?
Amb el temps, a mesura que tot canvia, la indústria i els processos del programari també han canviat molt.
qa preguntes i respostes d’entrevistes de treball
Tradicional Cascada i Models en V s'estan substituint per models àgils i iteratius. La documentació és necessària però per complir els terminis i fer el procés fàcil i transparent, es pot canviar la forma de documentació.
Quan és important la documentació de casos de prova?
- El client ha demanat el mateix com a part del projecte.
- No hi ha restricció de temps (no crec que sigui possible).
- Els provadors són més frescos o desconeguts pel producte.
- Política de l'empresa (crec fermament que es pot canviar).
Permeteu-me compartir amb vosaltres una experiència:
Jo i el meu equip vam participar en la prova d’un projecte d’una empresa Fortune 500 amb terminis flexibles. Hem documentat casos de prova amb la millor plantilla disponible i l’hem aprovat pel client.
Un cop la versió va començar a publicar-se a l’equip de control de qualitat, durant la major part del dia, el nostre deure era: seguir mecànicament 100 casos de prova al dia, actualitzar el document amb el resultat d’aprovació / error i enviar-lo al client al final del dia. La majoria de els membres de l’equip van començar a queixar-se treball monòton però l’empresa generava ingressos.
Després hi va haver una pausa per un dia entremig, sense cap nova versió per provar. Ens vam asseure junts al principi del dia i vam estar discutint què faríem per al dia. Quan vaig proposar generar més idees per millorar el document del cas de prova, tots els membres de l’equip van negar esforços.
Segons ells, no hi havia res més a pensar, ja que havíem cobert tots els escenaris. I convèncer-los pensa fora d’una caixa i genera més idees va ser molt dur.
La majoria de les vegades, quan documentem casos de prova i això també un cop aprovats pel client, aquesta ment humana pensa que hem fet la nostra feina i la nostra ment deixa de considerar automàticament qualsevol esforç per pensar en altres maneres de provar el producte.
I creieu-me, quan es prepara el document de casos de prova, només volem seguir-lo mecànicament. Digueu-me quantes vegades a la vostra carrera heu experimentat que vostè o el seu company d’equip van oferir casos de prova addicionals al document de casos de prova aprovat?
Una experiència més:
Durant l'activitat setmanal de desafiament d'equip, vam anunciar l'aplicació i vam demanar als membres de l'equip que presentessin escenaris de prova.
Tots els membres de l’equip, inclosos els que han respost tard o no, aporten idees. Per què? No hi havia documentació formal en què havien d'emplenar el resultat esperat per a cada seqüència de funcionalitat i condició prèvia per a cada cas de prova. Vam recollir 40 escenaris de prova en un dia i va ser una experiència fantàstica.
Per afavorir la meva experiència, M'agradaria presentar-ne un exemple.
Preneu una aplicació de mostra, digueu pàgina d'inici de sessió amb botons de nom d'usuari, contrasenya, inici de sessió i cancel·lació. Si se’ns demana que escriviu casos de prova per al mateix, acabarem escrivint més de 50 casos de prova combinant diferents opcions i detalls.
Però si s’escriuen escenaris de prova, es tractarà de 10 línies a continuació:
Escenari d’alt nivell: Funcionalitat d'inici de sessió
Escenaris de baix nivell :
hi ha auriculars vr per a Xbox 360
1. Per comprovar l'aplicació s'està iniciant
2. Per comprovar el contingut del text a la pàgina d'inici de sessió
3. Per comprovar el camp Nom d'usuari
4. Per comprovar el camp Contrasenya
5. Per comprovar el botó d'inici de sessió i cancel·lar la funcionalitat del botó
Vegeu també=> Més de 180 escenaris de proves de mostra per provar aplicacions web i d'escriptori.
Com que a tots ens falta poc temps, els escenaris de prova funcionen com un spray analgèsic més que no pas amb l’antiga IODEX. I encara, l’efecte és el mateix.
Diferències entre l'escenari de prova i el cas de prova en format tabular
Finalment, voldria resumir la diferència entre l’escenari de prova i el cas de prova:
| Casos de prova | Escenaris de prova | |
|---|---|---|
| Què és => | Un concepte que proporciona informació detallada sobre què cal provar, els passos a seguir i el resultat esperat del mateix | Un concepte que proporciona informació d’una línia sobre què s’ha de provar. |
| Es tracta de => | Es tracta més de documentar detalls. | Es tracta més de pensar i discutir detalls. |
| Importància => | És important quan les proves estan fora de perill i el desenvolupament és in situ. Escriure casos de prova amb detalls ajudarà a sincronitzar l’equip de desenvolupadors i de control de qualitat. | És important quan el temps és menor i la majoria dels membres de l’equip poden estar d’acord / entendre els detalls de l’escenari de línia única. |
| Avantatge => | La documentació única de tots els casos de prova és beneficiosa per fer un seguiment de 1.000 rondes de proves de regressió en el futur. La majoria de les vegades, és útil mentre s’informa d’errors. El provador només ha de donar referència a la identificació del cas de prova i no requereix mencionar tots els detalls de cada minut. | Una activitat d’estalvi de temps i generació d’idees, preferida per la comunitat de proves de programari de nova generació. La modificació i l’addició són senzilles i no són específiques d’una persona. Per a un projecte enorme, en el qual el grup de persones només coneix mòduls específics, aquesta activitat ofereix a tots l’oportunitat d’examinar altres mòduls i analitzar la tempesta cerebral |
| Beneficiós per a => | Un document de casos de prova a prova completa és una línia vital per al nou provador. | Es pot aconseguir una bona cobertura de proves dividint l'aplicació en escenaris de prova i redueix la repetibilitat i la complexitat del producte |
| Desavantatge => | Consumeixen temps i diners, ja que requereixen més recursos per detallar tot el que cal provar i com provar | Si és creat per una persona concreta, és possible que el revisor o l’altre usuari no sincronitzi la idea exacta que hi ha al darrere. Necessiteu més discussions i esforços en equip. |
Conclusió
Els casos de prova són la part més important del cicle de vida del desenvolupament de programari i, sense aquest, és difícil fer un seguiment, comprendre, seguir i raonar alguna cosa. Però a l’era de l’Agile, els casos de prova s’estan substituint ràpidament per escenaris de prova.
Un comú llista de comprovació de proves Per a cada tipus de prova (proves de bases de dades, proves de GUI, proves de funcionalitat, etc.) junt amb escenaris de prova, hi ha l'artilleria moderna per als provadors de programari. Els debats, la formació, les preguntes i la pràctica poden canviar definitivament el gràfic final de la vostra productivitat així com una matriu d'informes d'errors.
Com és habitual, donem la benvinguda a les vostres reflexions i consultes. Si us plau, sintonitzeu.
Lectura recomanada
- Diferència entre pla de prova, estratègia de prova, cas de prova, script de prova, escenari de prova i condició de prova
- Tipus de proves de programari: diferents tipus de proves amb detalls
- Com escriure casos de prova: la guia definitiva amb exemples
- Com revisar el document SRS i crear escenaris de prova: formació en proves de programari en un projecte en viu: dia 2
- Com classificar els escenaris de proves positius i negatius: full de trucs d’un provador
- Prova de rendiment vs Prova de càrrega vs Prova d’estrès (diferència)
- Proves estàtiques i proves dinàmiques: diferència entre aquestes dues tècniques de prova importants
- 101 diferències entre els fonaments bàsics de les proves de programari