bab i sqa

12
BAB I PENDAHULUAN 1. Dasar-dasar Pengujian Perangat lunak Pentingnya pengujian perangkat lunak dan implikasinya yang mengacu pada kualit lunak tidak dapat terlalu ditekan karena melibatkan sederetan aktivitas produk terjadinya kesalahan manusia sangat besar dan arena ketidakmampuan manusia unt dan berkomunikasi dengan sempurna maka pengembangan perangkat lunak diiringi d aktivitas jaminan kualitas. Meningkatnya visibilitas (kemampuan) perangkat lunak sebagai suatu elemen sist yang muncul akibat kegagalan perangkat lunak, memotivasi dilakukannya perencan baik melalui pengujian yang teliti. Pada dasarnya, pengujian merupakan satu la proses rekayasa perangkat lunak yang dapat dianggap sebagai hal yang merusak d membangun. Sejumlah aturan yang berfungsi sebagai sasaran pengujian pada perangkat lunak 1. Pengujian adalah proses eksekusi suatu program dengan maksud menemukan kes 2. Test case yang baik adalah test case yang memiliki probabilitas tinggi unt kesalahan yang belum pernah ditemukan sebelumnya 3. Pengujian yang sukses adalah pengujian yang mengungkap semua kesalahan yan pernah ditemukan sebelumnya Sasaran itu berlawanan dengan pandangan yang biasanya dipegang yang menyatakan pengujian yang berhasil adalah pengujian yang tidak ada kesalahan yang ditemuk dikumpulkan pada saat pengujian dilakukan memberikan indikasi yang baik mengen reliabilitas perangkat lunak dan beberapa menunjukkan kualitas perangkat lunak keseluruhan, tetapi ada satu hal yang tidak dapat dilakukan oleh pengujian, ya dapat memperlihatkan tidak adanya cacat, pengujian hanya dapat memperlihatkan kesalahan perangkat lunak. Sebelum mengaplikasikan metode untuk mendesain test case yang efektif, perekay lunak harus memahami prinsip dasar yang menuntun pengujian perangkat lunak, ya Semua pengujian harus dapat ditelusuri sampai ke persyaratan pelanggan,ma k su d n ya

Upload: rizky-thape

Post on 21-Jul-2015

61 views

Category:

Documents


0 download

TRANSCRIPT

BAB I PENDAHULUAN 1. Dasar-dasar Pengujian Perangat lunak Pentingnya pengujian perangkat lunak dan implikasinya yang mengacu pada kualitas perangkat lunak tidak dapat terlalu ditekan karena melibatkan sederetan aktivitas produksi di mana peluang terjadinya kesalahan manusia sangat besar dan arena ketidakmampuan manusia untuk melakukan dan berkomunikasi dengan sempurna maka pengembangan perangkat lunak diiringi dengan aktivitas jaminan kualitas. Meningkatnya visibilitas (kemampuan) perangkat lunak sebagai suatu elemen sistem dan biaya yang muncul akibat kegagalan perangkat lunak, memotivasi dilakukannya perencanaan yang baik melalui pengujian yang teliti. Pada dasarnya, pengujian merupakan satu langkah dalam proses rekayasa perangkat lunak yang dapat dianggap sebagai hal yang merusak daripada membangun. Sejumlah aturan yang berfungsi sebagai sasaran pengujian pada perangkat lunak adalah :

1. Pengujian adalah proses eksekusi suatu program dengan maksud menemukan kesalahan 2. Test case yang baik adalah test case yang memiliki probabilitas tinggi untuk menemukan kesalahan yang belum pernah ditemukan sebelumnya 3. Pengujian yang sukses adalah pengujian yang mengungkap semua kesalahan yang belum pernah ditemukan sebelumnya Sasaran itu berlawanan dengan pandangan yang biasanya dipegang yang menyatakan bahwa pengujian yang berhasil adalah pengujian yang tidak ada kesalahan yang ditemukan. Data yang dikumpulkan pada saat pengujian dilakukan memberikan indikasi yang baik mengenai reliabilitas perangkat lunak dan beberapa menunjukkan kualitas perangkat lunak secara keseluruhan, tetapi ada satu hal yang tidak dapat dilakukan oleh pengujian, yaitu pengujian tidak dapat memperlihatkan tidak adanya cacat, pengujian hanya dapat memperlihatkan bahwa ada kesalahan perangkat lunak. Sebelum mengaplikasikan metode untuk mendesain test case yang efektif, perekayasa perangkat lunak harus memahami prinsip dasar yang menuntun pengujian perangkat lunak, yaitu:

