Pokok bahasan: Pengujian Sistem Informasi

a) Terminologi pengujian sistem informasi

b) Strategi pengujian sistem informasi
c) Jenis pengujian sistem informasi
d) Gambaran umum strategi dan pelaksanaan pengujian sistem informasi di DJKN

Pengujian Perangkat Lunak

Pengujian/Testing adalah proses dan kegiatan untuk menemukan kesalahan (errors,
bugs, defects) yang merupakan tinjauan akhir dari spesifikasi, desain, dan code. Tujuan dari
pengujian adalah untuk menjamin bahwa semua elemen dari aplikasi dengan benar, berfungsi
seperti yang diharapkan, dan memenuhi kriteria kinerja.
Pengujian/Testing Perangkat Lunak adalah proses menjalankan program atau sistem
dengan tujuan menemukan kesalahan. Kegiatan ini melibatkan aktivitas apa pun yang
ditujukan untuk mengevaluasi atribut atau kemampuan program atau sistem dan menentukan
apakah memenuhi hasil yang diperlukan atau belum.
Tidak seperti kebanyakan sistem/produk fisik, pada perangkat lunak, sebagian besar
kesalahan/cacat pada perangkat lunak adalah karena kesalahan desain, bukan cacat
manufaktur. Perangkat lunak tidak mengalami korosi, keausan, umumnya tidak akan berubah
sampai user melakukan upgrade, atau sampai usang. Jadi setelah perangkat lunak dikirimkan/
di release, cacat desain, atau bug, akan terkubur dan tetap tersembunyi hingga aktivasi,
hingga user mengoperasikan sistem dan hingga aktivitas user mentrigger error tersebut.
Bug perangkat lunak hampir selalu ada di modul perangkat lunak apa pun dalam
ukuran yang moderate: bukan karena programmer/ tim developer ceroboh atau tidak
bertanggung jawab, tetapi karena kompleksitas perangkat lunak umumnya tidak mudah
dikontrol, dan manusia hanya memiliki kemampuan terbatas untuk mengelola kompleksitas.
Dan untuk setiap sistem yang kompleks, cacat desain tidak pernah dapat sepenuhnya
dikesampingkan/dikecualikan.
Komplikasi pengujian seringkali berkaitan dengan sifat dinamis dari program
perangkat lunak. Biasanya tim penguji sudah menyiapkan skenario pengujian. Dan misal
pada masa sebelum testing, dari tim developer sudah mengubah code atau mendeteksi error
lalu mengubah code yang menyebabkan scenario menjadi tidak relevan lagi, maka tim testing
perlu memikirkan scenario testing terhadap perubahan yang dilakukan tersebut. Karena pada
dasarnya setiap perubahan juga memiliki potensi munculnya error.
 Terlepas dari keterbatasan-keterbatasan, pengujian merupakan bagian integral dalam
pengembangan perangkat lunak. Pengujian digunakan secara luas di setiap fase dalam siklus
pengembangan perangkat lunak. Biasanya, secara ideal, lebih dari 50% persen waktu
pengembangan dihabiskan untuk pengujian. Pengujian biasanya dilakukan untuk tujuan
berikut:
1. Untuk meningkatkan kualitas
2. Untuk Verifikasi & Validasi (V&V)
3. Untuk estimasi keandalan

