Testing SI – part.8-9

Senin, 9 November 2009

Kelas testing khusus grup A yang diadain tiap hari senin ini dipadetin materinya karena pertemuan sebelumnya yang harusnya ada pada tanggal 2 November ditiadakan karena waktu itu ada Dies Natalis UKDW. Untuk mencari kelas pengganti susah jadi solusinya adalah pemadatan materi jadi satu setengah materi per pertemuan untuk mengganti pertemuan yang hilang sekali.

Pertemuan kali ini membahas lanjutan prinsip debugging (TRAFFIC) yang sudah dijelaskan minggu lalu. Tapi materinya agak loncat-loncat dan sepesrtinya pemadatan materi tidak terlalu terasa karena temen-temen grup A sudah ngantuk karena juga sebelumnya sudah nunggu kelas yang diundur setengah jam karena ada pemadatan materi juga di prodi Teknik Informatika. Langsung masuk ke materi saja.

Tracking adalah melacak problem atau suatu masalah. Suatu masalah seperti ada daur hidupnya (life cycle). Seperti berikut

Problem Report bisa dibagi menjadi dua bagian yaitu change request dan bug report seperti di bawah ini

Apa perbedaan diantara keduanya, karena intinya adalah problem report. Penjelasan sebagai berikut:

• Bug Report — laporan kesalahan yang dilaporkan kepada pihak vendor atau owner yang membangun suatu produk tertentu bahwa produk tersebut terdapat kesalahan
• Change Request — problem report yang intinya bukan melaporkan kesalahan melainkan berisi permintaan perubahan atau penambahan fitur dari suatu produk. Misalnya: request untuk ponsel nokia seri X untuk fitur multitasking.

Sebenarnya masih susah untuk mengelompokkan apakah itu change request atau bug report, karena kadang kala orang yang meminta change request juga menyertakan bug report di dalamnya. Tinggal kita mengamati dan mencermati apa kasusnya. Dan problem report ini tidak hanya berlaku di hanya software saja tapi juga bisa hardware atau produk apapun.

Dalam mengirimkan problem report agar vendor yang menerima problem report kita itu mudah untuk mempelajari dan mereproduksi problem report, format apa saja yang dianjurkan untuk dilampirkan? Antara lain adalah sebagai berikut:

• product release — sertakan detail produk kita, misalnya kesalahan ada pada program IDE NetBeans. Sertakan product Release dari program tersebut. Ex: NetBeans IDE 6.7.2
• operating environment — lingkungan dimana program itu berjalan (misalnya kasusnya adalah tentang software). Misalnya anda mengalami problem ketika menjalankan sebuah aplikasi java atau aplikasi [dot]Net. Sertakan juga anda menggunakan JDK/JRE versi berapa atau [dot]Net framework versi berapa. Bahkan jika perlu beri detail device anda meliputi detail hardware dan sistem operasi yang digunakan lengkap dengan versinya atau serinya.
• problem history — jelaskan juga langkah-langkah sampai kamu menemukan suatu error, ini memudahkan untuk proses reproduksi.
• expected and experienced — beritahukan apa output yang kamu inginkan dan output yang kamu dapatkan sesuai dengan pengalaman kamu
• one line summary — di akhir report berilah satu baris deskripsi singkat tentang problemmu . Singkat tapi jelas.

Ketika kita menggunakan suatu aplikasi atau program tidak selalu berjalan mulus, setidaknya ada error atau fitur yang masih kurang di dalam aplikasi tersebut karena aplikasi yang terus direvisi semakin lama akan semakin kompleks juga. Sudah kita ketahui bahwa debugger adalah orang yang menemukan kesalahan yang kemudian kesalahan itu dilaporkan ke programmer. Lalu apa saja yang dilaporkan ke programmer, antara lain:

• event — menjelaskan pada event atau kondisi bagaimana suatu program itu menyebabkan kesalahan. Misalnya ketika memencet tombol close ketika program masih berjalan
• pesan error — memberitahukan peran error yang keluar dari event tadi
• hasil yang didapat — memberitahukan apakah output yang didapatkan ketika suatu event itu sudah dikerjakan
• hasil yang diharapkan — memberitahukan output apa yang diharapkan jika mengerjakan suatu event tertentu di aplikasi atau program

kemaren agak lupa tentang penjelasan pak willy ^^, sepertinya ada penjelasan tentang severity  (keparahan) yang isinya:

• enhancement — ciri khas ketika ada change request
• trivial — cuma masalah kecil. Misalnya aplikasi windownya tidak bisa di resize
• minor — masalah kecil yang tidak menimbulkan masalah lain
• normal — masalah standar, biasa dan sering ada
• major — ada fungsi yang hilang. Ex: word processor tidak bisa melakukan preview atau perintah cetak (print)
• critical — kehilangan data di memory
• showstopper — ada suatu bug yang belum selesai diperbaiki yang mengganggu release produk selanjutnya

Testing – part.7

Senin, 26 Oktober 2009

 

setelah mid test (mata kuliah ini kemaren tidak ada mid testnya) langsung masuk ke bahasan debugging. Pertemuan kali ini membahas tentang Why Program Failure. Bagaimana program bisa gagal. How failure come to be? Serta bagaimana kegagalan bisa terjadi. Langsung masuk ke topik pembahasan.

 

Dalam membuat program jangan selalu berpikiran program kita akan selalu berhasil, karena suatu program kemungkinan akan muncul bugs (kesalahan). Bisa saja program anda gagal karena memiliki bug dan bug bisa bermacam-macam.

 

Misalnya: suatu kasus kita membuat program dimana kita memanfaatkan waktu sistem dalam proses program berjalan. Kita membuat program itu di komputer kita. Lalu ketika program sudah jadi kita memberikan program yang sudah kita buat ke teman kita atau ke klien kita untuk dicoba atau di test. Nah, keitka dicoba ternyata error, karena setting waktu yang berbeda membuat sistem tidak berjalan.

 