Semua pengujian harus dapat ditelusuri sampai ke persyaratan pelanggan,ma k su d n ya

mengungkap kesalahan dari cacat yang menyebabkan program gagal. Pengujian harus direncanakan lama sebelum pengujian itu mulai, maksudnya semua pengujian dapat direncanakan dan dirancang sebelum semua kode dijalankan. Prinsip Pareto berlaku untuk pengujian perangkat lunak, maksudnya dari 80% kesalahan yang ditemukan selama pengujian dapat ditelusuri sampai 20% dari semua modul program. Pengujian harus mulai dari yang kecil dan berkembang ke pengujian yang besar, Selagi pengujian berlangsung maju, pengujian mengubah focus dalam usaha menemukan kesalahan pada cluster modul yang terintegrasi dan akhirnya pada sistem. Pengujian yang mendalam tidak mungkin karena tidak mungkin mengeksekusi setiap kombinasi jalur skema pengujian dikarenakan jumlah jalur permutasi untuk program menengah pun sangat besar. Untuk menjadi paling efektif, pengujian harus dilakukan oleh pihak ketiga yang independent . Dalam lingkungan yang ideal, perekayasa perangkat lunak mendesain suatu program computer, sebuah sistem atau produk dengan testabilitas dalam pikirannya. Hal ini memungkinkan individu yang berurusan dengan pengujian mendesain test case yang efektif secara lebih mudah. Testabilitas adalah seberapa mudah sebuah program computer dapat diuji. Karena sangat sulit, perlu diketahui apa yang dapat dilakukan untuk membuatnya menjadi lebih mudah. Procedural dan menggunakannya sebagai pedoman untuk menetapkan basis set dari jalur eksekusi. 2. Pengujian Black Box Dan White Box 2.1 Pengujian Black Box Black Box adalah metode pengujian perangkat lunak yang menguji fungsionalitas aplikasiyang bertentangan dengan struktur internal atau kerja . Pengetahuan khusus dari kode aplikasi / struktur internal dan pengetahuan pemrograman pada umumnya tidak diperlukan. Uji kasus dibangun di sekitar spesifikasi dan persyaratan, yakni, aplikasi apa yang seharusnya dilakukan. Menggunakan deskripsi eksternal perangkat lunak, termasuk spesifikasi, persyaratan, dan desain untukmenurunkan uji kasus. Tes ini dapat menjadi fungsional atau nonfungsional, meskipun biasanya fungsional. Perancang uji memilih input yang valid dan tidak

valid dan menentukan output yang benar. Tidak ada pengetahuan tentang struktur internal benda uji itu. Metode pengujian dapat diterapkan pada semua tingkat pengujian perangkat lunak: unit, integrasi, fungsional, sistem dan penerimaan. Ini biasanya terdiri dari kebanyakan jika tidak semua pengujian pada tingkat yang lebih tinggi, tetapi juga bisa mendominasi unit testing juga. 2.2 Pengujian White Box Ujicoba Whitebox merupakan metode desain uji kasus yang menggunakan struktur kontrol dari desain prosedural untuk menghasilkan kasus-kasus uji. Dengan menggunakan metode ujicoba whitebox, para pengembang software dapat menghasilkan kasus-kasus uji yang : Menjamin bahwa seluruh independent paths dalam modul telah dilakukan sedikitnya satu kali. Melakukan seluruh keputusan logikal baik dari sisi benar maupun salah. Melakukan seluruh perulangan sesuai batasannya dan dalam batasan operasionalnya. Menguji struktur data internal untuk memastikan validitas. BAB II KAJIAN TEORITIS Dengan melihat perbedaan dari kedua teknik pengujian perangkat lunak di atas, saya lebih cenderung untuk menggunakan teknik pengujian Black Box dalam melaksanakan tugas pengujian perangkat ini. Hal ini mengingat akan keterbatasan waktu yang diberikan oleh Bapak Zen Munawar selaku dosen mata kuliah Rekayasa Perangkat Lunak. Dalam kesempatan ini saya akan membahas suatu perangkat lunak yang digunakan untuk melakukan pendaftaran sebuah account dunia maya yaitu MSN dari Microsoft Cororation. Namun sebelum berlanjut kepada tahap pembahasan, tidak ada salah untuk membasa terlebih dahulu mengenai teknik pengujian Black Box, berikut uraiannya: Black Box pengujian adalah metode pengujian perangkat lunak yang menguji fungsionalitas aplikasiyang bertentangan dengan struktur internal atau kerja. Pengetahuan khususdari kode aplikasi / struktur internal dan pengetahuan pemrograman pada umumnya tidak diperlukan. Uji kasus dibangun di sekitar spesifikasi dan persyaratan, yakni, aplikasi apa yang seharusnya dilakukan.Menggunakan deskripsi eksternal perangkat lunak, termasuk spesifikasi, persyaratan, dan desain untukmenurunkan uji kasus. Tes ini dapat menjadi fungsional atau non-fungsional, meskipun biasanyafungsional. Perancang uji memilih input yang valid dan tidak valid dan menentukan output yang benar. Tidak ada pengetahuan tentang struktur internal benda uji itu.

