Metodologi Pengujian Perangkat Lunak: Model QA
Thomas Hamilton
⚡ Ringkasan Cerdas
Metodologi Pengujian Perangkat Lunak mendefinisikan strategi dan jenis pengujian yang digunakan untuk memastikan bahwa suatu aplikasi memenuhi harapan klien. Waterfall, iteratif, agile, dan extreme programming masing-masing membentuk kapan pengujian dimulai dan bagaimana umpan balik diberikan.
Apa itu Metodologi Pengujian Perangkat Lunak?
Metodologi Pengujian Perangkat Lunak didefinisikan sebagai strategi dan jenis pengujian yang digunakan untuk menyatakan bahwa Aplikasi yang Sedang Diuji memenuhi harapan klien. Metodologi Pengujian mencakup pengujian fungsional dan non-fungsional untuk memvalidasi AUT. Contoh Metodologi Pengujian adalah Pengujian Unit, Tes integrasi, Pengujian Sistem, Pengujian Kinerja dll. Setiap metodologi pengujian memiliki tujuan pengujian, strategi pengujian, dan hasil yang ditentukan.
Note: Karena Pengujian Perangkat Lunak merupakan bagian integral dari Metodologi Pengembangan apa pun, banyak perusahaan menggunakan istilah Metodologi Pengembangan & Metodologi Pengujian dalam bahasa sehari-hari. Oleh karena itu, Metodologi Pengujian juga dapat merujuk pada model Waterfall, Agile, dan model QA lainnya yang bertentangan dengan definisi Metodologi Pengujian di atas. Pembahasan berbagai jenis pengujian tidak memberikan nilai tambah bagi pembaca. Oleh karena itu, kita akan membahas model pembangunan yang berbeda.
Metodologi Pengujian vs Jenis Pengujian vs Strategi Pengujian
Catatan di atas mengisyaratkan adanya ambiguitas yang nyata dalam industri ini. Tiga istilah digunakan secara bergantian dalam percakapan tetapi memiliki arti yang berbeda dalam dokumen proyek, dan mencampuradukkan ketiganya menghasilkan rencana pengujian yang menjawab pertanyaan yang salah.
| Istilah | Pertanyaan itu menjawab | Diputuskan oleh | contoh |
|---|---|---|---|
| Metodologi pengujian | Kapan dan bagaimana pengujian masuk ke dalam siklus pengembangan? | Model pengembangan yang digunakan | Waterfall, iteratif, agile, extreme programming |
| Jenis pengujian | Aspek produk apa yang sedang diverifikasi? | Cakupan risiko dan persyaratan | Unit, integrasi, sistem, kinerja, keamanan |
| Tingkat pengujian | Seberapa dalam perangkat lunak tersebut diperiksa? | Posisi dalam hierarki pembangunan | Komponen, integrasi, sistem, penerimaan |
| Strategi pengujian | Bagaimana pendekatan organisasi kita terhadap kualitas? | Kepemimpinan QA, berlaku di seluruh proyek. | Berbasis risiko, otomatisasi utama, pergeseran ke kiri. |
| Rencana uji | Apa sebenarnya yang akan diuji oleh proyek ini, kapan, dan oleh siapa? | Manajer pengujian, khusus proyek | Cakupan, jadwal, sumber daya, kriteria masuk dan keluar |
Aturan praktis yang berguna: metodologi menentukan ritme, jenisnya menentukan target, dan seterusnya. rencana pengujian mencatat komitmen tersebut. Bagian-bagian di bawah ini mengkaji metodologi yang digunakan.
Model Air Terjun
Apa itu?
Dalam majalah model air terjun, kemajuan pengembangan perangkat lunak melalui berbagai fase seperti Analisis Persyaratan, Desain, dll – berurutan.
Dalam model ini, fase selanjutnya dimulai hanya ketika fase sebelumnya telah selesai.
Apa Pendekatan Pengujiannya?
Fase pertama dalam model air terjun adalah fase persyaratan di mana semua persyaratan proyek didefinisikan secara lengkap sebelum memulai pengujian. Selama fase ini, tim penguji melakukan brainstorming ruang lingkup pengujian, strategi pengujian, dan menyusun rencana pengujian terperinci.
Hanya setelah desain perangkat lunak selesai, tim akan melanjutkan ke pelaksanaan uji kasus untuk memastikan bahwa perangkat lunak yang dikembangkan berfungsi seperti yang diharapkan.
Dalam metodologi ini, tim penguji melanjutkan ke fase berikutnya hanya jika fase sebelumnya telah selesai.
| Kelebihan | Kekurangan |
|---|---|
| Model Rekayasa perangkat lunak ini sangat sederhana untuk direncanakan dan dikelola. Oleh karena itu, proyek yang persyaratannya didefinisikan dan dinyatakan dengan jelas sebelumnya, dapat dengan mudah diuji menggunakan model air terjun. | Dalam model air terjun, Anda dapat memulai fase berikutnya hanya setelah fase sebelumnya selesai. Oleh karena itu, model ini tidak dapat mengakomodasi kejadian yang tidak direncanakan dan ketidakpastian. |
| Metodologi ini tidak cocok untuk proyek yang persyaratannya sering berubah. |
Pengembangan berulang
Apa itu?
Dalam model ini, proyek besar dibagi menjadi bagian-bagian kecil, dan setiap bagian menjalani beberapa iterasi model waterfall. Di akhir setiap iterasi, modul baru dikembangkan atau modul yang sudah ada ditingkatkan. Modul ini diintegrasikan ke dalam arsitektur perangkat lunak dan seluruh sistem diuji secara bersamaan.
Apa Pendekatan pengujiannya?
Segera setelah iterasi selesai, seluruh sistem diuji. Umpan balik dari pengujian segera tersedia dan dimasukkan dalam siklus berikutnya. Waktu pengujian yang diperlukan dalam iterasi berturut-turut dapat dikurangi berdasarkan pengalaman yang diperoleh dari iterasi sebelumnya.
| Kelebihan | Kekurangan |
|---|---|
| Keuntungan utama dari pengembangan berulang adalah umpan balik tes segera tersedia pada akhir setiap siklus. | Model ini meningkatkan biaya komunikasi secara signifikan karena, pada akhir setiap siklus, umpan balik tentang hasil, upaya, dll harus diberikan. |
Metodologi tangkas
Apa itu?
Metodologi pengembangan perangkat lunak tradisional bekerja berdasarkan premis bahwa persyaratan perangkat lunak tetap konstan selama proyek berlangsung. Namun seiring meningkatnya kompleksitas, persyaratan tersebut mengalami banyak perubahan dan terus berkembang. Terkadang, pelanggan sendiri tidak yakin apa yang diinginkannya. Meskipun model iteratif mengatasi masalah ini, model tersebut masih didasarkan pada model waterfall.
Dalam metodologi Agile, perangkat lunak dikembangkan secara bertahap dan siklus cepat. Interaksi antara pelanggan, pengembang, dan klien lebih ditekankan daripada proses dan alat. Metodologi tangkas berfokus pada respons terhadap perubahan daripada perencanaan ekstensif.
Apa Pendekatan Pengujiannya?
Pengujian tambahan digunakan dalam metode pengembangan tangkas dan karenanya, setiap rilis proyek diuji secara menyeluruh. Hal ini memastikan bahwa setiap bug dalam sistem telah diperbaiki sebelum rilis berikutnya.
| Kelebihan | Kekurangan |
|---|---|
| Perubahan pada proyek dapat dilakukan kapan saja untuk memenuhi persyaratan. | Interaksi klien yang konstan berarti menambah tekanan waktu pada semua pemangku kepentingan termasuk klien itu sendiri, tim pengembangan perangkat lunak, dan pengujian. |
| Pengujian tambahan ini meminimalkan risiko. |
Pemrograman ekstrem
Apa itu?
Pemrograman ekstrim adalah jenis metodologi tangkas yang percaya pada siklus pengembangan yang pendek. Sebuah proyek dibagi menjadi tugas-tugas teknik sederhana. Pemrogram membuat kode perangkat lunak sederhana dan menghubungi pelanggan untuk mendapatkan umpan balik. RevBeberapa poin dari pelanggan dimasukkan dan pengembang melanjutkan dengan tugas berikutnya.
Dalam pemrograman ekstrim, pengembang biasanya bekerja berpasangan.
Pemrograman Ekstrim digunakan di tempat-tempat di mana kebutuhan pelanggan terus berubah.
Apa Pendekatan Pengujiannya?
Pemrograman ekstrim mengikuti pengembangan berbasis Tes yang dijelaskan sebagai berikut –
- Tambahkan Uji Kasus ke rangkaian pengujian untuk memverifikasi fungsionalitas baru yang belum dikembangkan.
- Jalankan semua pengujian dan jelas kasus pengujian baru yang ditambahkan harus gagal karena fungsinya belum dikodekan
- Tulis beberapa kode untuk mengimplementasikan fitur/fungsi tersebut
- Jalankan rangkaian pengujian lagi. Kali ini, kasus uji baru harus lulus karena fungsinya telah diberi kode
| Kelebihan | Kekurangan |
|---|---|
| Pelanggan yang memiliki rancangan perangkat lunak yang masih samar-samar dapat menggunakan pemrograman ekstrem. | Pertemuan antara tim pengembangan perangkat lunak dan klien menambah kebutuhan waktu. |
| Pengujian berkelanjutan dan integrasi berkelanjutan dari rilis kecil memastikan kode perangkat lunak yang dikirimkan berkualitas tinggi |
Model V dan Model Spiral
Dua model tambahan muncul di sebagian besar proyek dan melengkapi gambaran keseluruhan, karena masing-masing menjawab kelemahan pendekatan waterfall dengan cara yang berbeda.
Model V. Sering disebut verifikasi dan validasi, Model V memasangkan setiap fase pengembangan dengan fase pengujian yang sesuai, digambarkan sebagai dua lengan huruf V. Persyaratan dipasangkan dengan pengujian penerimaan, desain tingkat tinggi dengan pengujian sistem, desain tingkat rendah dengan pengujian integrasi, dan pengkodean dengan pengujian unit. Nilainya adalah desain pengujian dimulai bersamaan dengan setiap fase pengembangan, bukan setelah pengkodean, sehingga persyaratan yang ambigu ditemukan oleh orang yang menulis pengujian penerimaan beberapa bulan sebelum cacat dapat dibuat. Kelemahannya diwarisi dari model waterfall: model ini masih mengasumsikan persyaratan bersifat stabil.
Model Spiral. Model spiral membungkus iterasi di sekitar analisis risiko eksplisit. Setiap siklus berisi empat aktivitas: menentukan tujuan, mengidentifikasi dan menyelesaikan risiko, mengembangkan dan menguji, kemudian merencanakan iterasi berikutnya. Oleh karena itu, pengujian terkonsentrasi di tempat risiko paling tinggi daripada menyebar secara merata. Model ini cocok untuk program besar, mahal, dan jangka panjang seperti sistem inti kedirgantaraan atau perbankan, di mana biaya penemuan terlambat sangat besar. Untuk proyek web kecil, biaya tambahan analisis risiko formal pada setiap siklus jarang dapat dibenarkan.
Kedua model tersebut berada di antara disiplin waterfall dan responsivitas agile. Jika frekuensi rilis lebih penting daripada keduanya, maka... DevOps Pipeline ini mendorong pengujian ke dalam integrasi berkelanjutan sehingga setiap commit diverifikasi secara otomatis.
Metodologi Perangkat Lunak mana yang harus dipilih?
Ada banyak sekali metodologi yang tersedia untuk pengembangan perangkat lunak dan pengujian terkait. Setiap teknik dan metodologi pengujian dirancang untuk tujuan tertentu dan memiliki kelebihan dan kekurangan masing-masing.
Pemilihan metodologi tertentu bergantung pada banyak faktor seperti sifat proyek, kebutuhan klien, jadwal proyek, dll.
Dari perspektif pengujian, beberapa metodologi mendorong masukan pengujian di awal siklus hidup pengembangan, sementara metodologi lainnya menunggu hingga model kerja sistem siap.
Bagaimana cara mengatur metodologi pengujian perangkat lunak?
Metodologi pengujian perangkat lunak tidak boleh dibuat hanya untuk kepentingan pengujian kode perangkat lunak. Gambaran besarnya harus dipertimbangkan dan tujuan utama proyek harus dipenuhi dengan metodologi pengujian. Lihat daftar yang memiliki reputasi baik ini penyedia layanan pengujian perangkat lunak yang dapat membantu Anda menetapkan strategi pengujian efektif yang disesuaikan dengan tujuan proyek Anda.
Penjadwalan
Penjadwalan yang realistis adalah kunci keberhasilan penerapan metodologi pengujian dan jadwal harus memenuhi kebutuhan setiap anggota tim.
Hasil yang ditentukan
Untuk menjaga agar semua anggota tim mempunyai pemikiran yang sama, hasil yang terdefinisi dengan baik harus disediakan. Kiriman harus berisi konten langsung tanpa ambiguitas.
Pendekatan tes
Setelah penjadwalan selesai dan hasil yang ditentukan telah tersedia, tim penguji harus dapat merumuskan pendekatan pengujian yang tepat. Dokumen definisi dan pertemuan pengembang harus menunjukkan kepada tim tentang pendekatan pengujian terbaik yang dapat digunakan untuk proyek tersebut.
Pelaporan
Pelaporan yang transparan sangat sulit dicapai, namun langkah ini menentukan efektivitas pendekatan pengujian yang digunakan dalam proyek.