Sekarang membahas tentang beberapa istilah atau terminologi yang cukup membingungkan…antara lain:

• Defect — ada suatu program yang keliru, ketika membuat program ada kesalahan pada program / code. Jadi defect adalah kekeliruan dalam pembuatan program, tapi dalam ukuran yang tidak terlalu besar.
• Infection — infeksi. Infection ini adalah kondisi dimana program dalam kondisi program yang tidak benar.
• Failure — suatu kondisi yang bisa dilihat yang bisa kita tangkap. Ada 1 atau beberapa code yang salah. Misalnya: pesan error.
• Flaws — kondisi cacat. Kondisi ini kebih banyak berhubungan dengan design yang tidak bagus. Jika terjadi cacat kemungkinan ganti total program (revisi) dan ini membutuhkan perubahan besar jika ingin memperbaikinya

 

keterangan tambahan untuk memperjelas:

• Berbeda dengan defect. Jika program ada defect tapi tidak terinfeksi maka akan baik-baik saja. Jika membuat program ada error dan tidak terhandle, kemungkinan terkena infeksi.
• Defect tidak failure jika tidak terjadi infection.
• Jika failure terus berarti program cacat (flaws). Bisa dibilang flaws adalah kumpulan dari failure.
• Dari defect bias muncul failure
• Tiap defect belum tentu failure.
• Tidak ada failure belum tentu tidak ada deffect.

 

Apa beda tester dengan analisis? Tugas tester adalah mengetest program. Jika program berjalan dengan benar maka diasumsikan program berjalan dan sukses, walaupun mungkin operasi salah. Tugas analis kerjanya lebih detil dari tester. Selain mengetes program yang berjalan, kemudian mencari kesalahannya.

 

Dalam proses debugging ada proses yang namanya traced back. Proses ini adalah semacam mengulang kembali proses pembangunan aplikasi. Setiap error bisa kita lacak, sete;ah ketemu errornya kemudian diperbaiki itulah yang dinamakan debugging.

 

How to debug? Bagaimana melakukan debug?

Yang pertama dilakukan adalah mencari error >> jika ada errro, setelah itu dicermati apakah berpengaruh pada design, error di program atau di design. Jika error pada design perbaiki dulu designnya >> perbaiki error >> re-test program. (regresi adalah bug yang ditimbulkan akrena perubahan).

 

Ada prinsip debugging (TRAFFIC)…akan dijelaskan minggu depan (2 minggu ke depan, karena senin 2 november 2009 tidak ada kelas testing SI khusus grup ‘A’ — ada acara dies natalis UKDW)

Testing – part.6

Senin, 5 Oktober 2009

lanjutan pertemuan yang lalu…masih membahas tentang jenis-jenis testing

Black Box Testing

testing yang menganggap software menjadi kotak hitam, tidak tau source code. Jadi, harus ada cara khusus untuk membukanya.

Carfa mengetest bisa dengan cara input – proses – output. Lalu outputnya dibandingkan dengan yang kita inginkan.

Test ini biasa disebut dengan input output testing atau disebut juga dengan data driven, karena semua test berdasarkan data (inputan).  Jumlah test case sangat banyak.

di dalam Black Box perlu membuat test case dalam unit test dibagi menjadi 3:

1.graph based testing — melihat software terdiri dari berbagai komponen yang dainggap menjadi node (objek satu berhubungan denga objek lain, nodes dengan garis). Bisa digunakan untuk pengujian. Cocok digunakan untuk pengetesan program sederhana

2.equivalen positioning — digunakan untuk meminimalkan test case. Mengumpulkan input dan dengan seminimal mungkin bisa mengeluarkan output yang banyak dan bervariasi. Jadi, jumlah test case bisa dikurangi

3.boundary value analysis — mengecek batasan, error terjadi pada batas. Misalnya membuat array sepanjang 5, lalu diisi 6 nilai maka akan error (array out of bonds). Jadi, mengetes batasan-batasan sistem.

White Box Testing

white box adalah kebalikan dari black box. Kita bisa melihat isinya, kita bisa melihat source codenya. Lalu apa yang dites? Yang dilihat struktur dan logikanya. Melihat dari kontrol struktur. Tujuan white box adalah memastikan semua kemungkinan atau kondisi sudah dijalankan. Lalu kenapa harus dikerjakan semua? Agar keseluruhan bagian telah dikerjakan dengan baik, semua jalur / path di tes. Apa masalah di white box? Jawabannya adalah jumlah path bisa sangat banyak dan error logic susah ditemukan

More detail (Path testing, Condition testing, Loop testing, etc) in slides…enjoy…

Senin, 5 Oktober 2009

lanjutan pertemuan yang lalu…masih membahas tentang jenis-jenis testing

Black Box Testing

testing yang menganggap software menjadi kotak hitam, tidak tau source code. Jadi, harus ada cara khusus untuk membukanya.

Carfa mengetest bisa dengan cara input – proses – output. Lalu outputnya dibandingkan dengan yang kita inginkan.

Test ini biasa disebut dengan input output testing atau disebut juga dengan data driven, karena semua test berdasarkan data (inputan).  Jumlah test case sangat banyak.

di dalam Black Box perlu membuat test case dalam unit test dibagi menjadi 3:

1. graph based testing — melihat software terdiri dari berbagai komponen yang dainggap menjadi node (objek satu berhubungan denga objek lain, nodes dengan garis). Bisa digunakan untuk pengujian. Cocok digunakan untuk pengetesan program sederhana
2. equivalen positioning — digunakan untuk meminimalkan test case. Mengumpulkan input dan dengan seminimal mungkin bisa mengeluarkan output yang banyak dan bervariasi. Jadi, jumlah test case bisa dikurangi
3. boundary value analysis — mengecek batasan, error terjadi pada batas. Misalnya membuat array sepanjang 5, lalu diisi 6 nilai maka akan error (array out of bonds). Jadi, mengetes batasan-batasan sistem.

