Pengujian Perangkat Lunak - Panduan Cepat

Apa itu Pengujian?

Pengujian adalah proses mengevaluasi suatu sistem atau komponennya dengan tujuan untuk mengetahui apakah memenuhi persyaratan yang ditentukan atau tidak. Dengan kata sederhana, pengujian adalah menjalankan sistem untuk mengidentifikasi kesenjangan, kesalahan, atau persyaratan yang hilang yang bertentangan dengan persyaratan sebenarnya.

Menurut standar ANSI / IEEE 1059, Pengujian dapat didefinisikan sebagai - Proses menganalisis item perangkat lunak untuk mendeteksi perbedaan antara kondisi yang ada dan yang diperlukan (yaitu cacat / kesalahan / bug) dan untuk mengevaluasi fitur item perangkat lunak.

Siapa yang Menguji?

Itu tergantung pada proses dan pemangku kepentingan terkait proyek. Dalam industri TI, perusahaan besar memiliki tim dengan tanggung jawab untuk mengevaluasi perangkat lunak yang dikembangkan dalam konteks persyaratan yang diberikan. Selain itu, pengembang juga melakukan pengujian yang disebutUnit Testing. Dalam kebanyakan kasus, para profesional berikut terlibat dalam pengujian sistem dalam kapasitas masing-masing -

Penguji Perangkat Lunak
Pengembang perangkat lunak
Pimpinan / Manajer Proyek
Pengguna akhir

Perusahaan yang berbeda memiliki sebutan berbeda untuk orang yang menguji perangkat lunak berdasarkan pengalaman dan pengetahuan mereka seperti Penguji Perangkat Lunak, Insinyur Jaminan Kualitas Perangkat Lunak, Analis QA, dll.

Tidaklah mungkin untuk menguji perangkat lunak kapan pun selama siklusnya. Dua bagian berikutnya menyatakan kapan pengujian harus dimulai dan kapan harus mengakhirinya selama SDLC.

Kapan Memulai Pengujian?

Memulai pengujian lebih awal mengurangi biaya dan waktu untuk mengerjakan ulang dan menghasilkan perangkat lunak bebas kesalahan yang dikirimkan ke klien. Namun dalam Siklus Hidup Pengembangan Perangkat Lunak (SDLC), pengujian dapat dimulai dari fase Pengumpulan Persyaratan dan dilanjutkan hingga penerapan perangkat lunak.

Itu juga tergantung pada model pengembangan yang digunakan. Misalnya, dalam model Waterfall, pengujian formal dilakukan pada tahap pengujian; tetapi dalam model inkremental, pengujian dilakukan di akhir setiap kenaikan / iterasi dan seluruh aplikasi diuji di akhir.

Pengujian dilakukan dalam berbagai bentuk di setiap fase SDLC -

Selama fase pengumpulan persyaratan, analisis dan verifikasi persyaratan juga dianggap sebagai pengujian.
Mereview desain dalam tahap desain dengan maksud untuk meningkatkan desain juga dianggap sebagai pengujian.
Pengujian yang dilakukan oleh pengembang pada penyelesaian kode juga dikategorikan sebagai pengujian.

Kapan Harus Berhenti Menguji?

Sulit untuk menentukan kapan harus menghentikan pengujian, karena pengujian adalah proses yang tidak pernah berakhir dan tidak ada yang dapat mengklaim bahwa perangkat lunak telah diuji 100%. Aspek berikut harus dipertimbangkan untuk menghentikan proses pengujian -

Tenggat Pengujian
Penyelesaian eksekusi kasus uji
Penyelesaian fungsi dan kode cakupan ke titik tertentu
Tingkat bug berada di bawah level tertentu dan tidak ada bug prioritas tinggi yang teridentifikasi
Keputusan manajemen

Verifikasi & Validasi

Kedua istilah ini sangat membingungkan bagi kebanyakan orang, yang menggunakannya secara bergantian. Tabel berikut menyoroti perbedaan antara verifikasi dan validasi.

Sr.No.	Verifikasi	Validasi
1	Verifikasi mengatasi masalah: "Apakah Anda membuatnya dengan benar?"	Validasi membahas masalah: "Apakah Anda membangun hal yang benar?"
2	Memastikan bahwa sistem perangkat lunak memenuhi semua fungsionalitas.	Memastikan bahwa fungsionalitas memenuhi perilaku yang diinginkan.
3	Verifikasi dilakukan terlebih dahulu dan mencakup pemeriksaan dokumentasi, kode, dll.	Validasi terjadi setelah verifikasi dan terutama melibatkan pemeriksaan produk secara keseluruhan.
4	Dilakukan oleh pengembang.	Dilakukan oleh penguji.
5	Ini memiliki aktivitas statis, karena termasuk mengumpulkan ulasan, penelusuran, dan inspeksi untuk memverifikasi perangkat lunak.	Ini memiliki aktivitas dinamis, karena termasuk menjalankan perangkat lunak terhadap persyaratan.
6	Ini adalah proses yang obyektif dan tidak diperlukan keputusan subjektif untuk memverifikasi perangkat lunak.	Ini adalah proses subjektif dan melibatkan keputusan subjektif tentang seberapa baik perangkat lunak bekerja.

Diberikan di bawah ini adalah beberapa mitos paling umum tentang pengujian perangkat lunak.

Mitos 1: Pengujian Terlalu Mahal

Reality- Ada pepatah, bayar lebih sedikit untuk pengujian selama pengembangan perangkat lunak atau bayar lebih untuk pemeliharaan atau koreksi nanti. Pengujian awal menghemat waktu dan biaya dalam banyak aspek, namun mengurangi biaya tanpa pengujian dapat mengakibatkan desain aplikasi perangkat lunak yang tidak tepat sehingga produk tidak berguna.

Mitos 2: Menguji Memakan Waktu

Reality- Selama fase SDLC, pengujian tidak pernah menjadi proses yang memakan waktu. Namun mendiagnosis dan memperbaiki kesalahan yang teridentifikasi selama pengujian yang tepat adalah kegiatan yang memakan waktu tetapi produktif.

Mitos 3: Hanya Produk yang Dikembangkan Sepenuhnya yang Diuji

