ProHoster > Blogs > Administrācija > KurŔ ir atbildīgs par kvalitāti?

KurŔ ir atbildīgs par kvalitāti?

Čau Habr!

Mums ir jauna svarÄ«ga tēma ā€“ kvalitatÄ«va IT produktu izstrāde. HighLoad++ mēs bieži runājam par to, kā padarÄ«t noslogotus pakalpojumus ātrus, un Frontend Conf mēs runājam par forÅ”u lietotāja interfeisu, kas nepalēninās. Mums regulāri ir tēmas par testÄ“Å”anu un DevOpsConf par dažādu procesu apvienoÅ”anu, tostarp testÄ“Å”anu. Bet par to, ko vispār var saukt par kvalitāti un kā pie tā vispusÄ«gi strādāt - nē.

Izlabosim to lÄ«dz QualityConf ā€” attÄ«stÄ«sim domāŔanas kultÅ«ru par galaprodukta kvalitāti lietotājam katrā izstrādes posmā. Ieradums nekoncentrēties uz savu atbildÄ«bas jomu un saistÄ«t kvalitāti ne tikai ar testētājiem.

Zem griezuma mēs runāsim ar programmas komitejas vadÄ«tāju, Tinkoff.Business testÄ“Å”anas vadÄ«tāju, krievvalodÄ«go QA kopienas veidotāju. Anastasija Asejeva-Ngujena par QA nozares stāvokli un jaunās konferences misiju.

KurŔ ir atbildīgs par kvalitāti?

- Nastia sveiks. Lūdzu, pastāstiet mums par sevi.

KurÅ” ir atbildÄ«gs par kvalitāti?Anastasia: Es vadu testÄ“Å”anu bankā, esmu atbildÄ«gs par ļoti lielu komandu - mēs esam vairāk nekā 90 cilvēki. Mums ir svarÄ«ga biznesa lÄ«nija, mēs esam atbildÄ«gi par juridisko personu ekosistēmu.

Es studēju mehāniku un matemātiku un sākotnēji gribēju kļūt par programmētāju. Bet, kad saņēmu interesantu piedāvājumu, nolēmu izmēģināt sevi kā testētāju. Savādi, bet tas izrādÄ«jās mans aicinājums. Tagad es redzu visu savu darbu Å”ajā nozarē.

Esmu dedzÄ«gs kvalitātes nodroÅ”ināŔanas disciplÄ«nas piekritējs. Man nav vienaldzÄ«gi, kādi produkti tiek radÄ«ti, kā pret kvalitāti izturas uzņēmumā, kolektÄ«vā un principā arÄ« izstrādes procesā.

Man tas ir skaidrs sabiedrÄ«ba Å”ajā virzienā nav pietiekami nobriedusi, vismaz Krievijā. Mēs ne vienmēr saprotam, ka kvalitātes nodroÅ”ināŔana nav tikai pieteikuma testÄ“Å”anas fakts par atbilstÄ«bu prasÄ«bām. Es vēlētos mainÄ«t Å”o situāciju.

ā€” JÅ«s lietojat vārdus Kvalitātes nodroÅ”ināŔana un testÄ“Å”ana. Vidusmēra cilvēka acÄ«s Å”ie divi termini ļoti bieži pārklājas. Kā tie atŔķiras, ja jÅ«s rakāties dziļi?

Anastasija: DrÄ«zāk viņi neatŔķiras. TestÄ“Å”ana ir daļa no kvalitātes nodroÅ”ināŔanas disciplÄ«nas, tā ir tieÅ”a darbÄ«ba ā€“ pats fakts, ka es kaut ko pārbaudu. Faktiski ir daudz testÄ“Å”anas veidu, un par dažādiem testÄ“Å”anas veidiem ir atbildÄ«gi dažādi cilvēki. Bet Å”eit, Krievijā, kad parādÄ«jās ārpakalpojumu sniedzēju vilnis, kas piegādā testerus uzņēmumiem, testÄ“Å”ana tika samazināta lÄ«dz viena veida.

Vairumā gadÄ«jumu tie aprobežojas tikai ar funkcionālo testÄ“Å”anu: viņi pārbauda, ā€‹ā€‹vai izstrādātāju kodētais atbilst specifikācijai, un viss.