White Box Testing

white box adalah kebalikan dari black box. Kita bisa melihat isinya, kita bisa melihat source codenya. Lalu apa yang dites? Yang dilihat struktur dan logikanya. Melihat dari kontrol struktur. Tujuan white box adalah memastikan semua kemungkinan atau kondisi sudah dijalankan. Lalu kenapa harus dikerjakan semua? Agar keseluruhan bagian telah dikerjakan dengan baik, semua jalur / path di tes. Apa masalah di white box? Jawabannya adalah jumlah path bisa sangat banyak dan error logic susah ditemukan

More detail (Path testing, Condition testing, Loop testing, etc) in slides…enjoy…

Testing SI -part.5

Senin, 28 September 2009

Pertemuan kelima membahas tentang High Level Testing. Banyak bahasan tentang high level testing di pertemuan kelima ini. Langsung saja to the point…

Stress Testing

Stress testing itu mahal, kenapa mahal? Karena sesuai tujuan testing yaitu mengetest seberapa handal suatu produk, jadi jika kita akan mengetest suatu produk dengan menggunakan stress test maka kita harus menggunakan produk aslinya yang sudah jadi lalu kita benar-benar mengetestnya.

Contohnya: suatu perusahaan melakukan stress test iPhone, mereka akan mengetes kekuatan iPhone dan klaim-klaim apple tentang iPhone (layar anti gores). Caranya? Perusahaan itu membeli iPhone, lalu salah satu tester menjatuhkan iPhone dari ketinggian, setelah dijatuhkan dinyalakan lagi, ternyata bisa. Walaupun layar hancur / pecah ternyata iPhone masih bias dinyalakan. Kemudian tester mencoba  anti goresnya dengan menggoreskan kunci, beton dan benda-benda tumpul atau tajam ke layar iPhone.

Stress test memang mahal, tapi dari situ kita benar-benar membuktikan apabila produk yang ditest itu bagus. Stress test sering dilakukandi luar negeri, karena mereka mempunyai modal yang banyak untuk melakukan stress test ini.

Usability Testing

Test yang ini untuk mengetest seberapa mudah suatu produk dipakai. Apakah produk itu user friendly dan memenuhi kriteria usability yang lain. Suatu produk di test seberapa mudah sistem digunakan oleh user, jadi begitu pertama kali digunakan user bisa langsung mengetahui bagaimana cara menggunakan produk tersebut.

Untuk mengetahui detail tentang kriteria usability, bisa diliat di www.useit.com. Situs itu dikelola oleh Jacob Nielson yang dikenal dengan bapak usability. Check it out…

Kita ambil contoh web, ada beberapa fokus utama dalam aplikasi berbasis web, yaitu:

• Berapa waktu yang dibutuhkan user untuk mengenali perintah dasar (time on task)
• Seberapa banyak akurasi (accuracy)
• Seberapa mudah user mengingat aplikasi web ini (recalla)
• Bagaimana tanggapan user terhadap aplikasi web itu (emotional response)

Setelah dinilai kemudian dirata-rata dan dari situ kita tau seberapa usable produk yang kita hasilkan. Lebih ditekankan di desain sistem.

Security testing

Teknologi semakin berkembang dan tidak akan habis, semakin kompleks. Begitu juga dengan security atau keamanan. Security test adalah suatu test untuk memastikan pengamanan sudah baik. Sebisa mungkin walaupun masih bisa dibobol, kita harus bisa membuat si pembobol itu lama membobolnya. Jadi kita bisa memperbaiki sistem kita dan pembobol itu tidak jadi  membobol sistem kita.

Banyak sekali cara atau metode yang digunakan dalam security testing ini. Antara lain:

• Brute Force…biasa digunakan untuk membobol password atau cryptograpy, tapi prosesnya lama karena menggunakan model random
• Fuzzing
• Reverse engineering…biasa digunakan untuk membobol aplikasi close source
• Data injection…caranya adalah dengan cara memasukkan data atau inputan secara random
• Sniffing…melacak dan mencuri…dan masih banyak lagi

Performance testing

Test ini berfungsi untuk mengukur performa sistem yang dibangun. Bisa menggunakan aplikasi benchmark atau profiler. Dengan benchmark kita bisa mengukur performa Hardisk, VGA card, browser, dan lain-lain. Bahkan, kita bisa melakukan perbandingan (compire) antar suatu perangkat lunak atau keras.

Compatibility testing

Test ini berhubungan dengan masalah konversi. Misalnya ada sebuah program lama, kemudian akan diganti dengan program yang baru. Apakah program baru bisa bekerja dengan program lama dan membaca data lama. Seperti aplikasi office Microsoft Office, kita membuat aplikasi format text di Ms.Office 2003 bisa dibuka di Ms.Office 2007, tapi jika kita membuka file 2007 tidak bisa dibuka di Ms.Office 2003. Masih banyak lagi contoh lainnya.

Recovery testing

Jika ada suatu produk mengeluarkan error, produk itu akan melakukan recovery. Contohnya dalam aplikasi corel draw. Jika waktu proses membuat desain tiba-tiba aplikasi error dan terpaksa harus ditutup dan kita belum menyimpan file tersebut atau belum update file tersebut maka aplikasi corel ini akan melakukan recovery. Ketika kita membuka corel kembali, setelah merestart atau refresh komputer kita maka corel akan memberikan dan menawarkan kepada kita apakah kita akan melakukan recovery. Jika iya, maka corel akan mengembalikan posisinya saat desain kita tadi sebelum error. Biasanya suatu produk yang mempunya fitur recovery bisa mempunyai setting recovery yang berbeda-beda.

Volume testing

Test ini mirip dengan stress testing. Bedanya adalah ini datanya besar. Contohnya: export atau import database…import data sebesar 10GB.