Reality- Tidak diragukan lagi, pengujian bergantung pada kode sumber tetapi meninjau persyaratan dan mengembangkan kasus pengujian tidak bergantung pada kode yang dikembangkan. Namun pendekatan iteratif atau inkremental sebagai model siklus hidup pengembangan dapat mengurangi ketergantungan pengujian pada perangkat lunak yang dikembangkan sepenuhnya.

Mitos 4: Pengujian Lengkap Dimungkinkan

Reality- Ini menjadi masalah ketika klien atau penguji berpikir bahwa pengujian lengkap itu mungkin. Mungkin saja semua jalur telah diuji oleh tim, tetapi pengujian lengkap tidak pernah memungkinkan. Mungkin ada beberapa skenario yang tidak pernah dijalankan oleh tim pengujian atau klien selama siklus hidup pengembangan perangkat lunak dan mungkin dijalankan setelah proyek diterapkan.

Mitos 5: Perangkat Lunak yang Diuji Bebas Bug

Reality - Ini adalah mitos yang sangat umum yang dipercaya oleh klien, manajer proyek, dan tim manajemen. Tidak ada yang dapat mengklaim dengan pasti bahwa aplikasi perangkat lunak 100% bebas bug meskipun penguji dengan keterampilan pengujian yang luar biasa telah menguji aplikasi tersebut .

Mitos 6: Cacat yang Terlewatkan disebabkan oleh Penguji

Reality- Ini bukanlah pendekatan yang tepat untuk menyalahkan penguji atas bug yang tetap ada dalam aplikasi bahkan setelah pengujian dilakukan. Mitos ini berkaitan dengan Batasan Pengubahan Waktu, Biaya, dan Persyaratan. Namun, strategi pengujian juga dapat menyebabkan bug terlewat oleh tim penguji.

Mitos 7: Penguji Bertanggung Jawab atas Kualitas Produk

Reality- Ini adalah kesalahpahaman yang sangat umum bahwa hanya penguji atau tim penguji yang harus bertanggung jawab atas kualitas produk. Tanggung jawab penguji termasuk identifikasi bug kepada pemangku kepentingan dan kemudian keputusan mereka apakah mereka akan memperbaiki bug atau merilis perangkat lunak. Merilis perangkat lunak pada saat itu memberikan tekanan lebih pada penguji, karena mereka akan disalahkan atas kesalahan apa pun.

Mitos 8: Otomasi Tes harus digunakan sedapat mungkin untuk Mengurangi Waktu

Reality- Ya, memang benar bahwa Otomasi Tes mengurangi waktu pengujian, tetapi tidak mungkin untuk memulai otomatisasi pengujian kapan pun selama pengembangan perangkat lunak. Tes otomatis harus dimulai ketika perangkat lunak telah diuji secara manual dan stabil sampai batas tertentu. Selain itu, otomatisasi pengujian tidak akan pernah dapat digunakan jika persyaratan terus berubah.

Mitos 9: Siapapun dapat Menguji Aplikasi Perangkat Lunak

Reality- Orang-orang di luar industri TI berpikir dan bahkan percaya bahwa siapa pun dapat menguji perangkat lunak dan pengujian bukanlah pekerjaan yang kreatif. Namun penguji tahu betul bahwa ini adalah mitos. Berpikir skenario alternatif, mencoba untuk crash perangkat lunak dengan maksud untuk mengeksplorasi bug potensial tidak mungkin bagi orang yang mengembangkannya.

Mitos 10: Satu-satunya Tugas Penguji adalah Menemukan Bug

Reality- Menemukan bug dalam perangkat lunak adalah tugas penguji, tetapi pada saat yang sama, mereka adalah ahli domain dari perangkat lunak tertentu. Pengembang hanya bertanggung jawab atas komponen atau area tertentu yang ditugaskan kepada mereka, tetapi penguji memahami keseluruhan cara kerja perangkat lunak, apa ketergantungannya, dan dampak dari satu modul pada modul lain.

Pengujian, Jaminan Kualitas, dan Kontrol Kualitas

Kebanyakan orang menjadi bingung ketika harus menjelaskan perbedaan antara Quality Assurance, Quality Control, dan Testing. Meskipun mereka saling terkait dan sampai batas tertentu, mereka dapat dianggap sebagai aktivitas yang sama, tetapi ada poin pembeda yang membedakannya. Tabel berikut mencantumkan poin-poin yang membedakan QA, QC, dan Pengujian.

Kualitas asuransi	Kontrol kualitas	Menguji
QA mencakup aktivitas yang memastikan implementasi proses, prosedur, dan standar dalam konteks verifikasi perangkat lunak yang dikembangkan dan persyaratan yang dimaksudkan.	Ini mencakup aktivitas yang memastikan verifikasi perangkat lunak yang dikembangkan sehubungan dengan persyaratan yang didokumentasikan (atau tidak dalam beberapa kasus).	Ini termasuk kegiatan yang memastikan identifikasi bug / kesalahan / cacat pada perangkat lunak.
Berfokus pada proses dan prosedur daripada melakukan pengujian aktual pada sistem.	Berfokus pada pengujian aktual dengan menjalankan perangkat lunak dengan tujuan untuk mengidentifikasi bug / cacat melalui penerapan prosedur dan proses.	Berfokus pada pengujian yang sebenarnya.
Kegiatan berorientasi proses.	Aktivitas berorientasi produk.	Aktivitas berorientasi produk.
Kegiatan pencegahan.	Ini adalah proses korektif.	Ini adalah proses pencegahan.
Ini adalah bagian dari Software Test Life Cycle (STLC).	QC dapat dianggap sebagai bagian dari Jaminan Kualitas.	Pengujian adalah bagian dari Kontrol Kualitas.

Audit dan Inspeksi

Audit- Ini adalah proses sistematis untuk menentukan bagaimana proses pengujian yang sebenarnya dilakukan dalam sebuah organisasi atau tim. Umumnya, ini adalah pemeriksaan independen dari proses yang terlibat selama pengujian perangkat lunak. Sesuai IEEE, ini adalah tinjauan proses terdokumentasi yang diterapkan dan diikuti organisasi. Jenis audit meliputi Audit Kepatuhan Hukum, Audit Internal, dan Audit Sistem.

Inspection- Ini adalah teknik formal yang melibatkan tinjauan teknis formal atau informal dari artefak apa pun dengan mengidentifikasi kesalahan atau celah. Sesuai IEEE94, inspeksi adalah teknik evaluasi formal di mana persyaratan, desain, atau kode perangkat lunak diperiksa secara rinci oleh seseorang atau kelompok selain penulis untuk mendeteksi kesalahan, pelanggaran standar pengembangan, dan masalah lainnya.

