Konsep Dasar dan Pendahuluan

Pembahasan bab ini diambil dari bab 1 dari buku Software Testing and Quality Assurance - Theory and Practice

1.1 Latar Belakang

Orang mencari kualitas dalam setiap artefak buatan manusia. Tentu saja, konsep kualitas tidak berasal dari sistem perangkat lunak. Sebaliknya, konsep kualitas cenderung setua upaya manusia untuk menghasilkan massa artefak dan objek dengan ukuran besar. Dalam masa lalu selama beberapa dekade revolusi yang berkualitas, telah menyebar dengan cepat ke seluruh dunia dengan ledakan internet.Persaingan global, outsourcing, off-shoring, dan peningkatan harapan pelanggan telah membawa konsep kualitas ke garis depan. Mengembangkan produk berkualitas pada jadwal yang lebih ketat sangat penting bagi perusahaan untuk menjadi sukses dalam ekonomi global yang baru. Secara tradisional, upaya untuk meningkatkan kualitas telah berpusat di sekitar akhir siklus pengembangan produk dengan menekankan deteksi dan koreksi cacat. Sebaliknya, pendekatan baru untuk meningkatkan kualitas mencakup semua fase proses pengembangan produk - dari analisis persyaratan hingga pengiriman akhir produk kepada pelanggan. Setiap langkah dalam proses pengembangan harus dilakukan dengan standar setinggi mungkin. Proses kualitas yang efektif harus fokus pada:

Gerakan berkualitas dimulai di Jepang selama tahun 1940 -an dan tahun 1950 -an oleh William Edwards Deming, Joseph M. Juran, dan Kaoru Ishikawa. Dalam sekitar tahun 1947, W. Edwards Deming mengunjungi India juga, kemudian melanjutkan ke Jepang, di mana Dia telah diminta untuk bergabung dengan misi statistik yang bertanggung jawab untuk merencanakan Sensus Jepang 1951. Selama kunjungannya ke Jepang, Deming mengundang ahli statistik untuk pertemuan makan malam dan memberi tahu mereka betapa pentingnya mereka dan apa yang bisa mereka lakukan untuk Jepang. Pada bulan Maret 1950, ia kembali ke Jepang atas undangan Direktur Pelaksana Kenichi Koyanagi dari Union of Japanese Scientist and Engineers (JUSE) untuk mengajar kursus kepada para peneliti, pekerja, eksekutif, dan insinyur Jepang tentang metode Statistical Quality Control (SQC).Kontrol kualitas statistik adalah disiplin berdasarkan pengukuran dan statistik.Keputusan dibuat dan rencana dikembangkan berdasarkan pengumpulan dan evaluasi data aktual dalam bentuk metrik, daripada intuisi dan pengalaman. Metode SQC menggunakan tujuh alat manajemen kualitas dasar: analisis pareto, diagram sebab-dan-akibat, bagan aliran, grafik tren, histogram, diagram pencar, dan bagan kontrol.

Pada Juli 1950, Deming memberikan seminar delapan hari berdasarkan metode Shewhart kontrol kualitas statistik untuk insinyur dan eksekutif Jepang. Dia memperkenalkan plan-do-check-act (PDCA) dalam seminar, yang dia sebut siklus Shewhart (Gambar 1.1). Siklus Shewhart menggambarkan urutan aktivitas berikut: menetapkan tujuan, menugaskan mereka ke tonggak yang terukur, dan menilai kemajuan terhadap tonggak tersebut. Catatan kuliah 1950 Deming membentuk dasar untuk serangkaian seminar tentang metode SQC yang disponsori oleh Juse dan memberikan kriteria untuk hadiah deming terkenal Jepang. Pekerjaan Deming telah merangsang beberapa jenis industri yang berbeda, seperti untuk radio, transistor, kamera, teropong, mesin jahit, dan mobil.


Gambar 1.1

Antara sekitar tahun 1950 dan sekitar tahun 1970, industri mobil di Jepang, khususnya Toyota Motor Corporation, muncul dengan prinsip inovatif untuk memompres periode waktu dari pesanan pelanggan hingga pembayaran perbankan, yang dikenal sebagai “prinsip lean”. Tujuannya adalah untuk meminimalkan konsumsi sumber daya yang tidak menambah nilai pada suatu produk. Prinsip Lean telah ditentukan oleh Program Kemitraan Penyuluhan Manufaktur dari National Institute of Standards and Technology (NIST) sebagai “pendekatan sistematis untuk mengidentifikasi dan menghilangkan limbah melalui peningkatan berkelanjutan, mengalir produk saat menarik pelanggan dalam mengejar kesempurnaan,”. Biasanya diyakini bahwa prinsip-prinsip lean dimulai di Jepang oleh Taiichi Ohno dari Toyota, tetapi Henry Ford telah menggunakan bagian lean sejak sekitar tahun 1920, sebagaimana dibuktikan dengan kutipan berikut (Henry Ford, 1926):

Salah satu prestasi penting dalam menjaga harga produk Ford tetap rendah adalah pemendekan secara bertahap dari siklus produksi. Semakin lama sebuah artikel dalam proses pembuatan dan semakin banyak yang dipindahkan, semakin besar biaya utamanya.

Konsep ini dipopulerkan di Amerika Serikat oleh studi Massachusetts Institute of Technology (MIT) tentang gerakan dari produksi massal menuju produksi, seperti yang dijelaskan dalam mesin yang mengubah dunia, oleh James P. Womack, Daniel T. Jones, dan Daniel Roos, New York: Rawson and Associates, 1990. Lean Thinking terus menyebar ke setiap negara di dunia, dan para pemimpin mengadaptasi prinsip-prinsip di luar manufaktur mobil, ke logistik dan distribusi, layanan, ritel, Perawatan Kesehatan, Konstruksi, Pemeliharaan, dan Pengembangan Perangkat Lunak.

