Hé Habr!
We hebben een nieuw belangrijk onderwerp: hoogwaardige ontwikkeling van IT-producten. Bij HighLoad++ praten we vaak over hoe we drukke services snel kunnen maken, en bij Frontend Conf praten we over een coole gebruikersinterface die niet vertraagt. We hebben regelmatig onderwerpen over testen, en DevOpsConf over het combineren van verschillende processen, waaronder testen. Maar over wat kwaliteit in het algemeen kan worden genoemd, en hoe je daar integraal aan kunt werken - nee.
Laten we dit oplossen door — we zullen een cultuur ontwikkelen waarin we in elke ontwikkelingsfase nadenken over de kwaliteit van het eindproduct voor de gebruiker. De gewoonte om je niet te concentreren op je verantwoordelijkheidsgebied en kwaliteit niet alleen te associëren met testers.
Onder de cut gaan we praten met het hoofd van de programmacommissie, hoofd testen bij Tinkoff.Business, maker van de Russischtalige QA-gemeenschap Anastasia Aseeva-Nguyen over de toestand van de QA-industrie en de missie van de nieuwe conferentie.
- Nastia hallo. Vertelt u ons alstublieft wat over uzelf.
Anastasia: Ik beheer de tests bij een bank, ik ben verantwoordelijk voor een heel groot team - we zijn met meer dan 90 mensen. Wij hebben een belangrijke business line; wij zijn verantwoordelijk voor het ecosysteem voor rechtspersonen.
Ik heb mechanica en wiskunde gestudeerd en wilde aanvankelijk programmeur worden. Maar toen ik een interessant aanbod kreeg, besloot ik mezelf als tester uit te proberen. Vreemd genoeg bleek dit mijn roeping te zijn. Nu zie ik al mijn werk in deze branche.
Ik ben een fervent aanhanger van de discipline Kwaliteitszorg. Het maakt mij niet uit welke producten worden gemaakt, hoe met kwaliteit wordt omgegaan in het bedrijf, in het team en, in principe, in het ontwikkelingsproces.
Dat is mij duidelijk de gemeenschap in deze richting is niet volwassen genoeg, althans in Rusland. Wij begrijpen niet altijd dat kwaliteitsborging niet alleen het testen van een applicatie op het voldoen aan eisen is. Ik wil deze situatie graag veranderen.
— Je gebruikt de woorden Kwaliteitsborging en testen. In de ogen van de gemiddelde persoon overlappen deze twee termen elkaar vaak. Hoe verschillen ze als je diep graaft?
Anastasia: Integendeel, ze zijn niet anders. Testen maakt deel uit van de discipline Kwaliteitsborging; het is een directe activiteit: het feit dat ik iets test. Er zijn eigenlijk veel soorten tests en er zijn verschillende mensen verantwoordelijk voor verschillende soorten tests. Maar toen hier in Rusland een golf van uitbesteders verscheen die testers aan bedrijven leverden, werd het testen teruggebracht tot één type.
In de meeste gevallen beperken ze zich alleen tot functioneel testen: ze controleren of wat de ontwikkelaars hebben gecodeerd, voldoet aan de specificatie en dat is alles.
— Kunt u ons vertellen welke andere disciplines voor kwaliteitsborging er zijn? Wat valt hier nog meer onder, behalve testen?
Anastasia: Kwaliteitsborging gaat in de eerste plaats over het creëren van een kwaliteitsproduct. Dat wil zeggen, we vragen ons af welke kwaliteitskenmerken ons product zou moeten hebben. Als we dit begrijpen, kunnen we dus vergelijken wie deze kwaliteitskenmerken beïnvloedt. Maakt niet uit, ontwikkelaar, projectmanager of productspecialist is een persoon die invloed heeft op de ontwikkeling van een product, de backlog en de strategie ervan.
De tester wordt zich meer bewust van zijn rol. Hij begrijpt dat het zijn taak niet alleen is om te testen of aan de eisen wordt voldaan, maar ook om eisen te testen, de formuleringen van de productspecialist in twijfel te trekken en alle impliciete eisen en verwachtingen van de klant bloot te leggen. Wanneer we nieuwe functionaliteit aan onze klant leveren, moeten we echt aan hun verwachtingen voldoen en hun pijn oplossen. Als we nadenken over alle kenmerken van kwaliteit, zal de klant tevreden zijn en begrijpen dat het bedrijf wiens product hij gebruikt echt om zijn belangen geeft, en niet werkt volgens het principe van ‘gewoon een functie vrijgeven’.
— Het lijkt erop dat wat je zojuist hebt beschreven de taak is van een productspecialist. Dit gaat in principe niet over testen en niet over kwaliteit. Het gaat over het algemeen over productbeheer, nietwaar?
Anastasia: Inbegrepen. Kwaliteitszorg is geen discipline waarvoor één specifieke persoon verantwoordelijk is. Nu is er een populaire richting in het testen, een zogenaamde aanpak Agile testen. Zijn definitie stelt duidelijk dat dit een teambenadering van testen is, die een bepaalde reeks praktijken omvat. Het hele team is verantwoordelijk voor het implementeren van deze aanpak; het is niet eens nodig dat er een tester in het team zit. Het hele team is gefocust op het leveren van waarde aan de klant en het garanderen dat de waarde voldoet aan de verwachtingen van de klant.
— Het blijkt dat kwaliteit bijna alle omringende disciplines doorkruist en een kader oplegt aan alles eromheen?
Anastasia: Rechts. Wanneer we nadenken over hoe we een kwaliteitsproduct willen creëren, beginnen we na te denken over de verschillende kenmerken van kwaliteit. Hoe je bijvoorbeeld kunt controleren of we echt de functionaliteit hebben gemaakt die onze klant nodig heeft.
Dit is waar dit soort testen van pas komt: UAT (gebruikersacceptatietesten). Helaas wordt het in Rusland zelden toegepast, maar is het soms aanwezig in SCRUM-teams als demo voor de eindklant. Dit is een vrij veel voorkomende vorm van testen bij buitenlandse bedrijven. Voordat we de functionaliteit voor alle klanten openstellen, doen we eerst UAT, dat wil zeggen dat we de eindgebruiker uitnodigen die test en onmiddellijk feedback geeft - of het product echt aan de verwachtingen voldoet en de pijn oplost. Pas daarna vindt opschaling naar alle andere clients plaats.
Dat wil zeggen: wij richten ons op de business, op de eindklant, maar tegelijkertijd vergeet de technologie niet. De kwaliteit van het product is ook sterk afhankelijk van de technologie. Als we een slechte architectuur hebben, kunnen we niet snel functies vrijgeven en aan de verwachtingen van de klant voldoen. Er kunnen veel bugs voorkomen bij het opschalen, of bij het refactoren kunnen we iets kapot maken. Dit alles heeft invloed op de klanttevredenheid.
Vanuit dit oogpunt zou de architectuur zodanig moeten zijn dat we schone code kunnen schrijven waarmee we snel wijzigingen kunnen doorvoeren en niet bang hoeven te zijn dat we alles kapot maken. Zodat revisie-iteraties zich niet over meerdere maanden uitstrekken, simpelweg omdat we zoveel erfenis hebben en we lange testfasen moeten doorlopen.
— In totaal zijn ontwikkelaars, architecten, productwetenschappers, productmanagers en testers zelf al betrokken. Wie zijn er nog meer betrokken bij het kwaliteitsborgingsproces?
Anastasia: Laten we ons nu voorstellen dat we de functie al aan de klant hebben geleverd. Uiteraard moet de kwaliteit van het product bewaakt worden, zelfs als het al in productie is. In dit stadium kunnen zich situaties voordoen met niet voor de hand liggende scenario's, zogenaamde bugs.
De eerste vraag is: hoe gaan we om met deze bugs nadat we het product al hebben uitgebracht? Hoe reageren wij bijvoorbeeld op stress? De klant zal niet erg blij zijn als het laden van de pagina meer dan 30 seconden duurt.
Dit is waar uitbuiting in het spel komt of, zoals ze het nu noemen, DevOps. In feite zijn dit de mensen die verantwoordelijk zijn voor de bediening van het product terwijl het al in productie is. Hieronder vallen verschillende vormen van monitoring. Er is zelfs een subtype van testen: testen op productie, waarbij we onszelf toestaan iets niet te testen voordat het wordt uitgerold, maar het onmiddellijk in productie testen. Dit is een reeks maatregelen vanuit het oogpunt van het organiseren van infrastructuur waarmee u snel op een incident kunt reageren, er invloed op kunt uitoefenen en het kunt corrigeren.
Infrastructuur is ook belangrijk. Er zijn vaak situaties waarin het tijdens een test onmogelijk is om er zeker van te zijn dat we echt alles hebben wat we de klant willen geven. We rollen het uit in productie en beginnen niet voor de hand liggende situaties op te vangen. En dat allemaal omdat de infrastructuur in de test niet overeenkomt met de infrastructuur in productie. Dit leidt tot een nieuw soort testen: testen van de infrastructuur. Dit zijn verschillende configuraties, instellingen, databasemigratie, etc.
Dit roept de vraag op: misschien moet het team infrastructuur als code gebruiken.
Ik geloof dat infrastructuur rechtstreeks invloed heeft op de kwaliteit van het product.
Ik hoop dat er op de conferentie een rapport komt met een echte casus. Schrijf ons als u bereid bent ons uit eigen ervaring te vertellen hoe infrastructuur als code de kwaliteit beïnvloedt. Infrastructuur als code maakt het eenvoudiger om alle instellingen te controleren en dingen te testen die anders simpelweg niet mogelijk zijn. Daarom is de bediening ook betrokken bij het ontwikkelen van een kwaliteitsproduct.
— Hoe zit het met analyses en documentatie?
Anastasia: Dit geldt meer voor bedrijfssystemen. Als we het over ondernemen hebben, denken we onmiddellijk aan mensen als analisten en systeemanalisten. Ze worden soms technische schrijvers genoemd. Zij krijgen de opdracht om een specificatie te schrijven en deze bijvoorbeeld een maand lang uit te voeren.
Het is herhaaldelijk bewezen dat het schrijven van dergelijke documentatie leidt tot zeer lange ontwikkelingsiteraties en lange iteraties van verfijning, omdat tijdens het testproces bugs worden geïdentificeerd en de resultaten beginnen. Als gevolg hiervan zijn er veel lussen die de ontwikkelingskosten verhogen. Bovendien kan dit kwetsbaarheden met zich meebrengen. Het lijkt erop dat we referentiecode hebben geschreven, maar daarna hebben we wijzigingen aangebracht die de perfect doordachte architectuur doorbreken.
Het eindresultaat is een niet geheel kwalitatief hoogstaand product, omdat er al patches in de architectuur zijn verschenen, de code op sommige plaatsen niet voldoende wordt afgedekt door tests, omdat deadlines bijna op zijn, alle bugs snel moeten worden gedicht. En dat allemaal omdat in de oorspronkelijke specificatie geen rekening werd gehouden met alle punten die moesten worden geïmplementeerd.
Ontwikkelaars zijn geen plagen en schrijven niet met opzet code met fouten.
Als we in eerste instantie een specificatie hadden uitgedacht waarin alle noodzakelijke punten waren opgenomen, dan was alles precies zo uitgevoerd als nodig. Maar dit is een utopie.
Het is waarschijnlijk onmogelijk om een perfecte specificatie van 100 pagina's te schrijven. Daarom moeten nadenken over alternatieve manieren om documentatie te schrijven, specificaties, taken instellen die ons dichter bij de zekerheid brengen dat de ontwikkelaar precies doet wat nodig is.
Hier denk ik aan benaderingen van Agile: gebruikersverhalen met acceptatiecriteria. Dit is meer van toepassing op teams die zich in kleine iteraties ontwikkelen.
— Hoe zit het met bruikbaarheidstesten, productbruikbaarheid, ontwerp?
Anastasia: Dit is een heel belangrijk punt, omdat er ontwerpers in het team zitten. Meestal worden ontwerpers als dienst gebruikt, hetzij door een ontwerpafdeling, hetzij door een externe ontwerper. Er zijn vaak situaties waarin het lijkt alsof de ontwerper naar de productspecialist heeft geluisterd en heeft gedaan wat hij begreep. Maar als we met de iteratie beginnen, blijkt dat wat er feitelijk werd gedaan niet was wat er werd verwacht: de ontwerper vergat iets, dacht niet goed over het gedrag na, omdat hij niet in het team zit en niet in de context, of aan de voorkant -end-ontwikkelaar begreep de lay-out niet volledig. Er kunnen meerdere iteraties nodig zijn, alleen maar omdat er een probleem is met het begrijpen van het ontwerp door de front-end-ontwikkelaar.
Bovendien is er nog een probleem. Ontwerpsystemen winnen nu aan populariteit. Ze zijn een hype, maar de voordelen ervan zijn niet helemaal duidelijk.
Ik kom de mening tegen dat ontwerpsystemen enerzijds de ontwikkeling vereenvoudigen, maar anderzijds veel beperkingen opleggen aan de interface.
Hierdoor maken we niet de feature die de klant wil, maar degene die voor ons handig is, omdat we al bepaalde kubussen hebben waaruit we deze kunnen maken.
Ik denk dat dit een onderwerp is dat de moeite waard is om naar te kijken en me af te vragen of we, door het ontwerp eenvoudiger te maken, daadwerkelijk een pijnpunt van de klant oplossen.
— Er is een verrassend aantal onderwerpen gerelateerd aan kwaliteitsborging. Bestaat er een conferentie in Rusland waar ze allemaal kunnen worden besproken?
Anastasia: Er is de oudste testconferentie, die dit jaar voor de 25e keer wordt gehouden en de SQA Days Quality Assurance Conference heet. Het bespreekt vooral tools en specifieke testbenaderingen voor functionele testers. In de regel gaan de rapporten op SQA Days dieper in op specifieke gebieden op het gebied van de verantwoordelijkheid van de testers zelf, maar niet op complexe activiteiten.
Dit helpt veel bij het begrijpen van verschillende tools en benaderingen, het testen van databases, API’s, enz. Maar tegelijkertijd motiveert het enerzijds niet om meer dan alleen testen te betrekken bij het creëren van een beter product. Aan de andere kant raken testers niet meer betrokken bij het proces om na te denken over het mondiale doel van het product en de zakelijke component ervan.
Ik leid een grote afdeling en voer veel interviews af die echt inzicht geven in de toestand van de sector als geheel. In de regel werken onze jongens in ondernemingen en hebben ze een duidelijk verantwoordelijkheidsgebied. Collega's die in buitenlandse projecten werken, gebruiken verschillende soorten tests: ze kunnen zelf belastingtests, prestatietests en soms zelfs beveiligingstests doen, omdat ze het team echt helpen de kwaliteit van het product te waarborgen.
Ik zou graag willen dat de jongens in Rusland ook gaan denken dat de industrie niet ophoudt met functioneel testen.
— Hiervoor organiseren we een nieuwe conferentie, QualityConf, die gewijd is aan kwaliteit als integrale discipline. Vertel ons meer over het idee, wat is het hoofddoel van de conferentie?
Anastasia: We willen een gemeenschap creëren van mensen die geïnteresseerd zijn in het maken van kwaliteitsproducten. Bied een platform waar ze kunnen komen, naar rapporten kunnen luisteren en na de conferentie kunnen vertrekken met een specifiek inzicht in wat er moet veranderen om de kwaliteit te verbeteren.
Tegenwoordig hoor ik vaak de vraag van consultancy wat te doen als er problemen zijn met testen en kwaliteit. Wanneer je met teams gaat communiceren, zie je dat het probleem niet bij de testers zelf ligt, maar bij de manier waarop het proces is ingericht. Wanneer ontwikkelaars bijvoorbeeld denken dat zij alleen verantwoordelijk zijn voor het schrijven van code, eindigt hun verantwoordelijkheid precies op het moment dat zij de taak aan het testen overdragen.
Niet iedereen denkt erover na dat slecht geschreven code van lage kwaliteit met een slechte architectuur grote problemen voor het project bedreigt. Ze denken niet aan de kosten van fouten, dat bugs die in de productie terechtkomen, tot grote kosten voor het bedrijf en het team kunnen leiden. Er is geen cultuur om hierover na te denken. Ik wil dat we het op de conferentie gaan verspreiden.
Ik begrijp dat dit geen innovatie is. Edward Deming, de auteur van de 14 kwaliteitsprincipes, schreef in de vorige eeuw over de kosten van een fout. Kwaliteitsborging als discipline is op dit boek gebaseerd, maar helaas vergeet de moderne ontwikkeling dit.
— Bent u van plan onderwerpen over testen en tools rechtstreeks aan te snijden?
Anastasia: Ik geef toe dat er berichten over tools zullen zijn. Er zijn vrij universele tools waarmee bedrijven en teams het product kunnen beïnvloeden.
Alle rapporten zullen wereldwijd verenigd zijn door één gemeenschappelijke missie: aan het publiek overbrengen dat we met behulp van deze aanpak, tool, methode, proces en type testen de kwaliteit van het product hebben beïnvloed en de levensduur van de klant hebben verbeterd.
We zullen zeker geen rapporten hebben over een tool omwille van een tool. Alle rapporten in het programma zullen verenigd zijn door een gemeenschappelijk doel.
— Wie zal geïnteresseerd zijn in waar u het over heeft, wie ziet u als gasten van de conferentie?
Anastasia: We zullen rapporten hebben voor ontwikkelaars die zich bekommeren om het lot van hun project, product of systeem. Op dezelfde manier zal het interessant zijn voor testers en, naar mijn mening, vooral voor managers. Met managers bedoel ik mensen die beslissingen nemen en ook het lot en de ontwikkeling van een product, systeem en team kunnen beïnvloeden.
Dit zijn mensen die zich afvragen hoe ze de kwaliteit van een product of systeem kunnen verbeteren. Op onze conferentie zullen ze verschillende soorten maatregelen leren kennen en zullen ze begrijpen wat er nu mis mee is en wat er veranderd moet worden.
Ik denk dat het belangrijkste criterium is om te begrijpen dat er iets mis is met de kwaliteit en daar invloed op te willen uitoefenen. Mensen die denken dat dit alleen de eerste keer zal lukken, zullen we waarschijnlijk niet kunnen bereiken.
— Denkt u dat de industrie als geheel rijp is om niet alleen over testen te praten, maar ook over een cultuur van kwaliteit?
Anastasia: Ik denk dat ik volwassener ben geworden. Nu stappen veel bedrijven af van de traditionele watervalbenadering naar Agile. Er is sprake van klantgerichtheid, mensen in teams beginnen echt na te denken over hoe ze een kwaliteitsproduct kunnen maken. Zelfs grote bedrijven richten zich opnieuw op het verbeteren van de kwaliteit.
Afgaande op het aantal verzoeken dat binnen de gemeenschap binnenkomt, geloof ik dat het tijd is. Ik ben er natuurlijk niet zeker van dat dit een grootschalige revolutie zal zijn, maar ik zou graag willen dat deze revolutie in het bewustzijn plaatsvindt.
- Overeengekomen! We zullen cultuur inbrengen en het bewustzijn veranderen.
Conferentie over hoogwaardige ontwikkeling van IT-producten состоится in Moskou op 7 juni. U weet uit welke fasen een product van hoge kwaliteit bestaat, we hebben voorbeelden van het succesvol bestrijden van bugs in de productie, we hebben populaire methoden in onze praktijk getest - we hebben uw ervaring nodig. hun aanvragen vóór 1 mei, en de Programmacommissie zal helpen het thema scherp te stellen voor de algehele integriteit van de conferentie.
Verbinden aan , waarin we kwaliteitsvraagstukken bespreken en de conferentie, abonneer je op om op de hoogte te blijven van programmanieuws.
Bron: www.habr.com