Menú

Com participen els verificadors en les tècniques TDD, BDD i ATDD

how testers are involved tdd

Proveu El Nostre Instrument Per Eliminar Problemes

Visió general de les tècniques TDD, BDD i ATDD:

TDD, BDD i ATDD són els termes que han revolucionat el món del provador a Agile i també han agafat impuls. Canvi en la mentalitat dels provadors també requereix aprendre noves habilitats i, el que és més important, canviar l’actitud i la forma de treballar.

A diferència de treballar aïlladament, els provadors han de col·laborar i treballar junts amb els programadors, cosa que significa

  • Compartir els casos de prova
  • Participar en l’escriptura dels criteris d’acceptació de les històries
  • Proporcionar retroalimentació contínua als grups d'interès
  • Col·laborant per resoldre els defectes a temps.
  • Proporcioneu suggeriments i aportacions per millorar la qualitat dels lliuraments
  • Automatització

Testers implicats en Agile

Abans d’entrar en la discussió sobre la participació d’un provador en aquestes pràctiques, primer intentem comprendre els conceptes que hi ha darrere d’aquests termes:

Què aprendreu:

Desenvolupament provat

Penseu en l'enfocament tradicional del desenvolupament de programari, on el codi s'escriu primer i després es prova. El desenvolupament basat en proves o TDD és un enfocament que és el REVERS exacte del desenvolupament tradicional. En aquest enfocament, primer es fan proves i després s’escriu el codi.

Confós? !!

Com podem provar un programari encara per desenvolupar?

Sí !! Això és un desenvolupament basat en proves o TDD.

TDD funciona en petits increments on:

  • La prova s’escriu primer
  • S'executa la prova, que fallarà (per motius obvis)
  • El codi està escrit (o refactoritzat) només per aprovar el cas de prova
  • La prova es torna a executar
  • Si la prova passa, passeu a la següent prova ELSE reescrivint / modifiqueu el codi per passar la prova

Permeteu-me provar d'explicar-ho mitjançant un diagrama de flux:

Diagrama de flux TDD

Ara hem d’entendre el fet que TDD no parla de les proves que fan els provadors. Més aviat, aquest enfocament parla de les proves que fan els programadors.

Sí !! Ho has endevinat bé !! És la prova unitària.

La prova que s’escriu primer no és la prova que escriuen els verificadors, sinó que és la prova unitària que escriuen els programadors. Per tant, reformularia els passos com:

  • Primer s’escriu la prova UNIT
  • S'executa la prova UNIT, que fallarà (per motius obvis)
  • El codi està escrit (o refactoritzat) només per aprovar la prova
  • Es torna a executar la prova UNIT
  • Si la prova passa, passeu a la següent prova ELSE reescrivint / modifiqueu el codi per passar la prova

Ara, la pregunta que sorgeix aquí és: si TDD és una feina de programador, quin és el paper del provador en aquest enfocament?

Bé, havent dit que TDD és una feina de programador, no vol dir que els provadors no hi estiguin implicats. Els verificadors poden col·laborar compartint els escenaris de prova que consisteixen en:

El que vull dir és que els provadors haurien de participar en la definició dels escenaris de prova unitària i col·laborar amb els programadors per implementar-los. Els verificadors han de proporcionar els seus comentaris sobre els resultats de la prova.

Si volem implementar TDD, els provadors han d’actualitzar els seus conjunts d’habilitats. Han de ser més tècnics i centrar-se en millorar les seves habilitats analítiques i lògiques.

Els provadors també han d’esforçar-se per comprendre l’argot tècnic que fan servir els programadors i, si és possible, han de tenir una visió oculta del codi. De manera similar, els programadors han de posar-se en la pell del provador i intentar arribar a escenaris més sofisticats que faran que la prova d’unitat sigui més robusta i sòlida.

Tant els programadors com els provadors han de posar-se en comú, a diferència de l’antic enfocament tradicional, on els programadors no donaven massa pes a les proves unitàries perquè confiaven en els provadors per trobar errors i defectes, i els provadors no volien lliurar-se. a aprendre coses tècniques perquè creuen que la seva feina acaba després de trobar els defectes.

Desenvolupament impulsat pel comportament

El desenvolupament impulsat pel comportament o BDD és una extensió del desenvolupament impulsat per proves.

BDD, com el seu nom indica, il·lustra els mètodes per desenvolupar una característica en funció del seu comportament. El comportament s’explica bàsicament en termes d’exemples en un llenguatge molt senzill que tots els membres de l’equip que són responsables del desenvolupament poden entendre.

