Vem ansvarar för kvaliteten?

Hej, Habr!

Vi har ett nytt viktigt ämne – kvalitetsutveckling av IT-produkter. Vi pratar ofta på HighLoad++ om hur man gör belastade tjänster snabba, och på Frontend Conf om en häftig användargränssnitt som inte laggar. Vi har regelbundet ämnen om testning och DevOpsConf om att förena olika processer, inklusive testning. Men när det kommer till vad man kan kalla kvalitet i helhet och hur man arbetar med det på ett heltäckande sätt – finns det inget.

Vi fixar det till QualityConf – vi kommer att utveckla kulturen av att tänka på kvaliteten av den slutliga produkten för användaren i varje utvecklingsstadium. En vana att inte fastna i sitt eget ansvarsområde och att associera kvalitet inte bara med testare.

Under rubriken pratar vi med ordföranden för programkommittén, testledaren på Tinkoff Business, skaparen av den rysktalande QA-gemenskapen Anastasia Aseeva-Nguyen om tillståndet inom QA-branschen och syftet med den nya konferensen.

– Hej Nastya. Berätta gärna lite om dig själv.

Anastasia: Jag leder testningen på banken, ansvarar för ett mycket stort team – vi är fler än 90 personer. Vi har ett viktigt affärsområde, vi ansvarar för ekosystemet för juridiska personer.

Jag studerade på matematik och mekanik och ville från början bli programmerare. Men när jag fick ett intressant erbjudande bestämde jag mig för att prova på att vara testare. Konstig nog visade det sig vara mitt kall. Nu ser jag hela mitt arbete som en del av denna bransch.

Jag är en entusiastisk förespråkare av Quality Assurance-disciplinen. Det betyder mycket för mig vilka produkter som skapas, hur man förhåller sig till kvalitet inom företaget, i teamet och i princip i utvecklingsprocessen.

För mig är det uppenbart att gemenskapen inom detta område är inte tillräckligt mogen, åtminstone i Ryssland. Vi förstår inte alltid att kvalitetssäkring inte bara handlar om själva testandet av en applikation mot krav. Jag skulle vilja förändra denna situation.

– Du använder orden Quality Assurance och testning. I allmänhetens ögon överlappar dessa två termer ofta. Hur skiljer de sig åt om man gräver djupare?

Anastasia: Nej, de skiljer sig faktiskt inte. Testning är en del av kvalitetssäkring, det är en omedelbar aktivitet – själva faktum att jag testar något. Det finns faktiskt många olika typer av testning, och olika typer av testning hanteras av olika personer. Men i Ryssland, när vågen av outsourcingföretag dök upp som tillhandahåller testare till företag, har testning reducerats till en enda typ.

I de flesta fall begränsar man sig till funktionell testning: man kontrollerar att det som utvecklarna har kodad motsvarar specifikationen och inget mer.

– Berätta gärna, vilka andra discipliner finns det inom kvalitetssäkring? Vad mer, förutom testning, ingår här?

Anastasia: Kvalitetssäkring handlar först och främst om att skapa en kvalitetsprodukt. Det vill säga, vi ställer oss frågan vilka kvalitetsegenskaper vår produkt bör ha. Om vi förstår detta kan vi också identifiera vem som påverkar dessa kvalitetsegenskaper. Det spelar ingen roll, utvecklare, projektledare eller produktägare – är den personen som påverkar produktens utveckling, dess backlog och dess strategi.

Testaren börjar bättre förstå sin roll. Han eller hon inser att uppgiften inte bara handlar om att testa mot krav, utan också om att testa kraven, ifrågasätta formuleringar som kommer från produktägaren, identifiera alla underliggande krav och kundens förväntningar. När vi levererar ny funktionalitet till vår kund måste vi verkligen uppfylla deras förväntningar och lösa deras problem. Om vi tänker på alla kvalitetsegenskaper kommer kunden att vara nöjd och förstå att företaget vars produkt han eller hon använder verkligen bryr sig om deras intressen, och inte bara arbetar utifrån principen 'bara släppa en funktion'.

– Det verkar som det du just beskrev – det är produktägarens uppgift. Det handlar egentligen inte om testning och inte om kvalitet – det handlar överhuvudtaget om produktledning, eller hur?