Catatan: Walter Andrew Shewhart adalah seorang ahli fisika, insinyur, dan ahli statistik Amerika dan dikenal sebagai bapak kontrol kualitas statistik. Shewhart bekerja di laboratorium telepon Bell dari yayasannya pada tahun 1925 hingga pensiunnya pada tahun 1956. Karyanya dirangkum dalam bukunya Economic Control of Quality of Manufactured Product, yang diterbitkan oleh McGraw-Hill pada tahun 1931. Pada tahun 1938, karyanya menjadi perhatian dari perhatian Fisikawan W. Edwards Deming, yang mengembangkan beberapa proposal metodologis Shewhart di Jepang sejak tahun 1950 dan seterusnya dan dinamai miliknya Sintesis Siklus Shewhart.

Pada tahun 1954, Joseph M. Juran dari Amerika Serikat mengusulkan meningkatkan tingkat manajemen kualitas dari unit manufaktur ke seluruh organisasi. Dia menekankan pentingnya pemikiran sistem yang dimulai dengan persyaratan produk, desain, pengujian prototipe, operasi peralatan yang tepat, dan umpan balik proses yang akurat. Seminar Juran juga menjadi bagian dari program pendidikan Juse. Juran memacu perpindahan dari SQC ke TQC (Total Quality Control) di Jepang. Ini termasuk kegiatan dan pendidikan di seluruh perusahaan dalam Quality Control (QC), audit, lingkaran kualitas, dan promosi prinsip-prinsip manajemen kualitas. Istilah TQC diciptakan oleh seorang Amerika, Armand V. Feigenbaum, dalam bukunya 1951 Prinsip QC, Praktik, dan Administrasi. Itu diterbitkan ulang pada tahun 2004. Pada tahun 1968, Kaoru Ishikawa, salah satu ayah TQC di Jepang, telah diuraikan, seperti Ditampilkan di berikut ini, elemen kunci manajemen TQC:

Catatan: Lingkaran berkualitas adalah kelompok sukarelawan pekerja, biasanya anggota departemen yang sama, yang bertemu secara teratur untuk membahas masalah dan membuat presentasi kepada manajemen dengan ide-ide mereka untuk mengatasinya. Lingkaran kualitas dimulai di Jepang pada tahun 1962 oleh Kaoru Ishikawa sebagai metode lain untuk meningkatkan kualitas. Gerakan di Jepang dikoordinasikan oleh Juse.

Salah satu metodologi TQC inovatif yang dikembangkan di Jepang disebut sebagai diagram Ishikawa atau sebab-akibat. Kaoru Ishikawa ditemukan dari data statistik bahwa dispersi dalam kualitas produk berasal dari empat penyebab umum, yaitu Material (bahan), Machine (mesin), Methods (metode), dan Measurements (pengukuran), yang dikenal sebagai 4M (Gambar 1.2). Panah horizontal tebal menunjuk ke kualitas, sedangkan panah diagonal pada Gambar 1.2 kemungkinan penyebab memiliki efek pada kualitas. Bahan seringkali berbeda ketika sumber persyaratan pasokan atau ukuran bervariasi. Mesin, atau peralatan, juga berfungsi secara berbeda tergantung pada variasi bagian mereka, dan mereka beroperasi secara optimal hanya untuk sebagian waktu. Metode, atau proses, menyebabkan variasi yang lebih besar karena kurangnya pelatihan dan instruksi tulisan tangan yang buruk. Akhirnya, pengukuran juga bervariasi karena peralatan yang sudah ketinggalan zaman dan kalibrasi yang tidak tepat. Variasi dalam parameter 4M memiliki efek pada kualitas suatu produk. Diagram Ishikawa telah memengaruhi perusahaan Jepang untuk memfokuskan perhatian kontrol kualitas mereka pada peningkatan bahan, mesin, metode, dan pengukuran.

Gerakan TQC di Jepang telah menyebabkan keterlibatan manajemen puncak yang meresap. Banyak perusahaan di Jepang memiliki dokumentasi yang luas tentang kegiatan berkualitas mereka. Eksekutif senior di Amerika Serikat tidak percaya kualitas penting atau tidak tahu harus mulai dari mana sampai National Broadcasting Corporation (NBC), sebuah jaringan televisi Amerika, menyiarkan film dokumenter “If Japan Can… Why Can’t We?” (jika Jepang bisa? Mengapa kita tidak bisa?) pada jam 9:30 malam. Pada 24 Juni 1980. Film dokumenter ini diproduksi oleh Clare Crawford-Mason dan diriwayatkan oleh Lloyd Dobyns. Lima belas menit siaran itu dikhususkan untuk Dr. Deming dan pekerjaannya. Setelah siaran, banyak eksekutif dan pemimpin pemerintah menyadari bahwa penekanan baru pada kualitas tidak lagi menjadi pilihan bagi perusahaan-perusahaan Amerika tetapi suatu keharusan untuk melakukan bisnis dalam pasar dunia yang kompetitif dan lebih menuntut. Ford Motor Company dan General Motors segera mengadopsi metodologi SQC Deming ke dalam proses pembuatannya. Perusahaan lain seperti Dow Chemical dan Pesawat Hughes mengikutinya. Filosofi manajemen TQC Ishikawa mendapatkan popularitas di Amerika Serikat. Lebih lanjut, penekanan yang memicu kualitas di perusahaan manufaktur Amerika memimpin Kongres A.S. Keunggulan kualitas sebagai keunggulan kompetitif. Dalam Baldrige National Award, kualitas dipandang sebagai sesuatu yang ditentukan oleh pelanggan dan dengan demikian fokusnya adalah pada kualitas yang didorong oleh pelanggan. Di sisi lain, kualitas juga dipandang sebagai sesuatu yang ditentukan oleh produsen dengan menyesuaikan diri dengan spesifikasi dan dengan demikian fokusnya adalah pada kesesuaian dengan spesifikasi.


Gambar 1.2

