Kami telah menyiapkan untuk Anda terjemahan sebuah artikel oleh Dmitry Yarygin, Insinyur QA dengan pengalaman dalam proyek-proyek besar dunia selama lebih dari 8 tahun, seorang guru kursus Mobile QA Engineer di OTUS. Apakah menarik untuk dikembangkan ke arah ini? Kami mengundang Anda untuk mengambil intensif dua hari gratis "Pengantar otomatisasi pengujian aplikasi seluler di Selenium dan Appium . "

Pengujian kualitas. Siapa yang bertanggung jawab untuk ini? Selama bertahun-tahun, satu-satunya jawaban untuk pertanyaan ini ada di kepala saya. Tentu saja, seorang insinyur QA! Lagi pula, saya sendiri milik para insinyur QA.

Saya tahu pasti betapa pentingnya menguji kualitas produk perangkat lunak yang rencananya akan dirilis ke pasar. Namun, saya perhatikan beberapa pola yang terjadi selama pengujian. Mereka membuat saya berpikir tentang proses pengujian secara keseluruhan dan bagaimana hal itu dapat ditingkatkan.

Haruskah pengembang menguji kode mereka?

Terima kasih sudah bertanya. Jika Anda seorang pengembang, maka Anda tahu semua seluk-beluk dan jebakan dalam kode Anda, atau setidaknya Anda tahu lebih banyak tentang kode Anda daripada seorang insinyur QA. Anda tahu kode Anda jauh dan luas dan mengerti di mana masalah mungkin timbul.

Jika Anda tahu di mana area masalahnya, beri tahu insinyur QA. Ya, dia sendiri akan menemukannya pada saat tertentu, tetapi Anda masih tahu arsitektur aplikasi lebih baik. Penguji akan berterima kasih jika Anda memberi tahu mereka di mana akan terjadi masalah.

Kami adalah insinyur QA, kami akan fokus pada hal itu dan menutupinya dengan tes sehingga Anda tidak terlalu khawatir. Setiap informasi tambahan yang mungkin diberikan pengembang jelas bermanfaat.

Tes unit jelas merupakan sesuatu yang harus dilakukan pengembang, ini adalah area tanggung jawab mereka. Tes unit akan membantu untuk menghindari kesalahan yang tidak perlu dan laporan yang tidak perlu tentang mereka. Lebih baik untuk menghindari kesalahan sebelum kode sampai ke tim penguji, kan?

Beberapa kata tentang pengujian kode Anda sendiri. Saya percaya bahwa pengembang setidaknya harus melakukan pengujian asap kode mereka. Tidak diperlukan pengujian ekstensif. Cukup periksa bahwa kode berfungsi pada beberapa set data input dan berikan kepada tim penguji sehingga mereka sudah bekerja lebih lanjut.

Jika kode belum berfungsi pada tahap ini, lalu mengapa memberikannya QA? Anda akan mendapatkan lusinan pesan kesalahan meskipun Anda sudah tahu bahwa ada masalah - ini hanya akan memperlambat proses pengembangan.

Kami melewatkan bug. Apakah penguji yang harus disalahkan?

Ya dan tidak Setiap kali kesalahan terdeteksi, terutama dalam produksi, Anda dan tim Anda memiliki sesuatu untuk didiskusikan. Ada beberapa alasan mengapa kesalahan hanya muncul pada tahap ini:

1. Tempat kesalahan muncul tidak pernah menjadi prioritas bagi penguji. Sangat sering, tidak ada yang memikirkan kesalahan yang muncul pada produksi. Ini adalah hasil dari kurangnya komunikasi antara pengembang dan penguji. Saling pengertian tidak tercapai tentang masalah pentingnya memeriksa suatu area. Contoh klasik kelalaian ini adalah masalah kinerja dan keamanan. Jika Anda tahu bahwa area ini penting untuk aplikasi Anda, beri tahu tim.
2. QA tidak memiliki pengetahuan yang diperlukan di area yang diuji. Ini juga masalah umum. Pengembang menulis fungsi dan secara otomatis mengasumsikan bahwa QA memahami cara kerjanya dari dan ke. Nah, membuat asumsi tidak pernah menjadi strategi yang baik untuk menganalisis kualitas proyek yang serius. Jika Anda melihat beberapa aspek penting, pastikan bahwa insinyur QA utama dan timnya juga melihat dan memahaminya. Tidak ada jalan lain di sekitar langkah ini.
3. Pengembang tidak terlalu peduli. Kita semua adalah manusia. Dan kita semua memiliki kehidupan di luar pekerjaan. Beberapa pengembang bekerja keras dan keras untuk membuat produk berkualitas tinggi, mereka berbicara dengan penguji, memberi tahu mereka tentang kemungkinan masalah dan sejenisnya. Dan ada pengembang yang tidak peduli. Mereka tidak menggunakan produk ini setiap hari dan tidak memahami pentingnya produk ini. Bagi mereka, ini hanyalah tugas sampingan yang perlu diselesaikan dan dilupakan. Sederhananya, mereka tidak peduli bahwa produk akhir akan berkualitas tidak memadai.
4. Insinyur QA tidak peduli. Ini adalah sisi lain dari koin. Tidak semua penguji peduli dengan proyek ini. Beberapa hanya perlu menyelesaikan pengujian, membuat laporan yang indah dan melupakannya. Cakupan tes berkualitas tinggi tidak mengganggu mereka, mereka tidak ingin berkomunikasi dengan pengembang. Anda dapat mendiskusikan bug, tetapi penguji semacam itu mungkin tidak menganggapnya penting atau bahkan mendaftar.
5. Penguji tidak cukup berkualitas. Masalah lain mungkin terletak pada kenyataan bahwa penguji tidak cukup berkualitas untuk menguji aplikasi Anda. Misalnya, Anda perlu melakukan pengujian penetrasi, dan semua yang Anda inginkan adalah tim penguji yang hanya dapat melakukan pengujian manual. Dalam hal ini, mereka tidak akan tahu cara mendekatinya. Di sini Anda perlu mengandalkan pengembang, atau memilih lebih banyak
   Insinyur QA yang memenuhi syarat yang akan tahu persis cara menguji area khusus ini.