Scalability testing

Test ini untuk mengetest seberapa kuat sistem menghandle jika ada penambahan kebutuhan.

• Scale up (penambahan)…ex: menambah performa komputer dengan memaksimalkan penambahan slot RAM atau HD
• Scale out (pembagian)…ex: menambah web server karena ketersebaran, jadi dari 1 web server jadi 3 web server

Installation testing

Ada dua cara yaitu new installation atau upgrade. Aplikasi yang digunakan untuk membuat installer adalah NSIS, BitROCK dan lain-lain.

Acceptance testing

Ini sebenarnya seperti testing biasa, namun dilakukan oleh user yang bukan seorang developer ataupun tester. Jadi tester outsourcing dari user yang benar-benar awam jika perlu.

More detail in slides…enjoy…

Software Testing

software aplikasi, antarmuka, database yang sudah dibuat oleh para designer dan developer sangat mungkin masih mengandung kesalahan. sehingga masih mmbutuhkan penyempurnaan lagi atas kesalahan-kesalahan itu.

kesalahan-kesalahan itu biasa disebut dengan bug. jadi sering kita jumpai aplikasi-aplikasi yang ada embel-embel beta ataupun RC (release candidate). itu berarti aplikasi itu masih dalam tahap pengembangan dan perbaikan kesalahan-kesalahan untuk menyempurnakan aplikasi yang sudah dibuat. jadi tidak hanya membuat kemudian di release begitu saja. namun, setelah mereka membuat aplikasi baru maka mereka akan merevisi lagi aplikasi itu untuk acuan versi terbaru selanjutnya. jadi antara versi lama dan yang baru memang saling berhubungan.

for example: netbeans. nb adalah buatan sun microsystem, saat sun me-release produknya ini sering sekali menggunakan embel-embel beta ataupun RC, itu karena memang aplikasi itu masih dalam tahap pengembangan. jika sudah selesai mengembangkan aplikasi buatannya nb menggunakan kata final di produknya. misalnya nb 6.5 final.

ini kita lakukan juga saat kita membangun aplikasi menggunakan VFP ini. dalam membuat aplikasi yang wajib kita perhatikan dan pasti ada adalah database, GUI dan proses bisnisnya.

database sangat riskan, sangat penting. karena inilah satu-satunya media penyimpanan kita. tidak mungkin kita menyimpan semua data dalam suatu variabel karena selain boros tempat ini juga tidak praktis. nah apa yang di test di database. kita harus memperhatikan data apa yang akan disimpan dalam tabel kita. kita harus mengoptimalkan database yang kita rancang. misalnya kita akan membuat aplikasi sistem informasi kampus UKDW. tabel apa saja yang kita butuhkan. kita harus membuat blueprintnya, kita harus punya gambaran rqancangan database yang akan kita buat. pertama. jelas kita membuat table mahasiswa. banyak sekali property atau informasi yang ada dalam mahasiswa.

sebutkan contoh property mahasiswa?

nah tapi tidak mungkin kita memasukkan semua elemen itu dalam table kita. sebisa mungkin yang harus dimasukkan table ya dimasukkan dan yang tidak perlu dimasukkan ya tidak perlu dimasukkan.

yang perlu diperhatikan adalah

apakah tipe data yang dipilih sudah tepat

misalnya kita membuat table mahasiswa, yang menjadi primary keynya adalah NIM

kita harus mengoptimalkan field ini. yaitu dengan memilih tipe data yang benar, tipe data yang paling cocok adalah char. kenapa tidak menggukana number atau integer? kita menyimpan data NIM adalah untuk penanda unik untuk tiap mahasiswa, tujuannya adalah itu. sedangkan jika kita menggunakan number atau integer, berarti kita bisa menjumlahkan NIM. kita membuat field NIM dengan tipe data number atau integer memang bisa, tapi tidak optimal. tidak optimalnya bagaimana? jika pihak kampus akan melakukan penjumlahan mahasiswa berdasarkan NIMnya, maka mereka akan menjumlahkan NIMnya, dan jika NIMnya menggunakan integer maka akan banyak sekali hasilnya. selanjutnya adalah panjangnya atau widthnya. di kampus kita jumlah NIM ada 8 digit jadi sesuai dengan ketentuan itu kita menggunakan 8 digit itu untuk pengalokasian field NIM.

resiko jika menggunakan database atau table untuk proses penyimpanan data kita adalah kemungkinan tgerjadinya redundansi. redudansi bisa dibilang dengan penumpukan data yang berlebih dan dengan nilai yang sama.

GUI (graphical user interface)

mengapa kita harus membuat GUI?mengapa kita harus menggunakan GUI sebagai sarana input data yang utama?

karena kita membuat suati aplikasi atau sistem informasi ini adalah untuk memudahkan kita pemilik sistem informasi dalam mengelola proses bisnis yang sedang terjadi. jadi misalnya saat penginputan data mahasiswa. mahasiswa tidak mungkin memasukkan datanya langsung dengan cara masuk dan mengisi langsung data mereka ke table, memang bisa, tapi apakah mungkin seorang pembuat sistem informasi melakukan hal seperti itu. oleh karena itulah dibuat GUI untuk memudahkan user untuk menginputkan data mereka.

tidak asal membuat antarmuka. antarmuka yang baik adalah antarmuka yang memudahkan user bukan malah membingungkan user. dan usahakan sesimple mungkin. karena jika user berlama-lama bisa saja timbul kesalahan-kesalahan. oleh karena itu kita juga harus memikirkan itu agar kesalahan yang umum terjadi bisa diminimalkan. kita bisa meminimalkannya dengan cara pemilihan komponen GUI yang tepat.

misalnya untuk memasukkan jenis kelamin bisa ada banyak option komponen yang bisa dipakai. kita bisa menggunakan combo box, check box, radio button bahkan textbox. tapi manakah yang paling baik untuk digunakan menginputkan data tentang jenis kelamin?

