Hej Habr!
Vi har et nyt vigtigt emne - udvikling af høj kvalitet af IT-produkter. Hos HighLoad++ taler vi ofte om, hvordan man gør travle tjenester hurtige, og hos Frontend Conf taler vi om en fed brugergrænseflade, der ikke bremser. Vi har jævnligt emner om test, og DevOpsConf om at kombinere forskellige processer, herunder test. Men om, hvad man generelt kan kalde kvalitet, og hvordan man arbejder med det helhedsorienteret - nej.
Lad os ordne det her kl — vi vil udvikle en kultur, hvor vi tænker over kvaliteten af det endelige produkt for brugeren på alle udviklingstrin. Vanen med ikke at fokusere på dit ansvarsområde og forbinde kvalitet ikke kun med testere.
Under cut vil vi tale med lederen af programudvalget, leder af test hos Tinkoff.Business, skaberen af det russisktalende QA-fællesskab Anastasia Aseeva-Nguyen om tilstanden i QA-branchen og missionen for den nye konference.
- Nastia hej. Fortæl os venligst om dig selv.
Anastasia: Jeg styrer test i en bank, jeg er ansvarlig for et meget stort team - vi er mere end 90 personer. Vi har en vigtig forretningslinje; vi er ansvarlige for økosystemet for juridiske enheder.
Jeg læste mekanik og matematik og ville oprindeligt 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 er ikke ligeglad med, hvilke produkter der skabes, hvordan kvalitet behandles i virksomheden, i teamet og i princippet i udviklingsprocessen.
Det er indlysende for mig samfundet i denne retning er ikke modent noki hvert fald i Rusland. Vi forstår ikke altid, at kvalitetssikring ikke kun er det faktum at teste en ansøgning for overholdelse af kravene. Jeg vil gerne ændre denne situation.
— Du bruger ordene Kvalitetssikring og test. I den gennemsnitlige persons øjne overlapper disse to udtryk meget ofte hinanden. Hvordan adskiller de sig, hvis du graver dybt?
Anastasia: Tværtimod er de ikke anderledes. Test er en del af kvalitetssikringsdisciplinen; det er en direkte aktivitet - selve det, at jeg tester noget. Der er faktisk mange typer af test, og en række 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 er de kun begrænset til funktionel test: de kontrollerer, at det, udviklerne har kodet, overholder specifikationen, og det er alt.
— Fortæl os venligst, hvilke andre kvalitetssikringsdiscipliner der findes? Hvad er der mere, udover test, inkluderet her?
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 er en person, der påvirker udviklingen af et produkt, dets backlog og dets strategi.
Testeren bliver mere bevidst om 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 produktspecialisten, 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 tilfreds og vil forstå, at den virksomhed, hvis produkt han bruger, virkelig bekymrer sig om hans interesser og ikke arbejder efter princippet om "bare for at frigive en funktion."
— Det ser ud til, at det, du lige har beskrevet, er en produktspecialists opgave. Dette handler i princippet ikke om test og ikke om kvalitet - det handler generelt om produktstyring, ikke?
Anastasia: Inklusiv. Kvalitetssikring er ikke en disciplin, som én bestemt person er ansvarlig for. Nu er der en populær retning i test, en tilgang kaldet Agile test. Hans definition angiver klart, at dette er en teamtilgang til test, som omfatter et bestemt sæt praksisser. Hele teamet er ansvarligt for at implementere denne tilgang; det er ikke engang nødvendigt, at der er en tester på holdet. Hele teamet er fokuseret på at levere værdi til kunden og sikre, at værdien lever op til kundernes forventninger.
— Det viser sig, at kvalitet krydser næsten alle omgivende discipliner og sætter rammer for alt omkring?
Anastasia: Højre. Når vi tænker over, hvordan vi ønsker at skabe et kvalitetsprodukt, begynder vi at tænke på de forskellige egenskaber ved kvalitet. For eksempel hvordan man tjekker, at vi virkelig har lavet den funktion, som vores klient har brug for.
Det er her denne type test kommer ind: UAT (test af brugeraccept). Desværre praktiseres det sjældent i Rusland, men er nogle gange til stede i SCRUM-teams som en demo for slutkunden. Dette er en ret almindelig type test i udenlandske virksomheder. Inden vi åbner funktionaliteten for alle kunder, laver vi først UAT, det vil sige, at vi inviterer slutbrugeren, som tester 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 hurtigt kunne frigive funktioner 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 hurtigt at foretage ændringer og ikke være bange for, at vi vil bryde alt. Så revisionsgentagelser strækker sig ikke over flere måneder, blot fordi vi har så meget arv, og vi skal lave lange testfaser.
— I alt er udviklere, arkitekter, produktforskere, produktchefer og testere selv 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 for eksempel på stress? Klienten vil ikke være særlig glad, hvis siden tager mere end 30 sekunder at indlæse.
Det er her, udnyttelse kommer i spil eller, som de kalder det nu, DevOps. Det er faktisk de personer, der er ansvarlige for at betjene produktet, når det allerede 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 udrulning og tester det med det samme på produktion. Dette er en række tiltag ud fra et synspunkt om at organisere infrastruktur, der 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 en test er umuligt at sikre sig, at vi virkelig har alt det, vi gerne vil give til klienten. Vi ruller det ud i produktionen 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 på konferencen med en reel sag. Skriv til os, hvis du er klar til at fortælle os 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 simpelthen ikke er muligt. 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 i tankerne. De kaldes undertiden tekniske forfattere. De får en opgave om at skrive en specifikation og færdiggøre den for eksempel i en måned.
Det er gentagne gange blevet bevist, at skrivning af sådan dokumentation fører til meget lange udviklingsgentagelser og lange gentagelser af forfining, fordi under testprocessen identificeres fejl, og returnering begynder. Som et resultat er der en masse loops, der øger udviklingsomkostningerne. Derudover kan dette introducere sårbarheder. Vi ser ud til at have skrevet referencekode, men så lavede vi ændringer, der bryder den perfekt gennemtænkte arkitektur.
Slutresultatet er et produkt, der ikke er helt af høj kvalitet, for der er allerede dukket patches op i arkitekturen, koden er nogle steder ikke tilstrækkeligt dækket af test, fordi deadlines er ved at løbe ud, alle fejl skal lukkes hurtigt. Og alt sammen fordi den oprindelige specifikation ikke tog højde for alle de punkter, der skal implementeres.
Udviklere er ikke skadedyr og skriver ikke kode med fejl med vilje.
Hvis vi i første omgang havde gennemtænkt en specifikation, der ville have dækket alle de nødvendige punkter, så ville alt være implementeret præcis efter behov. Men dette er en utopi.
Det er sandsynligvis umuligt at skrive en perfekt 100-siders specifikation. Derfor skal tænke på alternative måder at skrive dokumentation på, specifikationer, opstilling af opgaver, der ville bringe os tættere på at sikre, at udvikleren gør præcis, hvad der er brug for.
Her kommer tilgange fra Agile til syne - 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, fordi der er designere på holdet. Oftest bruges designere som en service – enten af en designafdeling eller af en outsourcet designer. Der er ofte situationer, hvor det ser ud til, at designeren lyttede til produktspecialisten og gjorde, hvad han forstod. Men når vi starter iterationen, viser det sig, at det, der faktisk blev gjort, ikke var det, der var forventet: Designeren glemte noget, tænkte ikke helt igennem adfærden, fordi han ikke er på holdet og ikke i konteksten eller fronten -end udvikler forstod ikke fuldt ud det layout. Det kan tage flere gentagelser, bare fordi der er et problem med, at frontend-udvikleren forstår designet.
Plus der er endnu et problem. Designsystemer vinder nu popularitet. De er på hype, 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 de en masse begrænsninger på grænsefladen.
Som et resultat laver vi ikke den funktion, som klienten ønsker, men den, der er praktisk for os, fordi vi allerede har visse kuber, som vi kan lave den fra.
Jeg synes, dette er et emne, der er værd at tage et kig på og spekulere på, om vi i forsøget på at gøre design nemmere rent faktisk løser et smertepunkt for klienten.
— 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. Som regel undersøger rapporterne på SQA Days dybt specifikke områder inden for testernes ansvarsområde, men ikke komplekse aktiviteter.
Dette hjælper meget med at forstå forskellige værktøjer og tilgange, hvordan man tester databaser, API'er osv. Men samtidig motiverer det på den ene side ikke at involvere mere end blot at teste i skabelsen af et bedre produkt. 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 laver en masse interviews, der virkelig giver indblik i branchens tilstand som helhed. Som regel arbejder vores fyre i virksomheder, og de har et klart ansvarsområde. Kolleger, der arbejder i udenlandske projekter, bruger forskellige typer 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 fyrene i Rusland også begynder at tro, at industrien ikke ender med funktionel test.
— Til dette formål arrangerer vi en ny konference, QualityConf, som er dedikeret til kvalitet som en integreret 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 rapporter og gå af sted efter konferencen med en specifik forståelse af, hvad der skal ændres for at forbedre kvaliteten.
I dag hører jeg ofte en forespørgsel fra konsulenter 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 er hos 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 dårlig arkitektur truer med store problemer for projektet. De tænker ikke på omkostningerne ved fejl, at fejl, der ender i produktionen, kan resultere i store omkostninger for virksomheden og teamet. Der er ingen kultur at tænke over dette. 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 kvalitetsprincipper, skrev om omkostningerne ved en fejl tilbage i det sidste århundrede. Kvalitetssikring som disciplin er baseret på denne bog, men desværre glemmer moderne udvikling det.
— Planlægger du at berøre emner direkte om 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 påvirke produktet med.
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 kundens levetid.
Vi vil bestemt ikke have 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 du ser som gæster på konferencen?
Anastasia: Vi vil have rapporter til udviklere, der bekymrer sig om skæbnen for deres projekt, produkt, system. Ligeledes vil det være interessant for testere og, ser det ud til, især for ledere. Med ledere mener jeg mennesker, der træffer beslutninger og også kan påvirke skæbnen og udviklingen af et produkt, et system, et team.
Det er mennesker, der spekulerer på, hvordan man kan forbedre kvaliteten af et produkt eller system. På vores konference vil de lære om forskellige sæt af tiltag 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 noget er galt med kvalitet og at ville påvirke det. Vi vil nok ikke kunne nå ud til folk, der tror, at det gør det bare første gang.
— Tror du, at branchen som helhed er moden til ikke kun at tale om test, men om en kvalitetskultur?
Anastasia: Jeg tror, jeg er blevet moden. Nu er mange virksomheder på vej væk fra den traditionelle Waterfall-tilgang til Agile. Der er et kundefokus, folk i teams begynder virkelig at tænke på, hvordan man skaber et kvalitetsprodukt. Selv virksomhedsvirksomheder fokuserer igen på at forbedre kvaliteten.
At dømme efter antallet af anmodninger, der opstår i samfundet, mener jeg, at det er på tide. Jeg er selvfølgelig ikke sikker på, at dette vil være en revolution i stor skala, men jeg vil gerne have, at denne revolution i bevidstheden sker.
- Aftalt! Vi vil indgyde kultur og ændre bevidsthed.
Konference om højkvalitetsudvikling af IT-produkter finder sted i Moskva den 7. juni. Du ved, hvilke stadier der udgør et højkvalitetsprodukt, vi har tilfælde af succesfuld bekæmpelse af fejl i produktionen, vi har testet populære metoder i vores praksis - vi har brug for din erfaring. deres ansøgninger inden 1. maj, og programudvalget vil hjælpe med at fokusere temaet for konferencens overordnede integritet.
Forbinde til , hvor vi diskuterer kvalitetsspørgsmål og konferencen, abonnere på for at holde sig opdateret med programnyheder.
Kilde: www.habr.com