Komentar: Malcolm Baldrige adalah Sekretaris Perdagangan AS dari tahun 1981 hingga kematiannya dalam kecelakaan rodeo pada Juli 1987. Baldrige adalah pendukung manajemen kualitas sebagai kunci kemakmuran dan kekuatan jangka panjang negaranya. Dia menaruh minat pribadi pada Undang-Undang Peningkatan Kualitas, yang akhirnya dinamai menurut namanya, dan membantu menyusun salah satu versi awalnya. Sebagai pengakuan atas kontribusinya, Kongres menunjuk penghargaan untuk menghormatinya.

Secara tradisional, konsep TQC dan Lean diterapkan dalam proses pembuatan. Proses pengembangan perangkat lunak menggunakan konsep-konsep ini sebagai alat lain untuk memandu produksi perangkat lunak berkualitas. Konsep-konsep ini menyediakan kerangka kerja untuk membahas masalah produksi perangkat lunak. Arsitektur Model Kematangan Perangkat Lunak (CMM) yang dikembangkan di Software Engineering Institute didasarkan pada prinsip-prinsip kualitas produk yang telah dikembangkan oleh W. Edwards Deming, Joseph M. Juran, Kaoru Ishikawa, dan Philip Crosby.

1.2 Software Quality

Pertanyaan “Apa itu kualitas perangkat lunak?” memunculkan banyak jawaban yang berbeda. Kualitas adalah konsep yang kompleks, artinya berbeda bagi orang yang berbeda, dan sangat bergantung pada konteks. Kualitas perangkat lunak bisa dipersepsikan dengan cara yang berbeda dalam domain yang berbeda, seperti filsafat, ekonomi, pemasaran, dan manajemen.

Ada lima sudut pandang dalam kita melihat kualitas:

  1. Trancendental View: Pandangan ini memandang kualitas sebagai sesuatu yang dapat dikenali tetapi sulit didefinisikan. Pandangan transendental tidak hanya terbatas pada kualitas perangkat lunak saja, tetapi telah diterapkan di berbagai bidang kehidupan sehari-hari yang kompleks.
  2. User View: Pandangan ini memandang kualitas sebagai kesesuaian dengan tujuan. Menurut pandangan ini, saat mengevaluasi kualitas suatu produk, seseorang harus mengajukan pertanyaan kunci: “Apakah produk tersebut memenuhi kebutuhan dan harapan pengguna?”
  3. Manufacturing View: Di sini kualitas dipahami sebagai kesesuaian dengan spesifikasi. Tingkat kualitas suatu produk ditentukan oleh sejauh mana produk tersebut memenuhi spesifikasinya.
  4. Produk View: Dalam hal ini, kualitas dipandang terkait dengan karakteristik bawaan produk. Karakteristik bawaan suatu produk, yaitu kualitas internal, menentukan kualitas eksternalnya.
  5. Value-Based View: Kualitas, dalam perspektif ini, bergantung pada jumlah yang bersedia dibayarkan pelanggan untuk produk tersebut.

1.3 Peran Pengujian

Pengujian memainkan peran penting dalam mencapai dan menilai kualitas produk perangkat lunak. Di satu sisi, kita meningkatkan kualitas produk saat kita mengulang siklus pengujian–menemukan cacat–memperbaiki selama pengembangan. Di sisi lain, kita menilai seberapa baik sistem kita saat kita melakukan pengujian tingkat sistem sebelum merilis produk.

Dengan demikian, pengujian perangkat lunak adalah proses verifikasi untuk penilaian dan peningkatan kualitas perangkat lunak. Secara umum, aktivitas untuk penilaian kualitas perangkat lunak dapat dibagi menjadi dua kategori besar, yaitu analisis statis dan analisis dinamis.

Dengan melakukan analisis statis dan dinamis, penguji ingin mengidentifikasi sebanyak mungkin kesalahan sehingga kesalahan tersebut diperbaiki pada tahap awal pengembangan perangkat lunak. Analisis statis dan analisis dinamis bersifat saling melengkapi, dan untuk efektivitas yang lebih baik, keduanya harus dilakukan berulang kali dan bergantian.

1.4 Verifikasi dan Validasi

Dua konsep serupa yang terkait dengan pengujian perangkat lunak yang sering digunakan oleh praktisi adalah verifikasi dan validasi. Kedua konsep tersebut bersifat abstrak, dan masing-masing dapat diwujudkan melalui serangkaian aktivitas konkret yang dapat dieksekusi. Kedua konsep tersebut dijelaskan sebagai berikut:

Proses verifikasi menetapkan korespondensi fase implementasi dari proses pengembangan perangkat lunak dengan spesifikasinya, sedangkan validasi menetapkan korespondensi antara sistem dan harapan pengguna. Seseorang dapat membandingkan verifikasi dan validasi sebagai berikut:

1.5 Failure, Error, Fault dan Defect

Dalam literatur tentang pengujian perangkat lunak, seseorang dapat menemukan referensi tentang istilah Failure (kegagalan), error, fault (kesalahan), dan defect (cacat). Meskipun maknanya saling terkait, ada perbedaan penting antara keempat konsep ini.

Kesalahan (fault) mungkin tidak terdeteksi dalam waktu lama, hingga suatu kejadian mengaktifkannya. Ketika suatu kejadian mengaktifkan kesalahan, pertama-tama ia membawa program ke dalam status kesalahan (intermediate error state). Jika komputasi dibiarkan berlanjut dari status kesalahan tanpa tindakan korektif, program tersebut akhirnya menyebabkan kegagalan (failure). Sebagai tambahan, dalam komputasi yang toleran terhadap kesalahan, tindakan korektif dapat diambil untuk mengeluarkan program dari status kesalahan ke status yang diinginkan sehingga komputasi berikutnya tidak akhirnya menyebabkan kegagalan. Oleh karena itu, proses manifestasi kegagalan dapat secara ringkas direpresentasikan sebagai rantai perilaku sebagai berikut: fault → error → failure. Rantai perilaku tersebut dapat berulang untuk sementara waktu, yaitu, kegagalan satu komponen dapat menyebabkan kegagalan komponen lain yang berinteraksi.