ā€” Pastāstiet, lÅ«dzu, kādas vēl ir kvalitātes nodroÅ”ināŔanas disciplÄ«nas? Kas vēl, izņemot testÄ“Å”anu, ir iekļauts Å”eit?

Anastasia: Kvalitātes nodroÅ”ināŔana, pirmkārt, ir kvalitatÄ«va produkta radÄ«Å”ana. Tas ir, mēs uzdodam sev jautājumu, kādiem kvalitātes atribÅ«tiem vajadzētu bÅ«t mÅ«su produktam. AttiecÄ«gi, ja mēs to saprotam, varam salÄ«dzināt, kas ietekmē Å”os kvalitātes atribÅ«tus. Vienalga, izstrādātājs, projektu vadÄ«tājs vai produktu speciālists ir persona, kas ietekmē produkta attÄ«stÄ«bu, tā atpalicÄ«bu un stratēģiju.

Testētājs vairāk apzinās savu lomu. ViņŔ saprot, ka viņa uzdevums ir ne tikai pārbaudÄ«t atbilstÄ«bu prasÄ«bām, bet arÄ« pārbaudÄ«t prasÄ«bas, apÅ”aubÄ«t formulējumus, kas nāk no produkta speciālista, un atklāt visas klienta netieŔās prasÄ«bas un cerÄ«bas. Kad mēs saviem klientiem piegādājam jaunu funkcionalitāti, mums patiesi jāattaisno viņu cerÄ«bas un jāatrisina viņu sāpes. Ja pārdomāsim visus kvalitātes atribÅ«tus, klients bÅ«s apmierināts un sapratÄ«s, ka uzņēmums, kura produktu viņŔ izmanto, patieŔām rÅ«pējas par savām interesēm, nevis nedarbojas pēc principa ā€œtikai lai atbrÄ«votu funkcijuā€.

ā€” Å Ä·iet, ka tas, ko tikko aprakstÄ«jāt, ir produktu speciālista uzdevums. Tas principā nav par testÄ“Å”anu un ne par kvalitāti - tas parasti ir par produktu pārvaldÄ«bu, vai ne?

Anastasia: Ieskaitot. Kvalitātes nodroÅ”ināŔana nav disciplÄ«na, par kuru ir atbildÄ«ga viena konkrēta persona. Tagad ir populārs testÄ“Å”anas virziens, pieeja, ko sauc Agile testÄ“Å”ana. Viņa definÄ«cija skaidri norāda, ka Ŕī ir komandas pieeja testÄ“Å”anai, kas ietver noteiktu prakÅ”u kopumu. Visa komanda ir atbildÄ«ga par Ŕīs pieejas ievieÅ”anu, pat nav nepiecieÅ”ams, lai komandā bÅ«tu testētājs. Visa komanda ir vērsta uz vērtÄ«bas nodroÅ”ināŔanu klientam un to, lai vērtÄ«ba atbilstu klientu vēlmēm.

ā€” Izrādās, kvalitāte krustojas gandrÄ«z ar visām apkārtējām disciplÄ«nām, uzliekot ietvaru visam apkārt?

Anastasia: Pa labi. Kad mēs domājam par to, kā mēs vēlamies radÄ«t kvalitatÄ«vu produktu, mēs sākam domāt par dažādiem kvalitātes atribÅ«tiem. Piemēram, kā pārbaudÄ«t, vai mēs patieŔām esam izveidojuÅ”i mÅ«su klientam vajadzÄ«go lÄ«dzekli.

Å eit parādās Ŕāda veida pārbaude: UAT (lietotāja pieņemÅ”anas pārbaude). Diemžēl Krievijā tas tiek reti izmantots, bet dažreiz tas ir pieejams SCRUM komandās kā demonstrācija gala klientam. Tas ir diezgan izplatÄ«ts pārbaudes veids ārvalstu uzņēmumos. Pirms funkcionalitātes atvērÅ”anas visiem klientiem mēs vispirms veicam UAT, tas ir, aicinām gala lietotāju, kurÅ” pārbauda un uzreiz sniedz atsauksmes ā€“ vai produkts tieŔām atbilst cerÄ«bām un atrisina sāpes. Tikai pēc tam notiek mērogoÅ”ana visiem citiem klientiem.

