Menú

Proves basades en el context: 7 principis bàsics amb un exemple

context driven testing

Proveu El Nostre Instrument Per Eliminar Problemes

7 Principis bàsics de les proves basades en el context amb un exemple:

Preguntes d'entrevistes de seleni durant 8 anys d'experiència

Quan condueixo a l’aeroport, normalment agafo l’autopista que m’hi portarà en el temps mínim i evito els peatges. Però aquell dia vaig fer una ruta per carretera local més llarga amb peatge. Perquè volia uns minuts més amb el meu amic en cotxe, que va recórrer una llarga distància per passar el cap de setmana amb la nostra família. La pitjor opció normal, en aquest cas, va resultar ser la millor.

Però, tingueu en compte això.

I si em faltés gasolina?

Què passa si em faltava efectiu?

Tria la diferent opció. Per què? El context.

Què són les proves basades en el context

(imatge crèdit )

Quan es prenen decisions basades en el següent, és una decisió basada en el context:

  • Les persones implicades
  • Circumstàncies
  • Metes
  • Opcions disponibles
  • Emocions, etc.

Llavors, què són les proves basades en el context?

Context Driven Testing és un canvi mental (o escola de proves) desenvolupat per Cem Kaner, James Bach i Bret Pettichord. Podeu trobar-ne detalls al seu famós llibre: Lliçons apreses en proves de programari .

Hi ha 7 principis bàsics. Els següents són triats directament del seu llibre:

# 1) El valor de qualsevol pràctica depèn del seu context.

# 2) Hi ha bones pràctiques en context, però no hi ha bones pràctiques.

# 3) Les persones, que treballen juntes, són la part més important del context de qualsevol projecte.

# 4) Els projectes es desenvolupen amb el pas del temps de maneres que sovint no són previsibles.

# 5) El producte és una solució. Si el problema no es resol, el producte no funciona.

# 6) Una bona prova de programari és un procés intel·lectual desafiant.

# 7) Només a través del criteri i l’habilitat, exercits de manera cooperativa durant tot el projecte, podem fer les coses correctes en els moments adequats per provar eficaçment els nostres productes.

No explicaré cadascun d'ells perquè ho fa per a nosaltres aquí mateixos experts .

Simplement faré una explicació basada en escenaris sobre la meva opinió sobre les proves basades en context.

Un exemple de proves basades en el context:

Diguem que estic començant un projecte de proves: el projecte A, que inclou proves de punta a punta per a una aplicació basada en web.

Quina seria la meva estratègia?

Segons els processos estàndard, aquesta serà la seqüència d'esdeveniments:

  • Reuneix els requisits i entén l’aplicació
  • Creeu un pla de prova
  • Crear documentació de prova: escenaris de prova, casos de prova, matriu de traçabilitat, etc.
  • Feu revisar i aprovar tota la documentació
  • Configureu l'entorn de control de qualitat i les dades de prova
  • Realitzeu l'execució de la prova
  • Creeu informes d'errors
  • Generar i compartir informes d’estat d’execució de proves, etc.

Si em faig la pregunta: 'Com he decidit que és el que necessito fer?' La meva resposta seria: bones pràctiques, estàndards de control de qualitat, directrius de la indústria, línies de base de l’experiència passada, etc., oi?

Estic repetint el que m’han ensenyat a fer o el que he vist fer a d’altres.

Ara, hi ha alguna cosa malament en això? No del tot. Fins i tot això podria funcionar també, perquè hi ha una certa sensació de repetibilitat i contrast de temps en aquest enfocament. Tot i això, obre el camí a uns resultats òptims?

Dubtós. Per què?

