Hvem har ansvaret for kvaliteten?

Hej Habr!

Vi har et nyt vigtigt emne - udvikling af høj kvalitet af IT-produkter. Vi taler ofte hos HighLoad++ om, hvordan man gør indlæste tjenester hurtige, og hos Frontend Conf om en fed brugergrænseflade, der ikke bremser. Vi har jævnligt emner om test, og DevOpsConf handler om at kombinere forskellige processer, herunder test. Men om, hvad man generelt kan kalde kvalitet, og hvordan man arbejder med det på en omfattende måde - nej.

Lad os ordne det her QualityConf — vi vil udvikle en kultur, hvor vi tænker over kvaliteten af ​​det endelige produkt for brugeren på alle udviklingstrin. Vanen med ikke at blive hængende i dit ansvarsområde og forbinde kvalitet ikke kun med testere.

Nedenfor vil vi tale med lederen af ​​programudvalget, lederen af ​​test hos Tinkoff.Business, skaberen af ​​det russisksprogede QA-fællesskab Anastasia Aseeva-Nguyen om tilstanden i QA-branchen og missionen for den nye konference.

- Nastya, hej. Fortæl os venligst om dig selv.

Anastasia: Jeg står for test i banken, jeg har ansvaret for et meget stort team - vi er mere end 90. Vi har en vigtig forretningslinje, vi er ansvarlige for økosystemet for juridiske enheder.

Jeg læste på Det Mekaniske og Matematiske Fakultet og ville i første omgang blive programmør. Men da jeg fik et interessant tilbud, besluttede jeg at prøve mig selv som tester. Mærkeligt nok viste det sig at være mit kald. Nu ser jeg alt mit arbejde i denne branche.

Jeg er en ivrig tilhænger af kvalitetssikringsdisciplinen. Jeg går op i, hvilke produkter der skabes, hvordan kvalitet behandles i virksomheden, i teamet og i princippet i udviklingsprocessen.

Det er indlysende for mig samfundet i dette område er ikke modent nok, i hvert fald i Rusland. Vi forstår ikke altid, at kvalitetssikring ikke kun er det faktum at teste ansøgningen for overholdelse af kravene. Jeg vil gerne ændre denne situation.

- Du bruger ordene Kvalitetssikring og test. I den gennemsnitlige persons øjne krydser disse to udtryk meget ofte hinanden. Hvordan er de forskellige, hvis du graver dybt?

Anastasia: Tværtimod er de ikke forskellige. Test er en del af kvalitetssikringsdisciplinen, det er en direkte aktivitet – selve det, at jeg tester noget. Der er faktisk mange forskellige typer af test, og forskellige mennesker er ansvarlige for forskellige typer af test. Men her i Rusland, da en bølge af outsourcere dukkede op, som leverer testere til virksomheder, blev testningen reduceret til en enkelt type.

I de fleste tilfælde begrænser de sig kun til funktionel test: de kontrollerer, at det, udviklerne har kodet, overholder specifikationen, og det er det.

— Fortæl os venligst, hvilke andre kvalitetssikringsdiscipliner der findes? Hvad omfatter dette andet end test?

Anastasia: Kvalitetssikring handler først og fremmest om at skabe et kvalitetsprodukt. Det vil sige, at vi spørger os selv, hvilke kvalitetsegenskaber vores produkt skal have. Derfor, hvis vi forstår dette, kan vi sammenligne, hvem der påvirker disse kvalitetsegenskaber. betyder ikke noget, udvikler, projektleder eller produktspecialist - dette er en person, der påvirker udviklingen af ​​et produkt, dets backlog, dets strategi.

Testeren begynder bedre at forstå sin rolle. Han forstår, at hans opgave ikke kun er at teste for overholdelse af krav, men også at teste krav, stille spørgsmålstegn ved de formuleringer, der kommer fra produktchefen, og afsløre alle de implicitte krav og forventninger hos kunden. Når vi leverer ny funktionalitet til vores kunder, skal vi virkelig opfylde deres forventninger og løse deres smerter. Hvis vi tænker på alle kvaliteternes egenskaber, vil kunden være glad og vil forstå, at den virksomhed, hvis produkt han bruger, virkelig bekymrer sig om hans interesser og ikke arbejder efter princippet om at "bare frigive en funktion".

— Det ser ud til, at det, du lige har beskrevet, er en produktchefs opgave. Det handler i princippet ikke om test eller kvalitet - det handler generelt om produktstyring, ikke?

