Halo, Habr!
Kami memiliki topik penting baru - pengembangan produk IT yang berkualitas tinggi. Kita sering berbicara di HighLoad ++ tentang cara membuat layanan yang dimuat cepat, dan tentang Frontend Conf - antarmuka pengguna yang keren yang tidak melambat. Kami secara teratur memiliki topik tentang pengujian, dan DevOpsConf tentang menggabungkan berbagai proses, termasuk pengujian. Tetapi tentang kualitas apa yang bisa disebut sebagai keseluruhan, dan bagaimana mengatasinya secara komprehensif, tidak.
Mari kita perbaiki pada
QualityConf - kami akan mengembangkan budaya berpikir tentang kualitas produk akhir untuk pengguna di setiap tahap pengembangan. Kebiasaan tidak terpaku pada tanggung jawab Anda, dan mengasosiasikan kualitas tidak hanya dengan penguji.
Di bawah potongan, kita akan berbicara dengan kepala komite program, kepala pengujian di Tinkoff
Business , pencipta komunitas QA berbahasa Rusia
Anastasia Aseeva-Nguyen tentang keadaan industri QA dan misi konferensi baru.
- Nastya, halo. Tolong beritahu tentang dirimu.
Anastasia : Saya memimpin pengujian di bank, saya bertanggung jawab untuk tim yang sangat besar - ada lebih dari 90 dari kita. Kami memiliki lini bisnis yang penting, kami bertanggung jawab atas ekosistem untuk badan hukum.
Saya belajar di mehmat dan awalnya ingin menjadi seorang programmer. Tetapi ketika saya memiliki tawaran yang menarik, saya memutuskan untuk mencoba sendiri sebagai penguji. Anehnya, ini ternyata adalah panggilan saya. Sekarang saya melihat semua pekerjaan saya di industri ini.
Saya seorang penganut disiplin Jaminan Kualitas. Saya tidak peduli produk apa yang dibuat, bagaimana mereka berhubungan dengan kualitas di perusahaan, di tim dan, pada prinsipnya, dalam proses pengembangan.
Jelas bagi saya bahwa
komunitas ke arah ini tidak cukup matang , setidaknya di Rusia. Kami tidak selalu memahami bahwa jaminan kualitas tidak hanya fakta menguji aplikasi untuk kepatuhan terhadap persyaratan. Saya ingin mengubah situasi ini.
- Anda menggunakan kata-kata Jaminan Kualitas dan pengujian. Di mata orang kebanyakan, kedua istilah ini sangat sering bersilangan. Bagaimana mereka berbeda jika Anda menggali lebih dalam?Anastasia: Sebaliknya, mereka tidak berbeda. Pengujian adalah bagian dari disiplin Jaminan Kualitas, ini adalah aktivitas langsung - fakta bahwa saya sedang menguji sesuatu. Sebenarnya ada banyak jenis pengujian, dan orang yang berbeda bertanggung jawab untuk berbagai jenis pengujian. Tetapi di Rusia, ketika ada gelombang agen outsourcing yang memasok penguji ke perusahaan, pengujian dikurangi menjadi satu pandangan.
Dalam kebanyakan kasus, mereka hanya terbatas pada pengujian fungsional: mereka memverifikasi bahwa apa yang telah dikompilasi pengembang memenuhi spesifikasi dan itu saja.
- Tolong katakan, disiplin ilmu penjaminan kualitas apa lagi yang ada? Apa lagi selain pengujian yang termasuk?Anastasia : Jaminan Kualitas, pertama-tama, tentang menciptakan produk yang berkualitas. Artinya, kami bertanya-tanya atribut kualitas apa yang harus dimiliki produk kami. Dengan demikian, jika kita memahami ini, kita dapat membandingkan siapa yang memengaruhi atribut kualitas ini. Tidak masalah,
pengembang, manajer proyek atau manajer produk adalah orang yang memengaruhi pengembangan produk, jaminan simpanannya, strateginya.
Penguji lebih menyadari perannya. Dia memahami bahwa tugasnya tidak hanya menguji kepatuhan terhadap persyaratan, tetapi juga menguji persyaratan, mempertanyakan bahasa yang berasal dari teknolog produk, dan mengungkapkan semua persyaratan dan harapan implisit dari klien. Ketika kami memberikan fungsionalitas baru kepada pelanggan kami, kami harus benar-benar memenuhi harapannya dan menyelesaikan rasa sakitnya. Jika kita memikirkan semua atribut kualitas, klien akan puas dan akan memahami bahwa perusahaan yang produknya dia gunakan benar-benar peduli dengan minatnya, dan tidak bekerja berdasarkan prinsip "hanya untuk merilis fitur".
- Tampaknya apa yang baru saja Anda uraikan adalah tugas dari teknolog produk. Ini, pada prinsipnya, bukan tentang pengujian dan bukan tentang kualitas - ini umumnya tentang manajemen produk, bukan?Anastasia : Termasuk. Jaminan Kualitas bukan disiplin yang menjadi tanggung jawab satu orang tertentu. Sekarang ada arah populer dalam pengujian, sebuah pendekatan yang disebut
Agile Testing . Dalam definisinya, kedengarannya langsung bahwa ini adalah pendekatan tim untuk pengujian, yang mencakup serangkaian praktik tertentu. Seluruh tim bertanggung jawab untuk menerapkan pendekatan ini, bahkan penguji tidak perlu berada dalam tim. Seluruh tim fokus pada memberikan nilai kepada klien, dan agar nilai ini memenuhi harapannya.
- Ternyata kualitas berpotongan dengan hampir semua disiplin ilmu di sekitarnya, memaksakan kerangka kerja pada segala sesuatu di sekitarnya?Anastasia : Benar. Ketika kita berpikir tentang apa yang kita inginkan untuk menciptakan produk yang berkualitas, kita mulai berpikir tentang berbagai atribut kualitas. Misalnya, cara memeriksa apakah kami benar-benar membuat fitur yang dibutuhkan klien kami.
Pengujian semacam ini muncul seperti
UAT (pengujian penerimaan pengguna). Sayangnya, di Rusia jarang dilakukan, tetapi kadang-kadang hadir di tim SCRUM, sebagai demo untuk pelanggan akhir. Di perusahaan asing, ini adalah jenis pengujian yang cukup umum. Sebelum membuka fungsionalitas untuk semua pelanggan, pertama-tama kami membuat UAT, yaitu, kami mengundang pengguna akhir yang melakukan pengujian dan segera memberikan umpan balik - apakah produk benar-benar memenuhi harapan dan menyelesaikan rasa sakit. Hanya setelah ini adalah penskalaan untuk semua klien lain.
Artinya, kami fokus pada bisnis, pada konsumen akhir, tetapi pada saat yang sama
jangan lupa tentang teknologi . Kualitas produk juga sangat bergantung pada teknologi. Jika arsitektur kami buruk, kami tidak akan dapat dengan cepat merilis fitur dan memenuhi harapan pelanggan. Mungkin ada banyak bug saat mencoba skala, atau ketika mencoba refactor, kita dapat memecahkan sesuatu. Ini semua akan mempengaruhi kepuasan pelanggan.
Dari sudut pandang ini, arsitektur harus sedemikian rupa sehingga kita dapat menulis kode bersih yang memungkinkan kita untuk membuat perubahan dengan cepat dan tidak takut bahwa kita akan menghancurkan segalanya. Sehingga iterasi perbaikan tidak diperpanjang selama beberapa bulan hanya karena kami memiliki banyak warisan dan kami perlu melakukan langkah pengujian yang panjang.
- Secara total, pengembang, arsitek, pakar produk, manajer produk, penguji sendiri sudah terlibat. Siapa lagi yang terlibat dalam proses penjaminan kualitas?Anastasia : Sekarang bayangkan bahwa kami telah mengirimkan fitur kepada klien. Jelas, Anda perlu memantau kualitas produk, dan ketika sudah dalam produksi. Pada tahap ini, situasi dengan skenario yang tidak jelas, yang disebut bug, dapat muncul.
Pertanyaan pertama adalah bagaimana kita bekerja dengan bug ini setelah kita merilis produk? Bagaimana kita, misalnya, bereaksi terhadap beban? Klien tidak akan puas jika halaman dimuat lebih dari 30 detik.
Di
sinilah eksploitasi atau, sebagaimana mereka menyebutnya sekarang,
DevOps ikut bermain. Bahkan, ini adalah orang-orang yang bertanggung jawab atas pengoperasian produk ketika sudah dijual. Ini termasuk berbagai jenis pemantauan. Bahkan ada subtipe pengujian - pengujian pada prod, ketika kita membiarkan diri kita untuk tidak menguji sesuatu sebelum meluncurkan dan segera mengujinya pada prod. Ini adalah serangkaian langkah-langkah dari sudut pandang organisasi infrastruktur yang memungkinkan Anda untuk dengan cepat merespons suatu insiden, mempengaruhinya, dan memperbaikinya.
Infrastruktur juga penting. Seringkali ada situasi ketika selama tes tidak mungkin untuk memastikan bahwa kami benar-benar memiliki semua yang ingin kami berikan kepada klien. Kami meluncurkan produk - dan mulai menangkap situasi yang tidak terlihat. Dan semua karena infrastruktur dalam tes tidak sesuai dengan infrastruktur pada prod. Ini mengarah pada jenis pengujian baru -
pengujian infrastruktur . Ini adalah berbagai konfigurasi, pengaturan, migrasi basis data, dll.
Ini menimbulkan pertanyaan - mungkin tim perlu menggunakan infrastruktur sebagai kode.
Saya percaya infrastruktur secara langsung mempengaruhi kualitas produk.
Saya berharap konferensi akan memiliki laporan dengan kasus nyata. Menulis kepada kami jika Anda siap memberi tahu dari pengalaman Anda sendiri bagaimana infrastruktur sebagai kode memengaruhi kualitas. Infrastruktur sebagai kode memudahkan untuk memeriksa semua pengaturan dan menguji sesuatu yang tidak mungkin dilakukan. Oleh karena itu, eksploitasi juga terlibat dalam proses pengembangan produk yang berkualitas.
- Bagaimana dengan analitik dan dokumentasi?Anastasia : Ini lebih berlaku untuk sistem perusahaan. Ketika kita berbicara tentang perusahaan, orang-orang seperti analis dan analis sistem segera datang ke pikiran. Mereka kadang-kadang disebut penulis teknis. Mereka menerima tugas untuk menulis spesifikasi dan melengkapinya, misalnya, sebulan.
Sudah berulang kali dibuktikan bahwa penulisan dokumentasi semacam itu mengarah pada iterasi pengembangan yang sangat lama dan iterasi perbaikan yang lama, karena selama proses pengujian bug terdeteksi, pengembalian dimulai. Akibatnya, ada banyak loop yang meningkatkan biaya pengembangan. Selain itu, ini bisa menimbulkan kerentanan. Kami tampaknya telah menulis kode referensi, tetapi kemudian membuat perubahan yang memecah arsitektur yang dipikirkan dengan sempurna.
Hasilnya adalah produk yang tidak terlalu berkualitas tinggi, karena tambalan sudah muncul dalam arsitektur, kode di beberapa tempat tidak cukup tercakup oleh tes, karena tenggat waktu habis, Anda harus menutup semua bug lebih cepat. Dan semua karena dalam spesifikasi asli semua poin yang perlu diimplementasikan tidak diperhitungkan.
Pengembang bukan hama dan tidak secara khusus menulis kode dengan kesalahan.
Jika kita awalnya memikirkan spesifikasi di mana semua poin yang diperlukan akan dibahas, maka semuanya akan dilaksanakan persis seperti seharusnya. Tapi ini utopia.
Mungkin mustahil untuk menulis spesifikasi 100 halaman yang sempurna. Oleh karena itu,
kita perlu memikirkan cara-cara alternatif untuk menulis dokumentasi , menentukan, menetapkan tugas yang akan membawa kita lebih dekat dengan kenyataan bahwa pengembang melakukan apa yang kita butuhkan.
Di sinilah pendekatan Agile - cerita pengguna dengan kriteria penerimaan. Ini lebih berlaku untuk tim yang berkembang dalam iterasi kecil.
- Bagaimana dengan pengujian kegunaan, kegunaan produk, desain?Anastasia : Ini adalah poin yang sangat penting, karena ada desainer di tim. Paling sering, desainer menggunakannya sebagai layanan - baik departemen desain atau desainer outsourcing. Seringkali ada situasi dimana perancang tampaknya mendengarkan teknologi produk dan melakukan apa yang dia pahami. Tetapi ketika kita memulai iterasi, ternyata tidak apa yang diharapkan benar-benar dilakukan: perancang lupa sesuatu, tidak memikirkan perilaku karena dia tidak ada dalam tim atau dalam konteks, atau pengembang front-end tidak sepenuhnya memahaminya tata letak. Mungkin diperlukan beberapa iterasi hanya karena ada masalah dengan pemahaman desain oleh pengembang front-end.
Ditambah lagi ada masalah lain. Sistem desain semakin populer. Mereka sedang hype, tetapi manfaatnya tidak sepenuhnya jelas.
Saya menemukan pendapat bahwa sistem desain, di satu sisi, menyederhanakan pengembangan, dan di sisi lain, memberlakukan banyak batasan pada antarmuka.
Akibatnya, kami tidak membuat fitur yang ingin diterima klien, tetapi fitur yang nyaman bagi kami, karena kami sudah memiliki kubus tertentu yang dapat digunakan untuk membuatnya.
Menurut saya, Anda harus memperhatikan topik ini dan memikirkan apakah kami benar-benar menyelesaikan rasa sakit klien dalam upaya menyederhanakan pekerjaan dalam desain.
- Ternyata banyak topik yang terkait dengan Jaminan Kualitas. Apakah ada konferensi di Rusia di mana semuanya bisa dibahas?Anastasia : Ada konferensi pengujian tertua, yang akan diadakan untuk yang ke-25 tahun ini dan disebut SQA Days Quality Assurance Conference. Ini terutama membahas alat dan pendekatan pengujian khusus untuk penguji fungsional. Sebagai aturan, laporan tentang SQA Days secara mendalam memeriksa bidang-bidang tertentu di bidang tanggung jawab penguji itu sendiri, tetapi bukan peristiwa yang rumit.
Ini sangat membantu untuk memahami berbagai alat dan pendekatan, cara menguji basis data, API, dll. Tetapi pada saat yang sama, di satu sisi, itu tidak memotivasi untuk tidak hanya melibatkan pengujian dalam penciptaan produk yang lebih baik. Di sisi lain, penguji tidak menjadi lebih terlibat dalam proses untuk berpikir tentang tujuan global produk dan komponen bisnisnya.
Saya memimpin departemen besar, melakukan banyak wawancara, yang pada kenyataannya memungkinkan kami untuk menyajikan kondisi industri secara keseluruhan. Sebagai aturan, karyawan kami bekerja di perusahaan, dan mereka memiliki area tanggung jawab yang jelas. Kolega yang bekerja di proyek asing menggunakan berbagai jenis pengujian: mereka sendiri dapat melakukan pengujian stres, pengujian kinerja, dan bahkan terkadang pengujian keamanan, karena mereka benar-benar membantu tim untuk menyediakan produk dengan kualitas.
Saya ingin agar orang-orang kita di Rusia juga mulai berpikir bahwa industri ini tidak berakhir dengan pengujian fungsional.
- Untuk ini kami menyelenggarakan konferensi QualityConf baru, yang didedikasikan untuk kualitas sebagai disiplin holistik. Ceritakan lebih lanjut tentang ide itu, apa tujuan utama konferensi?Anastasia : Kami ingin menciptakan komunitas orang yang tertarik untuk membuat produk yang berkualitas. Tawarkan sebuah platform di mana mereka dapat datang, mendengarkan laporan dan pergi setelah konferensi dengan pemahaman konkret tentang apa yang perlu diubah di tempat mereka untuk meningkatkan kualitas.
Seringkali sekarang saya mendengar permintaan dari konsultasi apa yang harus dilakukan ketika ada masalah dengan pengujian, dengan kualitas. Ketika Anda mulai berbicara dengan tim, Anda melihat bahwa masalahnya bukan pada penguji sendiri, tetapi dengan cara proses dibangun. Misalnya, ketika pengembang percaya bahwa mereka hanya bertanggung jawab untuk menulis kode, tanggung jawab mereka berakhir tepat pada saat mereka mentransfer tugas ke pengujian.
Tidak semua orang berpikir bahwa kode berkualitas buruk yang ditulis dengan buruk dengan arsitektur yang buruk menimbulkan masalah besar bagi proyek. Jangan berpikir tentang biaya kesalahan, bahwa bug yang masuk ke produksi dapat menyebabkan biaya besar bagi perusahaan dan tim. Tidak ada budaya untuk memikirkannya. Saya ingin kita mulai membagikannya di konferensi.
Saya mengerti bahwa ini bukan inovasi. Edward Deming, penulis 14 postulat kualitas, menulis tentang biaya kesalahan pada abad terakhir. Buku ini didasarkan pada Jaminan Kualitas sebagai suatu disiplin ilmu, tetapi, sayangnya, perkembangan modern, melupakannya.
- Apakah Anda berencana untuk menyentuh topik secara langsung tentang pengujian dan alat?Anastasia : Saya akui bahwa akan ada laporan tentang alat tersebut. Ada alat yang cukup universal dimana perusahaan dan tim dapat mempengaruhi suatu produk.
Semua laporan akan disatukan secara global oleh satu misi bersama: untuk menyampaikan kepada hadirin bahwa dengan pendekatan, alat, metode, proses, jenis pengujian ini, kami telah memengaruhi kualitas produk dan meningkatkan kehidupan klien.
Kami pasti tidak akan memiliki laporan tentang alat ini demi alat tersebut. Semua laporan yang termasuk dalam program akan disatukan oleh tujuan bersama.
- Siapa yang akan tertarik dengan apa yang Anda bicarakan, yang Anda lihat sebagai tamu konferensi?Anastasia : Kami akan memiliki laporan untuk pengembang yang tidak peduli dengan nasib proyek, produk, sistem mereka. Ini akan sama menariknya bagi penguji dan, bagi saya, terutama bagi para manajer. Yang saya maksud dengan para manajer adalah orang-orang yang membuat keputusan dan dapat memengaruhi nasib dan pengembangan suatu produk, sistem, tim.
Mereka adalah orang-orang yang bertanya-tanya bagaimana cara meningkatkan kualitas suatu produk, sistem. Pada konferensi kami, mereka akan belajar tentang berbagai kompleks acara dan akan dapat memahami apa yang tidak benar dengan apa yang perlu diubah.
Saya pikir kriteria utama adalah untuk memahami bahwa ada sesuatu yang salah dengan kualitas, dan ingin mempengaruhinya. Mungkin, pertama kali menjangkau orang yang percaya bahwa itu akan berhasil, kita tidak akan berhasil.
- Apakah Anda pikir industri secara keseluruhan telah matang untuk berbicara tidak hanya tentang pengujian, tetapi tentang budaya kualitas?Anastasia : Saya pikir saya telah matang. Sekarang banyak perusahaan yang beralih dari pendekatan Air Terjun tradisional menuju Agile. Ada fokus pelanggan, orang-orang dalam tim benar-benar mulai berpikir tentang cara membuat produk yang berkualitas. Bahkan di perusahaan-perusahaan, ada reorientasi untuk meningkatkan kualitas.
Menilai dari jumlah pertanyaan yang muncul di komunitas, saya percaya ini saatnya. Saya tidak yakin, tentu saja, bahwa ini akan menjadi revolusi skala besar, tetapi saya ingin perubahan kesadaran ini terjadi.
- Setuju! Kami akan menanamkan budaya dan mengubah pikiran.Konferensi tentang pengembangan kualitas produk IT QualityConf akan diadakan di Moskow pada 7 Juni . Anda tahu, dari tahap apa sebuah produk berkualitas tinggi dibuat, ada kasus dalam stok untuk berhasil menangani bug pada prod, kami telah menguji teknik populer dalam praktik kami - kami membutuhkan pengalaman Anda. Kirimkan aplikasi Anda paling lambat 1 Mei , dan Komite Program akan membantu memfokuskan topik untuk keseluruhan integritas konferensi.
Terhubung ke obrolan di mana kami membahas masalah kualitas dan konferensi, berlangganan saluran Telegram untuk tetap mengikuti berita program.