Perquè amb cada projecte afrontareu diferents circumstàncies:

  • Requisits documentats o no documentats
  • Treballant molt enfront d’equips distribuïts geogràficament
  • Equips de desenvolupament i proves que pertanyen a la mateixa empresa vs. competició
  • Temps suficient vs. Horaris ajustats
  • La composició del vostre equip - Nouvinguts vs. experimentats. Entrenats vs. no entrenats.
  • Disponibilitat d'eines: ús de l'eina de gestió de manuals i de proves
  • Tipus de projecte: necessita un compliment estricte de les regles (FDA o banca) enfront d’experimentals (com les xarxes socials)
  • La tecnologia del projecte.Per exemple:no provareu el web i una aplicació de Windows de la mateixa manera
  • Requisits dels clients (alguns volen informes detallats diaris, d’altres només volen destacar-los)
  • Procés seguit (àgil vs. tradicional, guió vs. proves exploratòries)

Aquesta llista no és exhaustiva i sabeu tan bé com jo que hi ha moltes variables en cada projecte.

Les proves basades en el context són quan deixeu que aquestes circumstàncies decideixin les vostres pràctiques, tècniques i fins i tot definicions de proves en lloc de les normes estàndard percebudes per la indústria millors pràctiques' .

Ara, diguem que aquests són els detalls amb els quals estic treballant per al Projecte A:

  • Estic treballant amb un equip de 5 a 4 nouvinguts i 1 provador experimentat.
  • No tinc requisits documentats.
  • El meu equip és a l’Índia i l’equip de desenvolupament als Estats Units, de manera que treballem zones horàries oposades.
  • El client vol obtenir un informe d’estat detallat diàriament
  • Utilitzem una eina de seguiment d’errors basada en web, com ara Mantis o Bugzilla, i això és tot el que tenim.
  • He de fer 2 rondes de proves en 10 dies amb 3 dies per obtenir la documentació de la prova

Aquí teniu un pla de joc aproximat:

programes bàsics de Java demanats a les entrevistes

1) Com que hi ha molts nouvinguts a l’equip, necessitem moltes revisions per parells.

2) També necessitem almenys dues reunions de discussió sobre requisits amb l'equip de BA i Dev. Això ha de ser formal perquè els equips es troben en un altre lloc i hi ha poc marge per anar-hi a fer preguntes.

3) És una cronologia agressiva de proves de documentació. Com més documentació escrivim, més ressenyes necessitarem, cosa que equival a més temps. Per tant, haurem de guardar la documentació mínima. Documentarem només el principal TC de punta a punta i la resta ho serà provat exploratori .

4) Es crearan informes d’estat diaris durant l’execució de la prova i s’enviaran EOD cada dia.

5) La majoria de les proves són exploratòries, de manera que us recomanem que proveu de fer un breu resum de cada prova executada. D’aquesta manera sabem què es prova i què no.

6) Els defectes s’informaran en temps real a Mantis. Com que l’equip treballa en una zona horària diferent, és possible que hagin d’esperar un dia sencer abans de rebre notícies de l’equip de control de qualitat, per si necessiten aclariments. Per tant, configureu una trucada diària a un equip convenient, on l’equip de control de qualitat demostrarà la recreació d’errors. D’aquesta manera, no caldrà esperar ni fer un seguiment.

Etcètera.

Un cop tingueu una estratègia general, escriviu un pla de proves bàsic que expliqui aquests punts. Ara ja esteu a punt per endinsar-vos en un projecte de proves després d'una atenta reflexió i una estratègia d'èxit personalitzada.

En resum:

Això és Proves basades en el context; convertint les vostres circumstàncies (no els estàndards) en les aportacions i influents principals de la vostra estratègia de prova. Ens insta a mirar al nostre voltant i a tenir en compte tot el que us envolta.

Personalment, estic enamorat d’aquest concepte perquè massa sovint les pràctiques de proves es perceben com a rígides i basades en la imitació. Algú ho va fer i va tenir èxit, així que jo també ho faré. Aquest és el tipus d’imatge que espanta a la gent de provar i de mantenir-se en una carrera de proves.

Però, hi ha un munt d’abast per al pensament creatiu, les habilitats analítiques i la presa de decisions. Per obtenir més informació, llegiu el tema als enllaços que es proporcionen més amunt.

Proves feliços basades en el context

Lectura recomanada

^