proses bisnis juga sangat penting untuk dianalisa. ini juga berkaitan erat dengan database dan GUI yang telah kita buat.

aplikasi atau sistem informasi kita bisa dibilang handal jika sudah memenuhi requirement yang ada.

jika saat kita memanipulasi data dengan edit, misalnya menambah atau mengurangi stok kemudian kita simpan atau save. apakah stok yang tampil dan yang didatabase akan berkurang atau bertambah dan apakah sudah sesuai. semuanya harus dianalisa untuk meminimalkan atau bahkan menghilangkan kesalahan-kesalahan dalam pembuatan sistem informasi yang handal

software aplikasi, antarmuka, database yang sudah dibuat oleh para designer dan developer sangat mungkin masih mengandung kesalahan. sehingga masih mmbutuhkan penyempurnaan lagi atas kesalahan-kesalahan itu.

kesalahan-kesalahan itu biasa disebut dengan bug. jadi sering kita jumpai aplikasi-aplikasi yang ada embel-embel beta ataupun RC (release candidate). itu berarti aplikasi itu masih dalam tahap pengembangan dan perbaikan kesalahan-kesalahan untuk menyempurnakan aplikasi yang sudah dibuat. jadi tidak hanya membuat kemudian di release begitu saja. namun, setelah mereka membuat aplikasi baru maka mereka akan merevisi lagi aplikasi itu untuk acuan versi terbaru selanjutnya. jadi antara versi lama dan yang baru memang saling berhubungan.

for example: netbeans. nb adalah buatan sun microsystem, saat sun me-release produknya ini sering sekali menggunakan embel-embel beta ataupun RC, itu karena memang aplikasi itu masih dalam tahap pengembangan. jika sudah selesai mengembangkan aplikasi buatannya nb menggunakan kata final di produknya. misalnya nb 6.5 final.

ini kita lakukan juga saat kita membangun aplikasi menggunakan VFP ini. dalam membuat aplikasi yang wajib kita perhatikan dan pasti ada adalah database, GUI dan proses bisnisnya.

database sangat riskan, sangat penting. karena inilah satu-satunya media penyimpanan kita. tidak mungkin kita menyimpan semua data dalam suatu variabel karena selain boros tempat ini juga tidak praktis. nah apa yang di test di database. kita harus memperhatikan data apa yang akan disimpan dalam tabel kita. kita harus mengoptimalkan database yang kita rancang. misalnya kita akan membuat aplikasi sistem informasi kampus UKDW. tabel apa saja yang kita butuhkan. kita harus membuat blueprintnya, kita harus punya gambaran rqancangan database yang akan kita buat. pertama. jelas kita membuat table mahasiswa. banyak sekali property atau informasi yang ada dalam mahasiswa.

sebutkan contoh property mahasiswa?

nah tapi tidak mungkin kita memasukkan semua elemen itu dalam table kita. sebisa mungkin yang harus dimasukkan table ya dimasukkan dan yang tidak perlu dimasukkan ya tidak perlu dimasukkan.

yang perlu diperhatikan adalah apakah tipe data yang dipilih sudah tepat. misalnya kita membuat table mahasiswa, yang menjadi primary keynya adalah NIM. kita harus mengoptimalkan field ini. yaitu dengan memilih tipe data yang benar, tipe data yang paling cocok adalah char. kenapa tidak menggukana number atau integer? kita menyimpan data NIM adalah untuk penanda unik untuk tiap mahasiswa, tujuannya adalah itu. sedangkan jika kita menggunakan number atau integer, berarti kita bisa menjumlahkan NIM. kita membuat field NIM dengan tipe data number atau integer memang bisa, tapi tidak optimal. tidak optimalnya bagaimana? jika pihak kampus akan melakukan penjumlahan mahasiswa berdasarkan NIMnya, maka mereka akan menjumlahkan NIMnya, dan jika NIMnya menggunakan integer maka akan banyak sekali hasilnya. selanjutnya adalah panjangnya atau widthnya. di kampus kita jumlah NIM ada 8 digit jadi sesuai dengan ketentuan itu kita menggunakan 8 digit itu untuk pengalokasian field NIM.

resiko jika menggunakan database atau table untuk proses penyimpanan data kita adalah kemungkinan tgerjadinya redundansi. redudansi bisa dibilang dengan penumpukan data yang berlebih dan dengan nilai yang sama.

GUI (graphical user interface)

mengapa kita harus membuat GUI?mengapa kita harus menggunakan GUI sebagai sarana input data yang utama?

karena kita membuat suati aplikasi atau sistem informasi ini adalah untuk memudahkan kita pemilik sistem informasi dalam mengelola proses bisnis yang sedang terjadi. jadi misalnya saat penginputan data mahasiswa. mahasiswa tidak mungkin memasukkan datanya langsung dengan cara masuk dan mengisi langsung data mereka ke table, memang bisa, tapi apakah mungkin seorang pembuat sistem informasi melakukan hal seperti itu. oleh karena itulah dibuat GUI untuk memudahkan user untuk menginputkan data mereka.

tidak asal membuat antarmuka. antarmuka yang baik adalah antarmuka yang memudahkan user bukan malah membingungkan user. dan usahakan sesimple mungkin. karena jika user berlama-lama bisa saja timbul kesalahan-kesalahan. oleh karena itu kita juga harus memikirkan itu agar kesalahan yang umum terjadi bisa diminimalkan. kita bisa meminimalkannya dengan cara pemilihan komponen GUI yang tepat.

misalnya untuk memasukkan jenis kelamin bisa ada banyak option komponen yang bisa dipakai. kita bisa menggunakan combo box, check box, radio button bahkan textbox. tapi manakah yang paling baik untuk digunakan menginputkan data tentang jenis kelamin?

proses bisnis juga sangat penting untuk dianalisa. ini juga berkaitan erat dengan database dan GUI yang telah kita buat.