Metode uji dapat diterapkan pada semua tingkat pengujian perangkat lunak: unit, integrasi, fungsional,sistem dan penerimaan. Ini biasanya terdiri dari kebanyakan jika tidak semua pengujian pada tingkatyang lebih tinggi, tetapi juga bisa mendominasi unit testing juga. 1. Black Box Testing Metode ujicoba blackbox memfokuskan pada keperluan fungsional dari software. Karna itu ujicoba blackbox memungkinkan pengembang software untuk membuat himpunan kondisi input yang akan melatihseluruh syarat-syarat fungsional suatu program. Ujicoba blackbox bukan merupakan alternatif dari ujicoba whitebox, tetapi merupakan pendekatan yang melengkapi untuk menemukan kesalahan lainnya, selain menggunakan metode whitebox.

Ujicoba blackbox berusaha untuk menemukan kesalahan dalam beberapa kategori, diantaranya : 1. Fungsi-fungsi yang salah atau hilang 2. Kesalahan interface 3. Kesalahan dalam struktur data atau akses database eksternal 4. Kesalahan performa 5. kesalahan inisialisasi dan terminasi

Tidak seperti metode whitebox yang dilaksanakan diawal proses, ujicoba blackbox diaplikasikan dibeberapa tahapan berikutnya. Karena ujicoba blackbox dengan sengaja mengabaikan struktur control, sehingga perhatiannya difokuskan pada informasi domain. Dengan mengaplikasikan ujicoba blackbox, diharapkan dapat menghasilkan sekumpulan kasus uji yang memenuhi kriteria berikut : 1. kasus uji yang berkurang, jika jumlahnya lebih dari 1, maka jumlah dari ujikasus tambahan harus didesain untuk mencapai ujicoba yang cukup beralasan 2. Kasus uji yang memberitahukan sesuatu tentang keberadaan atau tidaknya suatu jenis kesalahan, daripada kesalahan yang terhubung hanya dengan suatu ujicoba yang spesifik.

1.1 Equivalence Partioning

sekumpulan keadaan valid dan invalid untuk kondisi input. Biasanya kondisi input dapat partioning merupakan metode ujicoba blackbox yang membagi domain input dari program menjadi beberapa kelas data dari kasus ujicoba yang dihasilkan. Kasus uji penanganan single Equivalence yang ideal menemukan sejumlah kesalahan (misalnya : kesalahan pemrosesan dari seluruh data karakter) yang merupakan syarat lain dari suatu kasus yang dieksekusi sebelum kesalahan umum diamati. Equivalence partioning berusaha untuk mendefinisikan kasus uji yang menemukan sejumlah jenis kesalahan, dan mengurangi jumlah kasus uji yang harus dibuat. Kasus uji yang didesain untuk Equivalence partioning berdasarkan pada evaluasi dari ekuivalensi jenis/class untuk kondisi input. Class-class yang ekuivalen merepresentasikan berupa spesifikasi nilai numerik, kisaran nilai, kumpulan nilai yang berhubungan atau kondisi boolean.

