1. Definisi dan
Tujuan Utama Software Quality Assurance (SQA)
Software Quality
Assurance (SQA) adalah langkah yang dilakukan untuk
menjaga dan menjamin bahwa semua proses, metode, aktivitas, dan work item
dari rekayasa perangkat lunak (software engineering) telah dipantau dan
mematuhi standar yang ditetapkan. Standar yang ditetapkan ini bisa berupa
ISO 9000, model CMMI, ISO 15504, atau kombinasi dari standar-standar tersebut.
Tujuan Utama SQA
- Memastikan kualitas dari perangkat lunak.
- Mencegah cacat (defect) dalam produk.
- Meningkatkan kepuasan pelanggan.
2. Empat Tipe
Pengujian Fungsional (Functional Testing)
Pengujian
fungsional bertujuan untuk memastikan bahwa setiap fungsi perangkat lunak
berjalan sesuai dengan yang tertulis di SRS.
- Unit Testing
- Pengujian yang dilakukan pada
komponen terkecil (unit) dari kode, seperti modul atau fungsi, untuk
memverifikasi bahwa kode tersebut berfungsi seperti yang dirancang.
Contoh sub-tipe: Gorilla Testing.
- Integration Testing
- Pengujian untuk memastikan bahwa
berbagai modul atau komponen perangkat lunak dapat bekerja sama (berintegrasi)
dengan benar. Tujuannya adalah menemukan cacat yang timbul dari interaksi
antar-modul. Contoh sub-tipe: Component Integration Testing dan System
Integration Testing.
- System Testing
- Pengujian terhadap sistem perangkat
lunak secara keseluruhan dan terintegrasi untuk memverifikasi bahwa
sistem memenuhi persyaratan yang telah ditentukan. Contoh sub-tipe: End
to end Testing, Smoke Testing, Sanity Testing, dan Monkey Testing
.
- Acceptance Testing
- Pengujian formal yang dilakukan
untuk memverifikasi bahwa sistem memenuhi kebutuhan dan persyaratan
bisnis pengguna, sehingga memastikan sistem siap untuk dirilis. Contoh
sub-tipe: Alpha, Beta, dan User Acceptance Testing .
3. Empat Tipe
Pengujian Non-Fungsional (Non-Functional Testing)
Pengujian
non-fungsional mengevaluasi performa, keamanan, kegunaan, dan aspek kualitas
lainnya yang tercantum dalam SRS. Empat tipe utama pengujian non-fungsional
yang disebutkan dalam materi adalah:
- Security Testing (Pengujian
Keamanan)
- Menjelaskan kebutuhan keamanan dan
kontrol akses. Tujuannya adalah untuk menguji seberapa baik sistem dapat
melindungi data dan mempertahankan fungsionalitasnya. Contoh sub-tipe: Penetration
testing, Fuzz testing, dan Access control testing .
- Performance Testing (Pengujian
Kinerja)
- Menentukan respons waktu, throughput,
dan kapasitas sistem. Tujuannya adalah menguji kecepatan, skalabilitas,
dan stabilitas sistem di bawah beban kerja yang berbeda. Contoh sub-tipe:
Load Testing, Stress Testing, Volume Testing, Scalability Testing,
Endurance Testing, dan Recovery testing .
- Usability Testing (Pengujian
Kegunaan)
- Menguji kebutuhan antarmuka yang
mempermudah penggunaan perangkat lunak. Tujuannya adalah mengukur
seberapa mudah pengguna dapat mempelajari dan menggunakan sistem. Contoh
sub-tipe: Exploratory Testing dan UI Testing.
- Compatibility Testing (Pengujian
Kompatibilitas)
- Pengujian untuk memastikan bahwa
perangkat lunak berfungsi dengan benar dalam berbagai lingkungan, seperti
sistem operasi, browser web, atau perangkat keras yang berbeda.
Contoh sub-tipe: Cross Browser Testing dan Cross Platform
Testing .
4. Apa yang
dimaksud dengan regression testing dan kapan pengujian ini dilakukan?
Regression
testing adalah pengujian yang dilakukan untuk
memastikan bahwa perbaikan bug tidak memengaruhi bagian lain dari perangkat
lunak. Tujuannya adalah untuk menjaga integritas sistem dan memastikan
bahwa tidak ada masalah baru yang muncul setelah perbaikan.
Kapan Pengujian
Ini Dilakukan?
Pengujian regresi
dijalankan setelah tim pengembang memperbaiki bug atau setelah perubahan
kode lainnya (misalnya, penambahan fitur baru). Bersamaan dengan retesting
(pengujian ulang pada test case yang sebelumnya gagal), regression
testing memastikan perbaikan bug tidak menimbulkan efek samping yang tidak
diinginkan di area fungsionalitas yang sudah ada.
5. Test Case dan
Komponen Pentingnya
Test Case adalah serangkaian kondisi atau langkah-langkah yang dilakukan untuk
memverifikasi fungsionalitas tertentu dari aplikasi perangkat lunak. Test
case dirancang berdasarkan persyaratan yang ada di Software Requirements
Specification (SRS) untuk menjamin seluruh persyaratan diuji.
Komponen Penting
dalam Test Case
Komponen penting
dalam sebuah test case (disajikan dalam format tabel) adalah:
|
Komponen |
Deskripsi |
|
Test Case ID |
Nomor
identifikasi unik untuk test case. |
|
Requirement
ID |
ID persyaratan dari SRS yang diuji, untuk memudahkan
pelacakan (Traceability). |
|
Description |
Penjelasan
singkat tentang tujuan pengujian. |
|
Preconditions |
Kondisi yang harus dipenuhi sebelum menjalankan test
case. |
|
Test Steps |
Langkah-langkah
rinci yang harus diikuti oleh penguji. |
|
Expected
Result |
Hasil yang seharusnya terjadi jika perangkat lunak bekerja
dengan benar. |
|
Actual Result |
Hasil
yang sebenarnya diperoleh setelah menjalankan langkah-langkah pengujian. |
|
Status |
Menunjukkan hasil pengujian (misalnya: Pass/Fail). |
6. Peran QA di
dalam SDLC
Peran Quality
Assurance (QA) mencakup seluruh proses pengembangan perangkat lunak (Software
Development Life Cycle - SDLC), mulai dari penentuan kebutuhan hingga
rilis.
Peran QA di setiap
fase utama SDLC adalah:
- Planning (Perencanaan): Melakukan Requirement Analysis (Analisis Kebutuhan) dan
menentukan Test Strategy (Strategi Pengujian).
- Design (Perancangan): Membuat Test Plan (Rencana Pengujian) dan merancang Test
Cases (Kasus Pengujian).
- Implementation (Implementasi): Melakukan pengujian seperti Code Testing dan Integration
Testing.
- Verification (Verifikasi): Melakukan pengujian seperti System Testing dan User
Acceptance Testing.
- Maintenance (Pemeliharaan): Melakukan Regression Testing dan penanganan Bug Fixes.
7. Software
Requirements Specification (SRS) dan Kepentingannya
Software
Requirements Specification (SRS) adalah dokumen yang
menjelaskan persyaratan perangkat lunak. Tujuan utamanya adalah untuk mendefinisikan
secara jelas apa yang dibutuhkan dari perangkat lunak, sehingga semua
pemangku kepentingan (stakeholders) memiliki pemahaman yang sama
mengenai apa yang harus dicapai.
Mengapa SRS
Penting?
SRS penting karena:
- SRS merupakan dokumen dasar
yang akan digunakan untuk merancang, mengembangkan, dan menguji perangkat
lunak.
- SRS yang jelas menjadi acuan utama
untuk pengembangan dan pengujian kualitas.
- SRS yang tidak berkualitas akan
menyebabkan masalah di tahap pengembangan dan pengujian, seperti mis-komunikasi
atau persyaratan yang tidak tepat, yang pada akhirnya akan mengganggu
kualitas perangkat lunak.
- Dokumen SRS memastikan bahwa
pengujian yang dilakukan memiliki cakupan (coverage) yang
memadai dan keterlacakan (traceability) antara persyaratan
dan pengujian.
8. Aspek yang
Harus Dinilai dalam SRS
Ada delapan aspek
kualitas yang harus dinilai dalam me-review dokumen SRS, terutama dalam
konteks SQA:
- Kelengkapan (Completeness): Apakah semua kebutuhan dan fungsi perangkat lunak telah tertulis
secara detail, mencakup semua fitur dan batasan yang dibutuhkan.
- Kejelasan (Clarity): Apakah persyaratan ditulis dengan jelas dan tidak ambigu,
sehingga mudah dipahami oleh semua pihak, termasuk tim pengembang dan
penguji.
- Konsistensi (Consistency): Apakah tidak ada konflik antar persyaratan atau konflik antara
persyaratan dengan standar atau aturan yang ada.
- Keterlacakan (Traceability): Apakah setiap persyaratan dapat ditelusuri kembali ke sumber
yang mendefinisikannya, seperti kebutuhan pengguna atau tujuan bisnis.
- Verifiability: Apakah semua persyaratan dapat diuji dan diukur secara objektif
pada tahap pengujian perangkat lunak.
- Prioritas (Priority): Apakah setiap persyaratan memiliki tingkat prioritas yang jelas
(misalnya: High, Medium, Low) untuk membantu tim
dalam pengembangan.
- Kesesuaian (Compliance): Apakah persyaratan memenuhi standar atau aturan yang telah
disepakati (misalnya: standar keamanan atau privasi data).
- Kemudahan Pemeliharaan (Maintainability): Apakah SRS dirancang agar perangkat lunak yang dikembangkan
mudah dipelihara atau diubah di masa mendatang.