Anastasia: Delvis. Kvalitetssäkring är inte en disciplin som ansvarar för en specifik person. Nu finns det en populär inriktning inom testning, en metodik som kallas Agil testningI definitionen står det direkt att detta är ett teamorienterat tillvägagångssätt för testning som omfattar en viss uppsättning metoder. Genomförandet av detta tillvägagångssätt ansvarar hela teamet för, det är inte nödvändigt att det finns en testare i teamet. Hela teamet är fokuserat på att leverera värde till kunden och att detta värde motsvarar hans förväntningar.

— Så kvalitet korsar sig med nästan alla omgivande discipliner och sätter ramar för allt omkring?

Anastasia: Precis. När vi tänker på att skapa en kvalitetsprodukt börjar vi tänka på olika kvalitetsattribut. Till exempel, hur ska vi kontrollera att vi verkligen har gjort en funktion som vår kund behöver.

Då dyker en typ av testning upp som UAT (användartestning). Tyvärr praktiseras detta sällan i Ryssland, men förekommer ibland i SCRUM-team som en demo för slutkunden. I utländska företag är detta en ganska vanlig typ av testning. Innan vi öppnar funktionaliteten för alla kunder gör vi först UAT, det vill säga vi bjuder in slutanvändaren som genomför tester och ger omedelbar feedback — om produkten verkligen uppfyller förväntningarna och löser problemet. Först efter detta sker en skalning till alla andra kunder.

Så vi fokuserar på affärer, på slutkunden, men glömmer inte heller teknologin. Teknologi påverkar också starkt produktens kvalitet. Om vi har en dålig arkitektur kan vi inte snabbt släppa funktioner och motsvara kundens förväntningar. Det kan uppstå många buggar vid försök att skala, eller vid försök att göra refaktorisering kan vi råka bryta något. Allt detta kommer att påverka kundens tillfredsställelse.Ur detta perspektiv bör arkitekturen vara sådan att vi kan skriva ren kod som gör det möjligt att snabbt göra ändringar utan att vara rädda för att vi förstör allt. För att iterationer av förbättringar inte ska sträcka sig över flera månader endast på grund av att vi har så mycket legacy och behöver genomföra långa testfaser.

— Sammanfattningsvis är utvecklare, arkitekter, produktentusiaster, produktchefer och själva testarna redan involverade. Vem mer är involverad i processen för att säkerställa kvalitet?

— Totalt är det redan utvecklare, arkitekter, produktutvecklare, produktchefer och testare involverade. Vem mer är involverad i processen för kvalitetskontroll?

Anastasia: Låt oss nu föreställa oss att vi har levererat funktionen till kunden. Det är uppenbart att vi måste övervaka produktens kvalitet när den väl är i produktion. Vid denna tidpunkt kan situationer med oväntade scenarier och så kallade buggar uppstå.

Den första frågan är hur vi arbetar med dessa buggar efter att produkten redan har släppts? Hur reagerar vi till exempel på belastning? Kunden kommer inte att vara särskilt nöjd om sidan laddas i mer än 30 sekunder.

Här spelar drift eller, som det nu kallas, DevOps. I praktiken handlar det om människor som ansvarar för produktens drift när den väl är i produktion. Det inkluderar olika typer av övervakning. Det finns till och med en underkategori av testning - produkttestning, där vi tillåter oss att inte testa något före lanseringen och testar det direkt i produktionen. Det handlar om åtgärder när det gäller att organisera infrastrukturen som möjliggör snabba reaktioner på incidenter, påverkar dem och åtgärdar dem.

Infrastrukturen är också viktig. Det är ofta så att under testningen kan vi inte vara säkra på att vi verkligen har allt det som vi skulle vilja ge kunden. Vi släpper ut i produktion - och börjar fånga oväntade situationer. Allt beroende på att infrastrukturen i testen inte stämmer överens med infrastrukturen i produktionen. Härifrån härstammar en ny typ av testning - infrastrukturtestning. Det handlar om olika konfigurationer, inställningar, databas-migrering och så vidare.

Här uppstår frågan - kanske teamet behöver använda infrastruktur som kod.

Jag tror att infrastrukturen direkt påverkar produktens kvalitet.

Jag hoppas att det kommer att finnas en presentation med en verklig fallstudie på konferensen. Skriv till oss om du är redo att dela med dig av din erfarenhet om hur infrastruktur som kod påverkar kvaliteten. Infrastruktur som kod gör det enklare att kontrollera alla inställningar och testa vad som annars är omöjligt. Därför involveras driften i utvecklingsprocessen av kvalitetsprodukter.

– Och hur är det med analys och dokumentation?