class dapat didefinisikan dengan panduan berikut : 1. Jika kondisi input menspesifikasikan kisaran/range, maka didefinisikan 1 yang valid dan 2 yang invalid untuk equivalence class. 2. Jika kondisi input memerlukan nilai yang spesifik, maka didefinisikan 1 yang valid dan 2 yang invalid untuk Ekuivalensi equivalence class. 3. Jika kondisi input menspesifikasikan anggota dari himpunan, maka didefinisikan 1 yang valid dan 1 yang invalid untuk equivalence class. 4. Jika kondisi input adalah boolean, maka didefinisikan 1 yang valid dan 1 yang invalid untuk equivalence class. 2.1 Boundary Value Analysis Sejumlah besar kesalahan cenderung terjadi dalam batasan domain input dari pada nilai tengah. Untuk alasan ini boundary value analysis (BVA) dibuat sebagai teknik ujicoba. BVA mengarahkan pada pemilihan kasus uji yang melatih nilai-nilai batas. BVA merupakan desain teknik kasus uji yang melengkapi equivalence partitioning. Dari pada memfokuskan hanya pada kondisi input, BVA juga menghasilkan kasus uji dari domain output.

Panduan untuk BVA hampir sama pada beberapa bagian seperti yang disediakan untuk equivalence partitioning : 1. Jika kondisi input menspesifikasikan kisaran yang dibatasi oleh nilai a dan b, kasus uji harus dibuat dengan nilai a dan b, sedikit diatas dan sedikit dibawah a dan b.

2. Jika kondisi input menspesifikasikan sejumlah nilai, kasus uji harus dibuat dengan melatih nilai maksimum dan minimum, juga nilai-nilai sedikit diatas dan sedikit dibawah nilai maksimum dan minimum tersebut. 3. Aplikasikan panduan 1 dan 2 untuk kondisi output. Sebagai contoh, asumsikan tabel temperatur VS table tekanan sebagai output dari program analisis engineering. Kasus uji harus didesain untuk membuat laporan output yang menghasilkan nilai maksimum(dan minimum) yang mungkin untuk tabel masukan. 4. Jika struktur data program internal telah mendeskripsikan batasan (misal : array ditetapkan maks. 100), maka desain kasus uji yang akan melatih struktur data pada batasan tersebut.

Kebanyakan pengembang software secara intuitif melakukan BVA pada beberapa tingkatan. Dengan mengaplikasikan panduan diatas, ujicoba batasan akan lebih lengkap, selain itu memiliki kemungkinan pendeteksian kesalahan yang lebih tinggi.

3.1 Cause-Effect Graphing Techniques Caeuse-effect graphing merupakan desain teknik kasus ujicoba yang menyediakan representasi singkat mengenai kondisi logikal dan aksi yang berhubungan. Tekniknya mengikuti 4 tahapan berikut : 1. Causes (kondisi input), dan Effects (aksi) didaftarkan untuk modul dan identifier yang dtujukan untuk masing-masing. 2. Causes-effect graph. 3. Graph dikonversikan kedalam tabel keputusan. 4. Aturan tabel keputusan dikonversikan kedalam kasus uji. Versi sederhana dari simbol graph cause-effect seperti dibawah ini. Terdapat hubungan causes ci dengan effects ei. Lainnya merupakan batasan relationship yang dapat diaplikasikan pada causes maupun effects.

4.1 Comparison Testing Dalam beberapa situasi (seperti : aircraft avionic, nuclear power plant control) dimana keandalan suatu software amat kritis, beberapa aplikasi sering menggunakan software dan hardware ganda (redundant). Ketika software redundant dibuat, tim pengembangan software lainnya membangun

versi independen dari aplikasi dengan menggunakan spesifikasi yang sama. Setiap versi dapat diuji dengan data uji yang sama untuk memastikan seluruhnya menyediakan output yang sama. Kemudian seluruh versi dieksekusi secara parallel dengan perbandingan hasil real-time untuk memastikan konsistensi.