Anastasia: Inklusiv. Kvalitetssikring er ikke en disciplin, der er en specifik persons ansvar. Der er en populær retning i test nu, en tilgang kaldet Agile test. Dens definition angiver klart, at det er en teamtilgang til test, der inkluderer et specifikt sæt af praksis. Hele teamet er ansvarligt for at implementere denne tilgang, og det er ikke engang nødvendigt for teamet at have en tester. Hele teamet er fokuseret på at levere værdi til kunden og sikre, at denne værdi lever op til deres forventninger.

— Det viser sig, at kvalitet krydser næsten alle omgivende discipliner og sætter rammer for alt omkring?

Anastasia: rigtigt. Når vi tænker på, at vi ønsker at skabe et kvalitetsprodukt, begynder vi at tænke på forskellige kvaliteter. For eksempel hvordan man tjekker, at vi rent faktisk har lavet en funktion, som vores klient har brug for.

Det er her denne type test kommer op: UAT (test af brugeraccept). Desværre praktiseres det sjældent i Rusland, men nogle gange er det til stede i SCRUM-hold som en demo for slutklienten. I udenlandske virksomheder er dette en ret almindelig type test. Inden vi åbner funktionaliteten for alle kunder, laver vi først UAT, det vil sige, at vi inviterer slutbrugeren, som udfører test og straks giver feedback – om produktet virkelig lever op til forventningerne og løser smerten. Først efter dette sker skalering til alle andre klienter.

Det vil sige, at vi fokuserer på forretning, på slutkunden, men samtidig glem ikke teknologien. Kvaliteten af ​​produktet afhænger også i høj grad af teknologien. Hvis vi har en dårlig arkitektur, vil vi ikke være i stand til at frigive funktioner hurtigt og opfylde kundernes forventninger. Der kan være mange fejl, når vi forsøger at skalere, eller når vi forsøger at refaktorere, kan vi bryde noget. Alt dette vil påvirke kundetilfredsheden.

Fra dette synspunkt bør arkitekturen være sådan, at vi kan skrive ren kode, der giver os mulighed for at foretage ændringer hurtigt og ikke være bange for, at vi vil bryde alt. Så gentagelserne af forbedringer ikke strækker sig over flere måneder, blot fordi vi har så meget arv og skal lave lange testfaser.

— Så udviklere, arkitekter, produktspecialister, produktchefer og testerne selv er allerede involveret. Hvem er ellers involveret i kvalitetssikringsprocessen?

Anastasia: Lad os nu forestille os, at vi allerede har leveret funktionen til klienten. Det er klart, at produktets kvalitet skal overvåges, selv når det allerede er i produktion. På dette stadium kan situationer med ikke-oplagte scenarier, såkaldte bugs, opstå.

Det første spørgsmål er, hvordan håndterer vi disse fejl, efter at vi allerede har udgivet produktet? Hvordan reagerer vi fx på stress? Klienten vil ikke være særlig glad, hvis siden tager mere end 30 sekunder at indlæse.

Det er her, udnyttelse, eller som det nu hedder, kommer i spil. DevOps. Faktisk er det disse personer, der er ansvarlige for at betjene produktet, når det først er i produktion. Dette omfatter forskellige typer overvågning. Der er endda en undertype af test - test på produktion, når vi tillader os ikke at teste noget, før vi ruller det ud og tester det med det samme på produktion. Dette er en række tiltag fra infrastrukturorganisationens synspunkt, som giver dig mulighed for hurtigt at reagere på en hændelse, påvirke den og rette den.

Infrastruktur er også vigtig. Der er ofte situationer, hvor det under test er umuligt at sikre sig, at vi virkelig har alt det, vi gerne vil give til kunden. Vi ruller det ud til produktion og begynder at fange ikke-oplagte situationer. Og alt sammen fordi infrastrukturen i testen ikke svarer til infrastrukturen i produktionen. Dette fører til en ny type test - infrastruktur test. Disse er forskellige konfigurationer, indstillinger, databasemigrering osv.

Dette rejser spørgsmålet: måske skal teamet bruge infrastruktur som kode.

Jeg tror på, at infrastruktur direkte påvirker kvaliteten af ​​produktet.

Jeg håber, der kommer en rapport med en reel case på konferencen. Skriv til os, hvis du er klar til at dele ud fra din egen erfaring, hvordan infrastruktur som kode påvirker kvaliteten. Infrastruktur som kode gør det nemmere at tjekke alle indstillinger og teste ting, der ellers ville være umulige. Derfor er drift også involveret i processen med at udvikle et kvalitetsprodukt.

— Hvad med analyser og dokumentation?

Anastasia: Dette gælder mere for virksomhedssystemer. Når vi taler om virksomhed, kommer folk som analytikere og systemanalytikere straks til at tænke på. De kaldes undertiden tekniske forfattere. De får til opgave at skrive en specifikation og bruger for eksempel en måned på at færdiggøre den.