Tujuan Pengujian
1. Untuk meningkatkan kualitas
Untuk produk perangkat lunak yang digunakan dalam lingkup kritikal, seperti
software untuk pesawat, rumah sakit, maka error atau bug dapat berakibat fatal jika luput dari
pengujian dan perbaikan. Bug dalam sistem kritis telah menyebabkan kecelakaan pesawat,
memungkinkan misi pesawat ulang-alik menjadi salah target, menghentikan perdagangan di
pasar saham, dan banyak lagi scenario buruk yang disebabkan karena error perangkat lunak.
Kualitas dan keandalan perangkat lunak seringkali adalah masalah hidup dan mati.
Kualitas berarti kesesuaian dengan persyaratan desain yang ditentukan: mampu
beroperasi dengan benar, memenuhi persyaratan kualitas minimum, yaitu melakukan seperti
yang dipersyaratkan dalam keadaan tertentu.
Debugging, adalah kegiatan untuk menguji case dalam scope kecil terhadap fungsi
perangkat lunak untuk mengetahui cacat desain oleh programmer. Debugging bertujuan
untuk menemukan error dan memperbaiki dan debugging terjadi dalam fase pemrograman.
2. Untuk Verifikasi & Validasi (V&V)
Tujuan penting dari pengujian adalah verifikasi dan validasi. Pengujian dapat
berfungsi sebagai metrik. Sehingga tester/penguji dapat menarik kesimpulan bahwa suatu
perangkat lunak berfungsi dalam situasi tertentu, atau tidak. Penguji juga dapat
membandingkan kualitas produk apakah beroperasi sama saat dijalankan pada spesifikasi
yang berbeda saat dilakukan pengujian yang sama.
Penguji tidak dapat menguji kualitas secara langsung namun mereka bisa menguji
faktor-faktor apa saja yang membuat suatu produk berkualitas. Kualitas memiliki tiga set
faktor: fungsionalitas, teknik, dan kemampuan beradaptasi. Ketiga set faktor ini dapat
dianggap sebagai dimensi dalam ruang kualitas perangkat lunak. Setiap dimensi dapat
dipecah menjadi faktor dan pertimbangan komponennya pada tingkat yang lebih detail.
 Pengujian yang baik menyediakan cara pengukuran untuk faktor-faktor tersebut
secara relevan. Faktor-faktor tersebut berbeda dari aplikasi ke aplikasi. Setiap sistem yang
kritikal (mempertaruhkan nyawa manusia) harus sangat menekankan faktor keandalan dan
integritas (reliability and integrity). Dalam sistem bisnis, faktor kegunaan dan pemeliharaan
(usability and maintainability) merupakan faktor kunci. Agar proses Pengujian berjalan
efektif, tim harus mampu mengukur setiap faktor dengan pengukuran yang relevan sehingga
kesempatan untuk mencapai/mendapatkan hasil berupa produk berkualitas menjadi nyata dan
mungkin dicapai.
Clean test atau positive test
Pengujian dengan tujuan untuk memvalidasi produk dapat bekerja dengan benar. Kekurangan
dari positive test adalah pengujian hanya dapat memvalidasi bahwa perangkat lunak
berfungsi untuk kasus uji yang ditentukan sebelumnya. Jumlah tes yang telah ditentukan
tersebut cenderung terbatas dan tidak dapat memvalidasi bahwa perangkat lunak dapat
berfungsi untuk semua situasi. Dan, hanya membutuhkan satu scenario tes dengan hasil yang
gagal sudah cukup untuk menunjukkan/disimpulkan bahwa perangkat lunak tidak berfungsi.
Dirty test, atau negative test
Pengujian yang bertujuan merusak/membuat error perangkat lunak, atau menunjukkan bahwa
produk tidak berfungsi. Perangkat lunak harus memiliki kemampuan exception handling yang
cukup untuk menahan scenario-scenario dirty test.
3. Untuk estimasi keandalan
Keandalan perangkat lunak memiliki hubungan penting dengan banyak aspek,
termasuk struktur dari perangkat lunak itu sendiri, dan banyaknya jumlah pengujian yang
telah dilakukan. Berdasarkan profil operasional (perkiraan frekuensi relatif penggunaan
berbagai input ke program), pengujian dapat berfungsi sebagai metode pengambilan sampel
statistik untuk mendapatkan data kegagalan untuk melakukan estimasi keandalan.
Test Level
1. Target Pengujian
a. Pengujian unit
b. Tes integrasi
c. Pengujian sistem
2. Tujuan Pengujian
a. Tes kualifikasi
b. Pengujian instalasi
c. Pengujian alfa dan beta
d. Pencapaian dan evaluasi keandalan
e. Tes kebenaran
f. Pengujian kinerja
g. Pengujian keamanan