Definisi kegagalan di atas mengasumsikan bahwa spesifikasi yang diberikan dapat diterima oleh pelanggan. Namun, jika spesifikasi tersebut tidak memenuhi harapan pelanggan, maka, tentu saja, bahkan implementasi yang bebas kesalahan pun gagal memuaskan pelanggan. Merupakan tugas yang sulit untuk memberikan definisi yang tepat tentang kesalahan, error, atau kegagalan perangkat lunak, karena “faktor manusia” yang terlibat dalam penerimaan keseluruhan suatu sistem. Dalam bisnis perangkat lunak modern, kegagalan perangkat lunak berarti “harapan pelanggan tidak terpenuhi dan/atau pelanggan tidak dapat melakukan pekerjaan yang bermanfaat dengan produk”.

Ada perbedaan tipis antara cacat dan kesalahan dalam contoh di atas, yaitu, pelaksanaan kebijakan yang cacat (defect) dapat menyebabkan pengambilan keputusan yang salah. Dalam konteks perangkat lunak, sistem perangkat lunak mungkin cacat karena masalah desain; status sistem tertentu akan memperlihatkan cacat, yang mengakibatkan perkembangan kesalahan yang didefinisikan sebagai nilai sinyal atau keputusan yang salah dalam sistem. Dalam industri, istilah cacat digunakan secara luas, sedangkan di kalangan peneliti istilah kesalahan lebih umum. Untuk semua tujuan praktis, kedua istilah tersebut adalah sinonim. Dalam buku ini, kami menggunakan kedua istilah tersebut secara bergantian sebagaimana diperlukan.

1.6 PENGERTIAN KEANDALAN (RELIABILITY) PERANGKAT LUNAK

Tidak peduli seberapa sering kita menjalankan siklus pengujian–menemukan kesalahan–memperbaiki selama pengembangan perangkat lunak, beberapa kesalahan mungkin luput dari perhatian kita, dan ini pada akhirnya akan muncul di lokasi user. Oleh karena itu, ukuran kuantitatif yang berguna dalam menilai kualitas perangkat lunak adalah keandalannya. Keandalan perangkat lunak didefinisikan sebagai probabilitas pengoperasian sistem perangkat lunak tanpa kegagalan selama waktu tertentu dalam lingkungan tertentu. Tingkat keandalan sistem bergantung pada masukan yang menyebabkan kegagalan diamati oleh pengguna akhir. Keandalan perangkat lunak dapat diperkirakan melalui pengujian acak, seperti yang disarankan oleh Hamlet. Karena pengertian keandalan bersifat khusus untuk “lingkungan tertentu”, data pengujian harus diambil dari distribusi masukan agar menyerupai penggunaan sistem di masa mendatang. Menangkap pola penggunaan sistem di masa mendatang secara umum dijelaskan dalam bentuk yang disebut profil operasional. Konsep profil operasional sistem dirintis oleh John D. Musa di AT&T Bell Laboratories antara tahun 1970-an dan 1990-an

1.7 Tujuan Pengujian

Para pemangku kepentingan dalam proses pengujian adalah programer, test engineer, manajer proyek, dan user. Pemangku kepentingan adalah orang atau organisasi yang memengaruhi perilaku sistem atau yang dipengaruhi oleh sistem itu. Pemangku kepentingan yang berbeda melihat proses pengujian dari berbagai perspektif seperti yang dijelaskan di bawah ini:

1.8 Apa itu test case?

Dalam bentuknya yang paling mendasar, test case adalah sepasang <input, hasil yang diharapkan> sederhana. Jika suatu program yang diuji diharapkan untuk menghitung akar kuadrat dari angka non -negatif, maka empat contoh kasus uji seperti yang ditunjukkan pada contoh berikut

TB1: <0, 0>
TB2: <25, 5>
TB3: <40, 6.02343254>
TB4: <100.5, 330.3239128>

gambar 1.3

TS1: <cek saldo, 1000000>, <tarik tunai, "jumlah?">, <200000, "Rp. 200.000">, <cek saldo, 800000>

gambar 1.4

Dalam stateless system, di mana hasilnya hanya bergantung pada input saat ini, kasus uji sangat sederhana dalam struktur, seperti yang ditunjukkan pada Gambar 1.3. Program untuk menghitung akar kuadrat dari angka positif adalah contoh dari stateless system. Kompiler untuk bahasa pemrograman C adalah contoh lain dari stateless system. Kompiler adalah stateless system karena untuk mengkompilasi program yang tidak perlu diketahui tentang program yang dikompilasi sebelumnya.

Dalam state-oriented system, di mana hasil program tergantung pada keadaan saat ini sistem dan input saat ini, kasus uji dapat terdiri dari urutan <input, hasil yang diharapkan> yang diharapkan. Sistem switching telepon dan mesin teller otomatis (ATM) adalah contoh state-oriented system.Untuk mesin ATM, test case untuk pengujian fungsi penarikan ditunjukkan pada Gambar 1.4. Di sini, kita berasumsi bahwa pengguna telah memasukkan input yang divalidasi, seperti uang tunai Kartu dan Nomor PIN.

Dalam kasus uji TS1, “cek saldo” dan “tarik tunai” di set pertama, kedua, dan keempat mewakili penekanan tombol yang sesuai pada keypad ATM. Diasumsikan bahwa akun pengguna memiliki 1.000.000 di atasnya, dan pengguna ingin menarik jumlah 200.000. Hasil yang diharapkan “Rp. 200.000” dalam set ketiga mewakili uang tunai yang dikeluarkan oleh ATM. Setelah operasi penarikan, pengguna memastikan bahwa saldo yang tersisa adalah 800.000

