Hello, Habr!
Vi har et nyt vigtigt emne - kvalitetsudvikling af IT-produkter. Vi taler ofte på HighLoad++, om hvordan man gør belastede tjenester hurtigere, og på Frontend Conf - en fantastisk brugergrænseflade, der ikke hænger. Vi har regelmæssigt emner om testning, og DevOpsConf handler om at forene forskellige processer, herunder testning. Men om det, man kan kalde kvalitet generelt, og hvordan man arbejder omfattende med det - der er der ingen.
Lad os rette dette til – vi vil udvikle kulturen for at tænke på kvaliteten af det endelige produkt for brugeren på hver udviklingsfase. En vane med ikke at kaste sig ind i sit eget ansvarsområde og associere kvalitet ikke kun med testere.
Under overskriften taler vi med hovedet for programkomiteen, lederen af testning hos Tinkoff.Business, skaberen af det russisktalende QA-fællesskab Anastasia Aseeva-Nguen om tilstanden i QA-branchen og missionen for den nye konference.
– Hej Nastya. Fortæl venligst lidt om dig selv.
Anastasia: Jeg leder testningen i banken, hvor jeg har ansvaret for et meget stort team - vi er over 90 personer. Vi har en vigtig forretningslinje, vi står for økosystemet for juridiske personer.
Jeg har studeret matematik og oprindeligt ønsket at blive programmør. Men da jeg fik et spændende tilbud, besluttede jeg at prøve mig som tester. Som mærkeligt det kan lyde, viste det sig at være min kald. Nu ser jeg hele mit arbejde præcist i denne branche.
Jeg er en fervent tilhænger af disciplinen Quality Assurance. Jeg er ikke ligeglad med, hvilke produkter der skabes, hvordan kvaliteten bliver behandlet i virksomheden, i teamet og generelt i udviklingsprocessen.
For mig er det åbenlyst, at fællesskabet på dette område er utilstrækkeligt modent, i det mindste i Rusland. Vi forstår ikke altid, at kvalitetssikring kun er selve testen af applikationen for at opfylde kravene. Jeg vil gerne ændre denne situation.
– Du bruger ord som Quality Assurance og testning. I almindelige menneskers øjne krydser disse to termer ofte hinanden. Hvordan adskiller de sig, hvis man graver dybt?
Anastasia: Det adskiller sig ikke rigtig. Testning er en del af disciplinen Quality Assurance, det er en direkte aktivitet – selve faktum, at jeg tester noget. Der findes faktisk mange forskellige former for testning, og forskellige personer ansvarer for de forskellige typer testning. Men i Rusland, da bølgen af outsourcere dukkede op, der leverede testere til virksomheder, blev testning reduceret til én type.
I de fleste tilfælde begrænser man sig kun til funktionel testning: man tjekker, at det, udviklerne har kodet, lever op til specifikationen og alt.
– Fortæl mig venligst, hvilke andre discipliner inden for kvalitetssikring der findes? Hvad andet end testning indgår i dette?
Anastasia: Quality Assurance handler først og fremmest om at skabe et kvalitetsprodukt. Det vil sige, at vi stiller os spørgsmålet, hvilke kvalitetsattributter vores produkt skal have. Hvis vi forstår dette, kan vi matche, hvem der påvirker disse kvalitetsattributter. Uanset om det er udvikleren, projektlederen eller produktlederen – det er en person, der påvirker produktets udvikling, dets backlog, dets strategi.
Testeren begynder bedre at forstå sin rolle. Han forstår, at hans opgave ikke kun er at teste for overensstemmelse med kravene, men også at teste kravene, stille spørgsmål ved formuleringer, der kommer fra produktlederen, og afdække alle de implicitte krav og forventninger fra kunden. Når vi leverer ny funktionalitet til vores kunde, skal vi virkelig imødekomme hans forventninger og løse hans problemer. Hvis vi tænker på alle kvalitetsattributterne, vil kunden være tilfreds og forstå, at virksomheden, hvis produkt han bruger, virkelig cares om hans interesser og ikke arbejder efter princippet "bare for at få en funktion ud af døren."
– Det virker som om, det, du lige har beskrevet, er produktlederens opgave. Det handler grundlæggende ikke om testning eller kvalitet – det handler overhovedet om produktstyring, ikke?
Anastasia: Det er delvist rigtigt. Quality Assurance er ikke en disciplin, som kun én konkret person har ansvaret for. Der er i øjeblikket en populær retning inden for testning, en tilgang kaldet Agile TestingI definitionen siger det klart, at det er en teamtilgang til testning, som inkluderer et bestemt sæt praksisser. Implementeringen af denne tilgang er et ansvar for hele teamet, og det er ikke nødvendigt, at der er en tester i teamet. Hele teamet fokuserer på at levere værdi til kunden, og at denne værdi opfylder hans forventninger.
— Så kvalitet passerer næppe ikke ind i næsten alle omkringliggende discipliner og lægger rammer for alt omkring os?
Anastasia: Korrekt. Når vi overvejer, hvad vi vil skabe et kvalitetsprodukt, begynder vi at tænke over forskellige kvalitetsattributter. For eksempel, hvordan vi kan tjekke, om vi faktisk har lavet en funktion, der er nødvendig for vores kunde.
Her dukker en testtype op, kaldet UAT (user acceptance testing). Desværre praktiseres det sjældent i Rusland, men det findes nogle gange i SCRUM-hold som en demo for den endelige kunde. I udenlandske virksomheder er det en ret udbredt testtype. Før vi åbner funktionaliteten for alle kunder, laver vi først UAT, det vil sige, vi inviterer den endelige forbruger, som udfører testningen og straks giver feedback - om produktet virkelig lever op til forventningerne og løser behovet. Først efter dette sker der en skalering til alle de andre kunder.
Så vi fokuserer på virksomheden, på den endelige kunde, men vi glemmer ikke teknologien. Kvaliteten af produktet afhænger også i høj grad af teknologierne. Hvis vi har en dårlig arkitektur, kan vi ikke hurtigt frigive funktioner og leve op til kundens forventninger. Der kan være mange fejl, når vi forsøger at skalere, eller under forsøg på at lave refaktorering, kan vi ødelægge noget. Alt dette vil påvirke kundetilfredsheden.
Fra denne synsvinkel skal arkitekturen være sådan, at vi kan skrive ren kode, som gør det muligt at foretage hurtige ændringer uden frygt for, at vi ødelægger alt. For at iterationerne af forbedringer ikke strækker sig over flere måneder bare fordi vi har så meget legacy, og der er behov for lange testfaser.
— Samlet set er udviklere, arkitekter, produktfolk, produktledere og selve testerne allerede involveret. Hvem ellers er involveret i kvalitetssikringsprocessen?
Anastasia: Lad os forestille os, at vi allerede har leveret en funktion til kunden. Det er tydeligt, at man skal holde øje med produktkvaliteten, når det allerede er i produktion. I denne fase kan der opstå situationer med uventede scenarier, såkaldte bugs.
Det første spørgsmål er - hvordan arbejder vi med disse bugs, efter vi har udgivet produktet? Hvordan reagerer vi for eksempel på belastningen? Kunden vil ikke være særlig tilfreds, hvis siden loader i mere end 30 sekunder.
Her træder drift eller, som det nu kaldes, DevOps. Faktisk er det mennesker, der er ansvarlige for driften af produktet, når det allerede er i produktion. Dette omfatter forskellige former for overvågning. Der er endda en underkategori af testning - testning i produktion, hvor vi tillader os ikke at teste noget før udgivelsen og tester det straks i produktion. Det er en række aktiviteter fra et perspektiv af infrastrukturorganisation, der gør det muligt hurtigt at reagere på en hændelse, påvirke den og rette fejlen.
Infrastrukturen er også vigtig. Der opstår ofte situationer, hvor det under test er umuligt at sikre, at vi virkelig har alt det, vi gerne vil give kunden. Vi udgiver i produktion - og begynder at opleve uventede situationer. Og det hele skyldes, at infrastrukturen i testen ikke svarer til infrastrukturen i produktionen. Heraf opstår en ny form for testning - infrastrukturtestning. Dette inkluderer forskellige konfigurationer, indstillinger, migrering af databaser osv.
Her opstår spørgsmålet - er det muligt, at teamet skal bruge infrastruktur som kode.
Jeg tror på, at infrastrukturen direkte påvirker produktkvaliteten.
Jeg håber, at der vil være et oplæg med en reel case på konferencen. Skriv til os, hvis du er klar til at dele din erfaring om, hvordan infrastruktur som kode påvirker kvaliteten. Infrastrukturen som kode gør det lettere at kontrollere alle indstillinger og teste det, der ellers ville være umuligt. Derfor involveres driften også i processen med at udvikle et kvalitetsprodukt.
— Hvad med analyser og dokumentation?
Anastasia: Dette vedrører mere enterprise-systemer. Når vi taler om enterprise, tænker man straks på personer som analytikere og systemanalytikere. Nogle gange kaldes de tekniske skribenter. De får en opgave om at skrive en specifikation og udfører den, for eksempel på en måned.
Det er gentagne gange bevist, at udarbejdelsen af sådan dokumentation fører til meget lange udviklingsiterationer og forlængede forbedringsfaser, fordi fejl opdages i testprocessen, hvilket resulterer i tilbagesendelser. Dette skaber mange sløjfer, der øger udviklingsomkostningerne. Derudover kan det introducere sårbarheder. Vi har tilsyneladende skrevet referencekode, men derefter foretaget ændringer, der bryder den velovervejede arkitektur.
Resultatet bliver ikke et særlig kvalitetsprodukt, fordi der allerede er kommet lapper i arkitekturen, og koden er ikke tilstrækkeligt dækket af tests i nogle områder, fordi tidsfristerne presser, og vi skal hurtigere få lukket alle fejl. Alt dette skyldes, at ikke alle punkter, der skulle implementeres, blev overvejet i den oprindelige specifikation.
Udviklere er ikke skurke og skriver ikke bevidst kode med fejl.
Hvis vi fra starten havde overvejet en specifikation, der dækkede alle nødvendige punkter, ville alt have blevet gennemført som det skulle. Men det er utopi.
Måske er det umuligt at skrive en perfekt specifikation på 100 sider. Derfor bør vi overveje alternative måder at skrive dokumentation på, specificering, opgavestilling, som bringer os tættere på, at udvikleren laver præcis det, der er nødvendigt.
Her kommer tilgange fra Agile i tankerne – brugerhistorier med acceptkriterier. Dette er mere anvendeligt for hold, der udvikler sig i små iterationer.
– Hvad med usability-testning, brugervenlighed af produktet, design?
Anastasia: Det er et meget vigtigt punkt, fordi der er designere i teamet. Ofte anvendes designere som en service – enten et designerteam eller en designer på outsourcing. Ofte opstår situationer, hvor designeren tilsyneladende har lyttet til produktlederen og gjort, hvad han forstod. Men når vi går i gang med iterationen, viser det sig, at det faktisk ikke er gjort, som forventet: designeren har glemt noget, ikke tænkt fuldt ud på opførelsen, fordi han ikke er i teamet og ikke i konteksten, eller frontend-udvikleren har ikke helt forstået hans layout. Det kan være nødvendigt med flere iterationer kun fordi der er et problem med forståelsen af designet fra frontend-udviklerens side.
Der er også et andet problem. Designsystemer vinder i øjeblikket popularitet. De er på mode, men fordelene ved dem er ikke helt åbenlyse.
Jeg støder på meninger om, at designsystemer på den ene side forenkler udviklingen, men på den anden side pålægger de mange begrænsninger på grænsefladen.
I sidste ende laver vi ikke den funktion, som kunden ønsker at få, men en, der er praktisk for os, fordi vi allerede har visse moduler, som vi kan bruge til at lave den.
Jeg synes, det er værd at overveje dette emne og tænke over, om vi i forsøget på at forenkle designarbejdet virkelig løser kundens problem.
— Det viser sig at være utroligt mange emner relateret til kvalitetssikring. Er der en konference i Rusland, hvor man kan diskutere dem alle?
Anastasia: Der er en meget gammel konference om testning, der i år afholdes for 25. gang og hedder – Konference om kvalitetssikring SQA Days. På den diskuteres der primært om værktøjer og specifikke tilgang til testning for funktionelle testere. Som regel bliver specifikke områder inden for testernes ansvar dybtgående behandlet i præsentationerne på SQA Days, men ikke komplekse emner.
Det hjælper virkelig med at forstå forskellige værktøjer og tilgange til, hvordan man tester databaser, API'er osv. Men på den anden side motiverer det ikke til at involvere andre aspekter i skabelsen af et kvalitetsprodukt end bare testning. Og testerne bliver ikke mere involverede i processen for at tænke på det overordnede mål for produktet og dets forretningskomponent.
Jeg leder en stor afdeling, har mange interviews, som faktisk giver et overblik over tilstanden i branchen som helhed. Som regel arbejder vores folk i enterprise, og de har et klart ansvarsområde. Kollegaer, der arbejder på udenlandske projekter, bruger forskellige former for testning: de kan selv udføre belastningstest, præstationstest og endda nogle gange sikkerhedstest, fordi de virkelig hjælper teamet med at sikre kvaliteten af produktet.
Jeg ønsker, at vores folk i Rusland også begynder at overveje, at branchen ikke slutter med funktionel testning.
— For this reason, we are organizing a new conference called QualityConf, which is dedicated to quality as an integral discipline. Can you tell us more about the concept and the main goal of the conference?
Anastasia: We want to create a community of individuals interested in producing quality products. To provide a platform where they can come, listen to lectures, and leave the conference with a concrete understanding of what they need to change in order to improve quality.
I often hear requests from consulting about what to do when there are issues with testing and quality. When you start communicating with the teams, you realize that the problem is not with the testers themselves, but with how the process is structured. For example, when developers believe that they are only responsible for writing code, their responsibility ends exactly the moment they hand over the task to testing.
Not everyone considers that poorly written, low-quality code with bad architecture poses significant risks for the project. They don’t think about the costs of mistakes, about how bugs that make it to production can lead to substantial expenses for the company and team. There is no culture of thinking about this. I want us to start spreading it at the conference.
I understand that this is not an innovation. Edward Deming, the author of the 14 quality principles, wrote about the cost of mistakes back in the last century. Quality Assurance as a discipline is based on this book, but unfortunately, modern development tends to forget about it.
— Will you directly address topics related to testing and tools?
Anastasia: I assume there will be talks about tools. There are quite universal tools that companies and teams can use to influence the product.
All presentations will be globally united by one common mission: to convey to the audience that with the help of this approach, tool, method, process, or type of testing, we impacted the quality of the product and improved the client’s experience.
We will definitely not have presentations about tools just for the sake of it. All presentations that will be included in the program will be united by a common goal.
— Who do you think will be interested in what you are talking about? Who do you see as guests at the conference?
Anastasia: Vi vil have præsentationer for udviklere, der er bekymrede for deres projekts, produkts eller systems skæbne. Det vil også være interessant for testere og, som jeg ser det, især for ledere. Med ledere mener jeg personer, der træffer beslutninger og kan påvirke udviklingen af produktet, systemet og teamet.
Det er mennesker, der stiller spørgsmålet - hvordan kan man forbedre kvaliteten af produktet eller systemet. På vores konference vil de lære om forskellige sæt af foranstaltninger og kunne forstå, hvad der ikke fungerer for dem i øjeblikket, og hvad der skal ændres.
Jeg mener, at hovedkriteriet er at forstå, at der er noget galt med kvaliteten og at ønske at påvirke det. Det bliver nok ikke muligt at nå igennem til folk, der mener, at alt er i orden, ved første forsøg.
— Hvad mener du, er branchen generelt klar til at tale ikke bare om testning, men om kvalitetens kultur?
Anastasia: Jeg mener, at det er den. Mange virksomheder går nu væk fra den traditionelle Waterfall-tilgang mod Agile. Der er en orientering mod kunden, og folk i teamene begynder virkelig at tænke over, hvordan man skaber et kvalitetsprodukt. Selv i enterprise-virksomheder sker der en omorientering mod at forbedre kvaliteten.
Hvis vi ser på antallet af forespørgsler, der opstår i samfundet, mener jeg, at det er tid. Jeg er dog ikke sikker på, at det vil være en massiv revolution, men jeg ville ønske, at denne ændring i bevidsthed finder sted.
— Aftale! Vi vil fremme kulturen og ændre bevidstheden.
Konferencen om kvalitetsudvikling af IT-produkter i efteråret i år. Specifikt drejer det sig om version 69, som vil være tilgængelig i september. I ESR-versioner af Firefox vil Flash-understøttelsen blive opretholdt indtil slutningen af 2020. I de almindelige versioner kan man dog tvinge aktivering af Flash via about:config. i Moskva den 7. juni. Ved du, hvilke faser der udgør et kvalitetsprodukt, vi har tilfælde af succesfuld bekæmpelse af fejl i produktionen, og vi har også afprøvet populære metoder i vores praksis - vi har brug for din erfaring. dine ansøgninger inden 1. maj, og det videnskabelige udvalg vil hjælpe med at fokusere emnet for konferencens samlede sammenhæng.
Deltag i , hvor vi diskuterer kvalitetsproblemer og konferencen, og tilmeld dig , så du kan holde dig opdateret om programmets nyheder.
Kilde: habr.com