1. Target Pengujian
Pengujian perangkat lunak biasanya dilakukan pada tingkat yang berbeda sepanjang proses
pengembangan dan pemeliharaan. Artinya, target pengujian dapat bervariasi: satu modul,
sekelompok modul-modul (yang saling terkait berdasarkan tujuan, penggunaan, perilaku, atau
struktur), atau keseluruhan sistem. Tiga tahap pengujian dapat dibedakan secara konseptual,
yaitu Unit, Integrasi, dan Sistem.
a. Pengujian unit
Pengujian unit memverifikasi fungsi dengan melakukan isolasi bagian perangkat lunak yang
dapat diuji secara terpisah. Tergantung pada konteksnya, unit bisa berupa subprogram
individu atau komponen yang lebih besar yang terbuat dari unit-unit yang saling terkait. Unit
pengujian didefinisikan lebih tepat dalam Standar IEEE untuk Pengujian Unit Perangkat
Lunak (IEEE1008-87), yang juga menjelaskan pendekatan terpadu untuk pengujian unit yang
sistematis dan terdokumentasi. Biasanya, pengujian unit terjadi dengan akses ke kode yang
sedang diuji dan dengan dukungan alat debugging, dan seringkali melibatkan programmer
yang menulis kode.
b. Tes integrasi
Pengujian integrasi adalah proses memverifikasi interaksi antara komponen perangkat lunak.
Strategi pengujian integrasi antara lain, seperti top-down atau bottom-up, digunakan untuk
perangkat lunak tradisional yang terstruktur secara hierarkis. Strategi integrasi sistematis
modern lebih berorientasi pada arsitektur, yang menyiratkan pengintegrasian komponen atau
subsistem perangkat lunak berdasarkan atas fungsionalitasnya.
c. Pengujian sistem
Pengujian sistem berkaitan dengan perilaku sistem secara keseluruhan. Mayoritas kegagalan
fungsional seharusnya sudah diidentifikasi selama pengujian unit dan integrasi. Pengujian
sistem biasanya dilakukan untuk membandingkan sistem dengan persyaratan sistem non-
fungsional, seperti keamanan, kecepatan, akurasi, dan keandalan. Antarmuka eksternal ke
aplikasi lain, utilitas, perangkat keras, atau lingkungan operasi juga dievaluasi pada tingkat
ini.
2. Tujuan Pengujian
Tujuan pengujian sebaiknya dituangkan secara eksplisit dan kuantitatif sehingga
memungkinkan control terhadap proses dan skenario pengujian.
Pengujian dapat ditujukan untuk memverifikasi properti yang berbeda. Kasus uji (test case)
dapat dirancang untuk memeriksa bahwa spesifikasi fungsional telah diterapkan dengan
benar, yaitu meliputi pengujian kesesuaian, pengujian kebenaran, atau pengujian
fungsionalitas. Namun, beberapa properti nonfungsional lainnya dapat diuji juga, termasuk
kinerja, keandalan, dan kegunaan, dan lain-lain.
Tujuan penting lainnya untuk pengujian termasuk (tetapi tidak terbatas pada) pengukuran
keandalan, evaluasi kegunaan, dan penerimaan, yang menggunakan pendekatannya berbeda.
Perhatikan bahwa tujuan pengujian bervariasi dengan target pengujian: artinya secara umum,
tujuan akan berbeda tergantung pada tingkat pengujian yang dijalankan.
Beberapa tujuan pengujian antara lain
a. Tes kualifikasi
Pengujian kualifikasi memeriksa perilaku sistem terhadap persyaratan yang ditentukan di user
requirement, di mana user menjalankan program dan menentukan tugas-tugas untuk
memeriksa bahwa persyaratan mereka telah dipenuhi. Aktivitas pengujian ini mungkin atau
mungkin tidak melibatkan pengembang sistem.
b. Pengujian instalasi
Biasanya setelah selesai pengujian penerimaan perangkat lunak (software acceptance testing),
perangkat lunak dapat diverifikasi pada saat instalasi di target environment yang telah
ditentukan. Pengujian instalasi dapat dilihat sebagai pengujian sistem yang dilakukan sekali
lagi untuk memenuhi persyaratan konfigurasi perangkat keras.
c. Pengujian alfa dan beta
Sebelum perangkat lunak dirilis, seringkali perangkat lunak diberikan kepada sekelompok
kecil pengguna potensial yang mampu mewakili untuk percobaan penggunaan, baik internal
(pengujian alfa) atau eksternal (pengujian beta). Pengguna ini melaporkan masalah dengan
produk. Penggunaan alfa dan beta sering kali tidak terkontrol sehingga mampu memberikan
feedback yang tidak terduga yang membantu penyempurnaan produk.
d. Pencapaian dan evaluasi keandalan
Selain membantu mengidentifikasi kesalahan, pengujian juga merupakan sarana untuk
meningkatkan keandalan.
Keandalan perangkat lunak mengacu pada kemungkinan operasi sistem yang bebas dari error.
Pengujian perangkat lunak (biasanya pengujian black box) dapat digunakan untuk
mendapatkan data kegagalan, dan sehingga data tersebut dapat digunakan untuk estimasi
lebih lanjut untuk menganalisis dan memperkirakan keandalan saat ini dan memprediksi
keandalan di masa mendatang. Oleh karena itu, berdasarkan estimasi, pengembang dapat
memutuskan apakah akan merilis perangkat lunak, dan pengguna dapat memutuskan apakah
akan mengadopsi dan menggunakan perangkat lunak tersebut. Risiko menggunakan
perangkat lunak juga dapat dinilai berdasarkan informasi keandalan.
Stress testing, atau load testing, sering digunakan untuk menguji seluruh sistem dengan cara
menguji perangkat lunak dengan beban di luar batas yang ditentukan. Stres test meliputi
pengujian kelelahan sumber daya, ledakan aktivitas, dan beban tinggi yang berkelanjutan.
e. Tes kebenaran
Kebenaran adalah persyaratan minimum perangkat lunak, yang merupakan tujuan penting
dari pengujian. Pengujian kebenaran akan membutuhkan beberapa jenis pengukuran, untuk
memberi tahu perilaku yang benar dan yang salah. Penguji mungkin atau mungkin tidak
mengetahui detail bagian dalam modul perangkat lunak yang sedang diuji, mis. aliran
kontrol, aliran data, dll.
Black box testing
Black box testing adalah metode pengujian di mana data pengujian diturunkan dari
persyaratan fungsional yang ditentukan tanpa memperhatikan struktur program akhir. Ini juga
disebut pengujian berbasis data, input/output, atau berbasis persyaratan. Black box testing
juga terutama mengacu pada pengujian fungsional - metode pengujian yang menekankan
pada pelaksanaan fungsi dan pemeriksaan data input dan output. Penguji memperlakukan
perangkat lunak yang diuji sebagai kotak hitam - hanya input, output, dan spesifikasi yang
terlihat, dan fungsionalitasnya ditentukan dengan mengamati output ke input yang sesuai.
Dalam pengujian, berbagai input dilakukan dan output dibandingkan dengan spesifikasi
untuk memvalidasi kebenarannya. Semua test case/ scenario diturunkan dari spesifikasi.
Pengujian ini tidak mempertimbangkan detail implementasi kode.
Pengujian kotak putih
White box testing menguji struktur dan aliran kerja perangkat lunak yang dapat dilihat oleh
penguji. Rencana pengujian dibuat sesuai dengan detail implementasi perangkat lunak,
seperti bahasa pemrograman, logika, dan gaya. Test case diturunkan dari struktur program.
Pengujian kotak putih juga disebut pengujian glass box, pengujian berbasis logika, atau
pengujian berbasis desain.
f. Pengujian kinerja
Tidak semua sistem perangkat lunak memiliki spesifikasi kinerja secara eksplisit. Namun
setiap sistem akan memiliki persyaratan kinerja implisit. Perangkat lunak idealnya tidak
menghabiskan waktu dan resource yang tidak terbatas untuk mengeksekusi suatu fungsi.
"Performance Bug" terkadang digunakan untuk merujuk pada masalah desain dalam
perangkat lunak yang menyebabkan kinerja sistem menurun.
g. Pengujian keamanan
Cacat dalam perangkat lunak dapat dimanfaatkan oleh penyusup untuk membuka lubang
keamanan. Dengan perkembangan Internet, masalah keamanan perangkat lunak merupakan
hal yang makin kritis.
Banyak aplikasi dan layanan perangkat lunak mengintegrasikan langkah-langkah keamanan
terhadap serangan dan ancaman. Tujuan pengujian keamanan sistem ini termasuk
mengidentifikasi dan menghapus kelemahan perangkat lunak yang berpotensi menyebabkan
kelemahan keamanan, dan memvalidasi efektivitas langkah-langkah keamanan. Dalam
pengujian, simulasi serangan keamanan dapat dilakukan untuk menemukan kerentanan
sistem.

