Quatre de cada cinc sol·licitants de control de qualitat volen aprendre a treballar amb proves automatitzades. No totes les empreses poden complir aquests desitjos de provadors manuals durant l'horari laboral. Wrike va organitzar una escola d'automatització per als empleats i es va adonar d'aquest desig per a molts. Vaig participar en aquesta escola precisament com a estudiant de QA.
Vaig aprendre a treballar amb Selenium i ara admet de manera independent un cert nombre d'autotests sense pràcticament cap ajuda externa. I, a partir dels resultats de la nostra experiència conjunta i de les meves conclusions personals, intentaré derivar la fórmula mateixa de l'escola d'automatització més ideal.
L'experiència de Wrike en l'organització d'una escola
Quan es va fer evident la necessitat d'una escola d'automatització, la seva organització va recaure en Stas Davydov, el responsable tècnic de l'automatització. Qui més que ell pot explicar per què es va plantejar aquesta iniciativa, si van aconseguir resultats i si es penedeixen del temps dedicat? Donem-li la paraula:
— L'any 2016 vam escriure un nou marc per a autotests i vam fer que es fes fàcil escriure proves: van aparèixer passos normals, l'estructura es va fer molt més entenedora. Ens va ocórrer una idea: hem d'implicar tothom que vulgui escriure noves proves i, per facilitar-ne la comprensió, hem creat una sèrie de conferències. Vam elaborar col·lectivament un pla de temes, cada un dels futurs professors en va agafar un i en va preparar un informe.
— Quines dificultats van tenir els alumnes?
— Principalment, és clar, arquitectura. Hi havia moltes preguntes sobre l'estructura de les nostres proves. En els comentaris, es va escriure molt sobre aquest tema i vam haver de fer conferències addicionals per explicar-ho amb més detall.
—L'escola va pagar?
- Sí, definitivament. Gràcies a ella, molta gent es va involucrar en la redacció de proves i, de mitjana, a l'hospital, tothom va començar a entendre millor què són les autotests, com s'escriuen i com es posen en marxa. La càrrega dels enginyers d'automatització també ha disminuït: ara rebem moltes vegades menys sol·licituds d'ajuda per analitzar proves, ja que els provadors i els desenvolupadors han començat a fer front a això ells mateixos en gairebé totes les situacions. Bé, hi ha diversos avantatges interns per al departament: hem adquirit experiència en presentacions i conferències, gràcies a la qual alguns enginyers d'automatització ja han aconseguit fer presentacions en conferències, i també han rebut un potent conjunt de vídeos i presentacions per a la incorporació de nouvinguts.
En nom propi, afegiré que la comunicació entre els nostres departaments s'ha simplificat a un nivell francament ridículament fàcil. Per exemple, ara pràcticament no em cal pensar en quins casos i a quin nivell d'atomicitat automatitzar. Com a resultat, totes les parts interessades s'estan cuidant completament de la cobertura de la prova, que està en constant creixement. Ningú exigeix l'impossible als altres.
En general, l'impacte en el treball dels equips és definitivament positiu. Potser els companys que llegeixen aquest article també estan pensant a fer alguna cosa semblant? Aleshores, el consell serà senzill: val la pena si les proves automatitzades són una prioritat per a vostè. A continuació, parlarem d'una qüestió més complexa: com organitzar tot això de la manera més correcta possible, de manera que els costos de totes les parts siguin mínims i la producció sigui màxima.
Consells d'organització
L'escola va ser útil, però, com va admetre Stas, hi va haver algunes dificultats, per les quals va ser necessari organitzar conferències addicionals. I va ser com a estudiant recent comparant-me amb mi mateix i en desconeixement, ara que vaig formular els passos següents per crear, al meu entendre, la manera ideal d'ensenyar als examinadors a entendre les proves automatitzades.
Pas 0. Creeu un diccionari
Per descomptat, aquest pas és necessari no només per al control de qualitat. Tanmateix, vull fer-ho explícit: la base de codi d'automatització s'ha de mantenir en una forma llegible. Llenguatges de programació, no menys important idiomes, i a partir d'aquí podeu començar la vostra immersió.
Aquí teniu una captura de pantalla d'una vista de tasques amb els noms dels elements. Imaginem que esteu provant la vista de tasques com una caixa negra i no heu vist mai Selenium a la vostra vida. Què fa aquest codi?
(Spoiler: la tasca s'elimina mitjançant rest en nom de l'administrador, i després veiem que hi ha un registre d'això al flux).
Només aquest pas apropa els idiomes QAA i QA. És més fàcil per als equips d'automatització explicar els resultats d'una execució; els provadors manuals han de dedicar menys esforç a crear casos: es poden fer menys detallats. Tot i així, tothom s'enten. Vam rebre els guanys fins i tot abans que comencés l'entrenament real.
Pas 1. Repetiu frases
Continuem el paral·lelisme amb la llengua. Quan aprenem a parlar de petits, no partim de l'etimologia i la semàntica. Repetim "mare", "comprar una joguina", però no entrem immediatament a les arrels protoindoeuropees d'aquestes paraules. Així és aquí: no té sentit endinsar-se en les profunditats de les característiques tècniques dels autotests sense intentar escriure alguna cosa que funcioni.
Sona una mica contraintuïtiu, però funciona.
A la primera lliçó, val la pena donar una base sobre com escriure autotests directament. Ajudem a configurar l'entorn de desenvolupament (en el meu cas, Intellij IDEA), expliquem les regles de llenguatge mínimes necessàries per escriure un altre mètode en una classe existent utilitzant els passos existents. Escrivim una o dues proves amb ells i els fem deures, que jo formaria així: una branca es va ramificar del màster, però se n'han eliminat diverses proves. Només queden les seves descripcions. Demanem als provadors que restauren aquestes proves (no a través de show diff, és clar).
Com a resultat, qui ho va escoltar i ho va fer tot serà capaç de:
- aprendre a treballar amb la interfície de l'entorn de desenvolupament: creació de branques, tecles d'accés directe, commits i pushs;
- dominar els conceptes bàsics de l'estructura del llenguatge i les classes: on inserir injeccions i on importar, per què calen anotacions i quin tipus de símbols s'hi troben, a més dels passos;
- entendre la diferència entre acció, esperar i comprovar, on utilitzar què;
- noteu la diferència entre les proves automàtiques i les comprovacions manuals: a les proves automàtiques podeu extreure un o un altre controlador en lloc de realitzar accions a través de la interfície. Per exemple, envieu un comentari directament al backend en lloc d'obrir una vista de tasques, seleccionar l'entrada, escriure text i fer clic al botó Envia;
- formular preguntes que es respondran en el següent pas.
L'últim punt és molt important. Aquestes respostes es poden donar fàcilment amb antelació, però és un principi pedagògic important que les respostes sense preguntes formulades no es recorden i no s'utilitzen quan finalment es necessiten.
Seria ideal que en aquest moment un enginyer d'automatització de l'equip de control de qualitat li assignés una tasca d'escriure un parell de proves en batalla i li permetés subcomprometre a la seva branca.
Què no donar:
- un coneixement més aprofundit de la funcionalitat de l'entorn de desenvolupament i del propi llenguatge de programació, que només serà necessari quan es treballa amb branques de manera independent. No es recordarà, ho hauràs d'explicar dues o tres vegades, però valorem el temps dels enginyers d'automatització, oi? Exemples: resoldre conflictes, afegir fitxers a git, crear classes des de zero, treballar amb dependències;
- tot el relacionat amb xpath. De debò. Cal parlar-ne per separat, una vegada i molt concentrat.
Pas 2. Donant un cop d'ull a la gramàtica
Recordem la captura de pantalla de la vista de tasques del pas #0. Tenim un pas anomenat checkCommentWithTextExists. El nostre verificador ja entén què fa aquest pas i podem mirar dins del pas i descompondre'l una mica.
I dins tenim el següent:
onCommentBlock(userName).comment(expectedText).should(displayed());On es troba onCommentBlock
onCommonStreamPanel().commentBlock(userName);Ara aprenem a dir no "comprar una joguina", sinó "comprar una joguina a la botiga Detsky Mir, situada a l'armari blau del tercer prestatge des de dalt". Cal explicar que apuntem a un element seqüencialment, a partir d'elements més grans (stream -> bloc amb comentaris d'una determinada persona -> aquella part d'aquest bloc on es troba el text especificat).
No, encara no és hora de parlar d'xpath. Només esmenta breument que totes aquestes instruccions són descrites per ells i l'herència passa per elles. Però hem de parlar de tots aquests equips i cambrers, que es relacionen específicament amb aquest pas i són necessaris per entendre què està passant. Però no sobrecarregueu: el vostre alumne pot estudiar afirmacions més complexes pel seu compte més tard. Molt probablement, hauria, waitUntil, mostrat();, exist();, not(); hauria de ser suficient.
La tasca és evident: una branca en la qual s'han eliminat el contingut de diversos passos necessaris per a un nombre determinat de proves. Deixeu que els provadors els restauren i feu que la carrera torni a ser verda.
A més, si l'equip de proves no només té noves funcions en el seu treball, sinó també algunes correccions d'errors, podeu demanar-li que escrigui immediatament proves per a aquests errors i els alliberi. El més probable és que ja s'hagin descrit tots els elements; només poden faltar un parell de passos. Aquest serà l'entrenament perfecte.
Pas 3. Immersió total
El més complet possible per a un provador que continuarà fent les seves funcions directes. Finalment, hem de parlar d'xpath.
Primer, deixem clar que tots aquests comentaris i blocs de comentaris els descriuen.
Total:
"//div[contains(@class, ‘stream-panel’)]//a[contains(@class,'author') and text()='{{ userName }}’]//div[contains(@class,'change-wrapper') and contains(.,'{{ text }}’)]"L'ordre de la història és molt important. Primer, prenem qualsevol xpath existent i mostrem com la pestanya elements conté un i només un element. A continuació, parlarem de l'estructura: quan necessiteu utilitzar WebElement i quan necessiteu crear un fitxer separat per a un element nou. Això us permetrà entendre millor l'herència.
S'ha d'indicar explícitament que un únic element és tota la vista de tasques, conté un element fill: el flux complet, que conté un element fill, un comentari separat, etc. Els elements secundaris es troben dins dels elements primaris tant a la pàgina com a l'estructura del marc de prova automàtica.
En aquest punt, l'audiència hauria d'haver entès fermament com s'hereten i què es pot introduir després del punt a onCommentBlock. En aquest punt, expliquem tots els operadors: /, //, ., [] i així successivament. Afegim coneixements sobre l'ús a la càrrega @class i altres coses necessàries.
Els estudiants haurien d'entendre com traduir xpath d'aquesta manera. Per consolidar, això és, deures. Suprimim les descripcions dels elements, deixem que recuperin el treball de les proves.
Per què aquest camí en concret?
No hem de sobrecarregar una persona amb coneixements complexos, però hem d'explicar-ho tot alhora, i aquest és un dilema difícil. Aquest camí ens permetrà fer primer que els oients facin preguntes i no entenguin alguna cosa i les responguin l'instant següent. Si parleu de tota l'arquitectura, quan s'analitzi el tema dels passos o xpath, les parts més importants ja s'oblidaran a causa de la seva incomprensibilitat.
Tanmateix, probablement alguns de vosaltres podreu compartir la vostra experiència sobre com es pot optimitzar encara més el procés. Estaré encantat de llegir suggeriments similars als comentaris!
Font: www.habr.com