Dianjurkan bahwa versi independen suatu software untuk aplikasi yang amat kritis harus dibuat, walaupun nantinya hanya satu versi saja yang akan digunakan dalam sistem. Versi independen ini merupakan basis dari teknik black box testing yang disebut comparison testing atau back-toback testing. Ketika multiple implementasi dari spesifikasi yang sama telah diproduksi, kasus uji didesain dengan menggunakan teknik black box yang lain (misalkan equivalence partitioning) disediakan sebagai input untuk setiap versi dari software. Jika setiap outputnya sama, diasumsikan implementasinya benar, jika tidak, setiap versi di periksa untuk menentukan jika kerusakan terdapat pada satu atau lebih versi yang akan bertanggung jawab atas perbedaan tersebut. Jika setiap spesifikasi dari seluruh versi telah dibuat dalam kesalahan, maka seluruh versi akan merefleksikan kesalahan. Sebagai tambahan, jika setiap versi independent memberikan hasil identik, tetapi salah, ujicoba hasil dan kondisi akan gagal untuk mendeteksi kesalahan.

5.1 Ujicoba Untuk Sistem Real Time Karakteristik khusus untuk sistem realtime memberikan tantangan tersendiri ketika ujicoba dilaksanakan. Ketergantungannya dengan waktu, sifat alami dari beberapa aplikasi yang tidak sinkron, menambah kesulitan baru dan potensial sebagai elemen untuk ujicoba dengan waktu beragam. Tidak hanya ujicoba whitebox maupun blackbox, tetapi juga ketepatan waktu pengiriman data dan pemrosesan paralel.

Contohnya software realtime yang mengontrol mesin fotocopy, yang dapat menerima interupsi dari operator (berupa penekanan tombol RESET atau DARKEN ) dengan tanpa kesalahan ketika mesin sedang berjalan (COPYING state). Operator yang sama akan menginterupsi, ketika mesin nberada dalam posisi jamned. Sebegai tambahan, keterkaitan antara software real time dengan perangkat keras pendukungnya juga dapat menyebabkan masalah dalam ujicoba. Ujicoba software harus mempertimbangkan kesalahan perangkat keras yang disebabkan karena pemrosesan software. Belum ada uji kasus yang komprehensif yang dikembangkan untuk sistem realtime, tetapi 4 langkah strategi berikut dapat dilaksanakan :

1. Task Testing, yaitu dengan mengujicobakan setiap task secara independen. Dalam hal ini metode whitebox dan blckbox testing dapat digunakan untuk menemukan kesalahan logika dan kesalahan fungsional, tetapi untuk kesalahan ketepatan waktu dan prilaku software (timing or behavioral errors), tidak dapat terdeteksi. 2. Behavioral Testing, dengan menggunakan model sistem dengan CASE tool, memungkinkan untuk mensimulasikan prilaku sistem realtime dan menentukannya sebagai konsekwensi dari peristiwa eksternal. Aktivitas analisis ini dapat dilaksanakan sebagai dasar untuk desain kasus uji yang diadakan ketika sebuah sistem realtime berhasil dibuat. Dengan menggunakan teknik yang sesuai (seperti equivalence partitioning), event dikategorikan (misalnya : interrupts, control signals, data), misalkan event pada sebuah buah mesin fotocopy dapat berupa interupsi dari user (reset counter), interupsi mekanikal (paper jamned), interupsi sistem (toner low), dan kesalahan bentuk (overheated). Setiap kesalahan yang terjadi diuji secara individual, dan prolaku executable sistem diperiksa. Prilaku software diperiksa untuk menentukan apakah terdeteksi kesalahan prilaku sistem 3. Intertask Testing, ketika sebuah kesalahan dari individual task berhasil diisolasi, ujucoba berlanjut kepada kesalahan pada waktu yang terkait. Task yang tidak sinkron yang berkomunikasi dengan task lainnya diuji dengan beberapa data dan pemrosesan untuk menentukan apakah kesalahan antar task akan terjadi. Sebagai tambahan task yang berkomunikasi via antrian pesan atau penyimpanan data, diujikan untuk menemukan kesalahan ukuran penyimpanan 4. System Testing, software dan hardware telah disatukan dan diujikan dalam uji sistem sebagai satu kesatuan. Uji ini dilakukan untuk menemukan kesalahan pada software/hardware interface.