Otomatisasi pengujian
Pengujian perangkat lunak dapat mengeluarkan sumber daya besar dan bisa sangat mahal.
Otomatisasi adalah cara yang baik untuk menghemat waktu dan biaya. Alat dan teknik
pengujian perangkat lunak biasanya memiliki kekurangan dalam penerapan dan skalabilitas.
Untuk mengotomatisasi proses, tim harus memiliki beberapa cara untuk menguji spesifikasi
sistem, dan menghasilkan test case untuk menguji target. Hingga saat ini belum ada sistem
pengujian otomatis secara utuh. Sejumlah besar pengujian tetap membutuhkan intervensi
manusia. Tingkat otomatisasi biasanya pada tingkat script.
Kapan pengujian dapat dihentikan?
Pengujian memiliki potensi keberlangsungan yang panjang dan cenderung tidak ada
selesainya. Namun tim penguji tidak dapat menguji sampai semua cacat digali dan
dihilangkan - karena hal tersebut tidak mungkin. Pada titik tertentu, tim penguji harus
menghentikan pengujian dan mengirimkan perangkat lunak untuk dirilis. Pertanyaannya
adalah kapan.
Secara realistis, pengujian merupakan bagian dari SDLC yang memiliki constraint/ batasan
antara lain anggaran, waktu, dan kualitas. Oleh karena batasan tersebut, seringkali pengujian
dihentikan ketika keandalan telah dapat memenuhi persyaratan yang ditetapkan.