Algunes de les característiques clau de BDD són les següents:

  • El llenguatge utilitzat per definir el comportament és molt senzill i en un format únic en el qual tothom pot entendre-les persones tècniques i no tècniques implicades en la implementació.
  • Ofereix una plataforma que permet als tres amics (programador, provador i PO / BA) col·laborar i entendre el requisit. Determina una plantilla comuna per documentar-la
  • Aquesta tècnica / enfocament discuteix el comportament final del sistema o com s’ha de comportar el sistema i NO parla de com s’ha de dissenyar o implementar el sistema
  • Destaca els dos aspectes de la qualitat:
    • Complir el requisit
    • Apte per al seu ús

Per què BDD?

Bé, sabem que solucionar un defecte / error en la fase posterior de qualsevol cicle de desenvolupament és bastant costós. La solució dels defectes de producció no només afecta el codi, sinó també el disseny i els seus requisits. Quan fem el RCA (Anàlisi de la causa arrel) de qualsevol defecte, la majoria de les vegades, arribem a la conclusió que el defecte es redueix a requisits mal entesos.

Això passa bàsicament perquè tothom té diferents aptituds per entendre els requisits. Per tant, les persones tècniques i no tècniques poden interpretar el mateix requisit de manera diferent, cosa que pot provocar un lliurament defectuós. Per tant, és fonamental que tothom de l’equip de desenvolupament entengui el mateix requisit i l’interpreti de la mateixa manera.

Hem d’assegurar-nos que tots els esforços de desenvolupament estiguin dirigits i enfocats a complir els requisits. Per evitar qualsevol tipus de defecte de 'requisit - falta', tot l'equip de desenvolupament ha d'alinear-los per entendre el requisit adequat per al seu ús.

L'enfocament BDD permet a l'equip de desenvolupament fer-ho mitjançant: -

  • Definició d'un enfocament estàndard per definir el requisit en anglès senzill
  • Subministrament d’exemples definitius que expliquin els requisits
  • Proporcionar una interfície / plataforma que permeti als tècnics (programadors / verificadors) i no tècnics (PO / BA / Client) col·laborar i reunir-se i estar a la mateixa pàgina per comprendre i implementar els requisits

Com implementar BDD?

Hi ha moltes eines disponibles al mercat per implementar BDD. En nomeno alguns aquí:

  • Cogombre
  • Aptitud
  • Concordió
  • J Comporta't
  • Flux espec

Exemple:

Intentem entendre BDD amb un exemple. Per al meu cas, estic fent servir cogombre (cogombre):

Penseu en un cas senzill en què volem permetre que només els usuaris autenticats puguin entrar al lloc XYZ.

El fitxer Gherkin (fitxer de funcions) seria el següent:

Característica: Portal de registre de proves

Esquema de l'escenari: Un usuari vàlid ha iniciat la sessió

Dada: El client obre el portal de registre

Quan: l'usuari introdueix el nom d'usuari com a '' i la contrasenya com a ''

Després: el client hauria de poder veure el formulari.

Exemples :

| usuari | contrasenya |

| usuari1 | pwd1 |

| usuari2 | pwd2 |

Podem veure com es documenta un requisit particular mitjançant un simple anglès. Els tres amics poden treballar junts per dissenyar els fitxers de funcions i es poden documentar dades de prova específiques a la secció d'exemple. BDD proporciona un mitjà per portar programadors, provadors i empreses a una sola taula i establir una comprensió comuna de les funcions a implementar.

L’enfocament BDD permet estalviar esforços, costos i comprovar si hi ha algun defecte després del desplegament de producció, ja que la col·laboració dels clients i dels desenvolupadors va ser durant tot el cicle de desenvolupament de la funció.

Els equips de desenvolupament poden utilitzar aquests fitxers de funcions i convertir-los en programes executables per provar una característica concreta.

Com?

Bé, per això cal aprendre Cogombre / Fitnesse !!

Desenvolupament impulsat per proves d’acceptació

El desenvolupament impulsat per proves d’acceptació o ATDD és una tècnica en què tot l’equip col·labora per definir els criteris d’acceptació d’una èpica / història abans que comenci la implementació. Aquestes proves d’acceptació es recolzen en exemples adequats i altra informació necessària.

La majoria de les vegades, BDD i ATDD s’utilitzen indistintament. L'enfocament ATDD també es pot implementar utilitzant el format Donat-Quan-Aleshores, de la mateixa manera que escrivim funcions en l'enfocament BDD.

