Hei Habr!
Vi har et nytt viktig tema – høykvalitetsutvikling av IT-produkter. Hos HighLoad++ snakker vi ofte om hvordan man kan gjøre travle tjenester raske, og på Frontend Conf snakker vi om et kult brukergrensesnitt som ikke bremser ned. Vi har jevnlig temaer om testing, og DevOpsConf om å kombinere ulike prosesser, inkludert testing. Men om hva som kan kalles kvalitet generelt, og hvordan man kan jobbe med det helhetlig - nei.
La oss fikse dette innen — vi skal utvikle en kultur for å tenke på kvaliteten på sluttproduktet for brukeren i alle utviklingstrinn. Vanen med å ikke fokusere på ditt ansvarsområde, og assosiere kvalitet ikke bare med testere.
Under kuttet skal vi snakke med lederen av programkomiteen, leder for testing ved Tinkoff.Business, skaperen av det russisktalende QA-fellesskapet Anastasia Aseeva-Nguyen om tilstanden til QA-industrien og oppdraget til den nye konferansen.
- Nastia hei. Fortell oss gjerne om deg selv.
Anastasia: Jeg administrerer testing i en bank, jeg har ansvar for et veldig stort team - vi er mer enn 90 personer. Vi har en viktig forretningslinje; vi er ansvarlige for økosystemet for juridiske personer.
Jeg studerte mekanikk og matematikk og ønsket i utgangspunktet å bli programmerer. Men da jeg fikk et interessant tilbud, bestemte jeg meg for å prøve meg som tester. Merkelig nok viste dette seg å være mitt kall. Nå ser jeg alt arbeidet mitt i denne bransjen.
Jeg er en ivrig tilhenger av kvalitetssikringsdisiplinen. Jeg er ikke likegyldig til hvilke produkter som skapes, hvordan kvalitet behandles i bedriften, i teamet og i prinsippet i utviklingsprosessen.
Det er åpenbart for meg det samfunnet i denne retningen er ikke modent nok, i hvert fall i Russland. Vi forstår ikke alltid at kvalitetssikring ikke bare er det faktum å teste en søknad for samsvar med kravene. Jeg vil gjerne endre denne situasjonen.
— Du bruker ordene Kvalitetssikring og testing. I den gjennomsnittlige personens øyne overlapper disse to begrepene ofte hverandre. Hvordan skiller de seg hvis du graver dypt?
Anastasia: De er heller ikke annerledes. Testing er en del av kvalitetssikringsdisiplinen; det er en direkte aktivitet - selve det faktum at jeg tester noe. Det finnes faktisk mange typer testing, og en rekke mennesker er ansvarlige for forskjellige typer testing. Men her i Russland, da en bølge av outsourcere dukket opp som leverer testere til selskaper, ble testingen redusert til en enkelt type.
I de fleste tilfeller er de bare begrenset til funksjonell testing: de sjekker at det utviklerne har kodet samsvarer med spesifikasjonen og det er det.
— Fortell oss hvilke andre kvalitetssikringsdisipliner som finnes? Hva annet, foruten testing, inkluderer dette?
Anastasia: Kvalitetssikring handler for det første om å skape et kvalitetsprodukt. Det vil si at vi spør oss selv hvilke kvalitetsegenskaper produktet vårt skal ha. Følgelig, hvis vi forstår dette, kan vi sammenligne hvem som påvirker disse kvalitetsattributtene. spiller ingen rolle, utvikler, prosjektleder eller produktspesialist er en person som påvirker utviklingen av et produkt, dets backlog og dets strategi.
Testeren blir mer bevisst sin rolle. Han forstår at hans oppgave ikke bare er å teste for etterlevelse av krav, men også å teste krav, stille spørsmål ved formuleringene som kommer fra produktspesialisten, og avsløre alle implisitte krav og forventninger til kunden. Når vi leverer ny funksjonalitet til kundene våre, må vi virkelig oppfylle deres forventninger og løse deres smerter. Hvis vi tenker på alle egenskapene til kvalitet, vil kunden være fornøyd og vil forstå at selskapet hvis produkt han bruker virkelig bryr seg om interessene hans, og ikke jobber etter prinsippet om "bare for å frigi en funksjon."
— Det virker som om det du nettopp beskrev er en produktspesialists oppgave. Dette handler i prinsippet ikke om testing og ikke om kvalitet - det handler generelt om produktstyring, ikke sant?
Anastasia: Gjelder også. Kvalitetssikring er ikke en disiplin som én spesifikk person er ansvarlig for. Nå er det en populær retning innen testing, en tilnærming som kalles Smidig testing. Definisjonen hans sier tydelig at dette er en teamtilnærming til testing, som inkluderer et visst sett med praksis. Hele teamet er ansvarlig for å implementere denne tilnærmingen; det er ikke engang nødvendig at det er en tester på laget. Hele teamet er fokusert på å levere verdi til kunden og sikre at verdien møter kundenes forventninger.
— Det viser seg at kvalitet skjærer seg med nesten alle omkringliggende disipliner, og legger rammeverk på alt rundt?
Anastasia: Ikke sant. Når vi tenker på det faktum at vi ønsker å lage et kvalitetsprodukt, begynner vi å tenke på de forskjellige egenskapene til kvalitet. For eksempel hvordan sjekke at vi virkelig har laget funksjonen som kunden vår trenger.
Det er her denne typen testing kommer inn: UAT (testing av brukeraksept). Dessverre praktiseres det sjelden i Russland, men er noen ganger til stede i SCRUM-team som en demo for sluttklienten. Dette er en ganske vanlig type testing i utenlandske selskaper. Før vi åpner funksjonaliteten for alle klienter, gjør vi først UAT, det vil si at vi inviterer sluttbrukeren som tester og umiddelbart gir tilbakemelding – om produktet virkelig oppfyller forventningene og løser smerten. Først etter dette skjer skalering til alle andre klienter.
Det vil si at vi fokuserer på virksomheten, på sluttkunden, men samtidig ikke glem teknologien. Kvaliteten på produktet avhenger også i stor grad av teknologi. Hvis vi har en dårlig arkitektur, vil vi ikke raskt kunne gi ut funksjoner og møte kundenes forventninger. Det kan være mange feil når vi prøver å skalere, eller når vi prøver å refaktorere, kan vi ødelegge noe. Alt dette vil påvirke kundetilfredsheten.
Fra dette synspunktet bør arkitekturen være slik at vi kan skrive ren kode som lar oss raskt gjøre endringer og ikke være redd for at vi skal bryte alt. Slik at revisjonsgjentakelser ikke strekker seg over flere måneder rett og slett fordi vi har så mye arv, og vi må gjøre lange teststadier.
— Totalt sett er utviklere, arkitekter, produktforskere, produktsjefer og testere selv allerede involvert. Hvem andre er involvert i kvalitetssikringsprosessen?
Anastasia: La oss nå forestille oss at vi allerede har levert funksjonen til klienten. Det er klart at kvaliteten på produktet må overvåkes selv når det allerede er i produksjon. På dette stadiet kan det oppstå situasjoner med ikke-opplagte scenarier, såkalte bugs.
Det første spørsmålet er hvordan vi håndterer disse feilene etter at vi allerede har gitt ut produktet? Hvordan reagerer vi for eksempel på stress? Klienten vil ikke være veldig fornøyd hvis siden tar mer enn 30 sekunder å laste.
Det er her utnyttelse spiller inn eller, som de kaller det nå, DevOps. Dette er faktisk personene som er ansvarlige for å betjene produktet når det allerede er i produksjon. Dette inkluderer ulike typer overvåking. Det er til og med en undertype av testing - testing på produksjon, når vi tillater oss å ikke teste noe før utgivelse og tester det umiddelbart på produksjon. Dette er en serie aktiviteter fra synspunktet om å organisere infrastruktur som lar deg raskt reagere på en hendelse, påvirke den og korrigere den.
Infrastruktur er også viktig. Det er ofte situasjoner hvor det under en test er umulig å sikre at vi virkelig har alt vi ønsker å gi til klienten. Vi ruller den ut i produksjon og begynner å fange opp ikke-opplagte situasjoner. Og alt fordi infrastrukturen i testen ikke samsvarer med infrastrukturen i produksjonen. Dette fører til en ny type testing - infrastrukturtesting. Disse inkluderer ulike konfigurasjoner, innstillinger, databasemigreringer, etc.
Dette reiser spørsmålet - kanskje teamet må bruke infrastruktur som kode.
Jeg tror at infrastruktur direkte påvirker kvaliteten på produktet.
Jeg håper det kommer en rapport på konferansen med en reell sak. Skriv til oss hvis du er klar til å fortelle oss fra egen erfaring hvordan infrastruktur som kode påvirker kvaliteten. Infrastruktur som kode gjør det enklere å sjekke alle innstillinger og teste ting som ellers rett og slett ikke er mulig. Derfor er drift også involvert i prosessen med å utvikle et kvalitetsprodukt.
— Hva med analyser og dokumentasjon?
Anastasia: Dette gjelder mer for bedriftssystemer. Når vi snakker om bedrift, kommer folk som analytikere og systemanalytikere umiddelbart til tankene. Noen ganger kalles de tekniske forfattere. De får en oppgave om å skrive en spesifikasjon og fullføre den for eksempel i en måned.
Det har gjentatte ganger blitt bevist at skriving av slik dokumentasjon fører til svært lange utviklingsgjentakelser og lange gjentakelser av forfining, fordi under testprosessen identifiseres feil og returer begynner. Som et resultat er det mange løkker som øker utviklingskostnadene. I tillegg kan dette introdusere sårbarheter. Vi ser ut til å ha skrevet referansekode, men så gjorde vi endringer som bryter den perfekt gjennomtenkte arkitekturen.
Sluttresultatet er et ikke helt høykvalitetsprodukt, fordi det allerede har dukket opp patcher i arkitekturen, koden noen steder er ikke tilstrekkelig dekket av tester, fordi tidsfristene renner ut, alle feilene må lukkes raskt. Og alt fordi den opprinnelige spesifikasjonen ikke tok hensyn til alle punktene som må implementeres.
Utviklere er ikke skadedyr og skriver ikke kode med feil med vilje.
Hvis vi i utgangspunktet hadde tenkt gjennom en spesifikasjon som ville ha dekket alle nødvendige punkter, så hadde alt blitt implementert akkurat etter behov. Men dette er en utopi.
Det er sannsynligvis umulig å skrive en perfekt 100-siders spesifikasjon. Derfor må tenke på alternative måter å skrive dokumentasjon på, spesifikasjoner, sette oppgaver som vil bringe oss nærmere å sikre at utvikleren gjør akkurat det som trengs.
Her kommer tilnærminger fra Agile til tankene – brukerhistorier med akseptkriterier. Dette er mer anvendelig for team som utvikler seg i små iterasjoner.
— Hva med brukervennlighetstesting, produktbrukbarhet, design?
Anastasia: Dette er et veldig viktig poeng, fordi det er designere på laget. Oftest brukes designere som en tjeneste – enten av en designavdeling eller av en utkontraktert designer. Det er ofte situasjoner der det ser ut til at designeren lyttet til produktforskeren og gjorde det han forsto. Men når vi starter iterasjonen, viser det seg at det som faktisk ble gjort ikke var det som var forventet: designeren glemte noe, tenkte ikke helt gjennom oppførselen, fordi han ikke var med på laget og ikke i konteksten, eller fronten -Utvikleren forsto ikke fullt ut layouten. Det kan ta flere iterasjoner bare fordi det er et problem med front-end-utviklerens forståelse av designet.
I tillegg er det ett problem til. Designsystemer blir nå stadig mer populært. De er på hype, men fordelene med dem er ikke helt åpenbare.
Jeg kommer over oppfatningen om at designsystemer på den ene siden forenkler utviklingen, men på den andre siden legger de mange begrensninger på grensesnittet.
Som et resultat lager vi ikke funksjonen som klienten ønsker, men den som er praktisk for oss, fordi vi allerede har visse kuber som vi kan lage den fra.
Jeg tror det er verdt å ta hensyn til dette emnet og lure på om vi i forsøket på å forenkle designarbeid faktisk løser klientens smerter.
— Det er overraskende mange temaer knyttet til Kvalitetssikring. Finnes det en konferanse i Russland hvor alle kan diskuteres?
Anastasia: Det er den eldste testkonferansen, som arrangeres for 25. gang i år og kalles SQA Days Quality Assurance Conference. Den diskuterer hovedsakelig verktøy og spesifikke testmetoder for funksjonstestere. Som regel undersøker rapportene på SQA Days spesifikke områder i ansvarsområdet til testerne selv, men ikke komplekse aktiviteter.
Dette hjelper mye med å forstå forskjellige verktøy og tilnærminger, hvordan man tester databaser, APIer, etc. Men samtidig motiverer det på den ene siden ikke å involvere mer enn bare testing i å skape et bedre produkt. På den annen side blir ikke testerne mer involvert i prosessen for å tenke på det globale målet for produktet og dets forretningskomponent.
Jeg driver en stor avdeling og gjennomfører mange intervjuer som virkelig gir innsikt i tilstanden til bransjen som helhet. Som regel jobber gutta våre i bedrifter, og de har et klart ansvarsområde. Kolleger som jobber i utenlandske prosjekter bruker forskjellige typer testing: de kan selv utføre belastningstesting, ytelsestesting og til og med noen ganger sikkerhetstesting, fordi de virkelig hjelper teamet med å sikre kvaliteten på produktet.
Jeg skulle ønske at gutta i Russland også begynte å tenke på det faktum at industrien ikke slutter med funksjonstesting.
— For dette formålet arrangerer vi en ny konferanse, QualityConf, som er dedikert til kvalitet som en integrert disiplin. Fortell oss mer om ideen, hva er hovedmålet med konferansen?
Anastasia: Vi ønsker å skape et fellesskap av mennesker som er interessert i å lage kvalitetsprodukter. Tilby en plattform hvor de kan komme, lytte til rapporter og dra etter konferansen med en spesifikk forståelse av hva som må endres for å forbedre kvaliteten.
Nå for tiden hører jeg ofte en forespørsel fra konsulent om hva man skal gjøre når det er problemer med testing og kvalitet. Når du begynner å kommunisere med team, ser du at problemet ikke ligger hos testerne selv, men i hvordan prosessen er strukturert. For eksempel, når utviklere mener at de kun er ansvarlige for å skrive kode, slutter ansvaret deres akkurat i det øyeblikket de overlater oppgaven til testing.
Ikke alle tenker over det faktum at dårlig skrevet kode av lav kvalitet med dårlig arkitektur truer med store problemer for prosjektet. De tenker ikke på kostnadene ved feil, at feil som havner i produksjonen kan resultere i store kostnader for selskapet og teamet. Det er ingen kultur for å tenke på dette. Jeg vil at vi skal begynne å distribuere det på konferansen.
Jeg forstår at dette ikke er en nyvinning.Edward Deming, forfatteren av de 14 kvalitetsprinsippene, skrev om kostnadene ved en feil i forrige århundre. Kvalitetssikring som disiplin er basert på denne boken, men dessverre glemmer moderne utvikling det.
— Har du tenkt å berøre temaer direkte om testing og verktøy?
Anastasia: Jeg innrømmer at det kommer rapporter om verktøy. Det finnes ganske universelle verktøy som bedrifter og team kan påvirke produktet med.
Alle rapporter vil være globalt forent av ett felles oppdrag: å formidle til publikum at vi ved hjelp av denne tilnærmingen, verktøyet, metoden, prosessen, type testing, har påvirket kvaliteten på produktet og forbedret livet til kunden.
Vi vil definitivt ikke ha rapporter om et verktøy for et verktøys skyld. Alle rapporter som inngår i programmet vil forenes av et felles mål.
— Hvem vil være interessert i det du snakker om, hvem du ser på som gjester på konferansen?
Anastasia: Vi vil ha rapporter for utviklere som bryr seg om skjebnen til prosjektet, produktet, systemet deres. På samme måte vil det være av interesse for testere og, ser det ut til, spesielt for ledere. Med ledere mener jeg mennesker som tar beslutninger og kan påvirke skjebnen og utviklingen til et produkt, system, team også.
Dette er folk som lurer på hvordan man kan forbedre kvaliteten på et produkt eller system. På vår konferanse vil de lære om ulike sett med tiltak og vil kunne forstå hva som feiler dem nå og hva som må endres.
Jeg tror hovedkriteriet er å forstå at noe er galt med kvalitet og ønsker å påvirke det. Vi vil nok ikke klare å nå de som tror at dette vil gjøre det første gangen.
— Tror du bransjen som helhet er moden for å snakke ikke bare om testing, men om en kvalitetskultur?
Anastasia: Jeg tror jeg har modnet. Nå beveger mange bedrifter seg bort fra den tradisjonelle Waterfall-tilnærmingen til Agile. Det er et kundefokus, folk i team begynner virkelig å tenke på hvordan man kan lage et kvalitetsprodukt. Selv bedriftsbedrifter fokuserer på nytt på å forbedre kvaliteten.
Å dømme etter antall forespørsler som dukker opp i samfunnet, tror jeg at det er på tide. Jeg er selvfølgelig ikke sikker på at dette vil være en storstilt revolusjon, men jeg skulle ønske at denne revolusjonen i bevisstheten skulle skje.
- Enig! Vi skal innpode kultur og endre bevissthet.
Konferanse om høykvalitetsutvikling av IT-produkter vil finne sted i Moskva 7. juni. Du vet hvilke stadier som utgjør et høykvalitetsprodukt, vi har tilfeller av vellykket bekjempelse av feil i produksjonen, vi har testet populære metoder i vår praksis - vi trenger din erfaring. deres søknader innen 1. mai, og programkomiteen vil bidra til å fokusere temaet for den generelle integriteten til konferansen.
Koble til , der vi diskuterer kvalitetsspørsmål og konferansen, abonnere på for å holde deg oppdatert med programnyheter.
Kilde: www.habr.com