Det er blevet bevist mange gange, at skrivning af sådan dokumentation fører til meget lange udviklingsgentagelser og lange revisionsgentagelser, fordi under testprocessen opdages fejl, og returnering begynder. Dette resulterer i en masse loops, hvilket øger omkostningerne ved udvikling. Derudover kan det introducere sårbarheder. Vi så ud til at have skrevet referencekode, men så lavede vi ændringer, der brød den perfekt gennemtænkte arkitektur.

Slutresultatet er et produkt af ikke særlig høj kvalitet, for der er allerede patches i arkitekturen, koden er nogle steder ikke tilstrækkeligt dækket af test, fordi deadlines presser på, alle fejl skal lukkes hurtigere. Og alt sammen fordi den oprindelige specifikation ikke tog højde for alle de aspekter, der skulle implementeres.

Udviklere er ikke sabotører og skriver ikke bevidst kode med fejl.

Hvis vi i første omgang havde udtænkt en specifikation, der skulle dække alle de nødvendige punkter, så ville alt være blevet implementeret præcis efter behov. Men dette er en utopi.

Det er nok umuligt at skrive en perfekt 100 siders specifikation. Det er derfor vi skal tænke på alternative måder at skrive dokumentation på, specifikationer, indstilling af opgaver, der ville bringe os tættere på, at udvikleren gør præcis det, der er nødvendigt.

Det er her, agile tilgange kommer til at tænke på: brugerhistorier med acceptkriterier. Dette er mere anvendeligt for teams, der udvikler sig i små iterationer.

— Hvad med brugervenlighedstest, produktbrugbarhed, design?

Anastasia: Dette er en meget vigtig pointe, det er derfor, der er designere på holdet. Oftest bruges designere som en service – enten en designafdeling eller en outsourcet designer. Der er ofte situationer, hvor det ser ud til, at designeren lyttede til produktchefen og gjorde, hvad han forstod. Men da vi begynder at iterere, viser det sig, at det, der rent faktisk blev gjort, ikke var det, der var forventet: Designeren glemte noget, tænkte ikke helt igennem adfærden, fordi han ikke var med på holdet og ikke i konteksten, eller frontend-udvikleren forstod ikke helt sit layout. Det kan tage flere gentagelser, bare fordi der er et problem med frontend-udviklerens forståelse af designet.

Plus der er endnu et problem. Designsystemer vinder popularitet nu. De er hypede, men fordelene ved dem er ikke helt indlysende.

Jeg støder på den opfattelse, at designsystemer på den ene side forenkler udviklingen, men på den anden side lægger en masse begrænsninger på grænsefladen.

Som et resultat opretter vi ikke den funktion, som klienten ønsker at modtage, men snarere den, der er praktisk for os, fordi vi allerede har visse kuber, som vi kan lave den fra.

Jeg synes, det er et emne, der er værd at se på og tænke over, om vi virkelig løser kundesmerter i et forsøg på at forenkle designarbejdet.

— Der er overraskende mange emner relateret til kvalitetssikring. Er der en konference i Rusland, hvor alle kan diskuteres?

Anastasia: Der er den ældste testkonference, som afholdes for 25. gang i år og kaldes SQA Days Quality Assurance Conference. Den diskuterer hovedsageligt værktøjer og specifikke testmetoder for funktionelle testere. Typisk fokuserer foredrag på SQA Days på specifikke ansvarsområder for testerne selv, snarere end omfattende aktiviteter.

Dette er en stor hjælp til at forstå de forskellige værktøjer og tilgange til test af databaser, API'er osv. Men samtidig motiverer det på den ene side ikke til at involvere mere end blot test i skabelsen af ​​et produkt af højere kvalitet. På den anden side bliver testere ikke mere involveret i processen for at tænke på det globale mål for produktet og dets forretningskomponent.

Jeg driver en stor afdeling og gennemfører en masse interviews, der virkelig giver dig en fornemmelse af tilstanden i branchen som helhed. Som regel arbejder vores fyre i en virksomhed, og de har et klart ansvarsområde. Kolleger, der arbejder på udenlandske projekter, bruger forskellige typer af test: de kan selv lave belastningstest, ydeevnetest og endda nogle gange sikkerhedstest, fordi de virkelig hjælper teamet med at sikre kvaliteten af ​​produktet.

Jeg vil gerne have, at vores fyre i Rusland også begynder at tænke på, at industrien ikke slutter med funktionstest.

— Derfor arrangerer vi en ny konference, QualityConf, som er dedikeret til kvalitet som en holistisk disciplin. Fortæl os mere om ideen, hvad er hovedmålet med konferencen?

