7
LANDASAN TEORI
2.1 Teori-teori Dasar/Umum
Teori-teori umum yang menjadi dasar penulisan adalah sebagai berikut:
2.1.1 Data
Data berasal dari bahasa Latin “datum” yang berarti “sesuatu yang diberikan”. Dalam penggunaan sehari-hari, data berarti suatu pernyataan yang diterima secara apa adanya. Pernyataan yang dimaksud di atas adalah hasil dari pengukuran atau pengamatan suatu variabel yang bentuknya dapat berupa angka, kata-kata, gambar, grafik, tabel ataupun gabungan dari semuanya.
Menurut KBBI online (kbbi.web.id/data), data adalah keterangan yg benar dan nyata; keterangan atau bahan nyata yg dapat dijadikan dasar kajian (analisis atau kesimpulan).
Menurut Rainer and Casey (2011:10), data mengarahkan pada deskripsi dasar suatu barang, kejadian, aktivitas, dan transaksi yang tercatat, terklasifikasi, dan tersimpan tetapi belum tersusun untuk menyampaikan makna tertentu. Data dapat berupa angka, huruf, figure, suara, atau gambar.
Berdasarkan pendapat para ahli di atas, dapat disimpulkan bahwa data adalah segala sesuatu yang diperoleh dari hasil pengamatan atau pengukuran pada kondisi yang sebenarnya, dapat berupa angka, gambar, grafik, tabel, atau kalimat yang belum memiliki makna atau arti tertentu.
2.1.2 Informasi
Menurut KBBI online (kbbi.web.id/informasi), informasi adalah penerangan, pemberitahuan, kabar atau berita tentang sesuatu.
Menurut Whitten, Bentley and Dittman (2007:21), informasi adalah data yang telah diolah dan disusun dengan pengolahan dan keahlian dengan tujuan tertentu. Akhirnya, keahlian dengan tujuan tertentu sangat penting untuk didefinisikan − orang-orang
menyediakan tujuan dan keahlian yang menghasilkan informasi yang benar.
Menurut Rainer and Casey (2011:10), informasi mengarahkan pada data yang telah disusun agar memiliki makna dan nilai untuk penerima.Penerima dapat menafsirkan makna dan menarik kesimpulan dan maksud dari informasi tersebut.
Informasi yang berkualitas harus memenuhi beberapa faktor, menurut Budi Sutedjo Dharma Oetomo (2002: 16 -17) faktor tersebut antara lain:
• Keakuratan dan teruji kebenarannya.
Informasi harus bebas dari kesalahan-kesalahan dan tidak menyesatkan.
• Kesempurnaan informasi
Informasi disajikan dengan lengkap tanpa pengurangan, penambahan, dan pengubahan.
• Tepat waktu
Infomasi harus disajikan secara tepat waktu, karena menjadi dasar dalam pengambilan keputusan.
• Relevansi
Informasi akan memiliki nilai manfaat yang tinggi, jika informasi tersebut dapat diterima oleh mereka yang membutuhkan.
• Mudah dan murah
Apabila cara dan biaya untuk memperoleh informasi sulit dan mahal, maka orang menjadi tidak berminat untuk memperolehnya, atau akan mencari alternatif substitusinya.
Berdasarkan pendapat para ahli di atas, dapat disimpulkan bahwa informasi adalah data yang telah diolah dan disusun sedemikian rupa sehingga memiliki suatu makna yang bermanfaat dan memiliki nilai bagi penerimanya.
2.1.3 Sistem
Menurut Satzinger (2005:6), sistem adalah kumpulan komponen yang saling berhubungan dan memiliki fungsi yang sama untuk mencapai suatu tujuan tertentu.
Menurut KBBI online (kbbi.web.id/sistem), sistem adalah perangkat unsur yang secara teratur saling berkaitan sehingga membentuk suatu totalitas.
Menurut Whitten, Bentley and Dittman (2007:6), sistem adalah sekelompok komponen yang saling berkaitan dan berfungsi bersama-sama untuk mencapai hasil yang diinginkan.
Berdasarkan pendapat para ahli di atas, dapat disimpulkan bahwa sistem adalah kumpulan perangkat, komponen dan prosedur yang saling berkaitan dan tersusun secara sistematis untuk mencapai suatu tujuan tertentu.
2.1.4 Sistem Informasi
Menurut Whitten, Bentley and Dittman (2007:6), sistem informasi adalah kumpulan orang, data, proses, tampilan informasi, dan teknologi informasi yang saling berkaitan untuk mendukung dan meningkatkan fungsi bisnis sehari-hari dan juga mendukung kebutuhan problem-solving dan decision-making bagi manajemen dan user.
Menurut Satzinger (2005:7), sistem informasi adalah kumpulan komponen yang saling berkaitan yang mengumpulkan, mengolah, menyimpan dan menyediakan sebagai hasil dari kebutuhan informasi untuk menyelesaikan tugas-tugas bisnis.
Berdasarkan pendapat para ahli di atas, dapat disimpulkan bahwa sistem informasi adalah sekumpulan komponen berupa orang, data, proses, informasi dan infrastruktur teknologi informasi yang saling berkaitan satu sama lain untuk memenuhi tujuan atau hasil tertentu.
2.1.5 Proses Bisnis
Menurut Monk and Wagner (2009:1), proses bisnis adalah sekumpulan kegiatan – kegiatan yang melakukan satu macam atau lebih input dan menciptakan suatu output yang memiliki nilai bagi perusahaan.
Menurut Considine, B. et al. (2010:744), proses bisnis adalah sekumpulan aktivitas yang bekerja antar satu dengan yang lain pada perusahaan, untuk mencapai tujuan perusahaan yang biasanya didefinisikan untuk mencapai kebutuhan atau kepuaasan customer.
Berdasarkan pendapat para ahli di atas, dapat disimpulkan bahwa proses bisnis adalah sekumpulan aktivitas baik pekerjaan atau kegiatan yang saling berhubungan satu sama lain dan menghasilkan tujuan dan nilai tertentu pada perusahan.
2.1.6 Enterprise Resource Planning (ERP)
Menurut Leon (2008:29), ERP adalah sekumpulan perangkat dan proses yang bertujuan untuk mengintegrasikan bagian – bagian dan fungsi dalam perusahaan menjadi suatu sistem komputer.
Menurut Rainer. et al. (2007:248), ERP mengintegrasikan perencanaan, manajemen, dan penggunaan semua sumber daya dari organisasi.
Menurut Monk and Wagner (2009:239), ERP adalah sebuah sistem yang membantu untuk mengatur proses bisnis seperti marketing, produksi, pembelian, dan accounting dalam suatu kesatuan yang terintegrasi.
Berdasarkan pendapat para ahli di atas, dapat disimpulkan bahwa ERP adalah sebuah sistem komputer terintegrasi yang mengatur berbagai modul yang ada dalam proses bisnis dan aktivitas pada perusahaan antara lain procurement, sales, finance, accounting dan human capital management.
2.2 Teori-teori Khusus 2.2.1 Web-based Systems
Menurut Perry (2006:799), web-based systems adalah sistem yang menggunakan internet, intranet, dan extranet. Internet adalah kumpulan jaringan yang terhubung secara worldwide. Intranet adalah jaringan pribadi yang ada di perusahaan yang menggunakan aplikasi berbasis web. Extranet adalah jaringan pribadi yang memungkinkan akses eksternal ke customer atau ke supplier menggunakan aplikasi berbasis web.
Web-based systems memiliki browser yang disimpan pada client. Client tersebut dihubungkan dengan server baik dengan jaringan seperti local area network (LAN) atau wide area network (WAN), ataupun dengan koneksi jarak jauh (remote connection).
2.2.2 Testing
Menurut standar ANSI/IEEE 1059, software testing adalah proses menganalisa suatu entitas software untuk mendeteksi perbedaan antara kondisi yang ada dengan kondisi yang diinginkan (defects/error/bugs) dan mengevaluasi fitur-fitur dari entitas software.
Menurut Galin (2004), software testing adalah proses formal yang dilakukan oleh tim testing terhadap suatu unit software atau beberapa unit software yang terintegrasi atau paket software yang diperiksa secara keseluruhan dengan menjalankan program pada komputer.
2.2.3 Software Testing Process
Menurut Perry (2006:56), ada 7 langkah proses melakukan software testing yaitu:
1. Organizing for Testing a. Define test scope
Menentukan tipe dari testing yang akan dilakukan.
b. Organize the test team
Menentukan tim yang akan melakukan testing berdasarkan tipe dari testing yang telah ditentukan.
c. Access development plan and status
Prasyarat unutk membangun test plan yang akan digunakan untuk mengevaluasi software implementation plan.
Tujuan dari Organizing for testing adalah untuk menentukan ruang lingkup testing dan menentukan siapa yang melakukan testing.
2. Developing the Test Plan a. Perform risk analysis
Mengidentifikasi resiko-resiko testing. b. Write the test plan
Membentuk perencanaan testing.
Tujuan dari tahap ini adalah untuk merencanakan bagaimana testing dilakukan dan menentukan tujuan – tujuan testing secara spesifik. 3. Verification Testing
a. Test software requirements
Persyaratan yang tidak lengkap, tidak akurat, dan tidak konsisten mampu menimbulkan kegagalan pada sistem. Dengan verification testing, tester harus menentukan persyaratan yang akurat dan lengkap sehingga tidak bertentangan antara satu dengan lainnya. b. Test software design
Melakukan testing terhadap desain internal dan eksternal suatu sistem.
c. Test software construction
Melakukan testing terhadap sistem yang dibangun dengan proses coding manual yang rentan error dan perlu diverifikasi lebih lanjut. Tujuan dari verification testing adalah memastikan apakah telah membangun sistem yang benar.
4. Validation Testing
a. Perform Validation testing
Melakukan testing terhadap kode dalam kondisi dinamis.
b. Record test results
Mendokumentasikan hasil testing tersebut. Tujuan dari validation testing adalah memastikan apakah telah membangun sistem dengan benar dan sistem bekerja sesuai dengan yang diharapkan.
5. Analyzing and Reporting Test Results a. Analyze the test results
Mempelajari hasil testing dan menentukan apa yang akan dilakukan selanjutnya.
b. Develop test reports
Membuat laporan testing yang dilakukan, baik dalam bentuk lisan maupun tertulis.
Tujuan dari tahap ini adalah untuk menentukan apa yang telah dipelajari setelah melakukan testing dan memberi informasi beserta saran dari tester untuk pihak lain.
6. Acceptance and Operational Testing a. Perform acceptance testing
Acceptance testing memungkinkan pengguna sistem untuk mengevaluasi penerapan dan
penggunaan sistem dalam melaksanakan fungsi pekerjaan sehari-hari.
b. Test software installation
Setelah test team memastikan sistem telah siap, kemampuan untuk menjalankan sistem di lingkungan perusahaan juga perlu di-tes.
c. Test software changes
Jika terjadi perubahan pada sistem, test plan juga perlu dirubah dan dampak perubahan pada sistem perlu di-tes dan dievaluasi.
Tujuan dari tahap ini adalah untuk menentukan bahwa sistem telah siap digunakan dan apabila terjadi perubahan sewaktu-waktu, sistem tetap dapat bekerja secara efektif dan efisien.
7. Post-Implementation Analysis
Perbaikan testing dapat dicapai dengan mengevaluasi efektivitas testing pada akhir setiap proses software testing. Tujuan dari tahap ini adalah untuk menentukan apakah testing sudah dilakukan dengan benar atau belum. Jika belum, perubahan testing perlu dilakukan sehingga proses testing berikutnya dapat berjalan lebih efektif dan efisien.
2.2.4 Failure Mode and Effect Analysis (FMEA)
Menurut Black (2009:32), Failure Mode and Effect Analysis (FMEA) adalah teknik untuk mempelajari dan memprioritaskan kemungkinan terjadi resiko atas kegagalan dan pengurangan kualitas pada fungsi, fitur, attribute, behavior, komponen, dan interface suatu sistem. FMEA juga menyediakan pencegahan terjadinya kegagalan dan proses pelacakan atas perbaikan yang dilakukan. Berikut adalah contoh tabel FMEA:
Gambar 2.1 Contoh Tabel FMEA
Dari gambar di atas, dapat dilihat bahwa tabel FMEA terdiri dari beberapa kolom, antara lain:
System Function or Feature
Merupakan poin permulaan dari analisis FMEA di mana kita menginput deskripsi singkat dari sebuah fungsi sistem. Jika entry tersebut merepresentasikan sebuah kategori, kita harus memecahnya ke dalam beberapa fungsi yang lebih spesifik atau fitur dalam baris selanjutnya. (Black, 2009: 32).
Potential Failure Mode(s) – Quality Risk(s)
Untuk setiap fungsi atau fitur spesifik (tetapi bukan untuk kategori itu sendiri), kita harus mengidentifikasi cara bagaimana untuk mengatasi kegagalan. Quality risks yang berhubungan dengan hilangnya fungsi sistem yang spesifik. Setiap fungsi atau fitur spesifik dapat memiliki beberapa jenis kegagalan yang berbeda. (Black, 2009: 32).
Potential Effect(s) of Failure
Dalam kolom ini dituliskan bagaimana jenis –jenis kegagalan yang dapat mempengaruhi user dalam satu atau beberapa cara. (Black, 2009: 33).
Critical?
Dalam kolom ini diindikasikan apakah efek potensial memiliki konsekuensi yang kritikal bagi user. Apakah fitur atau fungsi produk tidak dapat digunakan sama sekali jika jenis kegagalan ini terjadi? (Black, 2009: 33).
Severity
Dalam kolom ini ditangkap efek kegagalan (segera atau tertunda) di dalam sistem. (Black, 2009: 33). Di bawah ini contoh penggunaan skala 1-5, yaitu:
1. Kehilangan data, kerusakan hardware, atau isu keamanan.
2. Kehilangan fungsi vital yang tidak ada solusinya 3. Kehilangan fungsi vital dengan adanya solusi 4. Kehilangan sebagian fungsi vital.
5. Hal-hal lain yang kurang berarti atau biasa terjadi. Potential Cause(s) of Failure
Dalam kolom ini dituliskan daftar faktor-faktor yang mungkin memicu sebuah kegagalan. Contohnya error yang terjadi pada operating system, user error, atau penggunaan secara normal. (Black, 2009: 33).
Priority
Dalam kolom ini terdapat peringkat terhadap berbagai efek kegagalan pada user, customer, atau operator. (Black, 2009: 34). Berikut ini adalah contoh penggunaan skala 1-5, yaitu:
1. Kehilangan total dari nilai sistem.
2. Kehilangan nilai sistem yang tidak dapat diterima. 3. Pengurangan nilai sistem yang kemungkinan dapat
diterima.
4. Pengurangan nilai sistem yang dapat diterima. 5. Pengurangan nilai sistem yang dapat diabaikan. Detection Method(s)
Dalam kolom ini dituliskan daftar metode atau prosedur yang sedang digunakan, seperti aktivitas pembangunan atau vendor testing, yang dapat menemukan masalah sebelum masalah itu
berdampak pada user, tidak termasuk kegiatan yang dilakukan di masa mendatang (seperti membuat dan menjalankan test suite) yang dilakukan untuk menemukan masalah. (Black, 2009: 34).
Likelihood
Dalam kolom likelihood terdapat sebuah nomor yang merepresentasikan kerentanan sistem, yang terbagi menjadi : a) eksistensi dalam produk (berdasarkan faktor resiko teknikal seperti riwayat kompleksitas dan kecacatan yang terjadi sebelumnya); b) lepas dari proses pembangunan yang berjalan; dan c) gangguan pada operasional user. Contoh ini menggunakan skala 1 sampai 5 sebagai berikut (Black, 2009: 34) :
1. Pasti berdampak pada semua user.
2. Kemungkinan besar berdampak kepada beberapa user. 3. Mungkin berdampak pada beberapa user.
4. Pengaruh terbatas kepada sedikit user.
5. Tidak dapat dibayangkan pada penggunaan saat ini Risk Priority Number (RPN)
Dalam kolom ini diberitahukan betapa pentingnya melakukan tes jenis kegagalan tertentu. Risk Priority Number adalah hasil dari severity, priority, dan likelihood. Dikarenakan contoh ini menggunakan nilai dari 1 sampai 5 pada ketiga parameter, skala RPN adalah 1-125. (Black, 2009: 34).
Recommended Action
Berisi satu atau lebih simple action item untuk setiap efek potensial untuk mengurangi resiko yang berhubungan (yang mendorong risk priority number menuju 125). Bagi test team, aksi yang paling direkomendasikan meliputi pembuatan sebuah test case yang mempengaruhi peringkat likelihood. (Black, 2009: 34).
Who/When?
Mengindikasikan siapa yang bertanggung jawab terhadap setiap tindakan yang direkomendasikan dan kapan mereka bertanggungjawab untuk tindakan tersebut (sebagai contoh pada fase tes yang mana). (Black, 2009: 35).
References
Kolom ini menyediakan referensi dan informasi lebih lanjut mengenai resiko kualitas. Biasanya hal ini meliputi spesifikasi produk, dokumen yang dibutuhkan, dan sebagainya. (Black, 2009: 35).
Action Results
Memungkinkan untuk mencatat pengaruh dari aksi yang telah dilakukan pada priority, severity, likelihood, dan nilai RPN. Kolom ini akan digunakan setelah testing telah dilakukan, bukan selama awal FMEA. (Black, 2009: 35).
2.2.5 Test Plan
Menurut Perry (2006:251), test plan adalah suatu dokumentasi formal atau informal untuk menjabarkan budaya perusahaan. Test plan biasanya berbentuk sepuluh lembar kertas kerja atau disesuaikan dengan besar suatu test team pada perusahaan yang bersangkutan. Semakin besar test team, test plan yang dibuat akan lebih formal.
Tujuan dari test plan adalah untuk mendeskripsikan seluruh testing yang perlu dicapai, bersama dengan sumber dan jadwal yang diperlukan untuk menyelesaikannya. Test plan perlu menyediakan informasi mengenai software yang di-tes, tujuan dan resiko-resiko dilakukannya tes, dan tes yang akan dilakukan.
2.2.6 Test Case
Menurut Perry (2006:503), test case adalah sekumpulan input untuk tes, kondisi-kondisi pelaksanaan, dan hasil yang diharapkan dari pengembangan tujuan tes tertentu.
Menurut Black (2009:91), test case adalah kondisi saat testing melaksanakan action pada sistem, tester memberikan data pada sistem yang diuji, dan sistem berada pada satu atau beberapa kondisi dengan menghasilkan output yang dapat dibandingkan dengan hasil yang diharapkan. Tindakan, data, dan hasil yang diharapkan adalah bagian utama dari dilakukannya testing dan menghasilkan test condition.
Menurut Black (2009:610), test case adalah urutan langkah-langkah, sub dari langkah-langkah tersebut, dan tindakan lain yang dijalankan secara berurutan atau merupakan kombinasi dari konsekuensi yang menghasilkan kondisi tes sesuai harapan dan berguna untuk evaluasi lebih lanjut.
2.2.7 Activity Diagram
Menurut Satzinger (2005:144), activity diagram ialah suatu diagram yang menggambarkan alur kerja dari kegiatan-kegiatan user yang melakukan beberapa aktivitas dan urutan aktivitas mereka. 2.2.7.1 Notasi Activity Diagram
Tabel 2.1 Notasi Activity Diagram
No. Simbol Kegunaan
1. Swimlane adalah area persegi pada
activity diagram untuk mewakili kegiatan yang dilakukan oleh agen tunggal.
2. Starting activity ada simbol dimana untuk mengawali terjadinya proses bisnis.
3. Transition arrow adalah simbol untuk
memberi tahu arah selanjutnya proses bisnis itu berlangsung.
4. Activity adalah simbol dalam activity diagram untuk menggambarkan proses yang sedang berlangsung.
5. Ending activity adalah simbol yang
digunakan untuk mengakhiri sebuah proses bisnis yang sedang berjalan.
6. Synchronization yang digunakan dalam
activity diagram untuk mengendalikan pemisahan atau penyatuan jalur berurutan.
7. Decision adalah simbol yang digunakan ketika terjadi dua kemungkinan .
2.2.8 Use Case Diagram
2.2.8.1 Pengertian Use Case Diagram
Menurut Satzinger (2005:213), use case diagram adalah diagram yang menunjukan hubungan interaksi user dengan sistem. Use case diagram akan menunjukan proses atau event yang terjadi.
2.2.8.2 Notasi Use Case Diagram
Tabel 2.2 Notasi Use Case Diagram
Notasi Penjelasan
Actor
Menunjukkan aktor yang berinteraksi dengan sistem.
Use Case
Proses atau kejadian yang dilakukan.
________________ Connector Line
Menghubungkan actor dengan use case
Boundary
Pembatas antara sistem dengan lingkungan luar.
<<extends>>
Relationship : Extends
Relasi yang menunjukan use case tersebut harus atau tidak perlu dilakukan.
<<include>>
Relationship : Include
Relasi yang menunjukan use case harus di lakukan terlebih dahulu sebelum ke use case yang lain.
2.2.9 Product Specification
Product specification atau sering dikenal sebagai functional specification merupakan definisi fungsi-fungsi yang dibutuhkan untuk memenuhi kebutuhan pengguna. (Hambling, et al, 2010:39).
2.2.10 Technical Design Specification
Technical specification merupakan technical design dari fungsi-fungsi yang telah diidentifikasikan dalam product specification. (Hambling, et al, 2010:39).
2.3 Teori yang Berkaitan dengan Topik yang Dibahas 2.3.1 Test Execution
Menurut Black (2009:62), dalam melakukan perencanaan testing bagian ini menunjukan faktor-faktor penting yang mempengaruhi eksekusi testing.
Contohnya, untuk menjalankan testing, seringkali dibutuhkan barang-barang dari pihak luar, biasanya dalam bentuk sumber-sumber daya utama dan sistem untuk dites. Dalam menjalankan testing ini, diperlukan pengumpulan data-data yang akan ditinjau, dianalisis, dan dilaporkan kepada tim, rekan kerja, dan manager.
2.3.2 Resources
Menurut Black (2009:62), dalam bagian ini dilakukan identifikasi peserta-peserta kunci dalam usaha melaksanakan testing dan peran dari masing – masing peserta.
2.3.3 Bug
Menurut Black (2009:146), bug menjelaskan masalah–masalah yang ada pada sistem yang diuji yang memungkinkan kegagalan terhadap ekspetasi customer dan user terhadap kualitas sebuah sistem. Sebuah bug adalah sumber potensi atas ketidakpuasan dari produk dan layanan ke customer.
2.3.4 Test Tracking Spreadsheet
Menurut Black (2009:64), bagian ini berhubungan dengan sistem yang digunakan untuk mengolah dan meninjau test cases dan bugs. Peninjauan test cases mengacu kepada spreadsheets, database atau alat yang digunakan untuk mengolah seluruh test cases yang terdapat pada test suites dan bagaimana perkembangan dari testing tersebut ditinjau.
Untuk memudahkan pengelolaan terhadap pelaksanaan pengujian dapat digunakan sebuah alat yang dinamakan sebagai test tracking spreadsheet (Black, 2009: 199).
Penggunaan test tracking spreadsheet akan memungkinkan tester untuk melacak setiap status dari test case, mengetahui konfigurasi yang digunakan dan mengetahui siapa yang telah melaksanakan pengujian terhadap suatu test case (Black, 2009: 200).
Di bawah ini adalah contoh simple dari Test Tracking Spreadsheet yang dapat dilihat di gambar 2.3.
Gambar 2.3 Contoh Simple Test Tracking Spreadsheet (Black 2009: 201)
Kolom pertama dari test tracking spreadsheet tersebut berisi nama test suite/test case dari suatu pengujian.
Kolom state menggambarkan status dari tiap test case. Jika kolom state ini kosong, maka mengindikasikan bahwa test case tersebut masih dalam antrian untuk dilakukan pengujian. Jika kolom ini berisi pass, maka berarti bahwa pengujian untuk test case tersebut tidak menemukan bug. Jika berisi fail, maka berarti ada bug yang ditemukan dari pengujian test case tersebut baik satu maupun lebih.
Kolom system config berisi keterangan identifikasi untuk mengetahui konfigurasi sistem yang digunakan oleh tiap test case.
Kolom bug id berisi identitas dari bug yang ditemukan dari hasil pengujian test case. Kolom ini yang nantinya akan memudahkan test team untuk melacak bug tersebut dan mereferensikannya terhadap bug report yang dibuat dalam bug tracking database.
Kolom by berisi inisial dari tester yang telah melakukan pengujian terhadap test case. Kolom comment berisi komentar dari tester atau informasi tambahan mengenai status dari tiap test case.
Kolom roll up berisi ringkasan dari informasi mengenai status dari tiap test case. Kolom ini terbagi menjadi tiga kolom, yaitu: a) Kolom T berisi nilai 1 jika merupakan test case.
b) Kolom F berisi nilai 1 jika status dari test case adalah fail. c) Kolom P berisi nilai 1 jika status dari test case adalah pass.
2.3.5 Bug Report
Mengacu pada pendapat Black (2009: 146), bug report adalah dokumen teknis yang digunakan untuk mendeskripsikan berbagai gejala ataupun kegagalan yang berhubungan dengan suatu bug tertentu secara spesifik.
Suatu dokumen bug report yang dirancang dengan baik dapat memberikan informasi yang tepat bagi tim manajemen proyek mengenai bug tersebut sehingga dapat mengambil keputusan yang tepat (misalnya, apakah bug tersebut harus segera diperbaiki atau tidak). Selain itu, bug report juga dapat digunakan oleh para programmer atau developer untuk mengetahui informasi rinci mengenai suatu bug sehingga memudahkan penyelesaian bug tersebut. Field Bug ID berisi pengidentifikasi dari suatu bug yang dapat dijadikan referensi dari suatu test tracking spreadsheet. Field Project Name berisi informasi mengenai nama proyek dimana bug tersebut ditemukan. Field Tester berisi informasi mengenai namatester yang menemukan bug tersebut. Field Date Opened berisi informasi
mengenai tanggal bug tersebut dimasukkan ke dalam bug tracking database.
Field Quality Risk Category: Detail berisi informasi mengenai kategori rinci dari quality risk yang ditentukan secara spesifik berdasarkan bug tersebut. Field Subsystem berisi informasi mengenai subsystem dimana bug tersebut ditemukan. Field Configuration berisi informasi mengenai konfigurasi yang digunakan saat melakukan pengujian.
Field Severity dan Priority diisi dengan skala yang sama dengan yang telah dijelaskan pada bagian failure mode and effects analysis. Field RPN pada bug report didapat dari perkalian antara penilaian severity dan priority. Dengan demikian, range dari RPN adalah berkisar antara 1 – 25, dimana nilai 1 mengindikasikan bahwa bug tersebut sangat berbahaya dan nilai 25 mengindikasikan bahwa bug tersebut hanya hal sepele yang dapat diabaikan.
Field summary berisi uraian singkat mengenai bug. Field steps to reproduce menyediakan suatu deskripsi yang tepat dan jelas tentang bagaimana menghasilkan kembali bug tersebut. Field isolation berisi informasi untuk menyakinkan developer atau programmer bahwa bug yang ditemukan tersebut adalah benar-benar bug. Hal ini bisa dengan menyebutkan gejala-gejala timbulnya bug tersebut dan bisa juga dengan menjelaskan dampak serta penyebab dari timbulnya bug tersebut.
Field log berisi informasi rinci mengenai siklus hidup dari suatu bug mulai dari awal ketika bug tersebut di-entry ke dalam bug tracking database. Adapun gambaran siklus hidup dari bug report dapat dilihat pada gambar dibawah ini.
Gambar 2.4 Bug Report Life Cycle (Black 2009: 160)
State review menggambarkan status bug dimana bug telah di-input ke dalam bug tracking database dan menunggu untuk di-review oleh reviewer sebelum bug tersebut diinformasikan kepada seluruh tim proyek pengembangan.
State rejected menggambarkan status dimana bug tersebut ditolak oleh reviewer karena butuh penelitian atau informasi lebih lanjut mengenai bug tersebut.
State open menggambarkan status dimana bug tersebut telah di-review dan dianggap relevan dengan informasi rinci mengenai bug tersebut dan diinformasikan keberadaannya kepada seluruh tim proyek pengembangan.
State assigned menggambarkan status dimana bug tersebut ditugaskan kepada developer untuk mencari informasi lanjut mengenai bug tersebut serta menyelesaikannya.
State test menggambarkan status dimana bug tersebut telah selesai diperbaiki oleh developer serta harus diuji untuk memastikan bahwa bug tersebut benar-benar sudah diperbaiki.
State reopened menggambarkan status dimana bug dibuka kembali untuk diperbaiki lagi oleh developer.
State closed menggambarkan status dimana bug telah selesai diperbaiki dan telah dikonfirmasi kebenarannya melalui pengujian.
State deferred dapat digunakan oleh anggota tim proyek untuk menunda perbaikan bug tersebut jika mereka menilai bahwa bug tersebut memiliki prioritas yang rendah.
State cancelled dapat digunakan oleh anggota tim proyek untuk membatalkan perbaikan terhadap bug tersebut karena dinilai sudah tidak relevan lagi.
Field Owner pada bug report menunjukkan nama orang yang bertanggung jawab terhadap bug tersebut. Dengan adanya field ini diharapkan manajer proyek dapat dengan lebih mudah melacak atau mencari informasi yang lebih rinci lagi mengenai bug tersebut.
Field Estimated Fixed berisi informasi mengenai perkiraan tanggal bug tersebut selesai diperbaiki.
Field Root Cause berisi informasi mengenai akar penyebab dari terbentuknya bug tersebut. Menurut Black (2009: 171), root cause dari suatu bug secara umum dapat berupa:
a) Functional
Dari sisi functional, akar penyebab dari suatu bug dapat berupa spesifikasi yang salah, spesifikasinya benar tetapi implementasinya salah, atau sistem berfungsi dengan benar tetapi hasil pengujian melaporkan error yang salah.
b) System
Dari sisi system, akar penyebab dari suatu bug dapat berupa gagalnya komunikasi sistem internal, gagalnya hardware, gagalnya operating system, software architecture yang dibuat salah, atau asumsi perancangan sudah benar tetapi asumsi saat penerapannya salah. c) Process
Dari sisi process, akar penyebab dari suatu bug dapat berupa salahnya operasional aritmatika yang diterapkan, proses inisialisasi yang salah, control atau sequence yang salah, ataupun error dalam pemrosesan.
d) Data
Dari sisi data, akar penyebab dari suatu bug dapat berupa tipe data yang digunakan salah, struktur data yang salah atau penyebab lainnya yang berhubungan dengan data.
e) Code
Dari sisi code, akar penyebab dari suatu bug dapat berupa salah pengetikan pada code.
f) Documentation
Dari sisi documentation, akar penyebab dari suatu bug dapat berupa salahnya dokumentasi terhadap sistem.
g) Standards
Dari sisi standards, akar penyebab dari suatu bug dapat berupa tidak terpenuhnya standar yang seharusnya terhadap sistem tersebut. h) Other
Root cause dari bug dikategorikan ke dalam other jika akar penyebab dari bug telah diketahui tetapi tidak sesuai dengan kategori yang ada.
i) Duplicate
Root cause yang ini digunakan jika terdapat dua ataupun lebih bug report yang mendeskripsikan bug yang sama.
j) NAP
Dikategorikan sebagai NAP (Not a Problem) jika bug yang dilaporkan tersebut hanya karena pemahaman yang salah oleh tester. k) Bad Unit
Root cause ini digunakan jika bug tersebut terjadi kata kegagalan hardware yang tidak diduga.
l) RCN
RCN (Root Cause Needed) digunakan jika status dari bug tersebut sudah closed tetapi tidak ada yang mengetahui akar penyebab dari terjadinya bug tersebut.
m) Unknown
Root cause unknown digunakan jika tidak ada orang yang mengetahui apa yang terjadi atas bug tersebut.
Field Phase Injected mendeskripsikan fase dimana bug tersebut dikenalkan, biasanya pada fase awal sebelum fase dimana bug tersebut teridentifikasi.
Field Phase Detected mendeskripsikan fase dimana bug tersebut teridentifikasi.
Field Phase Removed mendeskripsikan fase dimana bug tersebut berhasil diperbaiki.
Field Close Date menjelaskan tanggal dimana status dari bug tersebut menjadi closed.
Field Resolution mendeskripsikan bagaimana bug tersebut diperbaiki.
Dari semua bug report yang telah dimasukkan ke dalam bug tracking database maka dapat dibuatkan grafik-grafik yang mendukung sebagai laporan kepada project manager. Grafik yang dibuat beruapa Open/Closed Chart yang dapat dilihat pada gambar di bawah ini.
Gambar 2.5 Contoh Open/Closed Chart (Black (2009: 180)
2.3.6 Bug Isolation and Clasification
Menurut Black (2009:64), bagian ini digunakan untuk menjelaskan seberapa jauh bugs akan diisolasi dan mengklasifikasikannya pada bugs reports. Mengisolasi bugs berarti mengadakan percobaan dengan sistem yang dites dalam usaha testing untuk mendapatkan hubungan antar variabel, sebab-akibat atau sejenisnya. Mengklasifikasikan laporan bugs berarti menempatkan bugs yang ditemukan ke dalam kategori-kategori tertentu yang
mengindikasikan bagaimana bugs tersebut seharusnya dikomunikasikan dan diatasi.
2.3.7 Test Release Management
Menurut Black (2009:65), salah satu interface utama antara proyek keseluruhan dan testing yang terjadi pada saat terdapat revisi, pembangunan dan komponen yang disampaikan kepada test team untuk melakukan testing.
Dengan tidak adanya rencana yang ditetapkan jika hal ini terjadi, testing yang dilakukan dapat menyebabkan kekacauan. Untuk menangani hal ini setiap perilisan suatu program harus dapat diindentifikasi untuk memudahkan proses testing sehingga test team dapat mengidentifikasi versi mana yang mengandung bugs dan mengetahui jenis bugs yang ada.
2.4 Kerangka Pikir
Untuk memudahkan pemahaman terhadap konsep dan hubungan tiap proses yang ada dalam penulisan ini maka digambarkan sebuah kerangka pikir yang terdapat di dalam gambar 2.6.
Kerangka pikir ini berawal dari penggambaran dan penjelasan proses bisnis yang nantinya akan digunakan setelah implementasi dan pendeskripsian spesifikasi produk dan teknis dari aplikasi yang akan digunakan.
Proses bisnis akan digambarkan dan dijelaskan per modul sesuai dengan ruang lingkup yang telah dijelaskan pada bab 1 sub bab ruang lingkup sedangkan aplikasinya akan dijelaskan berdasarkan 2 (dua) spesifikasi, yaitu dari product specification dan technical design specification, penjelasan aplikasi dan proses bisnis inilah yang nantinya akan menjadi persyaratan yang harus dipenuhi selama dilakukan pengujian.
Dari penggambaran dan penjelasan proses bisnis dan aplikasi ini akan dilakukan analisis dengan menggunakan Failure Mode and Effect Analysis (FMEA) untuk mengambil keputusan mengenai system function atau feature
manakah yang akan diprioritaskan dan nantinya menjadi system function atau feature yang akan diuji.
Dari hasil analisis FMEA tersebut maka dapat ditentukan dan diseleksi fitur-fitur yang mana saja yang akan menjadi prioritas dalam pengujian. Agar dapat terlihat dengan jelas fitur-fitur apa saja yang telah diseleksi, maka akan dipetakan antara fitur-fitur hasil seleksi dan scenario-scenario yang akan dijalankan dalam pengujian, kemudian dibuatlah perancangan pengujian, termasuk di dalamnya setting testing, proposed schedule of milestone, dan test configuration.
Setelah itu, akan di tentukan test case sesuai dengan testing scenario yang telah disebutkan sebelumnya. Test case tersebut akan dikelompokkan dalam beberapa test suite untuk memperjelas test case mana sajakah yang harus dikerjakan oleh tester dalam proses pengujian.
Sebelum mulai melakukan pengujian, test tracking spreadsheet telah dipersiapkan terlebih dahulu. Test tracking spreadsheet tidak hanya dibuat sebelum pengujian, namun test tracking spreadsheet akan terus di-update selama jalannya proses pengujian dan juga setelah proses pengujian selesai dilaksanakan.
Setelah semua perencanaan pengujian selesai disiapkan, maka proses testing siap dilakukan. Dari pelaksanaan pengujian akan ditemukan bug-bug yang harus didata dan diinformasikan ke pihak yang terkait agar bug tersebut dapat diperbaiki. Oleh karena itu, diperlukan untuk membuat bug report yang mana bug report ini berisi tabel-tabel yang menampung informasi mengenai bug ID, tester, state, date opened, estimated fix, severity, priority, RPN, summary, Step to Reproduce, Isolation, dan Log.
Data dalam tabel-tabel tersebut akan diolah menjadi informasi dalam bentuk grafik-grafik yang melaporkan mengenai hasil pelaksanaan pengujian yaitu berbentuk Open/Closed Chart.
Membuat Test Case Pengelompokkan Test Suites Melakukan Unit dan Integration Testing Perancangan Pengujian Penyeleksian proses yg akan diuji Penggambaran&penjelasan
Proses Bisnis dan Aplikasi yang akan digunakan
Membuat FMEA (Failure Mode and
Effect Analysis) Membuat Test Tracking Spreadsheet Membuat Bug Report Merekomendasikan Kelayakan Implementasi
Gambar 2.6 Kerangka Pikir
Penyeleksian Ruang Lingkup dan Komponen