Rapat inspeksi formal dapat mencakup proses berikut: Perencanaan, Persiapan Gambaran Umum, Rapat Inspeksi, Pengerjaan Ulang, dan Tindak Lanjut.

Pengujian dan Debugging

Testing- Ini melibatkan identifikasi bug / kesalahan / cacat dalam perangkat lunak tanpa memperbaikinya. Biasanya profesional dengan latar belakang jaminan kualitas terlibat dalam identifikasi bug. Pengujian dilakukan dalam tahap pengujian.

Debugging- Ini melibatkan mengidentifikasi, mengisolasi, dan memperbaiki masalah / bug. Pengembang yang membuat kode perangkat lunak melakukan debugging setelah menemukan kesalahan dalam kode. Debugging adalah bagian dari White Box Testing atau Unit Testing. Debugging dapat dilakukan dalam fase pengembangan saat melakukan Pengujian Unit atau dalam fase sambil memperbaiki bug yang dilaporkan.

Banyak organisasi di seluruh dunia mengembangkan dan menerapkan standar yang berbeda untuk meningkatkan kebutuhan kualitas perangkat lunak mereka. Bab ini secara singkat menjelaskan beberapa standar yang banyak digunakan terkait dengan Penjaminan dan Pengujian Kualitas.

ISO / IEC 9126

Standar ini berkaitan dengan aspek-aspek berikut untuk menentukan kualitas aplikasi perangkat lunak -

Model berkualitas
Metrik eksternal
Metrik internal
Kualitas dalam penggunaan metrik

Standar ini menyajikan beberapa set atribut kualitas untuk perangkat lunak apa pun seperti -

Functionality
Reliability
Usability
Efficiency
Maintainability
Portability

Atribut kualitas yang disebutkan di atas dibagi lagi menjadi sub-faktor, yang dapat Anda pelajari saat mempelajari standar secara mendetail.

ISO / IEC 9241-11

Bagian 11 dari standar ini membahas sejauh mana suatu produk dapat digunakan oleh pengguna tertentu untuk mencapai tujuan tertentu dengan Efektivitas, Efisiensi, dan Kepuasan dalam konteks penggunaan tertentu.

Standar ini mengusulkan kerangka kerja yang menjelaskan komponen kegunaan dan hubungan di antara mereka. Dalam standar ini, kegunaan dipertimbangkan dalam hal kinerja dan kepuasan pengguna. Menurut ISO 9241-11, kegunaan bergantung pada konteks penggunaan dan tingkat kegunaan akan berubah seiring perubahan konteks.

ISO / IEC 25000: 2005

ISO / IEC 25000: 2005 umumnya dikenal sebagai standar yang memberikan pedoman untuk Software Quality Requirements and Evaluation (SQuaRE). Standar ini membantu dalam mengatur dan meningkatkan proses yang berkaitan dengan persyaratan kualitas perangkat lunak dan evaluasinya. Pada kenyataannya ISO-25000 menggantikan dua standar ISO lama, yaitu ISO-9126 dan ISO-14598.

SQuaRE dibagi menjadi beberapa sub-bagian seperti -

ISO 2500n - Divisi Manajemen Kualitas
ISO 2501n - Divisi Model Kualitas
ISO 2502n - Divisi Pengukuran Kualitas
ISO 2503n - Divisi Persyaratan Kualitas
ISO 2504n - Divisi Evaluasi Kualitas

Isi utama SQuaRE adalah -

Istilah dan definisi
Model Referensi
Panduan umum
Panduan divisi individu
Standar terkait dengan Requirement Engineering (yaitu spesifikasi, perencanaan, pengukuran dan proses evaluasi)

ISO / IEC 12119

Standar ini berkaitan dengan paket perangkat lunak yang dikirimkan ke klien. Itu tidak fokus atau berurusan dengan proses produksi klien. Konten utama terkait dengan item berikut -

Set persyaratan untuk paket perangkat lunak.
Petunjuk untuk menguji paket perangkat lunak yang dikirim terhadap persyaratan yang ditentukan.

Miscellaneous

Beberapa standar lain yang terkait dengan QA dan proses Pengujian disebutkan di bawah -

Sr Tidak	Standar & Deskripsi
1	IEEE 829 Standar untuk format dokumen yang digunakan dalam berbagai tahap pengujian perangkat lunak.
2	IEEE 1061 Metodologi untuk menetapkan persyaratan kualitas, mengidentifikasi, menerapkan, menganalisis, dan memvalidasi proses, dan produk metrik kualitas perangkat lunak.
3	IEEE 1059 Panduan untuk Verifikasi dan Validasi Perangkat Lunak.
4	IEEE 1008 Standar untuk pengujian unit.
5	IEEE 1012 Standar untuk Verifikasi dan Validasi Perangkat Lunak.
6	IEEE 1028 Standar untuk inspeksi perangkat lunak.
7	IEEE 1044 Standar untuk klasifikasi anomali perangkat lunak.
8	IEEE 1044-1 Panduan untuk klasifikasi anomali perangkat lunak.
9	IEEE 830 Panduan untuk mengembangkan spesifikasi kebutuhan sistem.
10	IEEE 730 Sebuah standar untuk rencana jaminan kualitas perangkat lunak.
11	IEEE 1061 Standar untuk metrik dan metodologi kualitas perangkat lunak.
12	IEEE 12207 Standar untuk proses siklus hidup perangkat lunak dan data siklus hidup.
13	BS 7925-1 Kosakata istilah yang digunakan dalam pengujian perangkat lunak.
14	BS 7925-2 Standar untuk pengujian komponen perangkat lunak.

Bagian ini menjelaskan berbagai jenis pengujian yang dapat digunakan untuk menguji perangkat lunak selama SDLC.

Pengujian Manual

Pengujian manual mencakup pengujian perangkat lunak secara manual, yaitu tanpa menggunakan alat otomatis atau skrip apa pun. Dalam jenis ini, penguji mengambil alih peran pengguna akhir dan menguji perangkat lunak untuk mengidentifikasi perilaku atau bug yang tidak terduga. Ada tahapan yang berbeda untuk pengujian manual seperti pengujian unit, pengujian integrasi, pengujian sistem, dan pengujian penerimaan pengguna.