Teknik Pengujian
Salah satu tujuan pengujian adalah untuk mendapatkan sebanyak mungkin potensi kegagalan.
Beragam teknik telah dikembangkan untuk melakukan pengujian. Prinsip utama yang
mendasari teknik tersebut adalah proses yang sistematik yang mungkin dapat
mengidentifikasi perilaku program yang cukup mewakili; misalnya, mempertimbangkan
subkelas dari domain input, skenario, status, dan aliran data.
Jenis-jenis teknik pengujian
a. Berdasarkan intuisi dan pengalaman developer
b. Teknik berbasis spesifikasi/ Specification-based techniques
c. Teknik berbasis kode/ Code-based techniques
d. Teknik berbasis kesalahan/ Fault-based techniques
e. Teknik berbasis penggunaan/ Usage-based techniques
f. Memilih dan menggabungkan teknik

Teknik Pengujian
a. Berdasarkan intuisi dan pengalaman developer
Pengujian ad hoc
Scenario tes datang dari keterampilan, intuisi, dan pengalaman developer untuk program
serupa. Pengujian ad hoc dapat berguna untuk mengidentifikasi tes khusus yang tidak mudah
ditangkap oleh teknik formal.
Pengujian eksplorasi
Pengujian eksplorasi didefinisikan sebagai pembelajaran simultan, desain pengujian, dan
pelaksanaan pengujian; yaitu, pengujian tidak didefinisikan sebelumnya dalam rencana
pengujian yang ditetapkan, tetapi dirancang, dijalankan, dan dimodifikasi secara dinamis.
Efektivitas pengujian eksplorasi bergantung pada pengetahuan developer perangkat lunak,
yang dapat diturunkan dari berbagai sumber: perilaku produk yang diamati selama pengujian,
familiaritas terhadap aplikasi, platform, proses kegagalan, jenis kemungkinan kesalahan dan
kegagalan, risiko yang terkait dengan produk tertentu, dan sebagainya.
b. Teknik berbasis spesifikasi/ Specification-based techniques
Equivalence partitioning
Domain input dibagi menjadi kumpulan subset atau kelas yang setara, yang dianggap setara
menurut hubungan tertentu, dan satu set perwakilan tes diambil dari setiap kelas.
Boundary-value analysis
Kasus uji dipilih berdasar batas domain input variabel, karena banyak kesalahan cenderung
terkonsentrasi di dekat nilai input yang ekstrem. Perpanjangan dari teknik ini adalah
pengujian ketahanan, di mana test case juga dipilih di luar domain input variabel, untuk
menguji ketahanan program terhadap input yang tidak diharapkan atau salah.
Testing from formal specifications
Menguji berdasar spesifikasi formal untuk test case fungsionalitas yang sudah ditetapkan
dalam user requirements.
Random testing
Pengujian dihasilkan murni secara acak, dengan menguji input secara random.