Tas ir, mēs koncentrējamies uz biznesu, uz gala klientu, bet tajā paŔā laikā neaizmirstiet par tehnoloÄ£ijām. Produkta kvalitāte lielā mērā ir atkarÄ«ga arÄ« no tehnoloÄ£ijas. Ja mums ir slikta arhitektÅ«ra, mēs nevarēsim ātri atbrÄ«vot lÄ«dzekļus un apmierināt klientu vēlmes. Mēģinot palielināt mērogoÅ”anu, var bÅ«t daudz kļūdu, vai, mēģinot pārveidot, mēs varam kaut ko sabojāt. Tas viss ietekmēs klientu apmierinātÄ«bu.

No Ŕī viedokļa arhitektÅ«rai ir jābÅ«t tādai, lai mēs varētu uzrakstÄ«t tÄ«ru kodu, kas ļaus ātri veikt izmaiņas un nebaidÄ«ties, ka visu salauzÄ«sim. Lai pārskatÄ«Å”anas iterācijas nenotiktu vairākus mēneÅ”us tikai tāpēc, ka mums ir tik daudz mantojuma un mums ir jāveic garas testÄ“Å”anas stadijas.

ā€” Kopumā jau ir iesaistÄ«ti izstrādātāji, arhitekti, produktu zinātnieki, produktu vadÄ«tāji un paÅ”i testētāji. Kas vēl ir iesaistÄ«ts kvalitātes nodroÅ”ināŔanas procesā?

Anastasia: Tagad iedomāsimies, ka esam jau piegādājuŔi līdzekli klientam. Acīmredzot produkta kvalitāte ir jāuzrauga pat tad, kad tas jau tiek ražots. Šajā posmā var parādīties situācijas ar nepārprotamiem scenārijiem, tā sauktās kļūdas.

Pirmais jautājums ir, kā mēs varam tikt galā ar Ŕīm kļūdām pēc tam, kad esam jau izlaiduÅ”i produktu? Kā mēs, piemēram, reaģējam uz stresu? Klients nebÅ«s ļoti apmierināts, ja lapas ielāde prasÄ«s vairāk nekā 30 sekundes.

Å eit parādās ekspluatācija jeb, kā viņi to tagad sauc, DevOps. Faktiski Å”ie ir cilvēki, kas ir atbildÄ«gi par produkta darbÄ«bu, kad tas jau tiek ražots. Tas ietver dažādus uzraudzÄ«bas veidus. Ir pat testÄ“Å”anas apakÅ”veids - testÄ“Å”ana ražoÅ”anā, kad mēs atļaujamies kaut ko netestēt pirms izlaiÅ”anas un pārbaudām to uzreiz ražoÅ”anas laikā. Å Ä« ir pasākumu sērija no infrastruktÅ«ras sakārtoÅ”anas viedokļa, kas ļauj ātri reaģēt uz incidentu, ietekmēt to un novērst to.

SvarÄ«ga ir arÄ« infrastruktÅ«ra. Bieži gadās situācijas, kad pārbaudes laikā nav iespējams pārliecināties, ka mums tieŔām ir viss, ko vēlētos klientam uzdāvināt. Mēs to izlaižam ražoÅ”anā un sākam uztvert nepārprotamas situācijas. Un tas viss tāpēc, ka pārbaudē esoŔā infrastruktÅ«ra neatbilst ražoÅ”anas infrastruktÅ«rai. Tas noved pie jauna veida testÄ“Å”anas - infrastruktÅ«ras testÄ“Å”ana. Tās ir dažādas konfigurācijas, iestatÄ«jumi, datu bāzes migrācija utt.

Tas rada jautājumu - iespējams, komandai ir jāizmanto infrastruktūra kā kods.

Uzskatu, ka infrastruktÅ«ra tieÅ”i ietekmē produkta kvalitāti.

Ceru, ka konferencē bÅ«s ziņojums ar reālu gadÄ«jumu. Rakstiet mums, ja esat gatavs mums pastāstÄ«t no savas pieredzes, kā infrastruktÅ«ra kā kods ietekmē kvalitāti. InfrastruktÅ«ra kā kods ļauj vieglāk pārbaudÄ«t visus iestatÄ«jumus un pārbaudÄ«t lietas, kas citādi vienkārÅ”i nav iespējamas. Tāpēc kvalitatÄ«va produkta izstrādes procesā tiek iesaistÄ«ta arÄ« darbÄ«ba.