6.1 Automated Testing Tools Dikarenakan ujicoba software menghabiskan sekitar 40% dari total usaha yang diperlukan untuk sebuah proyek pengembangan software, maka tools tools yang dapat mengurangi waktu uji sangat dibutuhkan. Dengan melihat manfaat potensialnya, maka dibentuklah generasi pertama dari automated test tools. Miller mendeskripsikannya menjadi beberapa kategori, diantaranya : 1. Static Analyzer, program sistem analisis ini mendukung untuk pembuktian dari pernyataan tanpa bukti statis, perintah-perintah yang lemah dalam struktur program dan format. 2. Code Auditors, sebuah filter dengan kegunaan khusus yang digunakan untuk memeriksa kualitas software untuk memastikan bahwa software tersebut telah memenuhi standars pengkodean minimum 3. Assertion Processors, sistem preprocessor/postprocessor ini digunakan untuk memberitahukan programmer dengan menyediakan klaim, yang disebut assertion, yaitu mengenai suatu perilaku program yang benar-benar ditemukan saat pelaksanaan program riil

4. Test File Generators, merupakan pembangun processor, dan dipenuhi dengan definisi awal nilai, file masukan yang serupa untuk program yang sedang diujikan. 5. Test Data Generators. merupakan sistem analisis otomatis yang membantu pengguna aplikasi dalam memilih data uji yang menyebabkan program berperilaku khusus 6. Test Verifiers, tool ini mengukur cakupan uji internal, terkadang berhubungan dengan uji struktur control dari objek uji, dan melaporkan cakupan nilai untuk para ahli jaminan kualitas 7. Test Harnesses. Tools ini mendukung pemrosesan uji coba dengan (1) meng-instal program kandidat dalam lingkungan uji, (2) berikan input data, dan (3) simulasikan dengan menggunakan stubs perilaku dari modul-modul subordinat 8. Output Comparators, tool ini membuatnya sangat memungkinkan untuk membantingkan sekumpulan output dari suatu program dengan sekumpulan output dari proses sebelumnya(yang telah diarsipkan) untuk menentukan perbedaan diantara keduanya Dunn menambahkan tool otomatis diatas, dantaranya : 1. Symbolic Execution System, tool ini penampilkan ujicoba program dengan menggunakan input aljabar, dari pada nilai data numerik,. Software yang diuji akan menguji satu class data uji dari pada satu kasus uji spesifik. Output yang dihasilkan dalam bentuk aljabar dan dapat dibandingkan dengan output yang diharapkan yang telah ditulis dalam bentuk aljabar 2. Environment Simulator, merupakan tool untuk sistem berbasis komputer khusus, yang mampu untuk menguji model lingkungan eksternal dari suatu software realtme, dan mensimulasikan kondisi operasi sesungguhnya secara dinamis. 3. Data Flow Analyzer, tool ini melacak aliran data yang melewati sistem, dan berusaha untuk menemukan data reference yang belum didefinisikan , peng-indeks-an yang salah, dan kesalahan data terkait lainnya.

BAB III PEMBAHASAN Dalam pembuatan sebuah account di dunia maya, terlepas dari perusahaan apapun pasti akan selalu meminta verifikasi data yang sangat kompleks dengan system keamanan yang super ketat. Sehingga seseorang sangat tidak mungkin untuk mempunyai dua account yang berbeda dengan nama user yang sama (terutama sebuah account yang menggunakan alamat email sebagai user id).

Berikut ini saya mencoba untu menguji sebuah perangkat lunak dalam pembuatan sebuah account di dunia maya. saya akan mencoba menguji MSn (Windows Live) dari sebuah perusahaan raksasa milik Microsoft Corporation. Gambar di atas menunjukan halaman awal sebuah pendaftaran account MSn (Windows Live), dimana user diminta untuk mengisi sebuah form tanpa terkecuali.

Ketika saya mencoba untuk mengsi email address dengan kalimat sembarang maka muncullah sebuah notifikasi yang menyatakan untuk mengisi alamat email dengan benar. Berikut notifikasi yang muncul Please enter your email address in the format [email protected]. Dengan munculnya notifikasi di atas, maka system yang dibangun MSn sangat peka terhadap penulisan alamat email yang invalid. Hal ini dapat memperkecil kemungkinan bagi seseorang untuk membuat sebuah account yang asal-asalan.