Anastasia: Vi ønsker at skabe et fællesskab af mennesker, der er interesserede i at lave kvalitetsprodukter. Tilbyd en platform, hvor de kan komme, lytte til præsentationer og forlade konferencen med en specifik forståelse af, hvad der skal ændres for at forbedre kvaliteten.

Jeg hører ofte henvendelser fra konsulent nu om, hvad man skal gøre, når der er problemer med test og kvalitet. Når man begynder at kommunikere med teams, ser man, at problemet ikke ligger i testerne selv, men i hvordan processen er struktureret. For eksempel, når udviklere mener, at de kun er ansvarlige for at skrive kode, slutter deres ansvar præcis i det øjeblik, de overlader opgaven til test.

Ikke alle tænker over, at dårligt skrevet kode af lav kvalitet med en dårlig arkitektur truer med store problemer for projektet. De tænker ikke på omkostningerne ved fejl, på det faktum, at fejl, der kommer i produktion, kan resultere i store udgifter for virksomheden og teamet. Der er ingen kultur at tænke over det. Jeg vil gerne have, at vi begynder at distribuere det på konferencen.

Jeg forstår, at dette ikke er en nyskabelse. Edward Deming, forfatteren til de 14 kvalitetspostulater, skrev om omkostningerne ved fejl tilbage i forrige århundrede. Kvalitetssikring som disciplin er baseret på denne bog, men desværre glemmer moderne udvikling det.

— Planlægger du at berøre emner, der er direkte relateret til test og værktøjer?

Anastasia: Jeg indrømmer, at der vil komme rapporter om værktøjer. Der er ret universelle værktøjer, som virksomheder og teams kan bruge til at påvirke et produkt.

Alle rapporter vil være globalt forenet af én fælles mission: at formidle til publikum, at vi ved hjælp af denne tilgang, værktøj, metode, proces, type test har påvirket produktets kvalitet og forbedret livet for kunden.

Vi vil bestemt ikke have nogen rapporter om et værktøj af hensyn til et værktøj. Alle rapporter inkluderet i programmet vil blive forenet af et fælles mål.

— Hvem vil være interesseret i det, du taler om, hvem ser du som gæster på konferencen?

Anastasia: Vi vil have rapporter til udviklere, der bekymrer sig om skæbnen for deres projekt, produkt, system. Det vil også være interessant for testere og, ser det ud til, især for ledere. Med ledere mener jeg mennesker, der træffer beslutninger og kan påvirke skæbnen og udviklingen af ​​et produkt, et system eller et team, blandt andet.

Det er mennesker, der stiller sig selv spørgsmålet: hvordan man kan forbedre kvaliteten af ​​et produkt eller system. På vores konference vil de lære om forskellige sæt af aktiviteter og vil være i stand til at forstå, hvad der er galt med dem nu, og hvad der skal ændres.

Jeg tror, ​​at hovedkriteriet er at forstå, at der er noget galt med kvaliteten og at ville påvirke den. Vi vil sandsynligvis ikke være i stand til at nå folk, der tror, ​​at det her vil gøre tricket første gang.

— Tror du, at branchen som helhed er moden til ikke kun at tale om test, men om kvalitetskultur?

Anastasia: Jeg tror, ​​jeg er moden. I dag er mange virksomheder på vej væk fra den traditionelle vandfaldstilgang til Agile. Der er et kundefokus, og folk i teams er virkelig begyndt at tænke over, hvordan man skaber et kvalitetsprodukt. Selv i virksomhedsvirksomheder er der en nyorientering i retning af at forbedre kvaliteten.

At dømme efter antallet af forespørgsler, der kommer op i samfundet, synes jeg, det er på tide. Jeg er selvfølgelig ikke sikker på, at det her bliver en revolution i stor skala, men jeg kunne godt tænke mig, at denne revolution i bevidstheden skulle ske.

- Aftalt! Vi vil indgyde kultur og ændre bevidsthed.

Konference om højkvalitetsudvikling af IT-produkter QualityConf finder sted i Moskva den 7. juni. Du ved, hvilke stadier der udgør et kvalitetsprodukt, du har tilfælde af succesfuld bekæmpelse af fejl i produktionen, du har testet populære metoder i din praksis - vi har brug for din erfaring. Send det deres ansøgninger indtil 1. maj, og programudvalget vil hjælpe med at fokusere temaet for konferencens overordnede integritet.

Forbinde til snak, hvor vi diskuterer kvalitetsspørgsmål og konferencen, abonnere på Telegram kanalfor at holde sig opdateret med programmets nyheder.

Kilde: www.habr.com