Penguji menggunakan rencana pengujian, kasus pengujian, atau skenario pengujian untuk menguji perangkat lunak guna memastikan kelengkapan pengujian. Pengujian manual juga mencakup pengujian eksplorasi, karena penguji menjelajahi perangkat lunak untuk mengidentifikasi kesalahan di dalamnya.

Pengujian Otomasi

Pengujian otomasi, yang juga dikenal sebagai Test Automation, adalah saat penguji menulis skrip dan menggunakan perangkat lunak lain untuk menguji produk. Proses ini melibatkan otomatisasi proses manual. Automation Testing digunakan untuk menjalankan kembali skenario pengujian yang dilakukan secara manual, cepat, dan berulang-ulang.

Selain pengujian regresi, pengujian otomatisasi juga digunakan untuk menguji aplikasi dari sudut pandang beban, kinerja, dan tegangan. Ini meningkatkan cakupan pengujian, meningkatkan akurasi, dan menghemat waktu dan uang dibandingkan dengan pengujian manual.

Apa yang Diotomatiskan?

Tidaklah mungkin untuk mengotomatiskan segala sesuatu dalam sebuah perangkat lunak. Area di mana pengguna dapat melakukan transaksi seperti formulir login atau formulir pendaftaran, area mana pun di mana sejumlah besar pengguna dapat mengakses perangkat lunak secara bersamaan harus diotomatiskan.

Selain itu, semua item GUI, koneksi dengan database, validasi lapangan, dll. Dapat diuji secara efisien dengan mengotomatiskan proses manual.

Kapan Mengotomatiskan?

Otomasi Tes harus digunakan dengan mempertimbangkan aspek-aspek perangkat lunak berikut -

Proyek besar dan kritis
Proyek yang sering membutuhkan pengujian di area yang sama
Persyaratan tidak sering berubah
Mengakses aplikasi untuk memuat dan kinerja dengan banyak pengguna virtual
Perangkat lunak yang stabil sehubungan dengan pengujian manual
Ketersediaan waktu

Bagaimana Mengotomatiskan?

Otomatisasi dilakukan dengan menggunakan bahasa komputer yang mendukung seperti skrip VB dan aplikasi perangkat lunak otomatis. Ada banyak alat yang tersedia yang dapat digunakan untuk menulis skrip otomasi. Sebelum menyebutkan alatnya, mari kita identifikasi proses yang dapat digunakan untuk mengotomatiskan proses pengujian -

Mengidentifikasi area dalam perangkat lunak untuk otomatisasi
Pemilihan alat yang sesuai untuk otomatisasi pengujian
Menulis skrip tes
Pengembangan jas tes
Eksekusi skrip
Buat laporan hasil
Identifikasi potensi bug atau masalah kinerja

Alat Pengujian Perangkat Lunak

Alat berikut dapat digunakan untuk pengujian otomatisasi -

HP Quick Test Professional
Selenium
Penguji Fungsional Rasional IBM
SilkTest
TestComplete
Menguji Di Mana Saja
WinRunner
LoadRunner
Visual Studio Test Professional
WATIR

Ada beberapa metode berbeda yang dapat digunakan untuk pengujian perangkat lunak. Bab ini menjelaskan secara singkat metode yang tersedia.

Pengujian Kotak Hitam

Teknik pengujian tanpa memiliki pengetahuan tentang cara kerja interior aplikasi disebut pengujian kotak hitam. Penguji tidak menyadari arsitektur sistem dan tidak memiliki akses ke kode sumber. Biasanya, saat melakukan pengujian kotak hitam, penguji akan berinteraksi dengan antarmuka pengguna sistem dengan memberikan masukan dan memeriksa keluaran tanpa mengetahui bagaimana dan di mana masukan tersebut dikerjakan.

Tabel berikut mencantumkan keuntungan dan kerugian pengujian kotak hitam.

Keuntungan	Kekurangan
Sangat cocok dan efisien untuk segmen kode besar.	Cakupan terbatas, karena hanya sejumlah skenario pengujian yang benar-benar dilakukan.
Akses kode tidak diperlukan.	Pengujian tidak efisien, karena penguji hanya memiliki pengetahuan terbatas tentang suatu aplikasi.
Jelas memisahkan perspektif pengguna dari perspektif pengembang melalui peran yang didefinisikan secara jelas.	Cakupan buta, karena penguji tidak dapat menargetkan segmen kode tertentu atau area rawan kesalahan.
Sejumlah besar penguji yang cukup terampil dapat menguji aplikasi tanpa pengetahuan implementasi, bahasa pemrograman, atau sistem operasi.	Kasus uji sulit untuk dirancang.

Pengujian Kotak Putih

Pengujian white-box adalah investigasi terperinci dari logika internal dan struktur kode. Pengujian kotak putih juga disebutglass testing atau open-box testing. Untuk tampilwhite-box menguji aplikasi, penguji perlu mengetahui cara kerja internal kode.

Penguji perlu melihat ke dalam kode sumber dan mencari tahu unit / potongan kode mana yang berperilaku tidak tepat.

Tabel berikut mencantumkan keuntungan dan kerugian pengujian kotak putih.

Keuntungan	Kekurangan
Karena penguji memiliki pengetahuan tentang kode sumber, menjadi sangat mudah untuk mengetahui jenis data mana yang dapat membantu dalam menguji aplikasi secara efektif.	Karena fakta bahwa penguji yang terampil diperlukan untuk melakukan pengujian kotak putih, biayanya meningkat.
Ini membantu dalam mengoptimalkan kode.	Terkadang tidak mungkin untuk melihat ke setiap sudut dan sudut untuk menemukan kesalahan tersembunyi yang dapat menimbulkan masalah, karena banyak jalur yang belum teruji.
Baris kode tambahan dapat dihapus yang dapat menyebabkan cacat tersembunyi.	Sulit untuk mempertahankan pengujian kotak putih, karena memerlukan alat khusus seperti penganalisis kode dan alat debugging.
Karena pengetahuan penguji tentang kode, cakupan maksimum dicapai selama penulisan skenario pengujian.

Pengujian Gray-Box

Pengujian kotak abu-abu adalah teknik untuk menguji aplikasi dengan memiliki pengetahuan terbatas tentang cara kerja internal suatu aplikasi. Dalam pengujian perangkat lunak, frasa semakin banyak yang Anda ketahui, semakin baik membawa banyak bobot saat menguji aplikasi.