ā€” Kā ar analÄ«zi un dokumentāciju?

Anastasia: tas vairāk attiecas uz uzņēmumu sistēmām. Kad mēs runājam par uzņēmumu, prātā uzreiz nāk tādi cilvēki kā analītiķi un sistēmu analītiķi. Viņus dažreiz sauc par tehniskajiem rakstniekiem. Viņi saņem uzdevumu uzrakstīt specifikāciju un izpildīt to, piemēram, mēnesi.

Vairākkārt ir pierādÄ«ts, ka Ŕādas dokumentācijas rakstÄ«Å”ana noved pie ļoti ilgām izstrādes iterācijām un ilgām pilnveidoÅ”anas iterācijām, jo ā€‹ā€‹testÄ“Å”anas procesā tiek identificētas kļūdas un sākas atgrieÅ”ana. Rezultātā ir daudz cilpu, kas palielina izstrādes izmaksas. Turklāt tas var radÄ«t ievainojamÄ«bas. Å Ä·iet, ka esam uzrakstÄ«juÅ”i atsauces kodu, bet pēc tam veicām izmaiņas, kas pārtrauc perfekti pārdomāto arhitektÅ«ru.

Gala rezultāts ir ne visai kvalitatÄ«vs produkts, jo arhitektÅ«rā jau ir parādÄ«juÅ”ies ielāpi, kods vietām nav pietiekami nosegts ar testiem, jo ā€‹ā€‹termiņi iet uz beigām, ātri jāslēdz visas bugs. Un viss tāpēc, ka sākotnējā specifikācijā nebija ņemti vērā visi punkti, kas jāīsteno.

Izstrādātāji nav kaitēkļi un ar nolūku neraksta kodu ar kļūdām.

Ja mēs sākotnēji bÅ«tu pārdomājuÅ”i specifikāciju, kas aptvertu visus nepiecieÅ”amos punktus, tad viss bÅ«tu Ä«stenots tieÅ”i tā, kā nepiecieÅ”ams. Bet tā ir utopija.

DroÅ”i vien nav iespējams uzrakstÄ«t perfektu 100 lappuÅ”u specifikāciju. Tāpēc jādomā par alternatÄ«viem dokumentācijas rakstÄ«Å”anas veidiem, specifikācijas, uzstādot uzdevumus, kas tuvinātu mÅ«s tam, ka izstrādātājs dara tieÅ”i to, kas nepiecieÅ”ams.

Å eit nāk prātā pieejas no Agile - lietotāju stāsti ar pieņemÅ”anas kritērijiem. Tas vairāk attiecas uz komandām, kuras attÄ«stās nelielās iterācijās.

ā€” Kā ar lietojamÄ«bas testÄ“Å”anu, produkta lietojamÄ«bu, dizainu?

Anastasia: Tas ir ļoti svarÄ«gs punkts, jo komandā ir dizaineri. Visbiežāk dizaineri tiek izmantoti kā serviss ā€“ vai nu dizaina nodaļa, vai ārpakalpojuma dizainers. Nereti gadās situācijas, kad Ŕķiet, ka dizainers uzklausÄ«jis produktu speciālistu un darÄ«jis to, ko sapratis. Bet, kad sākam iterāciju, izrādās, ka patiesÄ«bā paveiktais nebija tas, kas bija gaidÄ«ts: dizainers kaut ko aizmirsa, lÄ«dz galam nepārdomāja uzvedÄ«bu, jo viņŔ nav komandā un nav kontekstā vai priekÅ”galā. gala izstrādātājs pilnÄ«bā nesaprata tā izkārtojumu. Tas var aizņemt vairākas iterācijas tikai tāpēc, ka priekÅ”gala izstrādātājam ir radusies problēma, kas saprot dizainu.

Turklāt ir vēl viena problēma. Tagad dizaina sistēmas kļūst arvien populārākas. Tie ir par ažiotāžu, taču ieguvumi no tiem nav pilnīgi acīmredzami.

Sastopos ar viedokli, ka projektÄ“Å”anas sistēmas, no vienas puses, vienkārÅ”o izstrādi, bet, no otras puses, uzliek daudz ierobežojumu saskarnei.