Untuk state-oriented system, sebagian besar kasus ujinya berkaitan dengan memberikan input yang biasanya berhubungan dengan suatu keputusan waktu dan waktu. Contoh kasusnya akan akan dibahas pada bagian lain.

1.9 Hasil yang diharapkan

Hasil eksekusi program bisa berupa output sebagai berikut:

Konsep penting dalam desain tes adalah konsep oracle. Sebuah oracle adalah entitas apa pun - program, proses, ahli manusia, atau badan data - yang memberi tahu kita hasil yang diharapkan dari tes atau serangkaian tes tertentu. Kasus uji hanya bermakna jika dimungkinkan untuk memutuskan penerimaan hasil yang dihasilkan oleh program yang sedang diuji.

Idealnya, hasil tes yang diharapkan harus dihitung saat merancang uji kasus. Dengan kata lain, hasil tes dihitung sebelum program dieksekusi dengan input tes yang dipilih. Idenya di sini adalah bahwa seseorang harus dapat menghitung hasil yang diharapkan dari pemahaman tentang persyaratan program.Prekomputasi hasil yang diharapkan akan menghilangkan bias implementasi jika kasus uji dirancang oleh pengembang.

Dalam kasus yang luar biasa, di mana sangat sulit, tidak mungkin, atau bahkan tidak diinginkan untuk menghitung hasil yang diharapkan tunggal, seseorang harus mengidentifikasi hasil yang diharapkan dengan memeriksa hasil tes yang sebenarnya, seperti yang dijelaskan dalam hal berikut:

  1. Jalankan program dengan input yang dipilih.
  2. Amati hasil aktual dari eksekusi program.
  3. Pastikan bahwa hasil yang sebenarnya adalah hasil yang diharapkan.
  4. Gunakan hasil aktual yang diverifikasi sebagai hasil yang diharapkan dalam menjalankan kasus uji berikutnya.

1.10 KONSEP PENGUJIAN LENGKAP

Bukan hal yang aneh untuk menemukan orang membuat klaim seperti “Saya telah melakukan pengujian lengkap pada program.”. Pengujian lengkap berarti tidak ada kesalahan yang belum ditemukan pada akhir fase uji. Semua masalah harus diketahui di akhir pengujian lengkap. Untuk sebagian besar sistem, pengujian lengkap hampir mustahil karena alasan berikut:

1.12 AKTIVITAS PENGUJIAN

Untuk menguji suatu program, test engineer harus melakukan urutan kegiatan pengujian. Sebagian besar kegiatan ini telah ditunjukkan pada Gambar 1.6 dan dijelaskan sebagai berikut. Penjelasan ini fokus pada satu kasus uji.

Laporan tes harus ditulis setelah menganalisis hasil tes. Motivasi untuk menulis laporan tes adalah memperbaiki kesalahan jika tes mengungkapkan kesalahan. Laporan tes berisi item berikut untuk informatif: - Jelaskan cara mereproduksi kegagalan. - Menganalisis kegagalan untuk dapat menggambarkannya. - Pointer ke hasil aktual dan test case, lengkap dengan input, hasil yang diharapkan, dan lingkungan eksekusi.

1.13 TINGKATAN PENGUJIAN

Pengujian dilakukan pada berbagai tingkat yang melibatkan sistem lengkap atau bagian-bagiannya selama siklus hidup produk perangkat lunak. Sistem perangkat lunak melewati empat tahap pengujian sebelum benar-benar digunakan. Keempat tahap ini dikenal sebagai unit, integrasi, sistem, dan pengujian tingkat penerimaan. Tiga tingkat pengujian pertama dilakukan oleh sejumlah pemangku kepentingan yang berbeda di organisasi pengembangan, di mana sebagai pengujian penerimaan dilakukan oleh pelanggan. Empat tahap pengujian telah diilustrasikan dalam bentuk apa yang disebut model V klasik pada Gambar 1.7.

Dalam pengujian unit, pemrogram menguji unit program individu, seperti prosedur, fungsi, metode, atau kelas, secara terpisah. Setelah memastikan bahwa unit individu bekerja pada tingkat yang memuaskan, modul dikumpulkan untuk membangun subsistem yang lebih besar dengan mengikuti teknik pengujian integrasi. Pengujian integrasi dilakukan bersama oleh pengembang perangkat lunak dan test engineer integrasi. Tujuan dari pengujian integrasi adalah untuk membangun sistem yang cukup stabil yang dapat menahan kekakuan pengujian tingkat sistem. Pengujian tingkat sistem mencakup spektrum pengujian yang luas, seperti pengujian fungsionalitas, pengujian keamanan, pengujian ketahanan, pengujian beban, pengujian stabilitas, pengujian tegangan, pengujian kinerja, dan pengujian keandalan. Pengujian sistem adalah fase kritis dalam proses pengembangan perangkat lunak karena kebutuhan untuk memenuhi jadwal yang ketat mendekati tanggal pengiriman, untuk menemukan sebagian besar kesalahan, dan untuk memverifikasi bahwa perbaikan berfungsi dan belum menghasilkan kesalahan baru.Pengujian sistem terdiri dari sejumlah kegiatan yang berbeda: membuat rencana pengujian, merancang rangkaian uji, mempersiapkan lingkungan pengujian, melaksanakan tes dengan mengikuti strategi yang jelas, dan memantau proses pelaksanaan tes.


Gamber 1.7

Pengujian regresi adalah tingkat pengujian lain yang dilakukan sepanjang siklus hidup suatu sistem. Pengujian regresi dilakukan setiap kali komponen sistem dimodifikasi. Pengujian regresi adalah untuk memastikan bahwa modifikasi tidak menimbulkan kesalahan baru di bagian yang tidak dapat dimodifikasi. Tepatnya, pengujian regresi bukanlah tingkat pengujian yang berbeda. Sebaliknya, ini dianggap sebagai subfase unit, integrasi, dan pengujian tingkat sistem, seperti yang diilustrasikan pada Gambar 1.8.