Menguasai domain suatu sistem selalu memberikan penguji keunggulan atas seseorang dengan pengetahuan domain terbatas. Tidak seperti pengujian kotak hitam, di mana penguji hanya menguji antarmuka pengguna aplikasi; dalam pengujian kotak abu-abu, penguji memiliki akses ke dokumen desain dan database. Dengan pengetahuan ini, seorang penguji dapat mempersiapkan data pengujian dan skenario pengujian yang lebih baik sambil membuat rencana pengujian.

Keuntungan	Kekurangan
Menawarkan manfaat gabungan dari pengujian kotak hitam dan kotak putih jika memungkinkan.	Karena akses ke kode sumber tidak tersedia, kemampuan untuk memeriksa kode dan cakupan pengujian menjadi terbatas.
Penguji kotak abu-abu tidak bergantung pada kode sumber; alih-alih mereka mengandalkan definisi antarmuka dan spesifikasi fungsional.	Tes dapat menjadi berlebihan jika perancang perangkat lunak telah menjalankan kasus uji.
Berdasarkan informasi terbatas yang tersedia, penguji kotak abu-abu dapat merancang skenario pengujian yang sangat baik terutama seputar protokol komunikasi dan penanganan tipe data.	Menguji setiap aliran masukan yang mungkin tidak realistis karena akan memakan waktu yang tidak wajar; oleh karena itu, banyak jalur program tidak akan teruji.
Tes dilakukan dari sudut pandang pengguna dan bukan desainer.

Perbandingan Metode Pengujian

Tabel berikut mencantumkan poin-poin yang membedakan pengujian kotak hitam, pengujian kotak abu-abu, dan pengujian kotak putih.

Pengujian Kotak Hitam	Pengujian Gray-Box	Pengujian Kotak Putih
Cara kerja internal suatu aplikasi tidak perlu diketahui.	Penguji memiliki pengetahuan terbatas tentang cara kerja internal aplikasi.	Penguji memiliki pengetahuan penuh tentang cara kerja internal aplikasi.
Juga dikenal sebagai pengujian kotak tertutup, pengujian berdasarkan data, atau pengujian fungsional.	Juga dikenal sebagai pengujian tembus cahaya, karena penguji memiliki pengetahuan terbatas tentang bagian dalam aplikasi.	Juga dikenal sebagai pengujian kotak jelas, pengujian struktural, atau pengujian berbasis kode.
Dilakukan oleh pengguna akhir dan juga oleh penguji dan pengembang.	Dilakukan oleh pengguna akhir dan juga oleh penguji dan pengembang.	Biasanya dilakukan oleh penguji dan pengembang.
Pengujian didasarkan pada ekspektasi eksternal - Perilaku internal aplikasi tidak diketahui.	Pengujian dilakukan atas dasar diagram database tingkat tinggi dan diagram aliran data.	Cara kerja internal sepenuhnya diketahui dan penguji dapat merancang data pengujian yang sesuai.
Ini lengkap dan paling tidak memakan waktu.	Sebagian memakan waktu dan melelahkan.	Jenis pengujian yang paling lengkap dan memakan waktu.
Tidak cocok untuk pengujian algoritme.	Tidak cocok untuk pengujian algoritme.	Cocok untuk pengujian algoritma.
Ini hanya dapat dilakukan dengan metode coba-coba.	Domain data dan batas internal dapat diuji, jika diketahui.	Domain data dan batas internal dapat diuji dengan lebih baik.

Ada level yang berbeda selama proses pengujian. Dalam bab ini, penjelasan singkat diberikan tentang level-level ini.

Tingkat pengujian mencakup berbagai metodologi yang dapat digunakan saat melakukan pengujian perangkat lunak. Tingkat utama pengujian perangkat lunak adalah -

Pengujian Fungsional
Pengujian Non-fungsional

Pengujian Fungsional

Ini adalah jenis pengujian kotak hitam yang didasarkan pada spesifikasi perangkat lunak yang akan diuji. Aplikasi diuji dengan memberikan masukan dan kemudian hasilnya diperiksa yang harus sesuai dengan fungsionalitas yang dimaksudkan. Pengujian fungsional perangkat lunak dilakukan pada sistem yang lengkap dan terintegrasi untuk mengevaluasi kepatuhan sistem dengan persyaratan yang ditentukan.

Ada lima langkah yang terlibat saat menguji fungsionalitas aplikasi.

Langkah	Deskripsi
saya	Penentuan fungsionalitas yang dimaksudkan untuk dilakukan oleh aplikasi yang dimaksudkan.
II	Pembuatan data uji berdasarkan spesifikasi aplikasi.
AKU AKU AKU	Keluarannya berdasarkan data uji dan spesifikasi aplikasi.
IV	Penulisan skenario pengujian dan pelaksanaan kasus pengujian.
V.	Perbandingan hasil aktual dan yang diharapkan berdasarkan kasus uji yang dijalankan.

Praktik pengujian yang efektif akan melihat langkah-langkah di atas diterapkan pada kebijakan pengujian setiap organisasi dan karenanya akan memastikan bahwa organisasi mempertahankan standar yang paling ketat dalam hal kualitas perangkat lunak.

Pengujian Unit

Jenis pengujian ini dilakukan oleh pengembang sebelum penyiapan diserahkan ke tim pengujian untuk secara resmi menjalankan kasus pengujian. Pengujian unit dilakukan oleh pengembang masing-masing pada unit individu dari area kode sumber yang ditetapkan. Pengembang menggunakan data pengujian yang berbeda dari data pengujian tim jaminan kualitas.

Tujuan pengujian unit adalah untuk mengisolasi setiap bagian dari program dan menunjukkan bahwa setiap bagian sudah benar dalam hal persyaratan dan fungsionalitas.

Batasan Pengujian Unit

Pengujian tidak dapat menangkap setiap bug dalam aplikasi. Tidak mungkin untuk mengevaluasi setiap jalur eksekusi di setiap aplikasi perangkat lunak. Hal yang sama terjadi pada pengujian unit.

Ada batasan jumlah skenario dan data pengujian yang dapat digunakan pengembang untuk memverifikasi kode sumber. Setelah menghabiskan semua opsi, tidak ada pilihan selain menghentikan pengujian unit dan menggabungkan segmen kode dengan unit lain.

Tes integrasi