c. Teknik berbasis kode/ Code-based techniques

Control-flow-based criteria
Kriteria berbasis aliran kontrol ditujukan untuk mencakup semua pernyataan kode program
atau blok pernyataan dalam suatu program, atau kombinasi dari pernyataan-pernyataan kode
program. Beberapa kriteria seperti condition/decision coverage. Kriteria berbasis aliran
kontrol yang paling kuat adalah path testing, yang bertujuan untuk mengeksekusi path/jalur
dalam aliran kontrol masuk-ke-keluar dalam diagram alir suatu program.
Data flow-based criteria
Dalam pengujian berbasis aliran data, diagram alir kontrol dianotasi dengan informasi tentang
bagaimana variabel program didefinisikan, digunakan, dan dimatikan.
Reference models for code-based testing
Teknik pengujian berbasis kode menguji struktur kontrol program yang secara grafis diwakili
dalam diagram alur yang dihasilkan saat tahap desain sistem.
d. Teknik berbasis kesalahan/ Fault-based techniques
Teknik pengujian berbasis kesalahan menguji sistem untuk mengungkapkan kategori
kesalahan yang mungkin atau yang telah ditentukan sebelumnya.
Error guessing
Dalam teknik error guessing, kasus uji dirancang khusus oleh developer perangkat lunak
yang mencoba mencari tahu kesalahan yang masuk akal dalam program tertentu. Developer
memiliki keterampilan ini dari pengalaman kesalahan yang ditemukan dalam proyek
sebelumnya, serta keahlian engineering perangkat lunak yang dimiliki dalam berkarir.
Mutation testing
Mutan seringkali dikaitkan dengan perubahahan/modifikasi. Mutation testing merupakan
testing yang dilakukan dengan cara dimodifikasi perilaku atau logic dari program yang
sedang diuji, seperti merubah sintaksis atau logic. Mutation testing juga dapat dikategorikan
sebagai teknik berbasis kode.
e. Teknik berbasis penggunaan/ Usage-based techniques
Operational profile
Dalam pengujian untuk evaluasi keandalan, lingkungan pengujian harus mampu
mewakili/meniru lingkungan operasional perangkat lunak sedekat mungkin. Hal ini untuk
memastikan keandalan perangkat lunak di masa depan nantinya saat digunakan secara nyata
oleh pengguna.
f. Memilih dan menggabungkan teknik
Functional and structural
Teknik pengujian berbasis spesifikasi dan berbasis kode sering dianalogikan dengan
pengujian fungsional vs. struktural. Kombinasi dari teknik yang memiliki basis tersebut akan
mampu meningkatkan kualitas hasil uji.
Deterministic vs. random
Test case dapat dipilih dengan cara deterministik, dari teknik-teknik yang ada, atau diambil
secara acak untuk kebutuhan pengujian reliabilitas sistem.

TEST PROCESS
Konsep pengujian, strategi, teknik, dan ukuran perlu diintegrasikan ke dalam proses yang
ditetapkan dan dikendalikan yang dijalankan oleh tim penguji. Proses pengujian mulai dari
perencanaan pengujian hingga evaluasi hasil pengujian dilakukan untuk memberikan jaminan
bahwa tujuan pengujian akan tercapai dengan biaya yang efektif.