Hei Habr!
Kami memiliki topik penting baru - pengembangan produk TI berkualitas tinggi. Di HighLoad++ kami sering berbicara tentang cara mempercepat layanan yang sibuk, dan di Frontend Conf kami berbicara tentang antarmuka pengguna keren yang tidak melambat. Kami secara rutin memiliki topik tentang pengujian, dan DevOpsConf tentang menggabungkan berbagai proses, termasuk pengujian. Namun soal apa yang bisa disebut kualitas secara umum, dan bagaimana cara menggarapnya secara komprehensif - tidak.
Mari kita perbaiki ini dengan — kami akan mengembangkan budaya berpikir tentang kualitas produk akhir bagi pengguna di setiap tahap pengembangan. Kebiasaan tidak fokus pada bidang tanggung jawab Anda, dan mengasosiasikan kualitas tidak hanya dengan penguji.
Di bawah pemotongan kita akan berbicara dengan ketua komite program, kepala pengujian di Tinkoff.Business, pencipta komunitas QA berbahasa Rusia Anastasia Aseeva-Nguyen tentang keadaan industri QA dan misi konferensi baru.
- Nastia halo. Tolong beritahu kami tentang diri Anda.
Anastasia: Saya mengelola pengujian di bank, saya bertanggung jawab atas tim yang sangat besar - kami berjumlah lebih dari 90 orang. Kami memiliki lini bisnis yang penting, kami bertanggung jawab atas ekosistem badan hukum.
Saya belajar mekanika dan matematika dan awalnya ingin menjadi seorang programmer. Namun ketika saya mendapat tawaran menarik, saya memutuskan untuk mencoba sendiri sebagai tester. Anehnya, ternyata ini adalah panggilan saya. Sekarang saya melihat semua pekerjaan saya di industri ini.
Saya seorang penganut setia disiplin Jaminan Kualitas. Saya tidak peduli dengan produk apa yang diciptakan, bagaimana kualitas diperlakukan di perusahaan, di tim dan, pada prinsipnya, dalam proses pengembangan.
Jelas bagi saya hal itu masyarakat ke arah ini belum cukup matang, setidaknya di Rusia. Kami tidak selalu memahami bahwa penjaminan mutu bukan hanya fakta menguji kepatuhan aplikasi terhadap persyaratan. Saya ingin mengubah situasi ini.
— Anda menggunakan kata Jaminan Kualitas dan pengujian. Di mata kebanyakan orang, kedua istilah ini sering kali tumpang tindih. Apa bedanya jika Anda menggali lebih dalam?
Anastasia: Sebaliknya, keduanya 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 berbagai orang bertanggung jawab atas berbagai jenis pengujian. Namun di sini, di Rusia, ketika gelombang agen outsourcing muncul yang memasok penguji ke perusahaan, pengujian dikurangi menjadi satu jenis saja.
Dalam kebanyakan kasus, mereka hanya terbatas pada pengujian fungsional: mereka memeriksa apakah kode yang telah dikodekan oleh pengembang sesuai dengan spesifikasi dan itu saja.
— Tolong beri tahu kami disiplin ilmu penjaminan mutu apa lagi yang ada? Apa lagi selain pengujian yang disertakan di sini?
Anastasia: Jaminan Mutu pertama-tama adalah tentang menciptakan produk yang berkualitas. Artinya, kita bertanya pada diri sendiri atribut kualitas apa yang harus dimiliki produk kita. Oleh karena itu, jika kita memahami hal ini, kita dapat membandingkan siapa yang mempengaruhi atribut kualitas tersebut. Tidak masalah, pengembang, manajer proyek, atau spesialis produk adalah orang yang mempengaruhi pengembangan suatu produk, jaminan simpanannya, dan strateginya.
Penguji menjadi lebih sadar akan perannya. Dia memahami bahwa tugasnya bukan hanya menguji kepatuhan terhadap persyaratan, tetapi juga menguji persyaratan, mempertanyakan formulasi yang berasal dari spesialis produk, dan mengungkapkan semua persyaratan dan harapan tersirat dari klien. Saat kami memberikan fungsionalitas baru kepada pelanggan, kami harus benar-benar memenuhi harapan mereka dan mengatasi kesulitan mereka. Jika kita memikirkan semua atribut kualitas, klien akan puas dan memahami bahwa perusahaan yang produknya ia gunakan sangat peduli dengan kepentingannya, dan tidak bekerja berdasarkan prinsip “hanya merilis fitur”.
— Tampaknya apa yang baru saja Anda jelaskan adalah tugas seorang spesialis produk. Pada prinsipnya, ini bukan tentang pengujian dan bukan tentang kualitas - ini umumnya tentang manajemen produk, bukan?
Anastasia: Termasuk. Penjaminan Mutu bukanlah suatu disiplin ilmu yang menjadi tanggung jawab satu orang tertentu. Sekarang ada arah yang populer dalam pengujian, sebuah pendekatan yang disebut Pengujian Agile. Definisinya dengan jelas menyatakan bahwa ini adalah pendekatan tim dalam pengujian, yang mencakup serangkaian praktik tertentu. Seluruh tim bertanggung jawab untuk menerapkan pendekatan ini; bahkan tidak perlu ada penguji dalam tim. Seluruh tim fokus untuk memberikan nilai kepada pelanggan dan memastikan bahwa nilai memenuhi harapan pelanggan.
— Ternyata kualitas bersinggungan dengan hampir semua disiplin ilmu di sekitarnya, menerapkan kerangka kerja pada segala sesuatu di sekitarnya?
Anastasia: Benar. Ketika kita berpikir tentang bagaimana kita ingin menciptakan produk yang berkualitas, kita mulai memikirkan berbagai atribut kualitas. Misalnya bagaimana cara mengecek apakah kita benar-benar membuat fitur yang dibutuhkan klien kita.
Di sinilah jenis pengujian ini berperan: UAT (pengujian penerimaan pengguna). Sayangnya, hal ini jarang dipraktikkan di Rusia, namun terkadang hadir di tim SCRUM sebagai demo untuk klien akhir. Ini adalah jenis pengujian yang cukup umum di perusahaan asing. Sebelum membuka fungsionalitas untuk semua klien, pertama-tama kami melakukan UAT, yaitu kami mengundang pengguna akhir yang menguji dan segera memberikan umpan balik - apakah produk benar-benar memenuhi harapan dan menyelesaikan masalah. Hanya setelah ini barulah penskalaan ke semua klien lain terjadi.
Artinya, kami fokus pada bisnis, pada klien akhir, tetapi pada saat yang sama jangan lupakan teknologi. Kualitas produk juga sangat bergantung pada teknologi. Jika kami memiliki arsitektur yang buruk, kami tidak akan dapat merilis fitur dengan cepat dan memenuhi harapan pelanggan. Mungkin ada banyak bug saat mencoba melakukan penskalaan, atau saat mencoba melakukan refaktorisasi, kami mungkin merusak sesuatu. Semua ini akan mempengaruhi kepuasan pelanggan.
Dari sudut pandang ini, arsitekturnya harus sedemikian rupa sehingga kita dapat menulis kode bersih yang memungkinkan kita melakukan perubahan dengan cepat dan tidak takut kita akan merusak segalanya. Agar iterasi revisi tidak memakan waktu beberapa bulan hanya karena kita memiliki begitu banyak warisan, dan kita perlu melakukan tahapan pengujian yang panjang.
— Secara total, pengembang, arsitek, ilmuwan produk, manajer produk, dan penguji sendiri sudah terlibat. Siapa lagi yang terlibat dalam proses penjaminan mutu?
Anastasia: Sekarang bayangkan kita telah mengirimkan fitur tersebut ke klien. Tentunya kualitas produk perlu dijaga meskipun sudah diproduksi. Pada tahap ini, situasi dengan skenario yang tidak jelas, yang disebut bug, mungkin muncul.
Pertanyaan pertama adalah bagaimana cara kita mengatasi bug ini setelah kita merilis produk? Misalnya, bagaimana kita bereaksi terhadap stres? Klien tidak akan senang jika halaman membutuhkan waktu lebih dari 30 detik untuk dimuat.
Di sinilah eksploitasi berperan atau, sebagaimana mereka menyebutnya sekarang, DevOps. Padahal, merekalah orang-orang yang bertanggung jawab mengoperasikan produk ketika sudah berproduksi. Ini mencakup berbagai jenis pemantauan. Bahkan ada subtipe pengujian - pengujian pada produksi, ketika kita membiarkan diri kita tidak menguji sesuatu sebelum peluncuran dan segera mengujinya pada produksi. Ini adalah serangkaian tindakan dalam hal pengorganisasian infrastruktur yang memungkinkan Anda merespons suatu insiden dengan cepat, memengaruhinya, dan memperbaikinya.
Infrastruktur juga penting. Seringkali ada situasi ketika, selama pengujian, tidak mungkin untuk memastikan bahwa kita benar-benar memiliki semua yang ingin kita berikan kepada klien. Kami meluncurkannya ke dalam produksi dan mulai menangkap situasi yang tidak jelas. Dan semua itu karena infrastruktur dalam pengujian tidak sesuai dengan infrastruktur dalam produksi. Hal ini mengarah pada jenis pengujian baru - pengujian infrastruktur. Ini adalah berbagai konfigurasi, pengaturan, migrasi basis data, dll.
Hal ini menimbulkan pertanyaan - mungkin tim perlu menggunakan infrastruktur sebagai kode.
Saya percaya bahwa infrastruktur secara langsung mempengaruhi kualitas produk.
Saya berharap akan ada laporan di konferensi dengan kasus nyata. Kirimkan surat kepada kami jika Anda siap memberi tahu kami berdasarkan pengalaman Anda sendiri bagaimana infrastruktur sebagai kode memengaruhi kualitas. Infrastruktur sebagai kode memudahkan untuk memeriksa semua pengaturan dan menguji hal-hal yang tidak mungkin dilakukan. Oleh karena itu, operasi juga terlibat dalam proses pengembangan produk yang berkualitas.
— Bagaimana dengan analitik dan dokumentasi?
Anastasia: Ini lebih berlaku pada sistem perusahaan. Ketika kita berbicara tentang perusahaan, orang-orang seperti analis dan analis sistem langsung terlintas dalam pikiran. Mereka kadang-kadang disebut penulis teknis. Mereka mendapat tugas untuk menulis spesifikasi dan menyelesaikannya, misalnya selama sebulan.
Telah berulang kali dibuktikan bahwa penulisan dokumentasi seperti itu mengarah pada iterasi pengembangan yang sangat panjang dan iterasi penyempurnaan yang panjang, karena bug diidentifikasi selama proses pengujian dan pengembalian dimulai. Akibatnya, banyak perulangan yang meningkatkan biaya pengembangan. Selain itu, hal ini dapat menimbulkan kerentanan. Tampaknya kami telah menulis kode referensi, tetapi kemudian kami membuat perubahan yang merusak arsitektur yang dirancang dengan sempurna.
Hasil akhirnya adalah produk yang tidak sepenuhnya berkualitas tinggi, karena tambalan telah muncul dalam arsitektur, kode di beberapa tempat tidak cukup tercakup dalam pengujian, karena tenggat waktu hampir habis, semua bug harus segera ditutup. Dan semua itu karena spesifikasi aslinya tidak memperhitungkan semua poin yang perlu diimplementasikan.
Pengembang bukanlah hama dan tidak sengaja menulis kode dengan kesalahan.
Jika pada awalnya kami memikirkan spesifikasi yang mencakup semua poin yang diperlukan, maka semuanya akan dilaksanakan tepat seperti yang diperlukan. Tapi ini adalah utopia.
Mungkin mustahil untuk menulis spesifikasi 100 halaman yang sempurna. Itu sebabnya perlu memikirkan cara alternatif untuk menulis dokumentasi, spesifikasi, menetapkan tugas yang akan membawa kita lebih dekat untuk memastikan bahwa pengembang melakukan apa yang dibutuhkan.
Di sini muncul pendekatan dari 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 poin yang sangat penting, karena ada desainer di tim. Paling sering, desainer digunakan sebagai layanan - baik oleh departemen desain atau oleh desainer outsourcing. Seringkali ada situasi di mana desainer terlihat mendengarkan spesialis produk dan melakukan apa yang dia pahami. Namun ketika kita memulai iterasi, ternyata apa yang sebenarnya dilakukan tidak sesuai dengan yang diharapkan: sang desainer melupakan sesuatu, tidak sepenuhnya memikirkan perilakunya, karena ia tidak berada dalam tim dan tidak berada dalam konteks, atau berada di depan. -Pengembang akhir tidak sepenuhnya memahami tata letaknya. Mungkin diperlukan beberapa kali pengulangan hanya karena ada masalah dengan pengembang front-end dalam memahami desainnya.
Ditambah lagi, ada satu masalah lagi. Sistem desain kini semakin populer. Mereka sedang populer, tetapi manfaatnya tidak sepenuhnya jelas.
Saya menemukan pendapat bahwa sistem desain, di satu sisi, menyederhanakan pengembangan, tetapi di sisi lain, sistem tersebut memberlakukan banyak batasan pada antarmuka.
Alhasil, kami tidak membuat fitur yang diinginkan klien, melainkan fitur yang nyaman bagi kami, karena kami sudah memiliki kubus tertentu untuk membuatnya.
Saya pikir ini adalah topik yang layak untuk dilihat dan ditanyakan apakah dalam mencoba membuat desain lebih mudah kita benar-benar memecahkan masalah klien.
— Ada sejumlah topik mengejutkan terkait Penjaminan Mutu. Apakah ada konferensi di Rusia di mana semuanya bisa didiskusikan?
Anastasia: Ada konferensi pengujian tertua, yang akan diadakan untuk ke-25 kalinya tahun ini dan disebut Konferensi Penjaminan Mutu Hari SQA. Ini terutama membahas alat dan pendekatan pengujian khusus untuk penguji fungsional. Sebagai aturan, laporan di SQA Days memeriksa secara mendalam area tertentu di area tanggung jawab penguji itu sendiri, tetapi bukan aktivitas yang kompleks.
Ini sangat membantu dalam memahami berbagai alat dan pendekatan, cara menguji database, API, dll. Namun pada saat yang sama, di satu sisi, hal ini tidak memotivasi untuk melibatkan lebih dari sekedar pengujian dalam penciptaan produk yang lebih baik. Di sisi lain, penguji tidak menjadi lebih terlibat dalam proses memikirkan tujuan global produk dan komponen bisnisnya.
Saya menjalankan departemen besar dan melakukan banyak wawancara yang benar-benar memberikan wawasan tentang keadaan industri secara keseluruhan. Biasanya, orang-orang kami bekerja di perusahaan, dan mereka memiliki tanggung jawab yang jelas. Kolega yang bekerja di proyek luar negeri menggunakan berbagai jenis pengujian: mereka sendiri dapat melakukan pengujian beban, pengujian kinerja, dan bahkan terkadang pengujian keamanan, karena mereka sangat membantu tim memastikan kualitas produk.
Saya ingin orang-orang di Rusia juga mulai berpikir bahwa industri ini tidak berakhir hanya dengan pengujian fungsional.
— Untuk tujuan ini, kami menyelenggarakan konferensi baru, QualityConf, yang didedikasikan untuk kualitas sebagai disiplin integral. Ceritakan lebih banyak tentang ide tersebut, apa tujuan utama konferensi ini?
Anastasia: Kami ingin menciptakan komunitas orang-orang yang tertarik untuk membuat produk berkualitas. Tawarkan sebuah platform di mana mereka dapat datang, mendengarkan laporan, dan pulang setelah konferensi dengan pemahaman khusus tentang apa yang perlu diubah untuk meningkatkan kualitas.
Saat ini saya sering mendengar permintaan dari konsultan tentang apa yang harus dilakukan ketika ada masalah dengan pengujian dan kualitas. Saat Anda mulai berkomunikasi dengan tim, Anda melihat bahwa masalahnya bukan pada penguji itu sendiri, tetapi pada struktur prosesnya. Misalnya, ketika pengembang yakin bahwa mereka hanya bertanggung jawab menulis kode, tanggung jawab mereka berakhir tepat pada saat mereka menyerahkan tugas untuk pengujian.
Tidak semua orang memikirkan fakta bahwa kode yang ditulis dengan buruk, berkualitas rendah dengan arsitektur yang buruk mengancam masalah besar bagi proyek tersebut. Mereka tidak memikirkan kerugian akibat kesalahan, bahwa kesalahan yang berakhir di produksi dapat mengakibatkan kerugian yang besar bagi perusahaan dan tim. Tidak ada budaya untuk memikirkan hal ini. Saya ingin kita mulai mendistribusikannya di konferensi.
Saya memahami bahwa ini bukanlah sebuah inovasi. Edward Deming, penulis 14 prinsip kualitas, menulis tentang akibat dari sebuah kesalahan pada abad yang lalu. Penjaminan Mutu sebagai suatu disiplin ilmu didasarkan pada buku ini, namun sayangnya perkembangan modern melupakannya.
— Apakah Anda berencana untuk membahas topik secara langsung tentang pengujian dan alat?
Anastasia: Saya akui akan ada laporan tentang alat. Ada alat yang cukup universal yang dapat digunakan perusahaan dan tim untuk memengaruhi produk.
Semua laporan secara global akan disatukan oleh satu misi yang sama: untuk menyampaikan kepada audiens bahwa dengan bantuan pendekatan, alat, metode, proses, jenis pengujian ini, kami telah memengaruhi kualitas produk dan meningkatkan kehidupan klien.
Kami pasti tidak akan memiliki laporan tentang suatu alat demi suatu alat. Semua laporan yang termasuk dalam program ini akan disatukan oleh tujuan yang sama.
— Siapa yang tertarik dengan apa yang Anda bicarakan, siapa yang Anda lihat sebagai tamu konferensi?
Anastasia: Kami akan memiliki laporan untuk pengembang yang peduli dengan nasib proyek, produk, sistem mereka. Demikian pula, ini akan menarik bagi penguji dan, menurut saya, terutama bagi para manajer. Yang saya maksud dengan manajer adalah orang-orang yang membuat keputusan dan dapat mempengaruhi nasib serta perkembangan suatu produk, sistem, tim juga.
Mereka adalah orang-orang yang bertanya-tanya bagaimana cara meningkatkan kualitas suatu produk atau sistem. Pada konferensi kami, mereka akan belajar tentang berbagai rangkaian tindakan dan akan dapat memahami apa yang salah saat ini dan apa yang perlu diubah.
Saya pikir kriteria utamanya adalah memahami bahwa ada sesuatu yang salah dengan kualitas dan ingin mempengaruhinya. Kami mungkin tidak akan dapat menjangkau orang-orang yang menganggap hal ini hanya akan berhasil untuk pertama kalinya.
— Apakah menurut Anda industri secara keseluruhan sudah siap untuk membicarakan tidak hanya tentang pengujian, namun juga tentang budaya kualitas?
Anastasia: Saya pikir saya sudah dewasa. Sekarang banyak perusahaan yang beralih dari pendekatan Waterfall tradisional menuju Agile. Ada fokus pelanggan, orang-orang dalam tim benar-benar mulai memikirkan cara menciptakan produk yang berkualitas. Bahkan perusahaan-perusahaan kembali fokus pada peningkatan kualitas.
Dilihat dari banyaknya permintaan yang muncul di masyarakat, saya yakin ini sudah waktunya. Tentu saja saya tidak yakin ini akan menjadi revolusi berskala besar, namun saya ingin revolusi kesadaran ini terjadi.
- Sepakat! Kami akan menanamkan budaya dan mengubah kesadaran.
Konferensi tentang pengembangan produk TI berkualitas tinggi diselenggarakan di Moskow pada 7 Juni. Anda tahu tahapan apa yang membentuk produk berkualitas tinggi, kami memiliki kasus keberhasilan memerangi bug dalam produksi, kami telah menguji metode populer dalam praktik kami - kami membutuhkan pengalaman Anda. mereka lamaran sebelum 1 Mei, dan Komite Program akan membantu memfokuskan tema untuk integritas konferensi secara keseluruhan.
Terhubung ke , di mana kita membahas masalah kualitas dan konferensi, berlangganan untuk tetap up to date dengan berita program.
Sumber: www.habr.com