Pengujian integrasi didefinisikan sebagai pengujian bagian gabungan dari suatu aplikasi untuk menentukan apakah mereka berfungsi dengan benar. Pengujian integrasi dapat dilakukan dengan dua cara: Pengujian integrasi bottom-up dan pengujian integrasi Top-down.

Sr.No.	Metode Pengujian Integrasi
1	Bottom-up integration Pengujian ini dimulai dengan pengujian unit, diikuti dengan pengujian kombinasi tingkat yang lebih tinggi dari unit yang disebut modul atau build.
2	Top-down integration Dalam pengujian ini, modul tingkat tertinggi diuji terlebih dahulu dan secara bertahap, modul tingkat yang lebih rendah diuji setelahnya.

Dalam lingkungan pengembangan perangkat lunak yang komprehensif, pengujian bottom-up biasanya dilakukan terlebih dahulu, diikuti oleh pengujian top-down. Proses ini diakhiri dengan beberapa tes dari aplikasi yang lengkap, sebaiknya dalam skenario yang dirancang untuk meniru situasi sebenarnya.

Pengujian Sistem

Pengujian sistem menguji sistem secara keseluruhan. Setelah semua komponen diintegrasikan, aplikasi secara keseluruhan diuji secara ketat untuk melihat apakah memenuhi Standar Kualitas yang ditentukan. Jenis pengujian ini dilakukan oleh tim pengujian khusus.

Pengujian sistem penting karena alasan berikut -

Pengujian sistem adalah langkah pertama dalam Siklus Hidup Pengembangan Perangkat Lunak, di mana aplikasi diuji secara keseluruhan.
Aplikasi diuji secara menyeluruh untuk memverifikasi bahwa aplikasi memenuhi spesifikasi fungsional dan teknis.
Aplikasi diuji dalam lingkungan yang sangat dekat dengan lingkungan produksi tempat aplikasi akan diterapkan.
Pengujian sistem memungkinkan kami untuk menguji, memverifikasi, dan memvalidasi persyaratan bisnis serta arsitektur aplikasi.

Pengujian Regresi

Kapanpun perubahan dalam aplikasi perangkat lunak dilakukan, sangat mungkin bahwa area lain dalam aplikasi telah terpengaruh oleh perubahan ini. Pengujian regresi dilakukan untuk memverifikasi bahwa bug tetap tidak mengakibatkan fungsionalitas lain atau pelanggaran aturan bisnis. Maksud dari pengujian regresi adalah untuk memastikan bahwa perubahan, seperti perbaikan bug tidak akan mengakibatkan kesalahan lain terungkap dalam aplikasi.

Pengujian regresi penting karena alasan berikut -

Minimalkan celah dalam pengujian ketika aplikasi dengan perubahan yang dibuat harus diuji.
Menguji perubahan baru untuk memverifikasi bahwa perubahan yang dibuat tidak mempengaruhi area aplikasi lainnya.
Mengurangi risiko saat pengujian regresi dilakukan pada aplikasi.
Cakupan tes ditingkatkan tanpa mengorbankan jadwal.
Tingkatkan kecepatan untuk memasarkan produk.

Ujian penerimaan

Ini bisa dibilang jenis pengujian yang paling penting, karena dilakukan oleh Tim Quality Assurance yang akan mengukur apakah aplikasi memenuhi spesifikasi yang dimaksudkan dan memenuhi persyaratan klien. Tim QA akan memiliki serangkaian skenario yang telah ditulis sebelumnya dan kasus uji yang akan digunakan untuk menguji aplikasi.

Lebih banyak ide akan dibagikan tentang aplikasi dan lebih banyak tes dapat dilakukan untuk mengukur keakuratannya dan alasan mengapa proyek dimulai. Tes penerimaan tidak hanya dimaksudkan untuk menunjukkan kesalahan ejaan sederhana, kesalahan kosmetik, atau celah antarmuka, tetapi juga untuk menunjukkan setiap bug dalam aplikasi yang akan mengakibatkan sistem crash atau kesalahan besar dalam aplikasi.

Dengan melakukan uji penerimaan pada suatu aplikasi, tim penguji akan mengurangi bagaimana aplikasi tersebut akan tampil dalam produksi. Ada juga persyaratan hukum dan kontrak untuk penerimaan sistem.

Pengujian Alfa

Tes ini adalah tahap pengujian pertama dan akan dilakukan di antara tim (tim pengembang dan QA). Pengujian unit, pengujian integrasi, dan pengujian sistem bila digabungkan bersama-sama dikenal sebagai pengujian alfa. Selama fase ini, aspek-aspek berikut akan diuji dalam aplikasi -

Kesalahan pengejaan
Tautan Rusak
Arah Berawan
Aplikasi akan diuji pada mesin dengan spesifikasi terendah untuk menguji waktu pemuatan dan masalah latensi apa pun.

Pengujian Beta

Tes ini dilakukan setelah pengujian alpha berhasil dilakukan. Dalam pengujian beta, sampel audiens yang dituju menguji aplikasi. Pengujian beta juga dikenal sebagaipre-release testing. Versi uji beta dari perangkat lunak idealnya didistribusikan ke khalayak luas di Web, sebagian untuk memberikan program tes "dunia nyata" dan sebagian untuk memberikan pratinjau rilis berikutnya. Pada fase ini, penonton akan menguji hal-hal berikut -

Pengguna akan menginstal, menjalankan aplikasi, dan mengirimkan umpan balik mereka ke tim proyek.
Kesalahan tipografi, aliran aplikasi yang membingungkan, dan bahkan crash.
Mendapatkan umpan balik, tim proyek dapat memperbaiki masalah sebelum merilis perangkat lunak ke pengguna sebenarnya.
Semakin banyak masalah yang Anda perbaiki yang menyelesaikan masalah pengguna nyata, semakin tinggi kualitas aplikasi Anda.
Memiliki aplikasi berkualitas lebih tinggi saat Anda merilisnya ke masyarakat umum akan meningkatkan kepuasan pelanggan.

Pengujian Non-Fungsional

Bagian ini didasarkan pada pengujian aplikasi dari atribut non-fungsionalnya. Pengujian non-fungsional melibatkan pengujian perangkat lunak dari persyaratan yang sifatnya nonfungsional tetapi penting seperti kinerja, keamanan, antarmuka pengguna, dll.