Anastasia: Det handlar mer om enterprise-system. När vi pratar om enterprise, dyker genast sådana personer som analytiker och systemanalytiker upp i tankarna. Ibland kallas de tekniska skribenter. De får i uppdrag att skriva en specifikation och utför den, till exempel under en månad.

Det har upprepade gånger bevisats att skrivande av sådan dokumentation leder till mycket långa utvecklingsiterationer och långa iterationer av revideringar, eftersom buggar upptäcks under testningen och det blir returer. Resultatet blir många loopar som ökar utvecklingskostnaden. Dessutom kan detta introducera sårbarheter. Vi har visserligen skrivit referenskod, men sedan har vi gjort ändringar som bryter den perfekt genomtänkta arkitekturen.

Slutprodukten blir inte helt kvalitativ eftersom arkitekturen redan har fått lappar, koden är inte tillräckligt testad på vissa ställen för att tidsfristen är pressande och allt måste fixas snabbare. Allt detta beror på att inte alla punkter som behöver genomföras togs upp i den ursprungliga specifikationen.

Utvecklare är inte skadliga och skriver inte medvetet kod med fel.

Om vi hade tänkt igenom specifikationen från början där alla nödvändiga punkter belyses skulle allt ha genomförts precis som det skulle. Men det är en utopi.

Det är nog omöjligt att skriva en perfekt specifikation på 100 sidor. Därför måste vi tänka på alternativa sätt att skriva dokumentation, specificera, ställa upp uppgifter som skulle föra oss närmare att utvecklaren gör exakt vad som behövs.

Då kommer jag att tänka på metoder från Agile – användarberättelser med acceptanskriterier. Detta är mer tillämpligt för team som utvecklas i små iterationer.

– Vad kan vi säga om användartester, användbarheten av produkten, designen?

Anastasia: Det är en mycket viktig punkt eftersom det finns designers i teamet. Oftast används designers som en tjänst – antingen en designeravdelning eller en designer på extern basis. Det är ofta situationer där det verkar som om designern har lyssnat på produktansvariga och gjort det som han eller hon förstod. Men när vi börjar med iterationen visar det sig att det verkligen inte gjordes som förväntat: designern har glömt något, inte helt tänkt igenom beteendet eftersom han eller hon inte är i teamet och inte i kontexten, eller frontendutvecklaren har inte helt förstått hans eller hennes skiss. Det kan behövas flera iterationer bara på grund av att det finns ett problem med att förstå designen av frontendutvecklaren.

Det finns också ett annat problem. Designsystem blir alltmer populära. De är på hajpen, men fördelarna med dem är inte helt uppenbara.

Jag stöter på åsikten att designsystem å ena sidan förenklar utvecklingen, å andra sidan lägger de på väldigt många begränsningar för gränssnittet.

Resultatet blir att vi inte gör den funktion som kunden vill ha, utan en som är bekväm för oss, eftersom vi redan har vissa komponenter som vi kan använda för att skapa den.

Jag tror att det är värt att uppmärksamma detta ämne och fundera på om vi verkligen löser kundens problem i vår strävan att förenkla designarbetet.

— Det finns otroligt många ämnen kring kvalitetssäkring. Finns det en konferens i Ryssland där man kan diskutera allt detta?

Anastasia: Det finns den äldsta konferensen för testning som i år hålls för 25:e gången och heter just SQA Days. Där diskuteras främst verktyg och specifika testmetoder för funktionella testare. Vanligtvis behandlas mer specifika områden inom testares ansvar, men inte de mer övergripande temana.

Det hjälper verkligen att förstå de olika verktygen och metoderna för hur man testar databaser, API och så vidare. Men å ena sidan motiverar det inte att involvera andra i skapandet av en mer kvalitativ produkt än bara testningen. Å andra sidan blir testarna inte mer involverade i processen för att tänka på produktens globala mål och dess affärsaspekt.

Jag leder en stor avdelning och genomför många intervjuer, vilket faktiskt ger en bild av industrins tillstånd som helhet. Vanligtvis arbetar våra killar med företag av högre standard (enterprise), och de har en tydlig ansvarszon. Kollegaer som arbetar med utländska projekt använder olika typer av testning: de kan själva genomföra belastningstest, prestandatest, och till och med ibland säkerhetstestning (security testing), eftersom de verkligen hjälper teamet att säkerställa produktens kvalitet.

Jag skulle vilja att våra killar i Ryssland också börjar tänka på att den funktionella testningen inte är slutet på industrin.