✳ ChatGPT prompt: jelaskan tentang regression testing

Dalam pengujian regresi, tes baru tidak dirancang. Sebaliknya, tes dipilih, diprioritaskan, dan dieksekusi dari kumpulan kasus uji yang ada untuk memastikan bahwa tidak ada yang rusak dalam versi baru perangkat lunak. Pengujian regresi adalah proses yang mahal dan menyumbang sebagian upaya pengujian utama dalam industri ini. Diinginkan untuk memilih subset dari kasus uji dari kumpulan yang ada untuk mengurangi biaya. Pertanyaan kunci adalah berapa banyak dan kasus uji mana yang harus dipilih sehingga kasus uji yang dipilih lebih cenderung mengungkap kesalahan baru.

Setelah menyelesaikan pengujian tingkat sistem, produk dikirimkan kepada pelanggan. Pelanggan melakukan serangkaian tes mereka sendiri, umumnya dikenal sebagai pengujian penerimaan (acceptance test). Tujuan pengujian penerimaan adalah untuk mengukur kualitas produk, daripada mencari cacat, yang merupakan tujuan pengujian sistem. Tujuan utama dalam pengujian penerimaan adalah harapan pelanggan dari sistem. Pada saat pengujian penerimaan, pelanggan seharusnya mengembangkan kriteria penerimaan mereka berdasarkan harapan mereka sendiri dari sistem. Ada dua jenis pengujian penerimaan seperti yang dijelaskan sebagai berikut:


Gamber 1.8

UAT dilakukan oleh pelanggan untuk memastikan bahwa sistem memenuhi kriteria penerimaan kontrak sebelum ditandatangani sebagai memenuhi kebutuhan pengguna. Di sisi lain, BAT dilakukan oleh developer. Tujuan adanya BAT adalah untuk memastikan bahwa sistem pada akhirnya akan lulus UAT.

1.16 DESAIN DAN PERENCANAAN PENGUJIAN

Tujuan perencanaan tes sistem adalah untuk persiapan pelaksanaan tes. Rencana pengujian menyediakan kerangka kerja, ruang lingkup, rincian sumber daya yang dibutuhkan, upaya yang diperlukan, jadwal kegiatan, dan anggaran. Kerangka kerja adalah seperangkat ide, fakta, atau keadaan di mana tes akan dilakukan. Lingkup yang dinyatakan menguraikan domain, atau luasnya, dari kegiatan pengujian. Lingkup ini mencakup aspek manajerial pengujian, daripada teknik terperinci dan kasus uji spesifik.

Desain tes adalah fase penting dari pengujian perangkat lunak. Selama fase desain tes, persyaratan sistem dipelajari secara kritis, fitur sistem yang akan diuji diidentifikasi secara menyeluruh, dan tujuan kasus uji dan perilaku terperinci dari kasus uji didefinisikan. Tujuan uji diidentifikasi dari berbagai sumber, yaitu spesifikasi persyaratan dan spesifikasi fungsional, dan satu atau lebih kasus uji dirancang untuk setiap tujuan tes. Setiap case uji dirancang sebagai kombinasi komponen uji modular yang disebut langkah uji. Langkah-langkah uji ini dapat digabungkan bersama untuk membuat tes yang lebih kompleks. Sebuah kasus pengujian ditentukan dengan jelas sehingga orang lain dapat dengan mudah meminjam, memahami, dan menggunakannya kembali.

Sangat menarik untuk dicatat bahwa pendekatan yang berpusat pada pengujian untuk pengembangan sistem secara bertahap muncul. Pendekatan ini disebut Test-Driven Development (TDD). Dalam pengembangan yang digerakkan oleh uji, programmer merancang dan mengimplementasikan kasus uji sebelum kode produksi ditulis. Pendekatan ini adalah praktik utama dalam proses pengembangan perangkat lunak modern seperti XP (Extreme Programming). Karakteristik utama proses pengembangan perangkat lunak menggunakan metodologi agile adalah: (i) incremental development, (ii) pengkodean unit dan tes penerimaan yang dilakukan oleh pemrogram bersama dengan user, (iii) pengujian regresi yang sering (iv) membuat kode pengujian secara bertahap dimulai sebelum proses coding.

1.17 PEMANTAUAN DAN PENGUKURAN EKSEKUSI PENGUJIAN

Pemantauan dan pengukuran adalah dua prinsip utama yang diikuti dalam setiap upaya ilmiah dan teknik. Prinsip yang sama juga berlaku untuk fase pengujian pengembangan perangkat lunak. Penting untuk memantau metrik tertentu yang benar-benar mewakili kemajuan pengujian dan mengungkapkan tingkat kualitas sistem.Berdasarkan metrik tersebut, manajemen dapat memicu tindakan korektif dan preventif. Dengan menempatkan serangkaian metrik kecil namun kritis di tempat, manajemen eksekutif akan dapat mengetahui apakah mereka berada di jalur yang benar. Metrik eksekusi pengujian dapat dikategorikan secara luas ke dalam dua kelas sebagai berikut:

Kelas pertama metrik menyangkut proses pelaksanaan kasus uji, sedangkan kelas kedua menyangkut cacat yang ditemukan sebagai akibat dari pelaksanaan tes. Metrik ini perlu dilacak dan dianalisis secara berkala, katakanlah, setiap hari atau mingguan. Untuk mengontrol proyek pengujian secara efektif, penting untuk mengumpulkan informasi yang valid dan akurat tentang proyek. Salah satu contohnya adalah dengan tepat mengetahui kapan harus memicu kriteria pengembalian untuk siklus uji dan memulai analisis akar penyebab masalah sebelum tes lebih banyak dapat dilakukan. Dengan memicu kriteria yang kembali seperti itu, seorang manajer pengujian dapat secara efektif memanfaatkan waktu test engineer, dan mungkin uang, dengan menangguhkan siklus uji pada produk dengan terlalu banyak cacat untuk melakukan tes sistem yang bermakna.Tim manajemen harus mengidentifikasi dan memantau metrik saat pengujian sedang berlangsung sehingga keputusan penting dapat dibuat.Penting untuk menganalisis dan memahami metrik uji, daripada hanya mengumpulkan data dan membuat keputusan berdasarkan data mentah tersebut.Metrik bermakna hanya jika mereka memungkinkan manajemen untuk membuat keputusan yang menghasilkan biaya produksi yang lebih rendah, berkurangnya keterlambatan pengiriman, dan peningkatan kualitas sistem perangkat lunak.