Beberapa jenis pengujian non-fungsional yang penting dan umum digunakan dibahas di bawah ini.

Pengujian Kinerja

Ini sebagian besar digunakan untuk mengidentifikasi kemacetan atau masalah kinerja daripada menemukan bug dalam perangkat lunak. Ada penyebab berbeda yang berkontribusi dalam menurunkan kinerja perangkat lunak -

Penundaan jaringan
Pemrosesan sisi klien
Pemrosesan transaksi database
Load balancing antar server
Rendering data

Pengujian kinerja dianggap sebagai salah satu jenis pengujian penting dan wajib dalam hal aspek berikut -

Kecepatan (yaitu Waktu Respons, rendering dan akses data)
Capacity
Stability
Scalability

Pengujian kinerja dapat berupa kualitatif atau kuantitatif dan dapat dibagi menjadi sub-jenis yang berbeda seperti Load testing dan Stress testing.

Pengujian Beban

Ini adalah proses pengujian perilaku perangkat lunak dengan menerapkan beban maksimum dalam hal perangkat lunak mengakses dan memanipulasi data masukan yang besar. Ini dapat dilakukan pada kondisi beban normal dan puncak. Jenis pengujian ini mengidentifikasi kapasitas maksimum perangkat lunak dan perilakunya pada waktu puncak.

Sebagian besar waktu, pengujian beban dilakukan dengan bantuan alat otomatis seperti Load Runner, AppLoader, IBM Rational Performance Tester, Apache JMeter, Silk Performer, Visual Studio Load Test, dll.

Pengguna virtual (VUsers) ditentukan dalam alat pengujian otomatis dan skrip dijalankan untuk memverifikasi pengujian beban untuk perangkat lunak. Jumlah pengguna dapat ditambah atau dikurangi secara bersamaan atau bertahap berdasarkan kebutuhan.

Pengujian Stres

Pengujian stres meliputi pengujian perilaku perangkat lunak dalam kondisi tidak normal. Misalnya, ini mungkin termasuk mengambil beberapa sumber daya atau menerapkan beban di luar batas beban sebenarnya.

Pengujian tegangan bertujuan untuk menguji perangkat lunak dengan menerapkan beban ke sistem dan mengambil alih sumber daya yang digunakan oleh perangkat lunak untuk mengidentifikasi titik putusnya. Pengujian ini dapat dilakukan dengan menguji berbagai skenario seperti -

Matikan atau mulai ulang port jaringan secara acak
Mengaktifkan atau menonaktifkan database
Menjalankan berbagai proses yang menghabiskan sumber daya seperti CPU, memori, server, dll.

Pengujian Kegunaan

Pengujian kegunaan adalah teknik kotak hitam dan digunakan untuk mengidentifikasi kesalahan dan peningkatan dalam perangkat lunak dengan mengamati pengguna melalui penggunaan dan pengoperasiannya.

Menurut Nielsen, usability dapat didefinisikan dalam lima faktor, yaitu efisiensi penggunaan, kemampuan belajar, kemampuan memori, kesalahan / keamanan, dan kepuasan. Menurutnya, kegunaan suatu produk akan baik dan sistem dapat digunakan jika memiliki faktor-faktor di atas.

Nigel Bevan dan Macleod menilai bahwa usability merupakan persyaratan kualitas yang dapat diukur sebagai hasil interaksi dengan sistem komputer. Persyaratan ini dapat dipenuhi dan pengguna akhir akan puas jika tujuan yang diinginkan tercapai secara efektif dengan penggunaan sumber daya yang tepat.

Molich pada tahun 2000 menyatakan bahwa sistem yang ramah pengguna harus memenuhi lima tujuan berikut, yaitu mudah dipelajari, mudah diingat, efisien digunakan, memuaskan untuk digunakan, dan mudah dipahami.

Selain perbedaan definisi usability, terdapat beberapa standar dan kualitas model dan metode yang mendefinisikan usability berupa atribut dan sub atribut seperti ISO-9126, ISO-9241-11, ISO-13407, dan IEEE std. 610.12, dll.

Pengujian UI vs Kegunaan

Pengujian UI melibatkan pengujian Antarmuka Pengguna Grafis dari Perangkat Lunak. Pengujian UI memastikan bahwa GUI berfungsi sesuai dengan persyaratan dan diuji dalam hal warna, kesejajaran, ukuran, dan properti lainnya.

Di sisi lain, pengujian kegunaan memastikan GUI yang baik dan ramah pengguna yang dapat dengan mudah ditangani. Pengujian UI dapat dianggap sebagai sub-bagian dari pengujian kegunaan.

Pengujian Keamanan

Pengujian keamanan melibatkan pengujian perangkat lunak untuk mengidentifikasi setiap kekurangan dan celah dari sudut pandang keamanan dan kerentanan. Di bawah ini adalah aspek utama yang harus dipastikan oleh pengujian keamanan -

Confidentiality
Integrity
Authentication
Availability
Authorization
Non-repudiation
Perangkat lunak aman dari kerentanan yang diketahui dan tidak diketahui
Data perangkat lunak aman
Perangkat lunak sesuai dengan semua peraturan keamanan
Pemeriksaan dan validasi input
Serangan penyisipan SQL
Cacat injeksi
Masalah manajemen sesi
Serangan skrip lintas situs
Buffer overflows kerentanan
Serangan traversal direktori

Pengujian Portabilitas

Pengujian portabilitas mencakup pengujian perangkat lunak dengan tujuan untuk memastikan dapat digunakan kembali dan dapat dipindahkan dari perangkat lunak lain juga. Berikut adalah strategi yang dapat digunakan untuk pengujian portabilitas -

Mentransfer perangkat lunak yang diinstal dari satu komputer ke komputer lainnya.
Membangun executable (.exe) untuk menjalankan perangkat lunak pada platform yang berbeda.

Pengujian portabilitas dapat dianggap sebagai salah satu sub-bagian dari pengujian sistem, karena jenis pengujian ini mencakup pengujian perangkat lunak secara keseluruhan sehubungan dengan penggunaannya di lingkungan yang berbeda. Perangkat keras komputer, sistem operasi, dan browser adalah fokus utama pengujian portabilitas. Beberapa prasyarat untuk pengujian portabilitas adalah sebagai berikut -

Perangkat lunak harus dirancang dan diberi kode, dengan memperhatikan persyaratan portabilitas.
Pengujian unit telah dilakukan pada komponen terkait.
Pengujian integrasi telah dilakukan.
Lingkungan pengujian telah ditetapkan.