aplikasi atau sistem informasi kita bisa dibilang handal jika sudah memenuhi requirement yang ada.

jika saat kita memanipulasi data dengan edit, misalnya menambah atau mengurangi stok kemudian kita simpan atau save. apakah stok yang tampil dan yang didatabase akan berkurang atau bertambah dan apakah sudah sesuai. semuanya harus dianalisa untuk meminimalkan atau bahkan menghilangkan kesalahan-kesalahan dalam pembuatan sistem informasi yang handal

Testing SI – part.4

Senin, 14 September 2009

Pertemuan ke empat ini mebahas tentang testing strategies. Perlu membuat strategi dalam proses testing agar proses testing bisa berjalan dengan cepat sehingga produk segera jadi dan mengurangi pembengkakan biaya yang mungkin bisa terjadi. Pembahasan pertemuan kali ini sangat panjang dan detail…

Unit testing

Level paling bawah dalam bentuk fungsi atau method (OOP). Jika unit testing dilakukan dalam bentuk procedural akan lebih susah. Unit testing mengadopsi konsep OOP sehingga bisa diterapkan di berbagai bahasa. Berbagai bahasa sudah banyak yang menggunakan konsep OOP, karena sudah ada unit test. Di dalam unit test ada test case, test case berupa inputan. Inputan dibandingkan dengan data yang kita harapkan, jika output benar berarti implementasi berhasil.