Rezultātā mēs izgatavojam nevis tādu fīču, kādu vēlas klients, bet tādu, kas mums ir ērta, jo mums jau ir noteikti klucÄ«Å”i, no kuriem to varam izgatavot.

Es domāju, ka Ŕī ir tēma, kuru ir vērts aplÅ«kot un padomāt, vai, mēģinot atvieglot dizainu, mēs patieŔām atrisinām klienta problēmu.

ā€” Ir pārsteidzoÅ”i daudz tēmu saistÄ«bā ar kvalitātes nodroÅ”ināŔanu. Vai Krievijā ir kāda konference, kur tos visus varētu apspriest?

Anastasia: Ir vecākā testÄ“Å”anas konference, kas Å”ogad notiks jau 25. reizi un saucas SQA Days Quality Assurance Conference. Tajā galvenokārt tiek apspriesti rÄ«ki un Ä«paÅ”as testÄ“Å”anas pieejas funkcionāliem testētājiem. Parasti SQA dienu ziņojumos ir padziļināti apskatÄ«tas konkrētas jomas paÅ”u testētāju atbildÄ«bas jomā, bet ne sarežģītas darbÄ«bas.

Tas ļoti palÄ«dz izprast dažādus rÄ«kus un pieejas, kā pārbaudÄ«t datu bāzes, API utt. Taču tajā paŔā laikā, no vienas puses, tas nemotivē labāka produkta radÄ«Å”anā iesaistÄ«t vairāk kā tikai testÄ“Å”anu. No otras puses, testētāji netiek vairāk iesaistÄ«ti procesā, lai domātu par produkta un tā biznesa komponenta globālo mērÄ·i.

Es vadu lielu nodaļu un vadu daudz interviju, kas patieŔām sniedz ieskatu par nozares stāvokli kopumā. Parasti mÅ«su puiÅ”i strādā uzņēmumos, un viņiem ir skaidra atbildÄ«bas joma. Kolēģi, kuri strādā ārzemju projektos, izmanto dažādus testÄ“Å”anas veidus: paÅ”i var veikt slodzes testÄ“Å”anu, veiktspējas testÄ“Å”anu un pat dažkārt droŔības testus, jo tie patieŔām palÄ«dz komandai nodroÅ”ināt produkta kvalitāti.

Gribētos, lai arÄ« Krievijas puiÅ”i sāktu domāt, ka nozare nebeidzas ar funkcionālo testÄ“Å”anu.

ā€” Å im nolÅ«kam organizējam jaunu konferenci QualityConf, kas veltÄ«ta kvalitātei kā neatņemamai disciplÄ«nai. Pastāstiet vairāk par ideju, kāds ir konferences galvenais mērÄ·is?

Anastasia: Mēs vēlamies izveidot cilvēku kopienu, kas interesējas par kvalitatÄ«vu produktu ražoÅ”anu. Piedāvājiet platformu, kur viņi var ierasties, klausÄ«ties referātus un pēc konferences doties prom ar konkrētu izpratni par to, kas ir jāmaina, lai uzlabotu kvalitāti.

MÅ«sdienās bieži dzirdu lÅ«gumu no konsultanta, ko darÄ«t, ja ir problēmas ar testÄ“Å”anu un kvalitāti. Uzsākot komunicēt ar komandām, redzi, ka problēma nav paÅ”os testētājos, bet gan tajā, kā process ir strukturēts. Piemēram, ja izstrādātāji uzskata, ka viņi ir atbildÄ«gi tikai par koda rakstÄ«Å”anu, viņu atbildÄ«ba beidzas tieÅ”i tajā brÄ«dÄ«, kad viņi nodod uzdevumu testÄ“Å”anai.

Ne visi domā par to, ka slikti uzrakstÄ«ts, zemas kvalitātes kods ar sliktu arhitektÅ«ru apdraud projektam lielas problēmas. Viņi nedomā par kļūdu izmaksām, ka kļūdas, kas nonāk ražoÅ”anā, var radÄ«t lielas izmaksas uzņēmumam un komandai. Nav kultÅ«ras, lai par to domātu. Es vēlos, lai mēs to sāktu izplatÄ«t konferencē.