— För detta syfte arrangerar vi den nya konferensen QualityConf, som handlar om kvalitet som en helhetsdisciplin. Kan du berätta mer om idén, vad är huvudsyftet med konferensen?

Anastasia: Vi vill skapa en gemenskap av människor som är intresserade av att göra kvalitetsprodukter. Erbjuda en plattform dit de kan komma, lyssna på föreläsningar och efter konferensen gå därifrån med en konkret förståelse för vad de behöver ändra för att förbättra kvaliteten.

Jag hör ofta från konsultföretag vad man ska göra när det finns problem med testning och kvalitet. När man börjar prata med teamen ser man att problemet inte ligger hos testarna, utan i hur processen är uppbyggd. Till exempel när utvecklarna tror att de endast är ansvariga för att skriva koden, slutar deras ansvar precis i det ögonblick de överlämnar uppgiften för testning.

Inte alla tänker på att dåligt skriven, kvalitetsmässigt undermålig kod med dålig arkitektur kan leda till stora problem för projektet. De tänker inte på kostnaderna för misstag, på att buggar som hamnar i produktion kan leda till stora kostnader för företaget och teamet. Det finns ingen kultur för att tänka på detta. Jag vill att vi på konferensen ska börja sprida denna kultur.

Jag förstår att detta inte är en innovation. Edward Deming, författaren till de 14 kvalitetsprinciperna, skrev om kostnaden för misstag redan förra seklet. Denna bok ligger till grund för Quality Assurance som disciplin, men tyvärr glömmer modern utveckling detta.

— Kommer ni att ta upp ämnen direkt relaterade till testning och verktyg?

Anastasia: Jag antar att det kommer att finnas föreläsningar om verktyg. Det finns tillräckligt universella verktyg som företag och team kan använda för att påverka produkten.

Alla föreläsningar kommer övergripande att förenas av ett gemensamt uppdrag: att förmedla till publiken att med hjälp av denna metod, detta verktyg, denna process eller typ av testning har vi påverkat produktens kvalitet och förbättrat kundens liv.

Vi kommer absolut inte att ha föreläsningar om verktyg för verktygets skull. Alla föreläsningar som kommer att inkluderas i programmet kommer att förenas av ett gemensamt syfte.

— Vem kommer att vara intresserad av det du pratar om, vilka ser du som gäster på konferensen?

Anastasia: Vi kommer att ha presentationer för utvecklare som bryr sig om sina projekt, produkter och system. Detta kommer även vara intressant för testare och, som jag ser det, särskilt för chefer. Med chefer menar jag personer som fattar beslut och kan påverka ödet och utvecklingen av produkter, system och team.

Det är personer som ställer sig frågan – hur kan vi höja kvaliteten på produkter och system. På vår konferens kommer de att få veta om olika aktivitetskomplex och kunna förstå vad som inte står rätt till, vad som behöver ändras.

Jag tror att det främsta kriteriet är att förstå att det är något fel med kvaliteten och att vilja påverka det. Antagligen kommer det inte att vara möjligt att nå fram till dem som anser att allt är okej på första försöket.

– Vad tycker du, har branschen i stort mognat till att prata om inte bara testning, utan om kvalitetkultur?

Anastasia: Jag anser att den har mognat. Många företag går nu ifrån den traditionella Waterfall-metoden mot Agile. Det sker en orientering mot kunden, och folk i teamen börjar verkligen tänka på hur man kan skapa kvalitetsprodukter. Även inom storföretag sker en omorientering mot att höja kvaliteten.

Baserat på antalet förfrågningar som uppstår i samhället, anser jag att det är dags. Jag är dock inte säker på att det kommer att bli en storskalig revolution, men jag skulle vilja att denna förändring i medvetande inträffar.

– Överens om det! Vi ska föra in kulturen och förändra medvetandet.

Konferens om kvalitativ utveckling av IT-produkter QualityConf ska i Moskva den 7 juni. Vet ni vilka steg som utgör en kvalitativ produkt, vi har fallstudier av framgångsrik kamp mot buggar i produktion, vi har testat populära metoder i vår egen praktik – vi behöver er erfarenhet. Skicka era ansökningar senast den 1 maj, och den programkommittén kommer att hjälpa till att fokusera ämnet för konferensen så att den blir en helhet.

Följ med i chatten, där vi diskuterar kvalitetsfrågor och konferensen, följ gärna vår Telegram-kanal, för att hålla er uppdaterade om programmets nyheter.

Källa: habr.com