6. Kurangnya penelitian pengguna. Pengembang tahu cara membuat aplikasi, dan insinyur QA bagaimana memecahkannya. Bagaimana dengan pengguna? Pengguna adalah orang-orang nyata yang akan menggunakan aplikasi Anda di dunia nyata. Mereka tidak akan merusaknya. Hanya saja mereka semua berbeda dan memiliki tujuan yang berbeda, tetapi mereka semua ingin mencapainya menggunakan aplikasi Anda. Insinyur QA dapat terbiasa dengan kesalahan dan menyadari bahwa hal itu jarang terjadi, oleh karena itu, tidak masalah. Pengguna tidak akan mentolerir ini. Jika aplikasi Anda macet, langkah berikutnya adalah menghapusnya, lalu mencari alternatif. Itulah kenyataannya. Meneliti audiens pengguna dan / atau memiliki kelompok pengguna uji adalah dua hal penting yang strategis.
7. Organisasi yang buruk dalam proses komunikasi. Idealnya, Anda memerlukan proses sederhana untuk menyortir bug yang memungkinkan Anda mengevaluasi kesalahan dari QA (atau setidaknya memberi peringkat pada mereka dengan benar) dan meneruskannya ke pengembang sehingga mereka memahami beban kerja mereka. Ketika ada kesalahpahaman, penguji dan pengembang harus selalu dapat saling mendekati dan menyelesaikan masalah ini dalam beberapa menit atau jam. Jika proses ini tidak dilakukan dan kedua belah pihak tidak terburu-buru untuk mencari penyebab kesalahpahaman, maka tidak ada hal baik yang akan terjadi. Kedua belah pihak akan meniru kegiatan, tetapi pada kenyataannya mereka berdua akan menemui jalan buntu dan menunggu orang lain yang bisa datang dan secara ajaib menyelesaikan situasi. Ini pada dasarnya pendekatan yang salah.
8. Penguji tidak cukup. Aplikasi bisa rumit dan mungkin memerlukan pengujian pada beberapa platform dan browser. Hanya beberapa insinyur QA untuk tugas ini mungkin tidak cukup. Pertimbangkan untuk mempekerjakan lebih banyak orang atau mendistribusikan kembali sumber daya yang Anda miliki sedemikian rupa untuk meningkatkan penekanan pada pengujian.
9. Pengembang kelebihan beban. Di sekitar Anda mungkin spesialis yang ideal dan berkualifikasi tinggi, tetapi mereka bekerja dalam tekanan konstan dan tidak ada yang dapat membantu mereka. Ya, mereka di bawah tekanan, dan mereka tidak punya waktu untuk berbicara dengan tim QA. Ini adalah masalah yang sangat umum dan ini adalah salah satu alasan utama mengapa perangkat lunak berkualitas buruk.
10. Kualitas tidak menjadi sorotan. Pertimbangkan skenario ini juga. Di sana-sini ada beberapa bug kecil. Tak satu pun dari mereka yang kritis. Namun, pengguna tidak menyukai aplikasi ini. Ulasan buruk. UX di bawah rata-rata. Dan mengapa? Ya, karena tidak ada yang berpikir untuk menciptakan produk yang berkualitas. Para pengembang melakukan pekerjaan mereka, para penguji melakukan pekerjaan mereka sendiri, tetapi tidak ada yang mengikuti proses kontrol kualitas itu sendiri. Pengembangan aplikasi harus menggabungkan tim, menjadikannya satu kesatuan. Jika kolektif tidak memiliki mood seperti itu, maka tidak ada yang peduli dengan kualitas.

Kesimpulan

Saat ini, aplikasi semakin sulit. Jika Anda ingin menemukan siapa yang harus disalahkan atas kegagalan proyek, itu mudah. Kesalahannya mungkin QA-insinyur, pengembang dan eksekutif. Atau semuanya. Pertanyaan utamanya adalah mengapa kita harus mencari orang-orang yang disalahkan alih-alih bertanggung jawab atas kualitas proyek? Siapa pun yang tidak menyadari pentingnya menguji suatu fungsi tertentu dapat menggantikan yang bersalah.

Satu-satunya pertanyaan adalah: "Apakah kita membuat produk yang benar-benar bagus?" . Jika jawaban untuk pertanyaan ini adalah ya, maka seharusnya tidak ada keraguan bahwa semua tim melakukan satu hal besar.

Tidak ada yang harus disalahkan dan semua orang akan senang, karena jaminan kualitas adalah tugas bersama!