Vier op de vijf QA-aanvragers willen leren werken met geautomatiseerde tests. Niet alle bedrijven kunnen aan dergelijke wensen van handmatige testers tijdens werkuren voldoen. Wrike hield een automatiseringsschool voor medewerkers en realiseerde deze wens voor velen. Ik heb precies als QA-student op deze school deelgenomen.
Ik heb geleerd hoe ik met Selenium moet werken en ondersteun nu zelfstandig een bepaald aantal autotests, vrijwel zonder hulp van buitenaf. En op basis van de resultaten van onze gezamenlijke ervaring en mijn persoonlijke conclusies zal ik proberen de formule voor de meest ideale automatiseringsschool af te leiden.
Wrike's ervaring met het organiseren van een school
Toen de behoefte aan een automatiseringsschool duidelijk werd, viel de organisatie ervan in handen van Stas Davydov, de technische leider van de automatisering. Wie anders dan hij kan uitleggen waarom ze met dit initiatief zijn gekomen, of ze resultaten hebben geboekt en of ze spijt hebben van de tijdsbesteding? Laten we hem het woord geven:
— In 2016 hebben we een nieuw raamwerk voor autotests geschreven en het zo gemaakt dat het schrijven van tests gemakkelijk werd: er verschenen normale stappen, de structuur werd veel begrijpelijker. We kwamen met een idee: we moeten iedereen erbij betrekken die nieuwe tests wil schrijven, en om het begrijpelijker te maken, hebben we een serie lezingen gemaakt. We hebben gezamenlijk een onderwerpsplan opgesteld, elk van de toekomstige docenten heeft er een voor zichzelf genomen en er een rapport over gemaakt.
— Welke moeilijkheden hadden de studenten?
— Voornamelijk natuurlijk architectuur. Er waren veel vragen over de opzet van onze tests. Als feedback is er veel over dit onderwerp geschreven en moesten we aanvullende lezingen houden om het in meer detail uit te leggen.
— Heeft de school zijn vruchten afgeworpen?
- Ja absoluut. Dankzij haar waren veel mensen betrokken bij het schrijven van tests, en gemiddeld begon iedereen in het ziekenhuis beter te begrijpen wat autotests zijn, hoe ze worden geschreven en hoe ze worden gelanceerd. Ook de belasting van automatiseringsingenieurs is afgenomen: we krijgen nu vele malen minder hulpvragen bij het analyseren van tests, omdat testers en ontwikkelaars hier in vrijwel alle situaties zelf mee aan de slag zijn gegaan. Welnu, er zijn verschillende interne voordelen voor de afdeling: we hebben ervaring opgedaan met presentaties en lezingen, waardoor sommige automatiseringsingenieurs al presentaties hebben kunnen geven op conferenties, en ook een krachtige reeks video's en presentaties hebben ontvangen voor het onboarden van nieuwkomers.
Namens mijzelf wil ik hieraan toevoegen dat de communicatie tussen onze afdelingen is vereenvoudigd tot een ronduit belachelijk eenvoudig niveau. Nu hoef ik bijvoorbeeld praktisch niet meer na te denken over welke gevallen en op welk atomiciteitsniveau ik moet automatiseren. Als gevolg hiervan dragen alle geïnteresseerde partijen de volledige zorg voor de testdekking, die voortdurend groeit. Niemand eist het onmogelijke van anderen.
Over het algemeen is de impact op het werk van teams zeker positief. Misschien denken collega's die dit artikel lezen er ook over om iets soortgelijks te doen? Dan is het advies simpel: het is de moeite waard als geautomatiseerde tests voor u prioriteit hebben. Vervolgens gaan we het hebben over een complexere vraag: hoe organiseer je dit allemaal zo goed mogelijk, zodat de kosten voor alle partijen minimaal zijn en de output maximaal.
Tips voor het organiseren
De school was nuttig, maar, zoals Stas toegaf, waren er enkele problemen, waardoor het nodig was om extra lezingen te regelen. En het was als een recente student die mezelf – in onwetendheid en mezelf – nu vergeleek, dat ik de volgende stappen formuleerde om, naar mijn mening, de ideale manier te creëren om testers te leren geautomatiseerde tests te begrijpen.
Stap 0. Maak een woordenboek
Uiteraard is deze stap niet alleen nodig voor QA. Ik wil het echter expliciet maken: de automatiseringscodebase moet in een leesbare vorm worden bewaard. Programmeertalen - niet in de laatste plaats talen, en vanaf hier kunt u uw duik beginnen.
Hier is een screenshot van een taakweergave met de namen van de elementen. Stel je voor dat je TaskView test als een zwarte doos en Selenium nog nooit in je leven hebt gezien. Wat doet deze code?
(Spoiler - de taak wordt verwijderd via rest namens de beheerder, en dan zien we dat er een record hiervan in de stream staat.)
Deze stap alleen al brengt de QAA- en QA-talen dichter bij elkaar. Het is voor automatiseringsteams gemakkelijker om de resultaten van een run uit te leggen; handmatige testers hoeven minder moeite te besteden aan het maken van cases: ze kunnen minder gedetailleerd worden gemaakt. Toch begrijpt iedereen elkaar. We ontvingen de winst nog voordat de daadwerkelijke training begon.
Stap 1. Herhaal zinnen
Laten we de parallel met taal voortzetten. Als we als kinderen leren spreken, gaan we niet uit van etymologie en semantiek. We herhalen ‘mama’, ‘koop speelgoed’, maar gaan niet meteen in op de Proto-Indo-Europese wortels van deze woorden. Dus het is hier: het heeft geen zin om in de diepte van de technische kenmerken van autotests te duiken zonder te proberen iets te schrijven dat werkt.
Het klinkt een beetje contra-intuïtief, maar het werkt.
In de eerste les is het de moeite waard om een basis te geven voor het direct schrijven van autotests. We helpen bij het opzetten van de ontwikkelomgeving (in mijn geval Intellij IDEA), leggen de minimale taalregels uit die nodig zijn om een andere methode in een bestaande klasse te schrijven met behulp van de bestaande stappen. We schrijven een of twee tests met hen en geven ze huiswerk, dat ik als volgt zou formatteren: een tak die zich aftakt van de master, maar er zijn verschillende tests uit verwijderd. Alleen hun beschrijvingen blijven over. We vragen testers om deze tests te herstellen (uiteraard niet via show diff).
Als gevolg hiervan kan degene die luisterde en alles deed:
- leren werken met de ontwikkelomgevingsinterface: vertakkingen, sneltoetsen, commits en pushes maken;
- beheers de basisprincipes van de structuur van de taal en klassen: waar injecties moeten worden ingevoegd en waar moeten worden geïmporteerd, waarom annotaties nodig zijn en wat voor soort symbolen daar worden gevonden, naast de stappen;
- begrijp het verschil tussen actie, wachten en controleren, waar je wat moet gebruiken;
- merk het verschil op tussen autotests en handmatige controles: bij autotests kun je een of andere handler ophalen in plaats van acties via de interface uit te voeren. Stuur bijvoorbeeld een opmerking rechtstreeks naar de backend in plaats van een taakweergave te openen, de invoer te selecteren, tekst te typen en op de knop Verzenden te klikken;
- Formuleer vragen die in de volgende stap beantwoord zullen worden.
Het laatste punt is heel belangrijk. Deze antwoorden kunnen gemakkelijk van tevoren worden gegeven, maar het is een belangrijk leerprincipe dat antwoorden zonder geformuleerde vragen niet worden onthouden en niet worden gebruikt wanneer ze uiteindelijk nodig zijn.
Het zou ideaal zijn als een automatiseringsingenieur van het QA-team hem op dit moment de taak zou geven om een paar tests in de strijd te schrijven en hem toe te staan zich aan zijn afdeling te binden.
Wat je niet moet geven:
- meer diepgaande kennis van de functionaliteit van de ontwikkelomgeving en de programmeertaal zelf, die alleen nodig zal zijn bij het zelfstandig werken met vestigingen. Het zal niet onthouden worden, je zult het twee of drie keer moeten uitleggen, maar we waarderen de tijd van automatiseringsingenieurs, toch? Voorbeelden: conflicten oplossen, bestanden toevoegen aan git, klassen helemaal opnieuw maken, werken met afhankelijkheden;
- alles wat met xpath te maken heeft. Ernstig. Je moet er afzonderlijk, een keer en heel geconcentreerd over praten.
Stap 2. De grammatica nader bekijken
Laten we de taakweergave-screenshot uit stap #0 onthouden. We hebben een stap genaamd checkCommentWithTextExists. Onze tester begrijpt al wat deze stap doet en we kunnen in de stap kijken en deze een beetje ontleden.
En binnen hebben we het volgende:
onCommentBlock(userName).comment(expectedText).should(displayed());Waar onCommentBlock is
onCommonStreamPanel().commentBlock(userName);Nu leren we niet te zeggen ‘koop speelgoed’, maar ‘koop speelgoed in de Detsky Mir-winkel, gelegen in de blauwe kast op de derde plank van boven’. Het is noodzakelijk om uit te leggen dat we opeenvolgend naar een element verwijzen, vanuit grotere elementen (stream -> blok met commentaar van een bepaalde persoon -> dat deel van dit blok waar de opgegeven tekst staat).
Nee, het is nog steeds geen tijd om over xpath te praten. Vermeld gewoon kort dat al deze instructies door hen worden beschreven en dat de erfenis via hen verloopt. Maar we moeten over al deze matchers en obers praten; ze hebben specifiek betrekking op deze stap en zijn noodzakelijk om te begrijpen wat er gebeurt. Maar overbelast niet: uw leerling kan later zelf complexere beweringen bestuderen. Hoogstwaarschijnlijk zou waitUntil, display();, exist();, not(); moeten volstaan.
Het huiswerk ligt voor de hand: een vertakking waarin de inhoud van verschillende stappen die nodig zijn voor een bepaald aantal toetsen is verwijderd. Laat de testers ze herstellen en de run weer groen maken.
Bovendien, als het testteam niet alleen nieuwe functies in zijn werk heeft, maar ook enkele bugfixes, kunt u hem vragen onmiddellijk tests voor deze bugs te schrijven en deze vrij te geven. Hoogstwaarschijnlijk zijn alle elementen al beschreven; het kan zijn dat er slechts een paar stappen ontbreken. Dit wordt de perfecte training.
Stap 3. Volledige onderdompeling
Zo compleet mogelijk voor een tester die zijn directe taken blijft uitvoeren. Ten slotte moeten we het hebben over xpath.
Laten we eerst duidelijk maken dat al deze onCommentBlock en commentaar door hen worden beschreven.
Totaal:
"//div[contains(@class, ‘stream-panel’)]//a[contains(@class,'author') and text()='{{ userName }}’]//div[contains(@class,'change-wrapper') and contains(.,'{{ text }}’)]"De volgorde van het verhaal is erg belangrijk. Eerst nemen we elk bestaand xpath en laten we zien hoe het tabblad Elementen slechts één element bevat. Vervolgens zullen we het hebben over de structuur: wanneer u WebElement moet gebruiken en wanneer u een apart bestand voor een nieuw element moet maken. Hierdoor kunt u de erfenis beter begrijpen.
Er moet expliciet worden vermeld dat een enkel element de gehele taakweergave is, het bevat een onderliggend element - de hele stream, die een onderliggend element bevat - een afzonderlijk commentaar, enz. Onderliggende elementen bevinden zich binnen bovenliggende elementen, zowel op de pagina als in de structuur van het autotestframework.
Op dit punt zou het publiek goed moeten begrijpen hoe ze worden geërfd en wat er kan worden ingevoerd na de punt bij onCommentBlock. Op dit punt leggen we alle operatoren uit: /, //, ., [] enzovoort. Wij voegen kennis over gebruik toe aan de lading @class en andere noodzakelijke dingen.
Studenten moeten begrijpen hoe ze xpath op deze manier kunnen vertalen. Om te consolideren - dat klopt, huiswerk. We verwijderen de beschrijvingen van de elementen en laten ze het werk van de tests herstellen.
Waarom dit specifieke pad?
We moeten iemand niet overladen met complexe kennis, maar we moeten alles in één keer uitleggen, en dit is een moeilijk dilemma. Dit pad stelt ons in staat om luisteraars eerst vragen te laten stellen en iets niet te begrijpen, en ze het volgende moment te laten beantwoorden. Als je het over de hele architectuur hebt, zullen tegen de tijd dat het onderwerp stappen of xpath wordt geanalyseerd, de belangrijkste delen ervan al vergeten zijn vanwege hun onbegrijpelijkheid.
Sommigen van u zullen echter waarschijnlijk uw ervaringen kunnen delen over hoe het proces nog verder kan worden geoptimaliseerd. Ik lees graag soortgelijke suggesties in de reacties!
Bron: www.habr.com