Es saprotu, ka tas nav jauninājums. Edvards Demings, 14 kvalitātes principu autors, jau pagājuÅ”ajā gadsimtā rakstÄ«ja par kļūdas izmaksām. Kvalitātes nodroÅ”ināŔana kā disciplÄ«na ir balstÄ«ta uz Å”o grāmatu, bet diemžēl mÅ«sdienu attÄ«stÄ«ba par to aizmirst.

ā€” Vai plānojat pieskarties tēmām tieÅ”i par testÄ“Å”anu un rÄ«kiem?

Anastasia: Pieļauju, ka būs atskaites par instrumentiem. Ir diezgan universāli instrumenti, ar kuriem uzņēmumi un komandas var ietekmēt produktu.

Visus pārskatus globāli vienos viena kopÄ«ga misija: nodot auditorijai, ka ar Ŕīs pieejas, rÄ«ka, metodes, procesa, testÄ“Å”anas veida palÄ«dzÄ«bu esam ietekmējuÅ”i produkta kvalitāti un uzlabojuÅ”i klienta dzÄ«vi.

Mums noteikti nebūs ziņojumu par rīku rīka dēļ. Visus programmā iekļautos ziņojumus vienos kopīgs mērķis.

ā€” Kuram bÅ«s interese par to, par ko jÅ«s runājat, kurus jÅ«s redzat kā konferences viesus?

Anastasia: Mums bÅ«s atskaites izstrādātājiem, kuriem rÅ«p sava projekta, produkta, sistēmas liktenis. Tāpat tas interesēs testētājus un, man Ŕķiet, Ä«paÅ”i vadÄ«tājus. Ar vadÄ«tājiem es domāju cilvēkus, kuri pieņem lēmumus un var ietekmēt arÄ« produkta, sistēmas, komandas likteni un attÄ«stÄ«bu.

Tie ir cilvēki, kuri domā, kā uzlabot produkta vai sistēmas kvalitāti. MÅ«su konferencē viņi uzzinās par dažādiem pasākumu kompleksiem un varēs saprast, kas viņiem Å”obrÄ«d nav kārtÄ«bā un kas ir jāmaina.

Manuprāt, galvenais kritērijs ir saprast, ka ar kvalitāti kaut kas nav kārtībā, un vēlme to ietekmēt. Visticamāk, mēs nevarēsim sasniegt cilvēkus, kuri domā, ka tas notiks pirmo reizi.

ā€” Vai, jÅ«suprāt, nozare kopumā ir nobriedusi runāt ne tikai par testÄ“Å”anu, bet arÄ« par kvalitātes kultÅ«ru?

Anastasia: Es domāju, ka esmu nobriedusi. Tagad daudzi uzņēmumi atsakās no tradicionālās Waterfall pieejas uz Agile. Ir klientu fokuss, cilvēki komandās patieŔām sāk domāt, kā izveidot kvalitatÄ«vu produktu. Pat uzņēmumu uzņēmumi atkal koncentrējas uz kvalitātes uzlaboÅ”anu.

Spriežot pēc lÅ«gumu skaita, kas rodas sabiedrÄ«bā, uzskatu, ka ir pienācis laiks. Es, protams, neesmu pārliecināts, ka tā bÅ«s liela mēroga revolÅ«cija, bet es gribētu, lai Ŕī apziņas revolÅ«cija notiktu.

- Piekritu! Mēs ieaudzināsim kultūru un mainīsim apziņu.

Konference par kvalitatÄ«vu IT produktu izstrādi QualityConf notiks Maskavā 7. jÅ«nijā. JÅ«s zināt, kādi posmi veido kvalitatÄ«vu produktu, mums ir gadÄ«jumi, kad ražoÅ”anā veiksmÄ«gi apkarojam kļūdas, esam pārbaudÄ«juÅ”i populāras metodes savā praksē - mums ir nepiecieÅ”ama jÅ«su pieredze. SÅ«tÄ«t viņu pieteikumus lÄ«dz 1. maijam, un Programmas komiteja palÄ«dzēs koncentrēties uz tēmu konferences vispārējai integritātei.

Pievienot tērzÄ“Å”ana, kurā apspriežam kvalitātes jautājumus un konferenci, abonējiet Telegrammas kanālslai bÅ«tu informēts par programmas jaunumiem.

Avots: www.habr.com

Pievieno komentāru