saya mencoba memasukan alamat email dengan nama piksi_ganesha dengan password yang hanya terdiri dari 3 karakter saja. Lagi-lagi system menolak dan keluar notifikasi: Please enter your email address in the format [email protected] Dan Your password must be longer than 5 character Hal ini mengindikasikan bahwa tidak ada alamat email dengan nama piksi_ganeshaserta mengindikasikan bahwa password minimal terdiri dari 5 karakter atau lebih.

Ketika saya mencoba untuk memasukan alamat email yang valid dengan jumlah password yang terdiri lebih dari 5 karakter, barulah system menerimanya dan keluar notifikasi sebagai berikut: After you sign up, we will send you a message with alink to verify this ID Hal ini mengindikasikan bahwa alamat yang kita masukan benar dan akan dikirimkan sebuah pesan ke alamat email tersebut yang telah dibubuhkan link untuk menferifikasi ID yang dibuat.

Setelah itu saya mencoba mengisi nama dengan dengan inputan sebagai berikut: First name : Tugas

Last name

: RPL

Proses ini berjalan dengan lancer. Hal ini mengindikasikan bahwa record First name dan Last name dan diisi dengan karakter sembarang (sesuai dengan keinginan user). Begitupun dengan record Country/region dan State. Namun, ketika saya mengisi record Postal code dengan karakter sembarang, system menolaknya dan keluar notifikasi berikut: Verify that you have entered the correct information

Namun ketika memasukan alamat pos yang benar, system menerimanya tanpa kendala sedikitpun dan bias lanjut mengisi form selanjutnya. Berarti untuk record Postal code system sangat sensitive terhadap penulisan kode pos yang invalid. Secara tidak langsung berarti system telah mempunyai basis data pos kode seluruh negara di belahan penjuru dunia.

Setelah menentukan jenis kelamin, user harus memasukan tahun lahir. saya mencobanya dengan memasukan angka 2 saja. Lagi-lagi system menolak dan keluar notifikasi sebagai berikut: 2 isnt correct. Verify that you have entered the correct information Secara logika memang tidak mungkin seseorang yang lahir pada tahun 2 Masehi masih hidup dan membuat sebuah account di dunia maya pada tahun 2011. Hal ini mengindikasikan bahwa system sangat sensitive.

Setelah semua data di-input dengan benar, user dapat melanjutkan kepada tahap yang terakhir yaitu memasukan karakter khusus yang tampil di layar. saya mencoba dengan memasukan beberapa karakter yang tidak sesuai dengan yang ada di gambar. Lagi-lagi system menolak dan keluar notifikasi sebagai berikut: Please enter all the characters you see. Dalam penulisan karakter khusus ini, system sangatlah sensitive bahkan terhadap penulisan antara huruf yang besar dan kecil. Sehingga user dituntut untuk sangat hati dalam memasukan

karakter khusus ini. Karena jika user melakukan kesalahan sebnyak 3 kali berturut-turut, maka user harus memulai registrasi dari awal.

Barulah setelah mengisikan karakter khusus dengan baik dan benar, maka proses registrasi berhasil dan dapat diterima oleh system. Muncullah notifikasi yang menyatakan bahwa registrasi telah berhasil dan system akan mengirimkan verifikasi kepada alamat email yang didaftarkan. Berikut notifikasi yang muncul: Verify your email address You have created [email protected] as your Windows Live ID, but it needs to be verified before you can use it. To verify, you can check your email at [email protected] and follow the instruction in the message we sent you. You can get to Windows Live account at any time to change Windows Live ID Selain itu, maka nama yang kita daftarkan pada form registrasi tadi akan muncul di pojok kanan atas halaman verifikasi ini. Sebagai contoh, karena tadi kita memasukan nama Tugas RPL maka nama tersebut tampil di pojok kanan atas halaman ini. Maka selesailah semua tahap dalam pembuatan account di dunia maya ini. Hal ini berlaku bagai pembuatan account yang lainnya. Semoga bermanfaat.

DAFTAR PUSTAKA http://www.teknologi.kompasiana.com/terapan/2011/3/4/white-box-testing/ http://www.teknologi.kompasiana.com/terapan/2010/3/4/black-box-testing/ http://www.Ilmukomputer.com/2011/ http://www.google.com