Evaluasi kuantitatif penting di setiap bidang ilmiah dan teknik. Evaluasi kuantitatif dilakukan melalui pengukuran. Pengukuran memungkinkan seseorang mengevaluasi parameter yang menarik secara kuantitatif sebagai berikut:

1.18 ALAT UJI DAN OTOMATISASI

Secara umum, pengujian perangkat lunak adalah tugas yang sangat intensif. Ini karena kasus uji sebagian besar dihasilkan secara manual dan sering dieksekusi secara manual. Selain itu, hasil eksekusi pengujian dianalisis secara manual. Durasi tugas-tugas tersebut dapat dipersingkat dengan menggunakan alat yang sesuai. Seorang test engineer dapat menggunakan berbagai alat, seperti penganalisa kode statis, generator data uji, dan penganalisa jaringan, jika aplikasi atau protokol berbasis jaringan sedang diuji.Alat -alat itu berguna dalam meningkatkan efisiensi dan efektivitas pengujian.

Otomatisasi pengujian sangat penting untuk setiap divisi pengujian dan penjaminan kualitas dari suatu pengembang untuk bergerak maju agar menjadi lebih efisien. Manfaat otomatisasi pengujian adalah sebagai berikut:

Otomasi pengujian memberikan kesempatan untuk meningkatkan keterampilan test engineer dengan menulis program. Mereka akan lebih fokus pada pengembangan kasus uji otomatis untuk menghindari hambatan dalam pengiriman produk ke pasar. Akibatnya, pengujian perangkat lunak menjadi kurang dari pekerjaan yang membosankan.

Otomatisasi pengujian meningkatkan cakupan pengujian regresi karena akumulasi kasus uji otomatis dari waktu ke waktu. Otomasi memungkinkan pengembang untuk membuat library untuk kasus uji yang dapat digunakan kembali dan memfasilitasi pelaksanaan serangkaian kasus uji yang konsisten. Di sini konsistensi berarti kemampuan kami untuk menghasilkan hasil yang berulang untuk set pengujian yang sama. Mungkin sangat sulit untuk mereproduksi hasil pengujian dalam pengujian manual, karena kondisi yang tepat pada waktu dan titik kegagalan mungkin tidak diketahui secara tepat. Dalam pengujian otomatis, lebih mudah untuk mengatur kondisi awal suatu sistem, sehingga membuatnya lebih mudah untuk mereproduksi hasil pengujian. Otomatisasi pengujian menyederhanakan pekerjaan debugging dengan memberikan log kegiatan yang terperinci dan tidak ambigu dan langkah-langkah pengujian menengah. Ini mengarah pada pendekatan pengujian yang lebih terorganisir, terstruktur, dan dapat direproduksi.

Eksekusi pengujian secara otomatis mengurangi waktu yang berlalu untuk pengujian. Kasus otomatis pengujian yang sama dapat dieksekusi dengan cara otomatis di malam hari. Singkatnya, otomatisasi meningkatkan efisiensi eksekusi pengujian. Namun, pada akhir pelaksanaan tes, penting untuk menganalisis hasil pengujian untuk menentukan jumlah kasus uji yang lulus atau gagal. Dan, jika kasus uji gagal, seseorang menganalisis alasan kegagalannya.

Dalam jangka panjang, otomatisasi uji hemat biaya. Ini secara drastis mengurangi biaya pemeliharaan perangkat lunak. Dalam fase berkelanjutan dari sistem perangkat lunak, tes regresi yang diperlukan setelah setiap perubahan pada sistem terlalu banyak. Akibatnya, pengujian regresi membutuhkan banyak waktu dan tenaga.

Jenis pengujian yang berulang sangat rumit dan mahal untuk dilakukan secara manual, tetapi dapat dengan mudah otomatis menggunakan perangkat lunak. Jenis aplikasi berulang yang sederhana dapat mengungkapkan kebocoran memori dalam perangkat lunak. Namun, aplikasi harus dijalankan untuk durasi yang sangat lama, katakanlah, selama berminggu-minggu, untuk mengungkapkan kebocoran memori. Oleh karena itu, pengujian manual mungkin tidak dibenarkan, sedangkan dengan otomatisasi mudah untuk mengungkapkan kebocoran memori. Misalnya, pengujian stres adalah kandidat utama untuk otomatisasi. Pengujian stres membutuhkan beban kasus terburuk untuk jangka waktu yang lama, yang sangat sulit untuk direalisasikan dengan cara manual. Pengujian skalabilitas adalah area lain yang dapat diotomatisasi. Alih-alih membuat tempat tidur tes besar dengan ratusan peralatan, seseorang dapat mengembangkan simulator untuk memverifikasi skalabilitas sistem.

Otomatisasi pengujian sangat menarik, tetapi dilengkapi dengan label harga. Waktu dan sumber daya yang cukup perlu dialokasikan untuk pengembangan testsuite otomatis. Pengembangan kasus uji otomatis perlu dikelola seperti proyek pemrograman. Artinya, itu harus dilakukan secara terorganisir; Kalau tidak, sangat mungkin gagal. Rangkaian tes otomatis mungkin membutuhkan waktu lebih lama untuk dikembangkan karena rangkaian tes perlu didebug sebelum dapat digunakan untuk pengujian. Waktu dan sumber daya yang cukup perlu dialokasikan untuk mempertahankan rangkaian uji otomatis dan menyiapkan lingkungan pengujian. Selain itu, setiap kali sistem dimodifikasi, modifikasi harus tercermin dalam rangkaian uji otomatis. Oleh karena itu, rangkaian uji otomatis harus dirancang sebagai sistem modular, dikoordinasikan menjadi perpustakaan yang dapat digunakan kembali, dan referensi silang dan dapat dilacak kembali ke fitur yang diuji.