Dalam unit test, cara membuatnya adalah membuat class yang baru yang berisi method-method untuk test. Pertama membentuk unit test baru test case. Banyak sekali unit test framework, contohnya: JUnit (java), CUnit (c#), dan lain-lain. Cara membuat test case tiap bahasa pemrograman bisa berbeda-beda. Untuk lebih detail tentang framework untuk unit test bisa search di wikipedia.

Keuntungan unit test…

• Jika suati saat kita akan ganti code, kesalahan bisa dicegah karena sudah ada test case dalam unit test.
• Mendukung test otomatis —– Bisa dibuat berbasis GUI dan bisa otomatis dijalankan
• Selagi coding bisa langsung menemui errornya —– Waktu coding, jalankan unit test…..agar error tidak menumpuk dan merugikan aspek yang lain (lower cost to fix)
• Waktu melakukan perubahan lebih mudah, karena ada kontrol.
• Fitur baru tidak akan merusak code sebelumnya
• Code yang mau bekerja akan bekerja di masa depan karena ada kontrol dan tidak error
• Akan lebih mudah jika ada programmer baru, karena di test case sudah ada dokumentasinya, jadi tidak perlu mengajari lagi.
• Semua implementasi bagus, karena semua sudah di test

Kekurangan unit test…

• Kerja programmer lebih besar
• Hanya berlaku pada unitnya saja
• Exhaustive input testing —– Kombinasi inputan sebanyak mungkin agar validasi complex
• Regression —– Penyebab yang ditimbulkan karena perubahan (code)
• Detail in slide…

Di SCM…(kalo ndak salah kepanjangannya Software Control Manager pa gitu)

Setiap perubahan akan dicatat atau didokumentasikan. Siapa yang mengubah, apa yang diubah, kapan diubah, dimana diubah akan diketahui. Semua bisa ditelusuri dan bahkan bisa di roll back.

Integration berguna untuk penggabungan modul. Misalnya sistem di kampus ingin mensinkronkan antara biro 1 dan biro 2, dengan integration kita bisa menggabungkan 2 modul tersebut.

Unit test berhasil tidak menjamin integration test sukses karena hubungannya dengan modul. Unit test bekerja dalam modul. Jika antar modul tidak bisa, harus integration.

BIG BANG

Di konsep ini, harus jadi semua baru diintegrasikan. Jadi sebelum mengintegrasikan, semua modul harus sudah jadi dan bisa diimplementasikan. Di konsep ini mengisolasi masalah susah, karena modul yang  digunakan sangat banyak. Ketika kita memperbaiki satu modul, bisa jadi yang lain menjadi salah. Oleh karena itu, konsep ini tidak cocok untuk pembangunan produk dalam skala besar.

INCREMENTAL

• Top down

Sistem yang terbesar, pecah menjadi yang lebih kecil-kecil dan semakin detail. Driver modul utama besar, ada modul dummy (modul blueprint yang diberi nilai kembalian). Modul dummy yang belum bisa digunakan disebut stubs

• Bottom up

Kebalikan dari top down, lebih aman. Dikerjakan dari bawah dulu, kemudian baru digabungkan dengan modul lain melalui driver.

• Detail incremental on slide…

Next week akan membahas tentang high level testing…WOW!!!

Senin, 14 September 2009

Pertemuan ke empat ini mebahas tentang testing strategies. Perlu membuat strategi dalam proses testing agar proses testing bisa berjalan dengan cepat sehingga produk segera jadi dan mengurangi pembengkakan biaya yang mungkin bisa terjadi. Pembahasan pertemuan kali ini sangat panjang dan detail…

Diagram segitiga

Unit testing

Level paling bawah dalam bentuk fungsi atau method (OOP). Jika unit testing dilakukan dalam bentuk procedural akan lebih susah. Unit testing mengadopsi konsep OOP sehingga bisa diterapkan di berbagai bahasa. Berbagai bahasa sudah banyak yang menggunakan konsep OOP, karena sudah ada unit test. Di dalam unit test ada test case, test case berupa inputan. Inputan dibandingkan dengan data yang kita harapkan, jika output benar berarti implementasi berhasil.

Dalam unit test, cara membuatnya adalah membuat class yang baru yang berisi method-method untuk test. Pertama membentuk unit test baru test case. Banyak sekali unit test framework, contohnya: JUnit (java), CUnit (c#), dan lain-lain. Cara membuat test case tiap bahasa pemrograman bisa berbeda-beda. Untuk lebih detail tentang framework untuk unit test bisa search di wikipedia.

Keuntungan unit test…

• Jika suati saat kita akan ganti code, kesalahan bisa dicegah karena sudah ada test case dalam unit test.
• Mendukung test otomatis

Bisa dibuat berbasis GUI dan bisa otomatis dijalankan

• Selagi coding bisa langsung menemui errornya

Waktu coding, jalankan unit test…..agar error tidak menumpuk dan merugikan aspek yang lain (lower cost to fix)

• Waktu melakukan perubahan lebih mudah, karena ada kontrol.
• Fitur baru tidak akan merusak code sebelumnya
• Code yang mau bekerja akan bekerja di masa depan karena ada kontrol dan tidak error
• Akan lebih mudah jika ada programmer baru, karena di test case sudah ada dokumentasinya, jadi tidak perlu mengajari lagi.
• Semua implementasi bagus, karena semua sudah di test

Kekurangan unit test…

• Kerja programmer lebih besar
• Hanya berlaku pada unitnya saja
• Exhaustive input testing

Kombinasi inputan sebanyak mungkin agar validasi complex

• Regression

Penyebab yang ditimbulkan karena perubahan (code)

• Detail in slide…

Di SCM…(kalo ndak salah kepanjangannya Software Control Manager pa gitu)

Setiap perubahan akan dicatat atau didokumentasikan. Siapa yang mengubah, apa yang diubah, kapan diubah, dimana diubah akan diketahui. Semua bisa ditelusuri dan bahkan bisa di roll back.

Integration berguna untuk penggabungan modul. Misalnya sistem di kampus ingin mensinkronkan antara biro 1 dan biro 2, dengan integration kita bisa menggabungkan 2 modul tersebut.

Unit test berhasil tidak menjamin integration test sukses karena hubungannya dengan modul. Unit test bekerja dalam modul. Jika antar modul tidak bisa, harus integration.

BIG BANG

Di konsep ini, harus jadi semua baru diintegrasikan. Jadi sebelum mengintegrasikan, semua modul harus sudah jadi dan bisa diimplementasikan. Di konsep ini mengisolasi masalah susah, karena modul yang  digunakan sangat banyak. Ketika kita memperbaiki satu modul, bisa jadi yang lain menjadi salah. Oleh karena itu, konsep ini tidak cocok untuk pembangunan produk dalam skala besar.

INCREMENTAL

• Top down

Sistem yang terbesar, pecah menjadi yang lebih kecil-kecil dan semakin detail. Driver modul utama besar, ada modul dummy (modul blueprint yang diberi nilai kembalian). Modul dummy yang belum bisa digunakan disebut stubs

• Bottom up

Kebalikan dari top down, lebih aman. Dikerjakan dari bawah dulu, kemudian baru digabungkan dengan modul lain melalui driver.

• Detail incremental on slide…

Next week akan membahas tentang high level testing…WOW!!!

Testing SI – part.3

Senin, 7 September 2009

Testing SI Chapter-3…

Proses testing yang biasa dilakukan oleh para tester-tester tidak selamanya berjalan mulus sesuai dengan SOP (Standard Operation Procedure) yang sudah ditetapkan. Testing juga ada gagalnya juga. Proses testing ini mengalami kegagalan karena tidak di support dari sisi manajemen.

Apa yang perlu disupport dan mengapa perlu disupport? Tester membutuhkan lingkungan yang kondusif agar proses testing bisa mencapai titik maksimal dan sukses, oleh karena itu bagaimana di sisi manajemen men-support tester untuk bisa memaksimalkan pekerjaannya. Testing bisa saja membosankan karena yang di test hanya itu-itu saja. Mereka membuka itu-itu saja, jadi bias saja tester merasa jenuh dengan apa yang mereka kerjakan. Berbeda dengan programmer yang selalu bertemu -dengan hal-hal yang baru.

Supportive Testing Environment

Testing membutuhkan lingkungan kerja yang kondusif agar proses testing bisa berjalan dengan maksimal oelh karena itu tester membutuhkan lingkungan kerja yang membantu untuk testing. Lingkungan kerja yang kondusif ini dibuat oleh bagian IT manajemen untuk membantu tester untuk melakukan proses testing lebih baik.

Management’s role:

• Membuat risk appetite —– Risk appetite…adalah jumlah resiko yang bisa diterima oleh pihak manajemen agar software atau produk yang dibuat bebas dari bugs (kesalahan). Jadi pihak manajemen juga harus mempersiapkan resiko terburuk dalam proses pembangunan suatu produk.

• Membuat definisi testing —– Bisa dibilang ini memberi definisi testing kepada para tester, agar mereka juga memahami paradigma testing di perusahaan, karena bisa jadi definisi dan prosedur standar proses testing di tiap perusahaan bisa berbeda, walaupun sedikit.

• Support to tester —– Memberikan support berupa fasilitas-fasilitas kepada tester, agar tester tidak merasa jenuh dengan pekerjaannya, misalnya pengadaan internet. Jadi sembari berisitirahat para tester bias browsing dan menjelajahi internet. Dari test yang diadakan salah satu dosen di perguruan tinggi di Australia, pekerja yang mengisi waktu istirahatnya dengan bermain internet atau bermain facebook, mempunyai produktifitas 9% lebih baik.

• Resource allocation for testing resource —– Memberikan resource-resource mengenai proses testing

• Processes and tools used —– Mempersiapkan dan menyediakan alat-alat yang digunakan tester untuk memperlancar proses kerjanya dan menjadi standar untuk semua tester yang lain.

Customer Dissatisfaction Gap:

• Spesification Gap —– Terjadi jika developer gagal membuat program atau program yang dibuat tidak lengkap atau juga gagal dalam proses pembangunan program

• Need Gap —– Program tidak sesuai dengan requirement. Program jadi, tapi tidak sesuai dengan kebutuhan pengguna. Biasanya terjadi jika proses requirement gagal

Mengapa terjadi gap sampai sekarang? Why gap exist?

• Tight schedule —– Waktu lama diperhitungkan. Karena faktor waktu juga sangat mempengaruhi dalam proses pembangunan. Mempengaruhi biaya yang dikeluarkan dan kualitas produk yang dihasilkan

• Limited budget —– jika budget yang disediakan minim, tidak perlu menambah tester
• Inadequet development and testing test —–Berkaitan dengan jumlah tester, waktu dan modul atau tugas yang harus diselesaikan

• Work processes that are prone to deffects —– Tidak ada panduan kerja atau tugas

Apa yang bisa dilakukan oleh tester:

• Menentukan apakah software sudah sesuai dengan spesifikasi (spesification gap)
• Menentukan apakah software sudah sesuai dengan kebutuhan user (need gap)
• Menjalankan keduanya. Manajemen harus membuat lingkungan tester dan user

Kesalahan dan kegagalan saat mendesain software bias dikarenakan pembuaatn keputusan tidak komplit dan software tidak sesuai dengan user (implementasinya).

Resiko dengan spek implementasi:

1. data problem —– ada masalah dengan data yang sedang akan diproses
2. incomplete data —– ada data yang kurang atau tidak komplit yang bias menyebabkan software tidak berjalan dengan mulus
3. incorrect data —– data yang salah, yang bias menyebabkan output yang dihasilkan dan proses juga salah
4. data expired —– data yang digunakan atau yang diolah adalah data yang sudah lama, sehingga walaupun bisa digunakan tapi sia-sia karena tidak terpakai dan kadaluarsa

Resiko yang muncul berhubungan dari kebutuhan user atau client kita, karena saat proses pembangunan dan design produk terlebih dahulu kita berkomunikasi dengan klien kita untuk masalah requirement yang ditetapkan oleh klien. Namun, tidak semua klien bisa memberikan requirement yang terbaik atas produk yang mereka inginkan. Inilah yang bisa mempengaruhi resiko-resiko yang muncul.

Kita bisa menimplementasikan spesifikasi tapi tidak berarti kita bisa memenuhi kebutuhan user. Bisa jadi ketika user membuat spesifikasi tapi tidak tahu apa fungsinya. Saat membuat spesifikasi, user bisa jadi tidak mengerti. Jadi, kita harus bisa menemukan kesalahan-kesalahan plus memberi solusinya.

Untuk lebih detail bisa diliat di file yang diupload di site pak Willy…

Testing SI – part.2

Senin, 31 Agustus 2009

Mata kuliah ini berhuungan dengan mata kuliah RPL, karena testing adalah bagian penting dalam pembangunan sebuah program atau aplikasi.

Tahap-tahap pembuatan software:

• Requirement…..Apa saja keinginan dan kebutuhan dari customer / user pada aplikasi yang kita buat

• Design…..Membuat rancangan aplikasi kita. Bisa dibilang ini tahap ini adalah tahap persiapan sebelum coding

• Coding…..Memulai developing program sampai jadi sebuah aplikasi

• Testing…..Aplikasi yang sudah jadiperlu di testing untuk menghilangkan bugs (kesalahan-kesalahan).

Testing juga bisa dilakukan sebelum memulai coding. Jadi bisa juga dilakukan pada saat tahap requirement atau design. Misalnya, jika requirement dari customer adalah customer menginginkan aplikasi yang kita buat itu tidak ada fitu back up data karena alas an tertentu. Namun, sebagai developer kita tau bahwa fitur itu penting, karena dampaknya akan terasa ketika dalam proses bisnis dan kita kehilangan data maka customer hanya bisa gigit jari. Jadi tetap perlu di tambahkan fitur back up data.

Ketika kita membuat program pasti ada masalah, tinggal bagaimana kita mencari dan menemukan masalahnya. Jadi, jangan sampai customer menemukan kesalahan atau masalah pada program yang kita buat ketika program kita sudah jadi. Oleh karena itu, proses testing sangat penting untuk menghindari adanya error pada program yang nantinya kita berikan pada customer. Testing sangat penting untuk program yang bagus.

Lalu apa setiap kita melakukan testing akan selalu sukses? Tidak sepenuhnya akan langsung berhasil begitu saja. Kegagalan dalam testing :

• Lack of testing…..Proses pengetesan yang terlalu lama. Ini merugikan kedua belah pihak. Baik di pihak developer dan pihak customer

• Using wrong strategies…..Teknik atau strategi yang digunakan salah.

• Too much to test…..Ketika kita membuat program yang kompleks maka banyak juga yang akan kita tes

Lalu…apa sih sebenarnya gunanya kita melakukan testing? Tujuan kita melakukan testing adalah (hanya) menemukan kesalahan dalam suatu program. Jadi itu lah tugas seorang tester. Kemudian setelah ditemukan kesalahannya, debugger mencari penyebab terjadinya kesalahan atau biasa disebut dengan debugging.

Testing SI – part.1

Senin, 24 Agustus 2009

Ini kelas pertama dan matakuliah pertama di semester 5 ini. Di matakuliah ini sempat terjadi kontroversi sebelum hari-H kelas pertama, karena jadwal di UP kelas ini mulai pada jam setengah 11, tapi saat melakukan registrasi mata kuliah ini dimulai jam setengah 12.

Aku yang termasuk terkecoh, dating jam setengah 12. pas masuk kelas, ternyata bener mulainya jam setengah 11. jadi telat 1 jam. Agenda hari itu Cuma perkenalan dan silabus serta pembentukan kelompok.

Dosen Testing SI ini namanya Pak Willy yang tak lain adalah dosen prodi TI. Setelah menunggu semua mahasiswa datang, termasuk yang telat, anak-anak dipersilahkan untuk pulang.

Tugas … Mahasiswa membentuk kelompok (4 orang), kemudian mencari artikel dan nanti di review (sesuai dengan silabus)