Dokumentasi pengujian melibatkan dokumentasi artefak yang harus dikembangkan sebelum atau selama pengujian Perangkat Lunak.

Dokumentasi untuk pengujian perangkat lunak membantu dalam memperkirakan upaya pengujian yang diperlukan, cakupan pengujian, pelacakan / penelusuran persyaratan, dll. Bagian ini menjelaskan beberapa artefak terdokumentasi yang umum digunakan terkait dengan pengujian perangkat lunak seperti -

Rencana Tes
Skenario Uji
Kasus cobaan
Matriks Ketertelusuran

Rencana Tes

Rencana pengujian menguraikan strategi yang akan digunakan untuk menguji aplikasi, sumber daya yang akan digunakan, lingkungan pengujian tempat pengujian akan dilakukan, dan batasan pengujian serta jadwal kegiatan pengujian. Biasanya Pimpinan Tim Penjaminan Mutu akan bertanggung jawab untuk menulis Rencana Tes.

Rencana pengujian mencakup yang berikut -

Pengantar dokumen Rencana Tes
Asumsi saat menguji aplikasi
Daftar kasus uji termasuk dalam pengujian aplikasi
Daftar fitur yang akan diuji
Pendekatan seperti apa yang digunakan saat menguji perangkat lunak
Daftar kiriman yang perlu diuji
Sumber daya yang dialokasikan untuk menguji aplikasi
Risiko apa pun yang terlibat selama proses pengujian
Jadwal tugas dan pencapaian yang harus dicapai

Skenario Uji

Ini adalah pernyataan satu baris yang memberi tahu area mana dalam aplikasi yang akan diuji. Skenario pengujian digunakan untuk memastikan bahwa semua aliran proses diuji dari ujung ke ujung. Area tertentu dari aplikasi dapat memiliki paling sedikit satu skenario pengujian hingga beberapa ratus skenario tergantung pada besarnya dan kompleksitas aplikasi.

Istilah 'skenario uji' dan 'kasus uji' digunakan secara bergantian, namun skenario pengujian memiliki beberapa langkah, sedangkan kasus uji memiliki satu langkah. Dilihat dari perspektif ini, skenario pengujian adalah kasus pengujian, tetapi mencakup beberapa kasus pengujian dan urutan yang harus dijalankan. Selain itu, setiap pengujian bergantung pada keluaran dari pengujian sebelumnya.

Kasus cobaan

Kasus pengujian melibatkan serangkaian langkah, kondisi, dan masukan yang dapat digunakan saat melakukan tugas pengujian. Maksud utama dari kegiatan ini adalah untuk memastikan apakah suatu perangkat lunak lolos atau gagal dalam hal fungsionalitas dan aspek lainnya. Ada banyak jenis kasus uji seperti kasus uji fungsional, negatif, kesalahan, uji logis, kasus uji fisik, kasus uji UI, dll.

Selanjutnya, kasus uji ditulis untuk melacak cakupan pengujian perangkat lunak. Umumnya, tidak ada templat formal yang dapat digunakan selama penulisan kasus uji. Namun, komponen berikut selalu tersedia dan disertakan dalam setiap kasus uji -

ID kasus uji
Modul produk
Versi produk
Sejarah revisi
Purpose
Assumptions
Pre-conditions
Steps
Hasil yang diharapkan
Hasil yang sebenarnya
Post-conditions

Banyak kasus pengujian dapat diturunkan dari satu skenario pengujian. Selain itu, terkadang beberapa kasus pengujian ditulis untuk satu perangkat lunak yang secara kolektif dikenal sebagai rangkaian pengujian.

Matriks Ketertelusuran

Traceability Matrix (juga dikenal sebagai Requirement Traceability Matrix - RTM) adalah tabel yang digunakan untuk melacak persyaratan selama Siklus Hidup Pengembangan Perangkat Lunak. Ini dapat digunakan untuk penelusuran maju (yaitu dari Persyaratan ke Desain atau Coding) atau mundur (yaitu dari Coding ke Persyaratan). Ada banyak template yang ditentukan pengguna untuk RTM.

Setiap persyaratan dalam dokumen RTM ditautkan dengan kasus uji terkait sehingga pengujian dapat dilakukan sesuai persyaratan yang disebutkan. Selain itu, ID Bug juga disertakan dan ditautkan dengan persyaratan terkait dan kasus uji. Tujuan utama dari matriks ini adalah -

Pastikan perangkat lunak dikembangkan sesuai persyaratan yang disebutkan.
Membantu menemukan akar penyebab bug apa pun.
Membantu dalam menelusuri dokumen yang dikembangkan selama fase SDLC yang berbeda.

Memperkirakan upaya yang diperlukan untuk pengujian adalah salah satu tugas utama dan penting dalam SDLC. Estimasi yang benar membantu dalam menguji perangkat lunak dengan cakupan maksimum. Bagian ini menjelaskan beberapa teknik yang dapat berguna dalam memperkirakan upaya yang diperlukan untuk pengujian.

Analisis Titik Fungsional

Metode ini didasarkan pada analisis kebutuhan fungsional pengguna perangkat lunak dengan kategori berikut -

Outputs
Inquiries
Inputs
File internal
File eksternal

Analisis Titik Uji

Proses estimasi ini digunakan untuk analisis titik fungsi untuk black-box atau pengujian penerimaan. Elemen utama dari metode ini adalah: Ukuran, Produktivitas, Strategi, Antarmuka, Kompleksitas, dan Keseragaman.

Metode Mark-II

Ini adalah metode estimasi yang digunakan untuk menganalisis dan mengukur estimasi berdasarkan tampilan fungsional pengguna akhir. Prosedur untuk metode Mark-II adalah sebagai berikut -

Tentukan sudut pandang
Tujuan dan jenis hitungan
Tentukan batas hitungan
Identifikasi transaksi logis
Identifikasi dan kategorikan jenis entitas data
Hitung jenis elemen data masukan
Hitung ukuran fungsional

Miscellaneous

Anda dapat menggunakan teknik estimasi populer lainnya seperti -

Teknik Delphi
Estimasi Berbasis Analogi
Uji Perkiraan Berdasarkan Pencacahan
Estimasi berdasarkan Tugas (Aktivitas)
Metode IFPUG