Hej Habr!
Vi har ett nytt viktigt ämne - högkvalitativ utveckling av IT-produkter. På HighLoad++ pratar vi ofta om hur man gör upptagna tjänster snabbt, och på Frontend Conf pratar vi om ett coolt användargränssnitt som inte saktar ner. Vi har regelbundet ämnen om testning och DevOpsConf om att kombinera olika processer, inklusive testning. Men om vad som kan kallas kvalitet i allmänhet, och hur man arbetar med det heltäckande - nej.
Låt oss fixa det här — Vi kommer att utveckla en kultur att tänka på kvaliteten på slutprodukten för användaren i varje utvecklingsstadium. Vanan att inte fokusera på ditt ansvarsområde och associera kvalitet inte bara med testare.
Under snittet kommer vi att prata med chefen för programkommittén, testchef på Tinkoff.Business, skaparen av den rysktalande QA-gemenskapen Anastasia Aseeva-Nguyen om QA-branschens tillstånd och uppdraget för den nya konferensen.
- Nastia hej. Berätta gärna om dig själv.
Анастасия: Jag sköter testning på en bank, jag ansvarar för ett väldigt stort team - vi är fler än 90 personer. Vi har en viktig affärslinje, vi ansvarar för ekosystemet för juridiska personer.
Jag studerade mekanik och matematik och ville först bli programmerare. Men när jag fick ett intressant erbjudande bestämde jag mig för att prova mig fram som testare. Konstigt nog visade sig detta vara mitt kall. Nu ser jag allt mitt arbete i den här branschen.
Jag är en ivrig anhängare av kvalitetssäkringsdisciplinen. Jag är inte likgiltig för vilka produkter som skapas, hur kvalitet behandlas i företaget, i teamet och i princip i utvecklingsprocessen.
Det är uppenbart för mig samhället i denna riktning är inte tillräckligt mogen, åtminstone i Ryssland. Vi förstår inte alltid att kvalitetssäkring inte bara är att testa en ansökan för att uppfylla kraven. Jag skulle vilja förändra den här situationen.
— Du använder orden Kvalitetssäkring och testning. I den genomsnittliga personens ögon överlappar dessa två termer ofta varandra. Hur skiljer de sig åt om man gräver djupt?
Anastasia: Snarare är de inte annorlunda. Testning är en del av kvalitetssäkringsdisciplinen, det är en direkt aktivitet - själva det faktum att jag testar något. Det finns faktiskt många typer av tester, och en mängd människor är ansvariga för olika typer av tester. Men här i Ryssland, när en våg av outsourcars dök upp som levererar testare till företag, reducerades testningen till en enda typ.
I de flesta fall är de begränsade endast till funktionstestning: de kontrollerar att det som utvecklarna har kodat överensstämmer med specifikationen och det är allt.
— Berätta gärna vilka andra kvalitetssäkringsdiscipliner som finns? Vad mer, förutom testning, ingår här?
Анастасия: Kvalitetssäkring handlar först och främst om att skapa en kvalitetsprodukt. Det vill säga vi frågar oss vilka kvalitetsegenskaper vår produkt ska ha. Följaktligen, om vi förstår detta, kan vi jämföra vem som påverkar dessa kvalitetsattribut. spelar ingen roll, utvecklare, projektledare eller produktspecialist är en person som påverkar utvecklingen av en produkt, dess backlog och dess strategi.
Testaren blir mer medveten om sin roll. Han förstår att hans uppgift inte bara är att testa efterlevnad av krav, utan också att testa krav, ifrågasätta formuleringarna som kommer från produktspecialisten och avslöja alla implicita krav och förväntningar från kunden. När vi levererar ny funktionalitet till våra kunder måste vi verkligen uppfylla deras förväntningar och lösa deras smärta. Om vi tänker på alla attribut av kvalitet, kommer kunden att vara nöjd och kommer att förstå att företaget vars produkt han använder verkligen bryr sig om sina intressen och inte arbetar enligt principen om "bara för att släppa en funktion."
— Det verkar som att det du just beskrev är en produktspecialists uppgift. Detta handlar i princip inte om testning och inte om kvalitet - det handlar i allmänhet om produkthantering, eller hur?
Анастасия: Inklusive. Kvalitetssäkring är inte en disciplin som en specifik person är ansvarig för. Nu finns det en populär riktning inom testning, ett tillvägagångssätt som kallas Agil testning. Hans definition anger tydligt att detta är en gruppmetod för testning, som inkluderar en viss uppsättning praxis. Hela teamet är ansvarigt för att implementera detta tillvägagångssätt, det är inte ens nödvändigt att det finns en testare i teamet. Hela teamet är fokuserat på att leverera värde till kunden och säkerställa att värdet motsvarar kundernas förväntningar.
— Det visar sig att kvalitet korsar nästan alla omgivande discipliner, vilket lägger ramar på allt runt omkring?
Анастасия: Höger. När vi tänker på hur vi vill skapa en kvalitetsprodukt börjar vi tänka på de olika egenskaperna för kvalitet. Till exempel hur man kontrollerar att vi verkligen gjort den funktion som vår kund behöver.
Det är här den här typen av testning kommer in: UAT (testning av användaracceptans). Tyvärr praktiseras det sällan i Ryssland, men finns ibland i SCRUM-team som en demo för slutkunden. Detta är en ganska vanlig typ av testning i utländska företag. Innan vi öppnar funktionaliteten för alla kunder gör vi först UAT, det vill säga vi bjuder in slutanvändaren som testar och omedelbart ger feedback – om produkten verkligen uppfyller förväntningarna och löser smärtan. Först efter detta sker skalning till alla andra klienter.
Det vill säga att vi fokuserar på affärer, på slutkunden, men samtidigt glöm inte tekniken. Kvaliteten på produkten beror också mycket på tekniken. Om vi har en dålig arkitektur kommer vi inte att snabbt kunna släppa funktioner och möta kundernas förväntningar. Det kan finnas många buggar när vi försöker skala, eller när vi försöker refaktorera kan vi gå sönder något. Allt detta kommer att påverka kundnöjdheten.
Ur denna synvinkel bör arkitekturen vara sådan att vi kan skriva ren kod som gör att vi snabbt kan göra ändringar och inte vara rädda för att vi ska bryta allt. Så att revisionsupprepningar inte sträcker sig över flera månader bara för att vi har så mycket arv, och vi behöver göra långa teststeg.
— Totalt sett är utvecklare, arkitekter, produktvetare, produktchefer och testare själva redan involverade. Vilka mer är involverade i kvalitetssäkringsprocessen?
Анастасия: Låt oss nu föreställa oss att vi redan har levererat funktionen till kunden. Självklart måste kvaliteten på produkten övervakas även när den redan är i produktion. I detta skede kan situationer med icke uppenbara scenarier, så kallade buggar, dyka upp.
Den första frågan är hur vi hanterar dessa buggar efter att vi redan har släppt produkten? Hur reagerar vi till exempel på stress? Kunden kommer inte att vara särskilt nöjd om sidan tar mer än 30 sekunder att ladda.
Det är här exploatering kommer in i bilden eller, som de kallar det nu, DevOps. I själva verket är det dessa personer som är ansvariga för driften av produkten när den redan är i produktion. Detta inkluderar olika typer av övervakning. Det finns till och med en undertyp av testning - testning på produktion, när vi tillåter oss själva att inte testa något innan utrullning och testa det direkt i produktion. Detta är en serie åtgärder ur synvinkeln att organisera infrastruktur som gör att du snabbt kan reagera på en incident, påverka den och korrigera den.
Infrastruktur är också viktig. Det finns ofta situationer när det under ett test är omöjligt att försäkra sig om att vi verkligen har allt som vi skulle vilja ge till kunden. Vi rullar ut det i produktion och börjar fånga icke uppenbara situationer. Och allt för att infrastrukturen i testet inte överensstämmer med infrastrukturen i produktionen. Detta leder till en ny typ av testning - infrastrukturtestning. Dessa är olika konfigurationer, inställningar, databasmigrering, etc.
Detta väcker frågan - kanske måste teamet använda infrastruktur som kod.
Jag tror att infrastruktur direkt påverkar kvaliteten på produkten.
Jag hoppas att det kommer en rapport på konferensen med ett verkligt fall. Skriv till oss om du är redo att berätta av din egen erfarenhet hur infrastruktur som kod påverkar kvaliteten. Infrastruktur som kod gör det lättare att kontrollera alla inställningar och testa saker som annars helt enkelt inte är möjliga. Därför är driften också involverad i processen att utveckla en kvalitetsprodukt.
— Hur är det med analys och dokumentation?
Анастасия: Detta gäller mer för företagssystem. När vi talar om företagande kommer människor som analytiker och systemanalytiker omedelbart att tänka på. De kallas ibland tekniska författare. De får i uppdrag att skriva en specifikation och slutföra den, till exempel under en månad.
Det har upprepade gånger bevisats att skrivandet av sådan dokumentation leder till mycket långa utvecklingsiterationer och långa iterationer av förfining, eftersom buggar identifieras under testprocessen och returer börjar. Som ett resultat finns det många loopar som ökar utvecklingskostnaderna. Dessutom kan detta introducera sårbarheter. Vi verkar ha skrivit referenskod, men sedan gjorde vi ändringar som bryter den perfekt genomtänkta arkitekturen.
Slutresultatet är en inte helt högkvalitativ produkt, eftersom patchar redan har dykt upp i arkitekturen, koden på vissa ställen täcks inte tillräckligt av tester, eftersom deadlines håller på att löpa ut, alla buggar måste stängas snabbt. Och allt för att den ursprungliga specifikationen inte tog hänsyn till alla punkter som måste implementeras.
Utvecklare är inte skadedjur och skriver inte kod med fel med avsikt.
Om vi från början hade tänkt igenom en specifikation som skulle ha täckt alla nödvändiga punkter, då skulle allt ha implementerats precis efter behov. Men detta är en utopi.
Det är förmodligen omöjligt att skriva en perfekt 100-sidig specifikation. Det är därför behöver fundera över alternativa sätt att skriva dokumentation, specifikationer, sätta uppgifter som skulle föra oss närmare att säkerställa att utvecklaren gör exakt vad som behövs.
Här dyker upp tillvägagångssätt från Agile – användarberättelser med acceptanskriterier. Detta är mer tillämpligt för team som utvecklas i små iterationer.
— Hur är det med användbarhetstestning, produktanvändbarhet, design?
Анастасия: Detta är en mycket viktig punkt, eftersom det finns designers i teamet. Oftast används designers som en tjänst – antingen av en designavdelning eller av en utlagd designer. Det finns ofta situationer där det verkar som att designern lyssnade på produktspecialisten och gjorde vad han förstod. Men när vi startar iterationen visar det sig att det som faktiskt gjordes inte var vad som förväntades: designern glömde något, tänkte inte igenom beteendet fullt ut, eftersom han inte är med i laget och inte i sammanhanget, eller fronten. -Utvecklaren förstod inte helt layouten. Det kan ta flera iterationer bara för att det finns ett problem med att frontend-utvecklaren förstår designen.
Plus att det finns ett problem till. Designsystem blir nu allt populärare. De är på hype, men fördelarna med dem är inte helt uppenbara.
Jag stöter på uppfattningen att designsystem å ena sidan förenklar utvecklingen, men å andra sidan sätter de en hel del restriktioner på gränssnittet.
Som ett resultat gör vi inte den funktion som klienten vill ha, utan den som är bekväm för oss, eftersom vi redan har vissa kuber som vi kan göra den från.
Jag tycker att detta är ett ämne som är värt att ta en titt på och undra om vi, när vi försöker göra design lättare, faktiskt löser en klientsmärta.
— Det finns förvånansvärt många ämnen relaterade till kvalitetssäkring. Finns det en konferens i Ryssland där alla kan diskuteras?
Анастасия: Det finns den äldsta testkonferensen, som kommer att hållas för 25:e gången i år och kallas SQA Days Quality Assurance Conference. Den diskuterar främst verktyg och specifika testmetoder för funktionella testare. Som regel undersöker rapporterna på SQA Days djupt specifika områden inom testarnas ansvarsområde, men inte komplexa aktiviteter.
Detta hjälper mycket för att förstå olika verktyg och tillvägagångssätt, hur man testar databaser, API:er, etc. Men samtidigt motiverar det å ena sidan inte att involvera mer än att bara testa i skapandet av en bättre produkt. Å andra sidan blir testare inte mer involverade i processen att tänka på det globala målet för produkten och dess affärskomponent.
Jag driver en stor avdelning och genomför en hel del intervjuer som verkligen ger en inblick i läget i branschen som helhet. Som regel arbetar våra killar i företag, och de har ett tydligt ansvarsområde. Kollegor som arbetar i utländska projekt använder olika typer av tester: de kan själva göra belastningstester, prestandatester och även ibland säkerhetstester, eftersom de verkligen hjälper teamet att säkerställa kvaliteten på produkten.
Jag skulle vilja att killarna i Ryssland också började tro att branschen inte slutar med funktionstestning.
— För detta ändamål anordnar vi en ny konferens, QualityConf, som är tillägnad kvalitet som en integrerad disciplin. Berätta mer om idén, vad är huvudmålet med konferensen?
Анастасия: Vi vill skapa en gemenskap av människor som är intresserade av att tillverka kvalitetsprodukter. Erbjud en plattform dit de kan komma, lyssna på rapporter och lämna efter konferensen med en specifik förståelse för vad som behöver förändras för att förbättra kvaliteten.
Numera får jag ofta en förfrågan från konsult om vad man ska göra när det är problem med testning och kvalitet. När man börjar kommunicera med team ser man att problemet inte ligger hos testarna själva, utan i hur processen är uppbyggd. Till exempel, när utvecklare tror att de bara är ansvariga för att skriva kod, slutar deras ansvar precis i samma ögonblick som de lämnar över uppgiften till testning.
Alla tänker inte på det faktum att dåligt skriven kod av låg kvalitet med dålig arkitektur hotar stora problem för projektet. De tänker inte på kostnaden för fel, att buggar som hamnar i produktionen kan resultera i stora kostnader för företaget och teamet. Det finns ingen kultur att tänka på detta. Jag vill att vi börjar dela ut det på konferensen.
Jag förstår att detta inte är en innovation.Edward Deming, författaren till de 14 kvalitetsprinciperna, skrev om kostnaden för ett fel under förra seklet. Kvalitetssäkring som disciplin bygger på denna bok, men tyvärr glömmer den moderna utvecklingen bort det.
— Tänker du beröra ämnen direkt om testning och verktyg?
Анастасия: Jag erkänner att det kommer rapporter om verktyg. Det finns ganska universella verktyg med vilka företag och team kan påverka produkten.
Alla rapporter kommer globalt att förenas av ett gemensamt uppdrag: att förmedla till publiken att vi med hjälp av detta tillvägagångssätt, verktyg, metod, process, typ av testning har påverkat produktens kvalitet och förbättrat kundens liv.
Vi kommer definitivt inte att ha rapporter om ett verktyg för ett verktygs skull. Alla rapporter som ingår i programmet kommer att förenas av ett gemensamt mål.
— Vem kommer att vara intresserad av vad du pratar om, vilka du ser som gäster på konferensen?
Анастасия: Vi kommer att ha rapporter för utvecklare som bryr sig om ödet för deras projekt, produkt, system. Likaså kommer det att vara av intresse för testare och, det förefaller mig, särskilt för chefer. Med chefer menar jag människor som fattar beslut och kan påverka ödet och utvecklingen av en produkt, ett system, ett team också.
Det här är människor som undrar hur man kan förbättra kvaliteten på en produkt eller ett system. På vår konferens kommer de att lära sig om olika uppsättningar av åtgärder och kommer att kunna förstå vad som är fel på dem nu och vad som behöver ändras.
Jag tror att huvudkriteriet är att förstå att något är fel med kvalitet och vilja påverka det. Vi kommer troligen inte att kunna nå folk som tror att det här kommer att duga bara första gången.
— Tror du att branschen som helhet är mogen att prata inte bara om tester utan om en kvalitetskultur?
Анастасия: Jag tror att jag har mognat. Nu går många företag bort från den traditionella vattenfallsstrategin mot Agile. Det finns ett kundfokus, folk i team börjar verkligen fundera på hur man skapar en kvalitetsprodukt. Även företagsföretag fokuserar om på att förbättra kvaliteten.
Att döma av antalet förfrågningar som dyker upp i samhället tycker jag att det är dags. Jag är naturligtvis inte säker på att det här kommer att bli en storskalig revolution, men jag skulle vilja att denna revolution i medvetandet skulle ske.
- Gick med på! Vi kommer att ingjuta kultur och förändra medvetandet.
Konferens om högkvalitativ utveckling av IT-produkter kommer att äga rum i Moskva den 7 juni. Du vet vilka stadier som utgör en högkvalitativ produkt, vi har fall av framgångsrik bekämpning av buggar i produktionen, vi har testat populära metoder i vår praktik - vi behöver din erfarenhet. deras ansökningar senast 1 maj, och programkommittén kommer att hjälpa till att fokusera temat för konferensens övergripande integritet.
Koppla till , där vi diskuterar kvalitetsfrågor och konferensen, prenumerera på för att hålla dig uppdaterad med programnyheter.
Källa: will.com