Intentem resumir ràpidament les diferències entre els tres enfocaments:

  • TDD és més tècnic i està escrit en el mateix idioma en què s’implementa la funció. Si la funció està implementada a Java, escrivim JUnit casos de prova . Mentre que BDD i ATDD s’escriuen en un simple idioma anglès
  • L'enfocament TDD se centra en la implementació d'una característica. Mentre que BDD se centra en el comportament de la funció, i ATDD se centra en captar els requisits
  • Per implementar TDD hem de tenir coneixements tècnics. Mentre que BDD i ATDD no requereixen cap coneixement tècnic. La bellesa de BDD / ATDD rau en el fet que tant els tècnics com els no tècnics poden participar en el desenvolupament de la funció.
  • Atès que TDD ha evolucionat, proporciona un bon disseny i se centra en l'aspecte 'Requisits de reunió' de qualitat; mentre que BDD / ATDD se centra en el 2ndaspecte de qualitat que és 'apte per al seu ús'

Totes aquestes tècniques parlen bàsicament de l’enfocament “test-First”, a diferència de l’enfocament “test-last” utilitzat en les metodologies tradicionals de desenvolupament.

Com que les proves s’escriuen primer, els verificadors tenen un paper molt important. Els provadors no només han de tenir un ampli domini i coneixements empresarials, sinó que també han de tenir bones habilitats tècniques per poder afegir valor en la pluja d’idees durant els debats de 3 amics.

Amb conceptes com CI (Integration Continuous) i CD (Continuous Delivery), els provadors han de col·laborar bé amb els programadors i contribuir igualment a l'àrea de desenvolupament i operacions.

programari de punt de venda per a ipad

Permeteu-me resumir aquesta discussió amb la famosa Test Pyramid in Agile:

Prova la piràmide en Agile

La capa més baixa d’aquesta piràmide està formada per la capa de prova unitària. Aquesta capa és la capa fonamental; per tant, és imperial que aquesta capa sigui sòlida com la roca. La majoria de les proves s’han d’introduir en aquesta capa. Aquesta capa més baixa es centra només en TDD.

A la Àgil a tot el món, es posa èmfasi a fer que aquesta capa de la piràmide sigui més forta i robusta i es subratlla que la majoria de les proves s’aconsegueixen en aquesta capa.

Les eines que s’utilitzen en aquesta capa de piràmide són totes les eines de Xunit.

La capa mitjana de la piràmide és la capa de servei, que explica les proves de nivell de servei. Aquesta capa actua com a pont entre la interfície d'usuari de l'aplicació i la unitat / component de nivell inferior. Aquesta capa es compon principalment de les API que accepten les sol·licituds de la IU i envien la resposta. L’enfocament BDD i TTDD és actiu en aquesta capa de la piràmide.

Les eines que s’utilitzen a la capa mitjana de la piràmide són: Fitnesse, Cucumber i Robot Framework .

La capa més superior de la piràmide és la interfície d’usuari real, que mostra que aquesta capa hauria de contenir el menor nombre de proves, o hauria de dir que l’esforç de prova en aquesta capa en particular hauria de ser mínim. La majoria de les proves de la característica s’haurien d’haver completat quan arribem a la capa superior de la piràmide.

Les eines que s’utilitzen a la capa superior són: Seleni , QTP i RFT.

Ja que treballem en petits increments a Scrum (anomenat Sprints), la implementació manual de tots aquests enfocaments no és factible. Aquests enfocaments requereixen una intervenció automatitzada. L’automatització, en aquest cas, és molt crítica.

De fet, aquests enfocaments s’executen realment mitjançant l’automatització. Al final de cada sprint, s’afegeixen noves funcions, per la qual cosa és important que la característica implementada anteriorment funcioni com s’esperava; per tant, Automatització es converteix en l’HEROI aquí.

Conclusió

Al final de l'article, heu d'haver après sobre com participen els verificadors en les tècniques TDD, BDD i ATDD.

A la tercera part de la sèrie, centraré la meva discussió en l'automatització en un món àgil.

Sobre l'autor: Aquest article és de l'autor STH Shilpa. Ha estat treballant en el camp de proves de programari durant els darrers deu anys en dominis com ara publicitat a Internet, banca d’inversions i telecomunicacions.

Seguiu mirant aquest espai per obtenir moltes més actualitzacions.

Lectura recomanada

^