Hey Habr!
Kita duwe topik penting anyar - pangembangan produk IT sing berkualitas tinggi. Ing HighLoad ++ kita kerep ngomong babagan carane nggawe layanan sing sibuk kanthi cepet, lan ing Frontend Conf kita ngomong babagan antarmuka pangguna sing keren sing ora alon-alon. Kita ajeg duwe topik babagan testing, lan DevOpsConf babagan nggabungake macem-macem proses, kalebu testing. Nanging babagan apa sing bisa diarani kualitas umume, lan cara nggarap kanthi komprehensif - ora.
Ayo ndandani iki dening — kita bakal ngembangake budaya mikir babagan kualitas produk pungkasan kanggo pangguna ing saben tahap pangembangan. Kebiasaan ora fokus ing tanggung jawab sampeyan, lan nggandhengake kualitas ora mung karo penguji.
Ing ngisor potong kita bakal ngomong karo kepala panitia program, kepala tes ing Tinkoff.Business, pencipta komunitas QA sing nganggo basa Rusia Anastasia Aseeva-Nguyen bab negara industri QA lan misi konferensi anyar.
- Nastia halo. Mangga nyritakake babagan sampeyan.
Anastasia: Aku mimpin testing ing bank lan tanggung jawab kanggo tim gedhe banget-kita luwih saka 90 wong. Kita duwe garis bisnis sing penting; kita tanggung jawab kanggo ekosistem kanggo entitas legal.
Aku sinau mekanika lan matématika lan pisanan pengin dadi programmer. Nanging nalika aku nampa tawaran menarik, aku mutusaké kanggo nyoba dhewe minangka tester. Anehe, iki dadi panggilanku. Saiki aku weruh kabeh karya ing industri iki.
Aku minangka penganut disiplin Quality Assurance. Aku peduli apa produk sing digawe, carane kualitas dianggep ing perusahaan, ing tim, lan, ing asas, ing proses pembangunan.
Iku cetha kanggo kula masyarakat ing arah iki ora cukup diwasa, paling ora ing Rusia. Kita ora mesthi ngerti manawa jaminan kualitas ora mung kasunyatan nyoba aplikasi kanggo tundhuk karo syarat. Aku pengin ngganti kahanan iki.
— Sampeyan nggunakake tembung Quality Assurance lan testing. Ing mripate wong biasa, rong istilah iki asring tumpang tindih. Kepiye bedane yen digali jero?
Anastasia: Nanging, padha ora beda. Tes minangka bagean saka disiplin Quality Assurance, minangka kegiatan langsung - nyatane yen aku lagi nyoba. Sejatine ana akeh jinis tes, lan macem-macem wong sing tanggung jawab kanggo macem-macem jinis tes. Nanging ing Rusia, nalika gelombang outsourcing muncul sing nyedhiyakake panguji kanggo perusahaan, tes dikurangi dadi siji jinis.
Umume kasus, mung diwatesi kanggo tes fungsional: dheweke mriksa manawa apa sing dikodekake pangembang tundhuk karo spesifikasi lan mung.
— Mangga kandhani apa disiplin jaminan kualitas liyane sing ana? Apa liyane, kajaba tes, kalebu ing kene?
Anastasia: Quality Assurance punika, pisanan lan utomo, babagan nggawe produk kualitas. Yaiku, kita takon dhéwé apa atribut kualitas sing kudu diduweni produk kita. Dadi, yen kita ngerti iki, mula kita bisa mbandhingake sapa sing mengaruhi atribut kualitas kasebut. Ora masalah, pangembang, manajer proyek utawa spesialis produk iku wong sing mengaruhi pangembangan produk, backlog, lan strategi.
Tester dadi luwih ngerti perane. Dheweke ngerti yen tugase ora mung kanggo nguji kepatuhan karo syarat, nanging uga nguji syarat, pitakonan formulasi sing teka saka spesialis produk, lan mbukak kabeh syarat lan pangarepan klien sing implisit. Nalika kita ngirim fungsi anyar kanggo pelanggan, kita kudu bener-bener nyukupi pangarepan lan ngrampungake rasa lara. Yen kita mikir babagan kabeh atribut kualitas, klien bakal kepenak lan bakal ngerti manawa perusahaan sing produke digunakake pancen peduli karo kapentingane lan ora nggarap prinsip "mung ngeculake fitur."
- Iku misale jek sing mung diterangake iku tugas saka spesialis produk. Iki, ing prinsip, dudu babagan tes lan dudu babagan kualitas - umume babagan manajemen produk, ora?
Anastasia: Kalebu. Jaminan Kualitas dudu disiplin sing tanggung jawab siji wong tartamtu. Saiki ana arah populer ing testing, pendekatan disebut Tes Agile. Definisi kasebut kanthi jelas nyatakake yen iki minangka pendekatan tim kanggo tes, sing kalebu sawetara praktik tartamtu. Kabeh tim tanggung jawab kanggo ngleksanakake pendekatan iki; malah ora perlu ana tester ing tim kasebut. Kabeh tim fokus kanggo ngirim nilai menyang pelanggan lan mesthekake yen nilai kasebut cocog karo pangarepan pelanggan.
- Pranyata metu sing kualitas intersects karo meh kabeh disiplin lingkungan, imposing framework ing kabeh watara?
Anastasia: Bener. Nalika kita mikir babagan kasunyatan manawa kita pengin nggawe produk sing berkualitas, mula kita mikir babagan macem-macem atribut kualitas. Contone, carane mriksa manawa kita pancene nggawe fitur sing dibutuhake klien kita.
Iki minangka tes jinis iki: UAT (uji acceptance pangguna). Sayange, jarang dipraktekke ing Rusia, nanging kadhangkala ana ing tim SCRUM minangka demo kanggo klien pungkasan. Iki minangka jinis tes sing cukup umum ing perusahaan manca. Sadurunge mbukak fungsionalitas kanggo kabeh pelanggan, kita pisanan nindakake UAT, yaiku, kita ngajak pangguna pungkasan kanggo nyoba lan langsung menehi umpan balik apa produk kasebut bener-bener nyukupi pangarepan lan ngrampungake rasa sakit. Mung sawise iki, skala menyang kabeh klien liyane kedadeyan.
Yaiku, kita fokus ing bisnis, ing klien pungkasan, nanging ing wektu sing padha aja lali babagan teknologi. Kualitas produk uga gumantung banget marang teknologi. Yen kita duwe arsitektur ala, kita ora bakal bisa cepet nerbitaké fitur lan ketemu pangarepan customer. Bisa uga ana akeh kewan omo nalika nyoba nggedhekake, utawa nalika nyoba refactor, bisa uga ana sing rusak. Kabeh iki bakal mengaruhi kepuasan pelanggan.
Saka sudut pandang iki, arsitektur kudu kaya ngono supaya kita bisa nulis kode sing resik sing bakal ngidini kita cepet nggawe owahan lan ora wedi yen kita bakal ngilangi kabeh. Kanggo mesthekake yen pengulangan revisi ora nganti pirang-pirang wulan mung amarga akeh warisan, kita kudu nindakake tahap tes sing dawa.
- Secara total, pangembang, arsitek, ilmuwan produk, manajer produk, lan penguji dhewe wis melu. Sapa maneh sing melu proses jaminan kualitas?
Anastasia: Saiki ayo bayangake yen kita wis ngirim fitur kasebut menyang klien. Temenan, kualitas produk kudu dipantau sanajan wis ana ing produksi. Ing tahap iki, kahanan kanthi skenario sing ora jelas, sing diarani bug, bisa uga katon.
Pitakonan pisanan yaiku kepiye cara ngatasi kewan omo kasebut sawise kita ngeculake produk kasebut? Kepiye carane kita, contone, nanggepi stres? Klien ora bakal seneng banget yen kaca njupuk luwih saka 30 detik kanggo mbukak.
Iki minangka eksploitasi, utawa sing diarani saiki. DevOps. Nyatane, iki minangka wong sing tanggung jawab kanggo ngoperasikake produk kasebut nalika wis ana ing produksi. Iki kalebu macem-macem jinis pemantauan. Malah ana subtipe tes - tes ing produksi, nalika kita ngidini awake dhewe ora nyoba apa wae sadurunge diluncurake lan langsung nyoba ing produksi. Iki minangka seri kegiatan saka sudut pandang ngatur prasarana sing ngidini sampeyan cepet nanggapi kedadeyan, pengaruhe, lan mbenerake.
Infrastruktur uga penting. Asring ana kahanan nalika, sajrone tes, ora mungkin kanggo mesthekake yen kita duwe kabeh sing pengin diwenehake marang klien. Kita muter metu kanggo produksi lan miwiti nyekel kahanan non-jelas. Lan kabeh amarga infrastruktur ing tes ora cocog karo infrastruktur ing produksi. Iki nyebabake jinis tes anyar - testing infrastruktur. Iki kalebu macem-macem konfigurasi, setelan, migrasi database, lsp.
Iki dadi pitakonan - mbok menawa tim kasebut kudu nggunakake infrastruktur minangka kode.
Aku pracaya yen infrastruktur langsung mengaruhi kualitas produk.
Muga-muga ana laporan kanthi kasus nyata ing konferensi kasebut. Tulis kanggo kita yen sampeyan siyap kanggo kita saka pengalaman dhewe carane infrastruktur minangka kode mengaruhi kualitas. Infrastruktur minangka kode nggampangake mriksa kabeh setelan lan nyoba samubarang sing ora bisa ditindakake. Mulane, operasi uga melu ing proses ngembangaken produk kualitas.
- Apa babagan analytics lan dokumentasi?
Anastasia: Iki luwih ditrapake kanggo sistem perusahaan. Nalika kita ngomong babagan perusahaan, wong-wong kayata analis lan analis sistem langsung mikir. Kadhangkala disebut panulis teknis. Dheweke nampa tugas kanggo nulis spesifikasi lan ngrampungake, umpamane, sajrone sasi.
Wis bola-bali kabukten manawa nulis dokumentasi kasebut nyebabake pengulangan pangembangan sing dawa banget lan perbaikan perbaikan sing dawa, amarga sajrone proses tes, bug diidentifikasi lan bali diwiwiti. Akibaté, ana akeh puteran sing nambah biaya pembangunan. Kajaba iku, iki bisa uga ngenalake kerentanan. Kita koyone wis nulis kode referensi, nanging banjur nggawe owah-owahan sing ngrusak arsitektur sing dipikirake kanthi sampurna.
Akibaté, asil kasebut dudu produk sing berkualitas tinggi, amarga patches wis muncul ing arsitektur, kode ing sawetara panggonan ora cukup dijamin dening tes, amarga deadline wis entek, kabeh kewan omo kudu ditutup luwih cepet. Lan kabeh amarga spesifikasi asli ora njupuk kabeh poin sing kudu ditindakake.
Pangembang dudu hama lan ora nulis kode kanthi sengaja.
Yen kita pisanan mikir babagan spesifikasi sing nyakup kabeh poin sing dibutuhake, mula kabeh bakal ditindakake kanthi persis kaya sing dibutuhake. Nanging iki utopia.
Mesthine ora bisa nulis spesifikasi 100 kaca sing sampurna. Mulane kudu mikir babagan cara alternatif nulis dokumentasi, specifications, statements tugas sing bakal nggawa kita nyedhaki mesthekake yen pangembang nindakake persis apa sing dibutuhake.
Iki ngendi pendekatan Agile teka ing pikiran-crita pangguna kanthi kritéria sing ditampa. Iki luwih ditrapake kanggo tim sing berkembang ing iterasi cilik.
— Kepiye babagan tes kegunaan, kegunaan produk, desain?
Anastasia: Iki minangka titik sing penting banget, amarga ana desainer ing tim. Paling asring, desainer digunakake minangka layanan - dening departemen desain utawa dening desainer outsourcing. Asring ana kahanan sing katon manawa desainer ngrungokake ilmuwan produk lan nindakake apa sing dingerteni. Nanging nalika kita miwiti pengulangan, pranyata apa sing bener ditindakake ora kaya sing dikarepake: desainer lali soko, ora mikir kanthi lengkap babagan prilaku kasebut, amarga dheweke ora ana ing tim lan ora ana ing konteks, utawa ngarep. pangembang -end durung ngerti tata letak. Perlu sawetara iterasi mung amarga ana masalah karo pangerten pangembang ngarep babagan desain kasebut.
Kajaba iku, ana masalah liyane. Sistem desain saiki dadi populer. Padha ana ing hype, nanging keuntungan saka wong-wong mau ora sakabehe ketok.
Aku ngadhepi karo pendapat sing sistem desain, ing tangan siji, menakake pembangunan, nanging ing tangan liyane, padha nemtokke akeh watesan ing antarmuka.
Akibaté, kita ora nggawe fitur sing dikarepake klien, nanging sing trep kanggo kita, amarga kita wis duwe kubus tartamtu saka ngendi kita bisa nggawe.
Aku mikir iku worth mbayar manungsa waé kanggo topik iki lan pemikiran apa ing nyoba kanggo menakake karya desain kita bener mecahaken pain klien.
- Ana pirang-pirang topik sing ana gandhengane karo Jaminan Kualitas. Apa ana konferensi ing Rusia ing ngendi kabeh mau bisa dibahas?
Anastasia: Ana konferensi paling tuwa ing testing, kang bakal dianakaké kanggo kaping 25 taun iki lan disebut Quality Assurance Conference SQA Days. Utamane mbahas alat lan pendekatan tes khusus kanggo penguji fungsional. Minangka aturan, laporan ing SQA Days nliti wilayah tartamtu ing area tanggung jawab para penguji dhewe, nanging dudu kegiatan sing kompleks.
Iki mbantu akeh kanggo mangerteni alat lan pendekatan sing beda-beda, carane nguji database, API, lsp. Nanging ing wektu sing padha, ing tangan siji, ora menehi motivasi kanggo melu luwih saka mung nyoba nggawe produk sing luwih apik. Ing sisih liya, penguji ora dadi luwih melu proses kanggo mikir babagan tujuan global produk lan komponen bisnis.
Aku mbukak departemen gedhe lan nindakake akeh wawancara, sing pancene menehi wawasan babagan kahanan industri kanthi sakabehe. Biasane, wong lanang kita kerja ing perusahaan, lan duwe tanggung jawab sing jelas. Kolega sing kerja ing proyek manca nggunakake macem-macem jinis tes: dheweke dhewe bisa nindakake tes beban, tes kinerja, lan uga kadhangkala tes keamanan, amarga dheweke pancene mbantu tim njamin kualitas produk.
Aku pengin wong lanang ing Rusia uga miwiti mikir babagan kasunyatan manawa industri kasebut ora mungkasi uji coba fungsional.
- Kanggo maksud iki, kita ngatur konferensi anyar, QualityConf, sing darmabakti kanggo kualitas minangka disiplin integral. Marang kita liyane babagan idea, apa tujuan utama konferensi?
Anastasia: Kita pengin nggawe komunitas wong sing kasengsem nggawe produk sing berkualitas. Nawakake platform sing bisa teka, ngrungokake laporan lan ninggalake konferensi kanthi pangerten khusus babagan apa sing kudu diganti kanggo nambah kualitas.
Saiki aku kerep krungu panjaluk saka konsultasi babagan apa sing kudu ditindakake nalika ana masalah karo tes lan kualitas. Nalika sampeyan miwiti komunikasi karo tim, sampeyan bisa ndeleng manawa masalah kasebut ora ana ing panguji dhewe, nanging kanthi cara proses kasebut disusun. Contone, nalika pangembang percaya yen dheweke mung tanggung jawab kanggo nulis kode, tanggung jawabe rampung nalika ngirim tugas kasebut menyang testing.
Ora saben wong mikir babagan kasunyatan sing ditulis kanthi apik, kode kualitas rendah kanthi arsitektur ala ngancam masalah gedhe kanggo proyek kasebut. Dheweke ora mikir babagan biaya kesalahan, yen kewan omo sing ana ing produksi bisa nyebabake biaya gedhe kanggo perusahaan lan tim. Ora ana budaya kanggo mikir babagan iki. Aku pengin kita miwiti nyebarake ing konferensi.
Aku ngerti manawa iki dudu inovasi. Edward Deming, penulis 14 prinsip kualitas, nulis babagan biaya kesalahan ing abad kepungkur. Quality Assurance minangka disiplin adhedhasar buku iki, nanging, sayangé, pembangunan modern lali bab iku.
— Apa sampeyan arep ndemek topik langsung babagan tes lan alat?
Anastasia: Aku ngakoni yen bakal ana laporan babagan alat. Ana alat sing cukup universal kanggo perusahaan lan tim bisa mengaruhi produk kasebut.
Kabeh laporan bakal digabungake sacara global kanthi siji misi umum: kanggo ngirim menyang pamirsa yen kanthi bantuan pendekatan, alat, metode, proses, jinis tes, kita wis mengaruhi kualitas produk lan ningkatake urip klien.
Kita mesthi ora bakal duwe laporan babagan alat kanggo alat. Kabeh laporan sing kalebu ing program kasebut bakal digabungake kanthi tujuan umum.
— Sapa sing bakal kasengsem ing apa sing sampeyan gunakake, sing sampeyan deleng minangka tamu konferensi?
Anastasia: Kita bakal duwe laporan kanggo pangembang sing peduli babagan nasib proyek, produk, sistem. Kajaba iku, bakal dadi kapentingan kanggo penguji lan, misale jek, utamane kanggo manajer. Miturut manajer, tegese wong sing nggawe keputusan lan bisa mengaruhi nasib lan pangembangan produk, sistem, tim, lan liya-liyane.
Iki minangka wong sing kepengin weruh carane nambah kualitas produk utawa sistem. Ing konferensi kita, dheweke bakal sinau babagan macem-macem ukuran lan bakal ngerti apa sing salah karo dheweke saiki lan apa sing kudu diganti.
Aku kritéria utama kanggo ngerti ana sing salah karo kualitas lan pengin pengaruhe. Kita mbokmenawa ora bakal bisa nyedhaki wong sing mikir yen iki bakal ditindakake sepisanan.
- Apa sampeyan mikir industri minangka sakabehe wis mateng kanggo pirembagan ora mung bab testing, nanging bab budaya kualitas?
Anastasia: Aku pracaya aku wis diwasa. Saiki akeh perusahaan sing pindhah saka pendekatan Waterfall tradisional menyang Agile. Ana fokus ing klien, wong ing tim pancene wiwit mikir babagan carane nggawe produk sing berkualitas. Malah perusahaan perusahaan fokus maneh kanggo ningkatake kualitas.
Dideleng saka jumlah panyuwunan sing muncul ing masyarakat, aku percaya yen wis wayahe. Mesthi wae, aku ora yakin manawa iki bakal dadi revolusi gedhe, nanging aku pengin revolusi kesadaran iki kedadeyan.
- Sarujuk! Kita bakal nanem budaya lan ngganti eling.
Konferensi babagan pangembangan produk IT sing berkualitas tinggi bakal njupuk Panggonan ing Moskow tanggal 7 Juni. Sampeyan ngerti apa tahapan nggawe produk berkualitas tinggi, kita duwe kasus sing sukses nglawan kewan omo ing produksi, kita wis nyoba metode populer ing praktik kita dhewe - kita butuh pengalaman sampeyan. sing aplikasi nganti 1 Mei, lan Komite Program bakal mbantu fokus tema kanggo integritas sakabèhé konferensi.
Nyambung menyang , kang kita ngrembug masalah kualitas lan konferensi, langganan kanggo tetep gaul karo warta program.
Source: www.habr.com