Penting untuk diingat bahwa otomatisasi pengujian tidak dapat menggantikan pengujian manual.Kreativitas manusia, variabilitas, dan observabilitas tidak dapat ditiru melalui otomatisasi.Otomatisasi tidak dapat mendeteksi beberapa masalah yang dapat dengan mudah diamati oleh manusia. Pengujian otomatis tidak memperkenalkan variasi kecil seperti yang bisa dilakukan manusia. Kategori tes tertentu, seperti kegunaan, interoperabilitas, ketahanan, dan kompatibilitas, seringkali tidak cocok untuk otomatisasi.Terlalu sulit untuk mengotomatiskan semua kasus uji; Biasanya 50% dari semua kasus uji tingkat sistem dapat diotomatisasi. Akan selalu ada kebutuhan untuk beberapa pengujian manual, bahkan jika semua Kasing uji tingkat sistem otomatis.

Tujuan otomatisasi uji bukan untuk mengurangi jumlah kepala di departemen pengujian suatu organisasi, tetapi untuk meningkatkan produktivitas, kualitas, dan efisiensi pelaksanaan pengujian. Faktanya, otomatisasi pengujian membutuhkan jumlah kepala yang lebih besar di departemen pengujian pada tahun pertama, karena departemen perlu mengotomatisasi kasus uji dan secara bersamaan melanjutkan pelaksanaan tes manual. Bahkan setelah selesainya pengembangan kerangka kerja otomasi pengujian dan pustaka kasus uji, jumlah kepala di departemen pengujian tidak turun di bawah level aslinya. Organisasi pengujian perlu mempertahankan anggota tim asli untuk meningkatkan kualitas dengan menambahkan lebih banyak kasus uji ke repositori kasus uji otomatis.

Sebelum proyek otomatisasi pengujian dapat dilanjutkan, organisasi harus menilai dan membahas sejumlah pertimbangan. Daftar prasyarat berikut harus dipertimbangkan untuk penilaian apakah organisasi siap untuk otomatisasi pengujian:

1.19 ORGANISASI DAN MANAJEMEN TIM

Pengujian adalah kegiatan terdistribusi yang dilakukan pada tingkat yang berbeda sepanjang siklus hidup perangkat lunak. Level yang berbeda ini adalah pengujian unit (unit testing), pengujian integrasi (integration testing), pengujian sistem (system testing), dan pengujian penerimaan (acceptance testing). Adalah logis untuk memiliki kelompok pengujian yang berbeda dalam suatu organisasi untuk setiap tingkat pengujian. Namun, ini lebih logis – dan pada kenyataannya – bahwa pengujian tingkat unit bisa dilakukan oleh programmer sendiri daripada kelompok independen dari test engineer. Programmer yang mengembangkan unit perangkat lunak harus mengambil kepemilikan dan tanggung jawab untuk menghasilkan perangkat lunak berkualitas baik untuk kepuasannya. Pengujian integrasi sistem dilakukan oleh penguji integrasi sistem (system integration test engineer). Penguji integrasi yang terlibat perlu mengetahui modul perangkat lunak dengan sangat baik. Ini berarti bahwa semua programmer yang secara kolektif membangun semua unit yang diintegrasikan perlu terlibat dalam pengujian integrasi. Juga, penguji integrasi sistem harus benar-benar mengetahui mekanisme sistem, yang merupakan kunci untuk mengintegrasikan sistem besar.

Sebuah tim untuk melakukan pengujian tingkat sistem benar-benar terpisah dari tim pengembangan, dan biasanya memiliki jumlah kepala yang terpisah dan anggaran terpisah. Tugas grup ini adalah untuk memastikan bahwa persyaratan sistem telah dipenuhi dan sistem dapat diterima. Anggota kelompok uji sistem melakukan berbagai kategori tes, seperti fungsionalitas, ketahanan, stres, beban, skalabilitas, keandalan, dan kinerja. Mereka juga menjalankan business acceptance test (BAT) yang diidentifikasi dalam rencana tes penerimaan pengguna untuk memastikan bahwa sistem pada akhirnya akan lulus pengujian penerimaan pengguna di situs pelanggan. Namun, user acceptance test (UAT) dijalankan oleh grup pengguna khusus klien. Grup pengguna terdiri dari orang-orang dari latar belakang yang berbeda, seperti SQA engineer, rekan bisnis, dan customer support engineer. Ini adalah praktik umum untuk membuat kelompok uji penerimaan pengguna sementara yang terdiri dari orang-orang dengan latar belakang yang berbeda, seperti penguji integrasi, penguji sistem, customer support engineer, dan marketing engineer. Setelah UAT selesai, bisa dibubarkan. Disarankan untuk memiliki setidaknya dua kelompok tes dalam suatu organisasi: kelompok penguji integrasi (integration test group) dan kelompok penguji sistem (system test group).

Mempekerjakan dan mempertahankan test engineer adalah tugas yang menantang. Wawancara adalah mekanisme utama untuk mengevaluasi pelamar. Wawancara adalah keterampilan yang meningkat dengan latihan.Penting untuk memiliki proses perekrutan agar efektif dalam mempekerjakan test engineer yang sangat baik. Untuk mempertahankan test engineer, manajemen harus mengakui pentingnya upaya pengujian setara dengan upaya pengembangan. Manajemen harus memperlakukan test engineer sebagai profesional dan sebagai bagian dari tim keseluruhan yang memberikan produk berkualitas