{"id":31264,"date":"2019-10-31T21:40:21","date_gmt":"2019-10-31T18:40:21","guid":{"rendered":"https:\/\/prohoster.info\/blog\/kto-otvetit-za-kachestvo\/"},"modified":"2019-10-31T21:40:21","modified_gmt":"2019-10-31T18:40:21","slug":"kto-otvetit-za-kachestvo","status":"publish","type":"post","link":"https:\/\/prohoster.info\/sv\/blog\/administrirovanie\/kto-otvetit-za-kachestvo","title":{"rendered":"Vem ansvarar f\u00f6r kvaliteten?","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Hej, Habr!<\/p>\n

Vi har ett nytt viktigt \u00e4mne \u2013 kvalitetsutveckling av IT-produkter. Vi pratar ofta p\u00e5 HighLoad++ om hur man g\u00f6r belastade tj\u00e4nster snabba, och p\u00e5 Frontend Conf om en h\u00e4ftig anv\u00e4ndargr\u00e4nssnitt som inte laggar. Vi har regelbundet \u00e4mnen om testning och DevOpsConf om att f\u00f6rena olika processer, inklusive testning. Men n\u00e4r det kommer till vad man kan kalla kvalitet i helhet och hur man arbetar med det p\u00e5 ett helt\u00e4ckande s\u00e4tt \u2013 finns det inget.<\/p>\n

Vi fixar det till QualityConf<\/a><\/noindex>\u00a0\u2013 vi kommer att utveckla kulturen av att t\u00e4nka p\u00e5 kvaliteten av den slutliga produkten f\u00f6r anv\u00e4ndaren i varje utvecklingsstadium. En vana att inte fastna i sitt eget ansvarsomr\u00e5de och att associera kvalitet inte bara med testare.<\/p>\n

Under rubriken pratar vi med ordf\u00f6randen f\u00f6r programkommitt\u00e9n, testledaren p\u00e5 Tinkoff Business, skaparen av den rysktalande QA-gemenskapen Anastasia Aseeva-Nguyen<\/b> om tillst\u00e5ndet inom QA-branschen och syftet med den nya konferensen.<\/p>\n

\"Vem
\n<\/a><\/noindex>
\n\u2013 Hej Nastya. Ber\u00e4tta g\u00e4rna lite om dig sj\u00e4lv.<\/em><\/strong><\/p>\n

\"VemAnastasia<\/strong>: Jag leder testningen p\u00e5 banken, ansvarar f\u00f6r ett mycket stort team \u2013 vi \u00e4r fler \u00e4n 90 personer. Vi har ett viktigt aff\u00e4rsomr\u00e5de, vi ansvarar f\u00f6r ekosystemet f\u00f6r juridiska personer.<\/p>\n

Jag studerade p\u00e5 matematik och mekanik och ville fr\u00e5n b\u00f6rjan bli programmerare. Men n\u00e4r jag fick ett intressant erbjudande best\u00e4mde jag mig f\u00f6r att prova p\u00e5 att vara testare. Konstig nog visade det sig vara mitt kall. Nu ser jag hela mitt arbete som en del av denna bransch.<\/p>\n

Jag \u00e4r en entusiastisk f\u00f6respr\u00e5kare av Quality Assurance-disciplinen. Det betyder mycket f\u00f6r mig vilka produkter som skapas, hur man f\u00f6rh\u00e5ller sig till kvalitet inom f\u00f6retaget, i teamet och i princip i utvecklingsprocessen.<\/p><\/blockquote>\n

\nF\u00f6r mig \u00e4r det uppenbart att gemenskapen inom detta omr\u00e5de \u00e4r inte tillr\u00e4ckligt mogen<\/strong>, \u00e5tminstone i Ryssland. Vi f\u00f6rst\u00e5r inte alltid att kvalitetss\u00e4kring inte bara handlar om sj\u00e4lva testandet av en applikation mot krav. Jag skulle vilja f\u00f6r\u00e4ndra denna situation.<\/p>\n

\u2013 Du anv\u00e4nder orden Quality Assurance och testning. I allm\u00e4nhetens \u00f6gon \u00f6verlappar dessa tv\u00e5 termer ofta. Hur skiljer de sig \u00e5t om man gr\u00e4ver djupare?<\/em><\/strong><\/p>\n

Anastasia:<\/strong> Nej, de skiljer sig faktiskt inte. Testning \u00e4r en del av kvalitetss\u00e4kring, det \u00e4r en omedelbar aktivitet \u2013 sj\u00e4lva faktum att jag testar n\u00e5got. Det finns faktiskt m\u00e5nga olika typer av testning, och olika typer av testning hanteras av olika personer. Men i Ryssland, n\u00e4r v\u00e5gen av outsourcingf\u00f6retag d\u00f6k upp som tillhandah\u00e5ller testare till f\u00f6retag, har testning reducerats till en enda typ.<\/p>\n

I de flesta fall begr\u00e4nsar man sig till funktionell testning: man kontrollerar att det som utvecklarna har kodad motsvarar specifikationen och inget mer.<\/p>\n

\u2013 Ber\u00e4tta g\u00e4rna, vilka andra discipliner finns det inom kvalitetss\u00e4kring? Vad mer, f\u00f6rutom testning, ing\u00e5r h\u00e4r?<\/em><\/strong><\/p>\n

Anastasia<\/strong>: Kvalitetss\u00e4kring handlar f\u00f6rst och fr\u00e4mst om att skapa en kvalitetsprodukt. Det vill s\u00e4ga, vi st\u00e4ller oss fr\u00e5gan vilka kvalitetsegenskaper v\u00e5r produkt b\u00f6r ha. Om vi f\u00f6rst\u00e5r detta kan vi ocks\u00e5 identifiera vem som p\u00e5verkar dessa kvalitetsegenskaper. Det spelar ingen roll, utvecklare, projektledare eller produkt\u00e4gare<\/strong>\u00a0\u2013 \u00e4r den personen som p\u00e5verkar produktens utveckling, dess backlog och dess strategi.<\/p>\n

Testaren b\u00f6rjar b\u00e4ttre f\u00f6rst\u00e5 sin roll. Han eller hon inser att uppgiften inte bara handlar om att testa mot krav, utan ocks\u00e5 om att testa kraven, ifr\u00e5gas\u00e4tta formuleringar som kommer fr\u00e5n produkt\u00e4garen, identifiera alla underliggande krav och kundens f\u00f6rv\u00e4ntningar. N\u00e4r vi levererar ny funktionalitet till v\u00e5r kund m\u00e5ste vi verkligen uppfylla deras f\u00f6rv\u00e4ntningar och l\u00f6sa deras problem. Om vi t\u00e4nker p\u00e5 alla kvalitetsegenskaper kommer kunden att vara n\u00f6jd och f\u00f6rst\u00e5 att f\u00f6retaget vars produkt han eller hon anv\u00e4nder verkligen bryr sig om deras intressen, och inte bara arbetar utifr\u00e5n principen 'bara sl\u00e4ppa en funktion'.<\/p>\n

\u2013 Det verkar som det du just beskrev \u2013 det \u00e4r produkt\u00e4garens uppgift. Det handlar egentligen inte om testning och inte om kvalitet \u2013 det handlar \u00f6verhuvudtaget om produktledning, eller hur?<\/em><\/strong><\/p>\n

Anastasia<\/strong>: Delvis. Kvalitetss\u00e4kring \u00e4r inte en disciplin som ansvarar f\u00f6r en specifik person. Nu finns det en popul\u00e4r inriktning inom testning, en metodik som kallas Agil testning<\/strong>I definitionen st\u00e5r det direkt att detta \u00e4r ett teamorienterat tillv\u00e4gag\u00e5ngss\u00e4tt f\u00f6r testning som omfattar en viss upps\u00e4ttning metoder. Genomf\u00f6randet av detta tillv\u00e4gag\u00e5ngss\u00e4tt ansvarar hela teamet f\u00f6r, det \u00e4r inte n\u00f6dv\u00e4ndigt att det finns en testare i teamet. Hela teamet \u00e4r fokuserat p\u00e5 att leverera v\u00e4rde till kunden och att detta v\u00e4rde motsvarar hans f\u00f6rv\u00e4ntningar.<\/p>\n

\u2014 S\u00e5 kvalitet korsar sig med n\u00e4stan alla omgivande discipliner och s\u00e4tter ramar f\u00f6r allt omkring?<\/em><\/strong><\/p>\n

Anastasia<\/strong>: Precis. N\u00e4r vi t\u00e4nker p\u00e5 att skapa en kvalitetsprodukt b\u00f6rjar vi t\u00e4nka p\u00e5 olika kvalitetsattribut. Till exempel, hur ska vi kontrollera att vi verkligen har gjort en funktion som v\u00e5r kund beh\u00f6ver.<\/p>\n

D\u00e5 dyker en typ av testning upp som UAT<\/strong> (anv\u00e4ndartestning). Tyv\u00e4rr praktiseras detta s\u00e4llan i Ryssland, men f\u00f6rekommer ibland i SCRUM-team som en demo f\u00f6r slutkunden. I utl\u00e4ndska f\u00f6retag \u00e4r detta en ganska vanlig typ av testning. Innan vi \u00f6ppnar funktionaliteten f\u00f6r alla kunder g\u00f6r vi f\u00f6rst UAT, det vill s\u00e4ga vi bjuder in slutanv\u00e4ndaren som genomf\u00f6r tester och ger omedelbar feedback \u2014 om produkten verkligen uppfyller f\u00f6rv\u00e4ntningarna och l\u00f6ser problemet. F\u00f6rst efter detta sker en skalning till alla andra kunder.<\/p>\n

S\u00e5 vi fokuserar p\u00e5 aff\u00e4rer, p\u00e5 slutkunden, men gl\u00f6mmer inte heller teknologin. Teknologi p\u00e5verkar ocks\u00e5 starkt produktens kvalitet. Om vi har en d\u00e5lig arkitektur kan vi inte snabbt sl\u00e4ppa funktioner och motsvara kundens f\u00f6rv\u00e4ntningar. Det kan uppst\u00e5 m\u00e5nga buggar vid f\u00f6rs\u00f6k att skala, eller vid f\u00f6rs\u00f6k att g\u00f6ra refaktorisering kan vi r\u00e5ka bryta n\u00e5got. Allt detta kommer att p\u00e5verka kundens tillfredsst\u00e4llelse.<\/strong>Ur detta perspektiv b\u00f6r arkitekturen vara s\u00e5dan att vi kan skriva ren kod som g\u00f6r det m\u00f6jligt att snabbt g\u00f6ra \u00e4ndringar utan att vara r\u00e4dda f\u00f6r att vi f\u00f6rst\u00f6r allt. F\u00f6r att iterationer av f\u00f6rb\u00e4ttringar inte ska str\u00e4cka sig \u00f6ver flera m\u00e5nader endast p\u00e5 grund av att vi har s\u00e5 mycket legacy och beh\u00f6ver genomf\u00f6ra l\u00e5nga testfaser.<\/p>\n

\u2014 Sammanfattningsvis \u00e4r utvecklare, arkitekter, produktentusiaster, produktchefer och sj\u00e4lva testarna redan involverade. Vem mer \u00e4r involverad i processen f\u00f6r att s\u00e4kerst\u00e4lla kvalitet?<\/p>\n

\u2014 Totalt \u00e4r det redan utvecklare, arkitekter, produktutvecklare, produktchefer och testare involverade. Vem mer \u00e4r involverad i processen f\u00f6r kvalitetskontroll?<\/em><\/strong><\/p>\n

Anastasia<\/strong>: L\u00e5t oss nu f\u00f6rest\u00e4lla oss att vi har levererat funktionen till kunden. Det \u00e4r uppenbart att vi m\u00e5ste \u00f6vervaka produktens kvalitet n\u00e4r den v\u00e4l \u00e4r i produktion. Vid denna tidpunkt kan situationer med ov\u00e4ntade scenarier och s\u00e5 kallade buggar uppst\u00e5.<\/p>\n

Den f\u00f6rsta fr\u00e5gan \u00e4r hur vi arbetar med dessa buggar efter att produkten redan har sl\u00e4ppts? Hur reagerar vi till exempel p\u00e5 belastning? Kunden kommer inte att vara s\u00e4rskilt n\u00f6jd om sidan laddas i mer \u00e4n 30 sekunder.<\/p>\n

H\u00e4r spelar drift eller, som det nu kallas, DevOps<\/strong>. I praktiken handlar det om m\u00e4nniskor som ansvarar f\u00f6r produktens drift n\u00e4r den v\u00e4l \u00e4r i produktion. Det inkluderar olika typer av \u00f6vervakning. Det finns till och med en underkategori av testning - produkttestning, d\u00e4r vi till\u00e5ter oss att inte testa n\u00e5got f\u00f6re lanseringen och testar det direkt i produktionen. Det handlar om \u00e5tg\u00e4rder n\u00e4r det g\u00e4ller att organisera infrastrukturen som m\u00f6jligg\u00f6r snabba reaktioner p\u00e5 incidenter, p\u00e5verkar dem och \u00e5tg\u00e4rdar dem.<\/p>\n

Infrastrukturen \u00e4r ocks\u00e5 viktig. Det \u00e4r ofta s\u00e5 att under testningen kan vi inte vara s\u00e4kra p\u00e5 att vi verkligen har allt det som vi skulle vilja ge kunden. Vi sl\u00e4pper ut i produktion - och b\u00f6rjar f\u00e5nga ov\u00e4ntade situationer. Allt beroende p\u00e5 att infrastrukturen i testen inte st\u00e4mmer \u00f6verens med infrastrukturen i produktionen. H\u00e4rifr\u00e5n h\u00e4rstammar en ny typ av testning - infrastrukturtestning<\/strong>. Det handlar om olika konfigurationer, inst\u00e4llningar, databas-migrering och s\u00e5 vidare.<\/p>\n

H\u00e4r uppst\u00e5r fr\u00e5gan - kanske teamet beh\u00f6ver anv\u00e4nda infrastruktur som kod.<\/p>\n

Jag tror att infrastrukturen direkt p\u00e5verkar produktens kvalitet.<\/p><\/blockquote>\n

\nJag hoppas att det kommer att finnas en presentation med en verklig fallstudie p\u00e5 konferensen. Skriv till oss om du \u00e4r redo att dela med dig av din erfarenhet om hur infrastruktur som kod p\u00e5verkar kvaliteten. Infrastruktur som kod g\u00f6r det enklare att kontrollera alla inst\u00e4llningar och testa vad som annars \u00e4r om\u00f6jligt. D\u00e4rf\u00f6r involveras driften i utvecklingsprocessen av kvalitetsprodukter.<\/p>\n

\u2013 Och hur \u00e4r det med analys och dokumentation?<\/em><\/strong><\/p>\n

Anastasia<\/strong>: Det handlar mer om enterprise-system. N\u00e4r vi pratar om enterprise, dyker genast s\u00e5dana personer som analytiker och systemanalytiker upp i tankarna. Ibland kallas de tekniska skribenter. De f\u00e5r i uppdrag att skriva en specifikation och utf\u00f6r den, till exempel under en m\u00e5nad.<\/p>\n

Det har upprepade g\u00e5nger bevisats att skrivande av s\u00e5dan dokumentation leder till mycket l\u00e5nga utvecklingsiterationer och l\u00e5nga iterationer av revideringar, eftersom buggar uppt\u00e4cks under testningen och det blir returer. Resultatet blir m\u00e5nga loopar som \u00f6kar utvecklingskostnaden. Dessutom kan detta introducera s\u00e5rbarheter. Vi har visserligen skrivit referenskod, men sedan har vi gjort \u00e4ndringar som bryter den perfekt genomt\u00e4nkta arkitekturen.<\/p>\n

Slutprodukten blir inte helt kvalitativ eftersom arkitekturen redan har f\u00e5tt lappar, koden \u00e4r inte tillr\u00e4ckligt testad p\u00e5 vissa st\u00e4llen f\u00f6r att tidsfristen \u00e4r pressande och allt m\u00e5ste fixas snabbare. Allt detta beror p\u00e5 att inte alla punkter som beh\u00f6ver genomf\u00f6ras togs upp i den ursprungliga specifikationen.<\/p>\n

Utvecklare \u00e4r inte skadliga och skriver inte medvetet kod med fel.<\/p><\/blockquote>\n

\nOm vi hade t\u00e4nkt igenom specifikationen fr\u00e5n b\u00f6rjan d\u00e4r alla n\u00f6dv\u00e4ndiga punkter belyses skulle allt ha genomf\u00f6rts precis som det skulle. Men det \u00e4r en utopi.<\/p>\n

Det \u00e4r nog om\u00f6jligt att skriva en perfekt specifikation p\u00e5 100 sidor. D\u00e4rf\u00f6r m\u00e5ste vi t\u00e4nka p\u00e5 alternativa s\u00e4tt att skriva dokumentation<\/strong>, specificera, st\u00e4lla upp uppgifter som skulle f\u00f6ra oss n\u00e4rmare att utvecklaren g\u00f6r exakt vad som beh\u00f6vs.<\/p>\n

D\u00e5 kommer jag att t\u00e4nka p\u00e5 metoder fr\u00e5n Agile \u2013 anv\u00e4ndarber\u00e4ttelser med acceptanskriterier. Detta \u00e4r mer till\u00e4mpligt f\u00f6r team som utvecklas i sm\u00e5 iterationer.<\/p>\n

\u2013 Vad kan vi s\u00e4ga om anv\u00e4ndartester, anv\u00e4ndbarheten av produkten, designen?<\/em><\/strong><\/p>\n

Anastasia<\/strong>: Det \u00e4r en mycket viktig punkt eftersom det finns designers i teamet. Oftast anv\u00e4nds designers som en tj\u00e4nst \u2013 antingen en designeravdelning eller en designer p\u00e5 extern basis. Det \u00e4r ofta situationer d\u00e4r det verkar som om designern har lyssnat p\u00e5 produktansvariga och gjort det som han eller hon f\u00f6rstod. Men n\u00e4r vi b\u00f6rjar med iterationen visar det sig att det verkligen inte gjordes som f\u00f6rv\u00e4ntat: designern har gl\u00f6mt n\u00e5got, inte helt t\u00e4nkt igenom beteendet eftersom han eller hon inte \u00e4r i teamet och inte i kontexten, eller frontendutvecklaren har inte helt f\u00f6rst\u00e5tt hans eller hennes skiss. Det kan beh\u00f6vas flera iterationer bara p\u00e5 grund av att det finns ett problem med att f\u00f6rst\u00e5 designen av frontendutvecklaren.<\/p>\n

Det finns ocks\u00e5 ett annat problem. Designsystem blir alltmer popul\u00e4ra. De \u00e4r p\u00e5 hajpen, men f\u00f6rdelarna med dem \u00e4r inte helt uppenbara.<\/p>\n

Jag st\u00f6ter p\u00e5 \u00e5sikten att designsystem \u00e5 ena sidan f\u00f6renklar utvecklingen, \u00e5 andra sidan l\u00e4gger de p\u00e5 v\u00e4ldigt m\u00e5nga begr\u00e4nsningar f\u00f6r gr\u00e4nssnittet.<\/p><\/blockquote>\n

\nResultatet blir att vi inte g\u00f6r den funktion som kunden vill ha, utan en som \u00e4r bekv\u00e4m f\u00f6r oss, eftersom vi redan har vissa komponenter som vi kan anv\u00e4nda f\u00f6r att skapa den.<\/p>\n

Jag tror att det \u00e4r v\u00e4rt att uppm\u00e4rksamma detta \u00e4mne och fundera p\u00e5 om vi verkligen l\u00f6ser kundens problem i v\u00e5r str\u00e4van att f\u00f6renkla designarbetet.<\/p>\n

\u2014 Det finns otroligt m\u00e5nga \u00e4mnen kring kvalitetss\u00e4kring. Finns det en konferens i Ryssland d\u00e4r man kan diskutera allt detta?<\/em><\/strong><\/p>\n

Anastasia<\/strong>: Det finns den \u00e4ldsta konferensen f\u00f6r testning som i \u00e5r h\u00e5lls f\u00f6r 25:e g\u00e5ngen och heter just SQA Days. D\u00e4r diskuteras fr\u00e4mst verktyg och specifika testmetoder f\u00f6r funktionella testare. Vanligtvis behandlas mer specifika omr\u00e5den inom testares ansvar, men inte de mer \u00f6vergripande temana.<\/p>\n

Det hj\u00e4lper verkligen att f\u00f6rst\u00e5 de olika verktygen och metoderna f\u00f6r hur man testar databaser, API och s\u00e5 vidare. Men \u00e5 ena sidan motiverar det inte att involvera andra i skapandet av en mer kvalitativ produkt \u00e4n bara testningen. \u00c5 andra sidan blir testarna inte mer involverade i processen f\u00f6r att t\u00e4nka p\u00e5 produktens globala m\u00e5l och dess aff\u00e4rsaspekt.<\/p>\n

Jag leder en stor avdelning och genomf\u00f6r m\u00e5nga intervjuer, vilket faktiskt ger en bild av industrins tillst\u00e5nd som helhet. Vanligtvis arbetar v\u00e5ra killar med f\u00f6retag av h\u00f6gre standard (enterprise), och de har en tydlig ansvarszon. Kollegaer som arbetar med utl\u00e4ndska projekt anv\u00e4nder olika typer av testning: de kan sj\u00e4lva genomf\u00f6ra belastningstest, prestandatest, och till och med ibland s\u00e4kerhetstestning (security testing), eftersom de verkligen hj\u00e4lper teamet att s\u00e4kerst\u00e4lla produktens kvalitet.<\/p>\n

Jag skulle vilja att v\u00e5ra killar i Ryssland ocks\u00e5 b\u00f6rjar t\u00e4nka p\u00e5 att den funktionella testningen inte \u00e4r slutet p\u00e5 industrin.<\/p>\n

\u2014 F\u00f6r detta syfte arrangerar vi den nya konferensen QualityConf, som handlar om kvalitet som en helhetsdisciplin. Kan du ber\u00e4tta mer om id\u00e9n, vad \u00e4r huvudsyftet med konferensen?<\/em><\/strong><\/p>\n

Anastasia<\/strong>: Vi vill skapa en gemenskap av m\u00e4nniskor som \u00e4r intresserade av att g\u00f6ra kvalitetsprodukter. Erbjuda en plattform dit de kan komma, lyssna p\u00e5 f\u00f6rel\u00e4sningar och efter konferensen g\u00e5 d\u00e4rifr\u00e5n med en konkret f\u00f6rst\u00e5else f\u00f6r vad de beh\u00f6ver \u00e4ndra f\u00f6r att f\u00f6rb\u00e4ttra kvaliteten.<\/p>\n

Jag h\u00f6r ofta fr\u00e5n konsultf\u00f6retag vad man ska g\u00f6ra n\u00e4r det finns problem med testning och kvalitet. N\u00e4r man b\u00f6rjar prata med teamen ser man att problemet inte ligger hos testarna, utan i hur processen \u00e4r uppbyggd. Till exempel n\u00e4r utvecklarna tror att de endast \u00e4r ansvariga f\u00f6r att skriva koden, slutar deras ansvar precis i det \u00f6gonblick de \u00f6verl\u00e4mnar uppgiften f\u00f6r testning.<\/p>\n

Inte alla t\u00e4nker p\u00e5 att d\u00e5ligt skriven, kvalitetsm\u00e4ssigt underm\u00e5lig kod med d\u00e5lig arkitektur kan leda till stora problem f\u00f6r projektet. De t\u00e4nker inte p\u00e5 kostnaderna f\u00f6r misstag, p\u00e5 att buggar som hamnar i produktion kan leda till stora kostnader f\u00f6r f\u00f6retaget och teamet. Det finns ingen kultur f\u00f6r att t\u00e4nka p\u00e5 detta. Jag vill att vi p\u00e5 konferensen ska b\u00f6rja sprida denna kultur.<\/p>\n

Jag f\u00f6rst\u00e5r att detta inte \u00e4r en innovation. Edward Deming, f\u00f6rfattaren till de 14 kvalitetsprinciperna, skrev om kostnaden f\u00f6r misstag redan f\u00f6rra seklet. Denna bok ligger till grund f\u00f6r Quality Assurance som disciplin, men tyv\u00e4rr gl\u00f6mmer modern utveckling detta.<\/p>\n

\u2014 Kommer ni att ta upp \u00e4mnen direkt relaterade till testning och verktyg?<\/em><\/strong><\/p>\n

Anastasia<\/strong>: Jag antar att det kommer att finnas f\u00f6rel\u00e4sningar om verktyg. Det finns tillr\u00e4ckligt universella verktyg som f\u00f6retag och team kan anv\u00e4nda f\u00f6r att p\u00e5verka produkten.<\/p>\n

Alla f\u00f6rel\u00e4sningar kommer \u00f6vergripande att f\u00f6renas av ett gemensamt uppdrag: att f\u00f6rmedla till publiken att med hj\u00e4lp av denna metod, detta verktyg, denna process eller typ av testning har vi p\u00e5verkat produktens kvalitet och f\u00f6rb\u00e4ttrat kundens liv.<\/p><\/blockquote>\n

\nVi kommer absolut inte att ha f\u00f6rel\u00e4sningar om verktyg f\u00f6r verktygets skull. Alla f\u00f6rel\u00e4sningar som kommer att inkluderas i programmet kommer att f\u00f6renas av ett gemensamt syfte.<\/p>\n

\u2014 Vem kommer att vara intresserad av det du pratar om, vilka ser du som g\u00e4ster p\u00e5 konferensen?<\/em><\/strong><\/p>\n

Anastasia<\/strong>: Vi kommer att ha presentationer f\u00f6r utvecklare som bryr sig om sina projekt, produkter och system. Detta kommer \u00e4ven vara intressant f\u00f6r testare och, som jag ser det, s\u00e4rskilt f\u00f6r chefer. Med chefer menar jag personer som fattar beslut och kan p\u00e5verka \u00f6det och utvecklingen av produkter, system och team.<\/p>\n

Det \u00e4r personer som st\u00e4ller sig fr\u00e5gan \u2013 hur kan vi h\u00f6ja kvaliteten p\u00e5 produkter och system. P\u00e5 v\u00e5r konferens kommer de att f\u00e5 veta om olika aktivitetskomplex och kunna f\u00f6rst\u00e5 vad som inte st\u00e5r r\u00e4tt till, vad som beh\u00f6ver \u00e4ndras.<\/p>\n

Jag tror att det fr\u00e4msta kriteriet \u00e4r att f\u00f6rst\u00e5 att det \u00e4r n\u00e5got fel med kvaliteten och att vilja p\u00e5verka det. Antagligen kommer det inte att vara m\u00f6jligt att n\u00e5 fram till dem som anser att allt \u00e4r okej p\u00e5 f\u00f6rsta f\u00f6rs\u00f6ket.<\/p>\n

\u2013 Vad tycker du, har branschen i stort mognat till att prata om inte bara testning, utan om kvalitetkultur?<\/em><\/strong><\/p>\n

Anastasia<\/strong>: Jag anser att den har mognat. M\u00e5nga f\u00f6retag g\u00e5r nu ifr\u00e5n den traditionella Waterfall-metoden mot Agile. Det sker en orientering mot kunden, och folk i teamen b\u00f6rjar verkligen t\u00e4nka p\u00e5 hur man kan skapa kvalitetsprodukter. \u00c4ven inom storf\u00f6retag sker en omorientering mot att h\u00f6ja kvaliteten.<\/p>\n

Baserat p\u00e5 antalet f\u00f6rfr\u00e5gningar som uppst\u00e5r i samh\u00e4llet, anser jag att det \u00e4r dags. Jag \u00e4r dock inte s\u00e4ker p\u00e5 att det kommer att bli en storskalig revolution, men jag skulle vilja att denna f\u00f6r\u00e4ndring i medvetande intr\u00e4ffar.<\/p>\n

\u2013 \u00d6verens om det! Vi ska f\u00f6ra in kulturen och f\u00f6r\u00e4ndra medvetandet.<\/em><\/strong><\/p>\n

Konferens om kvalitativ utveckling av IT-produkter QualityConf<\/a><\/noindex> ska i Moskva den 7 juni<\/strong>. Vet ni vilka steg som utg\u00f6r en kvalitativ produkt, vi har fallstudier av framg\u00e5ngsrik kamp mot buggar i produktion, vi har testat popul\u00e4ra metoder i v\u00e5r egen praktik \u2013 vi beh\u00f6ver er erfarenhet. Skicka<\/a><\/noindex> era ans\u00f6kningar senast den 1 maj<\/strong>, och den programkommitt\u00e9n kommer att hj\u00e4lpa till att fokusera \u00e4mnet f\u00f6r konferensen s\u00e5 att den blir en helhet.<\/p>\n

F\u00f6lj med i chatten<\/a><\/noindex>, d\u00e4r vi diskuterar kvalitetsfr\u00e5gor och konferensen, f\u00f6lj g\u00e4rna v\u00e5r Telegram-kanal<\/a><\/noindex>, f\u00f6r att h\u00e5lla er uppdaterade om programmets nyheter.<\/p><\/blockquote>\n

K\u00e4lla: habr.com<\/a><\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"

\u041f\u0440\u0438\u0432\u0435\u0442, \u0425\u0430\u0431\u0440! \u0423\u00a0\u043d\u0430\u0441 \u043d\u043e\u0432\u0430\u044f \u0432\u0430\u0436\u043d\u0430\u044f \u0442\u0435\u043c\u0430\u00a0\u2014 \u043a\u0430\u0447\u0435\u0441\u0442\u0432\u0435\u043d\u043d\u0430\u044f \u0440\u0430\u0437\u0440\u0430\u0431\u043e\u0442\u043a\u0430 IT-\u043f\u0440\u043e\u0434\u0443\u043a\u0442\u043e\u0432. \u041c\u044b\u00a0\u0447\u0430\u0441\u0442\u043e \u0433\u043e\u0432\u043e\u0440\u0438\u043c \u043d\u0430\u00a0HighLoad++, \u043a\u0430\u043a \u0441\u0434\u0435\u043b\u0430\u0442\u044c \u043d\u0430\u0433\u0440\u0443\u0436\u0435\u043d\u043d\u044b\u0435 \u0441\u0435\u0440\u0432\u0438\u0441\u044b \u0431\u044b\u0441\u0442\u0440\u044b\u043c\u0438, \u0430\u00a0\u043d\u0430\u00a0Frontend Conf\u00a0\u2014 \u043a\u043b\u0430\u0441\u0441\u043d\u044b\u0439 \u043f\u043e\u043b\u044c\u0437\u043e\u0432\u0430\u0442\u0435\u043b\u044c\u0441\u043a\u0438\u0439 \u0438\u043d\u0442\u0435\u0440\u0444\u0435\u0439\u0441, \u043a\u043e\u0442\u043e\u0440\u044b\u0439 \u043d\u0435\u00a0\u0442\u043e\u0440\u043c\u043e\u0437\u0438\u0442. \u0423\u00a0\u043d\u0430\u0441 \u0440\u0435\u0433\u0443\u043b\u044f\u0440\u043d\u043e \u0435\u0441\u0442\u044c \u0442\u0435\u043c\u044b \u043f\u0440\u043e \u0442\u0435\u0441\u0442\u0438\u0440\u043e\u0432\u0430\u043d\u0438\u0435, \u0438\u00a0DevOpsConf \u043f\u0440\u043e \u043e\u0431\u044a\u0435\u0434\u0438\u043d\u0435\u043d\u0438\u0435 \u0440\u0430\u0437\u043d\u044b\u0445 \u043f\u0440\u043e\u0446\u0435\u0441\u0441\u043e\u0432, \u0432\u043a\u043b\u044e\u0447\u0430\u044f \u0442\u0435\u0441\u0442\u0438\u0440\u043e\u0432\u0430\u043d\u0438\u0435. \u0410\u00a0\u043f\u0440\u043e\u00a0\u0442\u043e, \u0447\u0442\u043e \u043c\u043e\u0436\u043d\u043e \u043d\u0430\u0437\u0432\u0430\u0442\u044c \u043a\u0430\u0447\u0435\u0441\u0442\u0432\u043e \u0432\u00a0\u0446\u0435\u043b\u043e\u043c, \u0438\u00a0\u043a\u0430\u043a \u043d\u0430\u0434 \u043d\u0438\u043c \u043a\u043e\u043c\u043f\u043b\u0435\u043a\u0441\u043d\u043e \u0440\u0430\u0431\u043e\u0442\u0430\u0442\u044c\u00a0\u2014 \u043d\u0435\u0442. \u0418\u0441\u043f\u0440\u0430\u0432\u0438\u043c \u044d\u0442\u043e \u043d\u0430 QualityConf\u00a0\u2014 \u0431\u0443\u0434\u0435\u043c \u0440\u0430\u0437\u0432\u0438\u0432\u0430\u0442\u044c […]<\/p>\n","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"author":1,"featured_media":23230,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[688],"tags":[],"class_list":["post-31264","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-administrirovanie"],"aioseo_notices":[],"aioseo_head":"\n\t\t\n\t\n\t\n\t\n\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\n","aioseo_head_json":{"title":"\ud83e\udd47Vem ansvarar f\u00f6r kvaliteten? | ProHoster","description":"Hej, Habr! Vi har ett nytt viktigt \u00e4mne \u2013 kvalitativ utveckling av IT-produkter.","canonical_url":"https:\/\/prohoster.info\/sv\/blog\/administrirovanie\/kto-otvetit-za-kachestvo","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"sv_SE","og:site_name":"ProHoster | \u041a\u0443\u043f\u0438\u0442\u044c \u043d\u0430\u0434\u0435\u0436\u043d\u044b\u0439 \u0445\u043e\u0441\u0442\u0438\u043d\u0433 \u0434\u043b\u044f \u0441\u0430\u0439\u0442\u043e\u0432 \u0441 \u0437\u0430\u0449\u0438\u0442\u043e\u0439 \u043e\u0442 DDoS, VPS VDS \u0441\u0435\u0440\u0432\u0435\u0440\u044b","og:type":"article","og:title":"\ud83e\udd47\u041a\u0442\u043e \u043e\u0442\u0432\u0435\u0442\u0438\u0442 \u0437\u0430 \u043a\u0430\u0447\u0435\u0441\u0442\u0432\u043e? | ProHoster","og:description":"\u041f\u0440\u0438\u0432\u0435\u0442, \u0425\u0430\u0431\u0440! \u0423 \u043d\u0430\u0441 \u043d\u043e\u0432\u0430\u044f \u0432\u0430\u0436\u043d\u0430\u044f \u0442\u0435\u043c\u0430 \u2014 \u043a\u0430\u0447\u0435\u0441\u0442\u0432\u0435\u043d\u043d\u0430\u044f \u0440\u0430\u0437\u0440\u0430\u0431\u043e\u0442\u043a\u0430 IT-\u043f\u0440\u043e\u0434\u0443\u043a\u0442\u043e\u0432.","og:url":"https:\/\/prohoster.info\/sv\/blog\/administrirovanie\/kto-otvetit-za-kachestvo","og:image":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:secure_url":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:width":350,"og:image:height":350,"article:published_time":"2019-10-31T18:40:21+00:00","article:modified_time":"2019-10-31T18:40:21+00:00","article:publisher":"https:\/\/www.facebook.com\/prohoster","article:author":"https:\/\/www.facebook.com\/prohoster"},"aioseo_meta_data":{"post_id":"31264","title":null,"description":null,"keywords":null,"keyphrases":null,"primary_term":null,"canonical_url":null,"og_title":null,"og_description":null,"og_object_type":"default","og_image_type":"default","og_image_url":null,"og_image_width":null,"og_image_height":null,"og_image_custom_url":null,"og_image_custom_fields":null,"og_video":null,"og_custom_url":null,"og_article_section":null,"og_article_tags":null,"twitter_use_og":false,"twitter_card":"default","twitter_image_type":"default","twitter_image_url":null,"twitter_image_custom_url":null,"twitter_image_custom_fields":null,"twitter_title":null,"twitter_description":null,"schema":{"blockGraphs":[],"customGraphs":[],"default":{"data":{"Article":[],"Course":[],"Dataset":[],"FAQPage":[],"Movie":[],"Person":[],"Product":[],"ProductReview":[],"Car":[],"Recipe":[],"Service":[],"SoftwareApplication":[],"WebPage":[]},"graphName":"","isEnabled":true},"graphs":[]},"schema_type":null,"schema_type_options":null,"pillar_content":false,"robots_default":true,"robots_noindex":false,"robots_noarchive":false,"robots_nosnippet":false,"robots_nofollow":false,"robots_noimageindex":false,"robots_noodp":false,"robots_notranslate":false,"robots_max_snippet":null,"robots_max_videopreview":null,"robots_max_imagepreview":"large","priority":null,"frequency":null,"local_seo":null,"seo_analyzer_scan_date":"2026-01-21 05:19:19","breadcrumb_settings":null,"limit_modified_date":false,"reviewed_by":null,"ai":null,"created":"2021-03-01 03:19:50","updated":"2026-01-21 05:19:19","focus_keyword":null,"additional_keywords":null,"truseo_locale":null},"gt_translate_keys":[{"key":"link","format":"url"}],"_links":{"self":[{"href":"https:\/\/prohoster.info\/sv\/wp-json\/wp\/v2\/posts\/31264","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/sv\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/sv\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/sv\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/sv\/wp-json\/wp\/v2\/comments?post=31264"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/sv\/wp-json\/wp\/v2\/posts\/31264\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/sv\/wp-json\/wp\/v2\/media\/23230"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/sv\/wp-json\/wp\/v2\/media?parent=31264"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/sv\/wp-json\/wp\/v2\/categories?post=31264"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/sv\/wp-json\/wp\/v2\/tags?post=31264"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}