BAB 2 Landasan Teori 2.1 Teori-teori Dasar/Umum Teori-teori umum yang menjadi dasar penulisan adalah sebagai berikut: 2.1.1 Data Menurut Kelly Rainer dan 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. Proses pengolahan data terbagi menjadi tiga tahapan, yang disebut dengan siklus pengolahan data (Data Processing Cycle) yaitu: (Baddih, 2010) 1. Pada tahapan Input, yaitu dilakukan proses pemasukan data ke dalam komputer lewat media input (Input Devices). 2. Pada tahapan Processing, yaitu dilakukan proses pengolahan data yang sudah dimasukkan, yang dilakukan oleh alat pemroses (Process Devices) yang dapat berupa proses perhitungan, perbandingan, pengendalian, atau pencarian distorage. 3. Pada tahapan Output, yaitu dilakukan proses menghasilkan output dari hasil pengolahan data ke alat output (Output Devices) yaitu berupa informasi. 2.1.2 Informasi Menurut Whitten, Bentley dan 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 Kelly Rainer dan Casey (2011:10), informasi mengarahkan pada data yang telah disusun agar memiliki makna dan nilai untuk 7
8 penerima. Penerima dapat menafsirkan makna dan menarik kesimpulan dan maksud dari informasi tersebut. 2.1.3 Sistem Menurut Satzinger, Jackson, dan Burd (2010:6), sistem adalah kumpulan komponen yang saling berhubungan dan memiliki fungsi yang sama untuk mencapai suatu tujuan tertentu. Menurut Whitten, Bentley dan Dittman (2007:6), sistem adalah sekelompok komponen yang saling berkaitan dan berfungsi bersama-sama untuk mencapai hasil yang diinginkan. 2.1.4 Sistem Informasi Menurut Whitten, Bentley dan 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, Jackson, dan Burd (2010:6), sistem informasi adalah kumpulan komponen yang saling berkaitan yang mengumpulkan, mengolah, menyimpan dan menyediakan sebagai hasil dari kebutuhan informasi untuk menyelesaikan tugas-tugas bisnis. 2.1.5 Enterprise Resource Planning (ERP) Enterprise Resource Planning (ERP) adalah sistem informasi perusahaan yang dirancang untuk mengintegrasikan dan mengoptimalkan proses bisnis dan transaksi di sebuah perusahaan. ERP merupakan konsep dan sistem berbasis industri, dan secara universal diterima oleh industri sebagai solusi praktis untuk mencapai sistem informasi perusahaan yang terintegrasi. (Moon, 2007)
9 2.2 Teori-teori Khusus yang Berhubungan dengan Topik yang Dibahas 2.2.1 Business process Proses bisnis merupakan serangkaian aktivitas bisnis yang disusun secara spesifik, bergantung pada aturan bisnis yang diterapkan oleh setiap perusahaan. Proses bisnis sangat berguna untuk menganalisis suatu organisasi, dalam hal ini mengatur setiap departemen dan aktivitas operasional dengan pendekatan sistematik yang bertujuan untuk mencapai peningkatan kualitas yang diinginkan oleh suatu perusahaan. (Opit, 2012:169) 2.2.2 Procurement E-Procurement (Electronic Procurement) merupakan proses pengadaan barang dan jasa yang meliputi pengumuman pelelangan, permintaan spesifikasi barang dan jasa beserta harga, negosiasi atau tawar menawar harga, lelang, pemesanan barang dan jasa (terbentuknya purchase order), dan keterangan status pengiriman barang dan jasa, yang dilakukan secara online menggunakan teknologi internet. (Hasugian, 2010:117) E-procurement merupakan proses pengadaan barang/jasa yang pelaksanaannya dilakukan secara elektronik (berbasis web/internet). E- procurement dilatarbelakangi oleh kelemahan-kelemahan pengadaan dengan sistem konvensional yang dilakukan dengan langsung mempertemukan pihakpihak yang terkait pengadaan. E-procurement hadir dalam rangka pemanfaatan perkembangan teknologi informasi dalam proses pengadaan barang/jasa serta untuk mewujudkan pelaksanaan pengadaan barang/jasa yang efisien, efektif, adil dan transparan. (Wijaya, Indryani, & Putri, 2011:1-2) 2.2.3 Testing Testing sendiri memiliki pengertian yang luas, sedangkan software testing yang berarti suatu daerah yang luas terutama terdiri dari daerah teknis dan non-teknis yang berbeda, seperti requirement specifications, maintainance, process, design dan implementation, dan management issue dalam rekayasa perangkat lunak. Software testing terlibat dalam setiap tahap software life cycle, tetapi cara pengujian yang dilakukan pada setiap tahap
10 pengembangan perangkat lunak berbeda dan memiliki tujuan yang berbeda. (Nidhra & Dondeti, 2012:30) Software testing merupakan bagian integral dari proses software pengembangan, yang terdiri dari empat komponen berikut: (Perry, 2006:4) 1. Plan (P): Buatlah rancangan. Tentukan tujuan dan menentukan strategi dan metode pendukung untuk mencapainya dan harus mendasarkan rencana pada penilaian situasi saat ini, dan strategi harus jelas berfokus pada inisiatif strategis/unit utama yang akan mendorong rencana perbaikan. 2. Do (D): Jalankan rencana. Menciptakan kondisi dan melakukan pelatihan yang diperlukan untuk melaksanakan rencana tersebut. Pastikan semua orang benar-benar memahami tujuan dan rencana. Ajarkan karyawan tentang prosedur dan keterampilan yang mereka butuhkan untuk memenuhi rencana dan benar-benar memahami pekerjaan. Kemudian melakukan pekerjaan sesuai dengan prosedur ini. 3. Check (C): Periksa hasil. Periksa untuk menentukan apakah pekerjaan berjalan sesuai rencana dan apakah hasil yang diharapkan telah diperoleh. Periksa kinerja prosedur yang ditetapkan, perubahan kondisi, atau kelainan yang mungkin muncul. Sesering mungkin, membandingkan hasil pekerjaan dengan tujuan. 4. Act (A): Ambil tindakan yang diperlukan. Jika pemeriksaan menunjukkan bahwa pekerjaan tersebut tidak dilakukan sesuai dengan rencana atau hasilnya bukan yang diantisipasi, susun langkah-langkah untuk mengambil tindakan yang tepat. 2.2.3.1 Functional Tests Kadang-kadang kalimat ini mempunyai arti yang sama sebagai behavioral test, tetapi juga dapat berarti pengujian yang ketat berfokus pada kebenaran fungsionalitas. Dalam kasus ini, itu harus ditambah dengan pendekatan test lain untuk menangani potensial penting risiko kualitas seperti kinerja, beban, kapasitas, volume, dan sebagainya. (Black, 2009:601)
11 Hampir semua Functional testing adalah tes validasi, dan memeriksa bagaimana sistem berjalan. Contoh functional testing termasuk: Unit testing. Tes ini memverifikasi bahwa sistem benar-benar berfungsi. Misalnya, menekan tombol fungsi untuk menyelesaikan suatu tindakan. Integrated testing. Sistem ini menjalankan tugas-tugas yang melibatkan lebih dari satu aplikasi atau database untuk memverifikasi bahwa sistem melakukan tugas secara akurat. System testing. Tes ini mensimulasikan pengoperasian seluruh sistem, dan memverifikasi bahwa sistem berjalan dengan benar. User acceptance. Staff organisasi, pelanggan, atau vendor mulai berinteraksi dengan sistem, mereka akan memastikan bahwa sistem tersebut berfungsi dengan baik. (Perry, 2006:70) 2.2.3.2 Integration atau Product Test Integration atau product test berfokus pada hubungan dan antarmuka antara pasang komponen dan rombongan komponen dalam sistem di bawah tes, biasanya dalam mode bertahap. Tes integrasi harus terjadi dalam koordinasi dengan kegiatan tingkat proyek untuk mengintegrasikan seluruh sistem. Pementasan integrasi dan tes integrasi harus mengikuti rencana yang sama sehingga ditemukan set komponen yang benar dengan cara yang tepat dan pada waktu yang tepat untuk menemukan terlebih dahulu kemungkinan bug integrasi yang paling berbahaya. (Black, 2009:605) Integration test memvalidasikan dua atau lebih unit atau integrasi lainnya bekerja sama dengan baik, dan cenderung fokus pada antarmuka tertentu dalam desain tingkat rendah. (Nidhra & Dondeti, 2012:30) 2.2.3.3 White-box dan Black-box Test Menurut Black (2009:2), Structural test (juga dikenal sebagai whitebox test atau Technical test) digunakan untuk menemukan bug di elemen struktural tingkat rendah seperti kode-kode, skema database, chips, subassemblies, dan interfaces. Tester mendasarkan tes struktural pada
12 bagaimana sistem tersebut bekerja. Sedangkan tester menggunakan behavioral test (juga dikenal sebagai black-box test) untuk menemukan bug dalam operasi tingkat tinggi, fitur-fitur utama, profil operasional dan pelanggan skenario. Tester dapat membuat tes black-box yang berdasarkan sistem apa yang harus dilakukan. Gambar 2. 1 The test granularity spectrum and owners Black (2009:2) Dalam glosarium International Software Testing Qualifications Board dijelaskan bahwa Black-box testing merupakan testing, baik fungsional maupun non-fungsional, tanpa mengacu pada internal struktur komponen atau sistem. (McKay & Hamburg, 2014) Dalam teori, dua pendekatan umum adalah white-box testing dan black-box testing. White-box testing mengetes secara rinci dalam sistem. Untuk modul yang diberikan, struktur dan jalur eksekusi diuji. Test case perlu diuji setiap jalur dan mengetes setiap titik keputusan yang mungkin benar atau salah. Metode ini juga mengetes loop iterations. Test case didasarkan pada proses aliran grafik. Black-box testing melengkapi White-box testing. Metode ini akan memeriksa apakah output telah sesuai dengan input. Jika input dalam batas, modul tersebut akan diperiksa apakah output sudah benar. Jika input tidak benar, diperiksa apakah ada pesan error atau modul telah melakukan sesuai dengan spesifikasi atau tidak. (Chantrapornchai, Kinputtan, & Santibowanwing, 2014: 319-338) 2.2.3.4 System Testing System Testing menunjukkan bahwa sistem bekerja end-to-end di lokasi produksi seperti untuk menyediakan fungsi bisnis tertentu dalam desain tingkat tinggi. (Nidhra & Dondeti, 2012:30)
13 Sebuah test phase pengembangan perangkat lunak atau perangkat keras yang menemukan bug secara keseluruhan dan perilaku, fungsi, dan respon dari sistem yang diuji secara keseluruhan beroperasi di bawah realistic usage scenarios. Berbagai sistem operasi dilakukan setelah sistem tersebut sepenuhnya terintegrasi. (Black, 2009:609) System Testing memeriksa aplikasi web secara keseluruhan dan dengan sistem lain. Definisi klasik dari System Testing adalah memvalidasi bahwa fungsi sistem komputasi sesuai dengan kebutuhan tertulis dan spesifikasi. Hal ini juga berlaku pada aplikasi berbasis web. Perbedaannya berlaku pada bagaimana sistem didefinisikan. System Testing biasanya mencakup hardware, software, data, procedures, and people. Dalam aplikasi perusahaan yang berbasis web, sistem mungkin berinteraksi dengan Internet web pages, data warehouses, back-end processing systems, dan reporting systems. (Perry, 2006:807) 2.2.3.5 User acceptance Testing Tujuan tes ini adalah untuk menunjukkan bahwa sistem telah memenuhi persyaratan. Fase ini bertujuan untuk membangun kepercayaan dalam kualitas perangkat lunak. Acceptance testing seharusnya bukan menemukan bug dan biasanya merupakan tahap testing yang terakhir sebelum produk dirilis. (Black, 2009:601) User acceptance testing dilakukan oleh pemilik bisnis, tujuannya untuk menguji apakah sistem telah memenuhi kebutuhan bisnis mereka atau tidak. (Nidhra & Dondeti, 2012:30) Gagasan utama dalam User acceptance testing (atau validasi proses bisnis) adalah untuk memastikan bahwa produk akhir telah mendukung kebutuhan user. Untuk aplikasi bisnis, hal ini berarti pengujian bahwa sistem memungkinkan user untuk melakukan bisnis dengan benar dan efisien. Untuk aplikasi pribadi, hal ini berarti bahwa user bisa mendapatkan informasi atau layanan yang mereka butuhkan dari website secara efisien. Dalam halaman web perusahaan, User acceptance testing mungkin dari kelompok end user, manajemen, atau team testing independen yang mengambil peran end user. Dalam aplikasi web publik,
14 User acceptance testing mungkin beta tester, yang menerima prototype atau rilis awal aplikasi web baru, atau tester independen yang mengambil peran user web publik. (Perry, 2006:808) 2.2.3.6 Test case Test case adalah sebuah urutan langkah-langkah, substeps, dan tindakan lainnya, dilakukan secara serial, secara paralel, atau kombinasi dari deretan, yang menciptakan kondisi tes yang diinginkan yang test case dirancang untuk mengevaluasi. Dalam gaya dokumentasi IEEE 829, elemen ini disebut sebagai uji spesifikasi dan prosedur pengujian. Gambar 2. 2 Contoh Test case (Black, 2009:610) Langkah langkah untuk membuat test case adalah sebagai berikut: (Nidhra & Dondeti 2012:34) Mendefinisikan kelas ekuivalen Menulis test case yang mencakup sebanyak mungkin kelas ekuivalen
15 Melanjutkan menulis test case untuk semua kelas ekuivalen yang berlaku Kemudia menulis satu test case untuk setiap kelas yang tidak valid. Sistem yang digunakan untuk mengelola dan melacak bug dan test cases. Test case tracking mengacu pada spreadsheet, database, atau alat yang digunakan untuk mengelola semua test case dalam test suite dan bagaimana cara melacak kemajuan melalui test tersebut. (Black, 2009:64) 2.2.3.7 Test Suite Sebuah kerangka untuk eksekusi dari sekelompok test case; cara untuk mengatur test cases. Di test suite, test case dapat dikombinasikan untuk menciptakan kondisi test yang unik. (Black, 2009:611) 2.2.3.8 Test Phase Test phase merupakan sebuah pendekatan uji bertahap sistematis, dari test struktural untuk behavioral test sampai live test. Pelaksanaan aktivitas dalam fase ini mungkin memiliki panjang yang relatif berbeda. Gambar 2. 3 The test execution period for various test phases in a development project (Black, 2009:9) 2.2.3.9 Test Cycle Eksekusi sebagian atau seluruh dari semua tes suite yang direncanakan untuk diberikan test phase sebagai bagian dari fase. Sebuah test phase melibatkan setidaknya satu siklus (biasanya lebih) melalui semua test suite yang ditunjuk. Test cycle biasanya terkait dengan sistem
16 tunggal yang diuji, seperti contoh pada pembangunan dari perangkat lunak atau motherboard. (Black, 2009:610) 2.2.3.10 Bug Suatu masalah yang hadir dalam sistem yang diuji yang menyebabkan kegagalan dalam memenuhi harapan atau disebut juga kecacatan dalam sistem. Gejala dari bug adalah kegagalan. Tim tester biasanya hanya melihat kegagalan tetapi bug itu sendiri adalah kecacatan yang menyebabkan kegagalan. (Black, 2009) 2.2.3.11 Bug Tracking Gambar 2. 4 The design for a basic bug-tracking database (Black, 2009:155) Untuk dapat mengkomunikasikan secara efektif antara team tester, team programmer, dan team lainnya dalam suatu project, maka dibutuhkannya cara untuk melacak setiap bug melalui serangkaian keadaan dalam perjalanan ke penutupan. Black (2009) menunjukkan cara untuk membuat dan menggunakan database yang efektif dan sederhana yang menyelesaikan tujuan ini. Database ini juga dapat merangkum bug dalam grafik informatif yang memberitahu manajemen tentang projected test completion, product stability, system turnaround times, troublesome subsystems, dan root causes.
17 2.2.3.12 Bug report Klasifikasi bug report memberikan bug untuk kategori tertentu yang menunjukkan bagaimana bug harus dikomunikasikan dan ditangani. Gambar 2. 5 A good SpeedyWriter bug report (Black, 2009:149) Black (2009:64) telah menggunakan klasifikasi seperti berikut: Requirements failure. bug report menyangkut kegagalan sistem untuk memenuhi persyaratan. Pihak terkait akan menyelesaikan masalah tersebut. Non Requirements failure. Bug dilaporkan tidak dicakupi oleh persyaratan sistem, tetapi secara signifikan mempengaruhi kualitas sistem. Pihak terkait akan menyelesaikan masalah tersebut. Waiver requested. Bug report memang menggambarkan kegagalan, tetapi programmer telah meminta pengabaian karena mereka percaya bahwa hal itu tidak akan berpengaruh secara signifikan terhadap kualitas. External failure. Bug report membahas kegagalan yang muncul dari faktor eksternal atau faktor atau di luar kendali sistem yang diuji. Test failure. Para programer percaya bahwa tes telah menemukan kesalahan palsu atau tidak valid.
18 2.2.3.13 FMEA Singkatan dari Failure Mode and Effect Analysis, suatu teknik untuk mengidentifikasi dan menentukan potensial risiko kualitas, menentukan peringkat mereka dengan prioritas risiko, dan menetapkan tindakan untuk mencegah dan/atau mendeteksi masalah yang terkait. (Black, 2009) Gambar 2. 6 A Portion of the FMEA for Data Rocket (Black 2009: 33) Pada kolom The System Function or Feature, terdapat deskripsi singkat dari sistem dimasukkan di baris baris yang ada, jika entri yang dimasukkan merepresentasikan suatu kategori, maka harus dipecah ke dalam fungsi-fungsi atau fitur fitur yang lebih spesifik dalam barisbaris berikutnya. (Black, 2009:32) Dalam Potential Failure Mode(s)-Quality Risk(s) column, untuk setiap fungsi atau fitur tertentu (tetapi tidak untuk kategori itu sendiri), diidentifikasi cara-cara yang mungkin mengalami kegagalan. Ini adalah resiko kualitas yang berhubungan dengan hilangnya fungsi sistem tertentu. (Black, 2009:32)
19 Dalam Potential Effect(s) of Failure column, didaftar bagaimana setiap failure mode dapat mempengaruhi user, dalam satu atau lebih cara. Black (2009:33) menetapkan entri ini umum daripada mencoba untuk mengantisipasi setiap hasil yang mungkin tidak diharapkan. Dalam kolom Critical menunjukkan apakah efek potensial memiliki konsekuensi penting bagi user, apakah fitur produk atau fungsi sama sekali tidak dapat digunakan jika failure mode ini terjadi? (Black, 2009:33) Dalam kolom Severity, menangkap efek dari kegagalan (langsung atau tertunda) pada sistem. Black (2009:33) menggunakan skala 1 sampai 5 sebagai berikut: 1. Hilangnya data, kerusakan hardware, atau masalah keamanan 2. Hilangnya fungsi tanpa solusi 3. Hilangnya fungsi dengan solusi 4. Hilangnya sebagian fungsi 5. Hal kecil lainnya Dalam Potential Cause(s) of Failure column, didaftar kemungkinan faktor yang mungkin memicu kegagalan. Misalnya, kesalahan sistem operasi, kesalahan user, atau penggunaan normal. Black (2009: 33) mengatakan kolom ini tidak sepenting yang lain ketika menggunakan FMEA sebagai alat uji desain. Pada kolom Priority, menilai efek dari kegagalan pada user, pelanggan, atau operator. Black (2009:34) menggunakan skala 1 sampai 5, sebagai berikut: 1. Hilangnya nilai sistem secara total 2. Kehilangan nilai sistem yang tidak dapat diterima 3. Pengurangan nilai sistem yang mungkin dapat diterima 4. Pengurangan nilai sistem yang dapat diterima 5. Pengurangan nilai sistem yang tidak berarti Pada kolom Detection Method(s), didaftar metode atau prosedur yang ada sekarang, seperti aktivitas development atau vendor testing,
20 yang dapat menemukan masalah sebelum mempengaruhi ke user, terkecuali tindakan kedepannya (seperti membuat dan menjalankan test suites) yang mungkin dilakukan untuk ditemukan. (Black, 2009:34) Pada kolom likelihood terdapat angka-angka yang merepresentasikan kerentanan dari sistem yang berkaitan dengan: a) Eksistensi dari produk; b) lepas dari proses pengembangan yang ada; dan c) gangguan pada operasi user, yang akan direpresentasikan dari skala 1 sampai skala 5 sebagai berikut: (Black, 2009:34) 1. Secara pasti akan mempengaruhi seluruh user. 2. Kemungkinan besar akan mempengaruhi sebagian user. 3. Kemungkinan akan mempengaruhi sebagian user. 4. Dampak terbatas yang akan mempengaruhi beberapa user. 5. Tidak dapat dibayangkan dalam penggunaan yang sebenarnya. Kolom RPN (Risk Priority Number) memberitahu betapa pentingnya untuk menguji failure mode tertentu. RPN adalah produk dari severity, priority, dan likelihood. RPN berkirasan 1 sampai 125 dari nilai 1 sampai 5 untuk 3 parameter tersebut. Black (2009:34) Pada kolom Recommended Action akan berisi satu atau lebih tindakan untuk setiap efek potensial guna mengurangi resiko yang terkait (yang menekan Risk Priority Number (RPN) hingga ke angka 125). (Black, 2009:34) Pada kolom Who/When akan mengindikasikan siapa yang bertanggung jawab untuk setiap rekomendasi tindakan, dan kapan mereka akan bertanggung jawab terhadap tindakan tersebut. (Black, 2009:35) Pada kolom References menyediakan referensi informasi tambahan mengenai kualitas resiko yang umumnya melibatkan spesifikasi produk, dokumen persyaratan. (Black, 2009:35) The Action Results columns memungkinkan untuk merekam pengaruh tindakan yang diambil pada prioritas, tingkat keparahan, kemungkinan, dan nilai-nilai RPN. (Black, 2009:35)
21 2.2.3.14 Root Cause Alasan mendasar mengapa terjadinya bug, dibandingkan dengan gejala bug yang diamati. Data root cause paling berguna dalam menganalisis rincian root cause semua bug yang ditemukan dalam sistem di bawah pengujian dapat membantu untuk memfokuskan perhatian tes dan pembangunan di area yang menyebabkan masalah yang paling sering dan serius. (Black, 2009:170) Gambar 2. 7 Bugs dan root causes (Black, 2009:170) Anomali terjadi ketika tester mengamati perilaku tak terduga. Jika lingkungan pengujian dan tindakan tester benar, anomali ini menunjukkan baik kegagalan sistem atau kegagalan tes. Kegagalan muncul dari bug baik dalam sistem atau tes. Bug berasal dari kesalahan yang dilakukan oleh perangkat lunak atau perangkat keras insinyur (sekaligus menciptakan sistem yang diuji) atau insinyur uji (saat membuat tes sistem). Kesalahan yang adalah akar penyebab. (Black, 2009:170) 2.2.3.15 Bug Life Cycle Black (2009:158-159) menjelaskan Life cycle akan bervariasi sesuai kebutuhan organisasi, salah satu life cycle yang digunakan:
22 Review. Ketika tester memasukkan laporan bug baru dalam bugtracking database, bug-tracking database tersebut direview sebelum terlihat oleh team luar. Rejected. Jika reviewer memutuskan bahwa laporan butuh diulang secara signifikan, reviewer menolak laporan. Anggota tim proyek juga dapat menolak laporan bug setelah persetujuan oleh reviewer. Open. Jika tester telah sepenuhnya menangani masalahnya, reviewer membuka laporan, membuatnya tampil sebagai sebuah bug yang dikenal. Assigned. Anggota tim proyek menetapkannya ke development manager, yang memberikan bug pada developer tertentu untuk perbaikan. Test. Perbaikan bug didatangkan ke organisasi untuk konfirmasi testing (yang menjamin bahwa usulan perbaikan benar-benar memecahkan bug seperti yang dilaporkan) dan regresi testing (yang membahas pertanyaan tentang apakah perbaikan akan menmunculkan masalah baru sebagai efek samping). Reopened. Jika perbaikan gagal konfirmasi testing, tester membuka laporan bug. Jika perbaikan melewati konfirmasi testing tetapi gagal regresi testing, tester membuka laporan bug baru. Closed. Jika perbaikan melewati konfirmasi testing, tester menutup laporan bug. Deferred. Jika anggota tim proyek memutuskan bahwa masalah nyata tetapi memilih untuk ditetapkan di prioritas rendah pada bug atau menjadwalkan perbaikan pada rilis berikutnya. Cancelled. Jika anggota tim proyek memutuskan bahwa masalah itu tidak nyata, laporan bug dibatalkan. 2.2.3.16 Testware Testware adalah semua artefak yang diciptakan untuk testing, termasuk script, data, dokumentasi, berkas, informasi lingkungan dan
23 sebagainya. Arsitektur Testware adalah cara di mana artefak tersebut diatur dan bagaimana mereka berhubungan satu sama lain. (Graham & Fewster, 2012:8) Gambar 2. 8 Sebuah dekomposisi logis dari komponen testware umum (Graham & Fewster, 2012:8) 2.2.3.17 Bug Isolation Mengisolasi bug berarti bereksperimen dengan sistem yang diuji dalam upaya untuk menemukan variabel yang terhubung, kausal atau sebaliknya. Penting untuk membuat eksplisit tentang bug isolation. Penguji akhirnya membantu dengan debugging, tugas programmer yang dapat mengkonsumsi banyak waktu dengan menunjukkan sangat sedikit untuk dalam hal cakupan test. (Black, 2009:64) 2.2.3.18 Test Configuration Pengujian sistem dengan elemen perangkat keras khusus yang signifikan (seperti laptop baru atau server), satu dengan banyak unsur perangkat keras (seperti sistem operasi jaringan atau aplikasi jaringan), atau satu dengan elemen perangkat keras yang mahal (seperti mainframe, sebuah tinggi ketersediaan server, atau server cluster). (Black, 2009:61)
24 2.2.3.19 Test tracking spread sheet Test tracking spreadsheet merupakan suatu alat yang digunakan untuk mengelola eksekusi pengujian. Pada test Tracking Spreadsheet ini dapat dimasukkan: Test case summary, yang digunakan saat penguji ingin melacak status dari setiap test case, konfigurasi mana yang dijalankan saat pengujian, dan siapa yang menjalankan pengujian (Black, 2009:200) Test suite summary, yang berisi data jumlah test case dalam setiap suite dan berapa test case dalam status (Fail, Pass, Skip, in queue, dan Block). (Black, 2009:203) 2.2.3.20 Open/Closed chart diagram Gambar 2. 9 Contoh opened/closed chart (Black, 2009:179) Open/Closed chart diagram merupakan yang paling dasar dari bagan analisis kecacatan menggambarkan jumlah bug terbuka terhadap jumlah yang diselesaikan setiap hari. Open/Closed chart diagram menawarkan pandangan umum status proyek pembangunan tersebut, yang diambil selama pertengahan test phase sistem. Dalam tabel ini, Black menggunakan jumlah bug yang diprediksi untuk menunjukkan harapan jumlah bug terbuka untuk bertemu. Test project akhirnya mencapai titik di mana pengujian lebih lanjut menghasilkan hasil yang menurun. Ketika kurva Total opened mendatar ke jumlah yang diharapkan dari bug, testing dikuringi, setidaknya untuk tahap saat ini yang sedang berlangsung. (Black, 2009:179)
25 2.2.3.21 Quality risk Kemungkinan dari jenis perilaku yang tidak diinginkan, atau kegagalan, di mana sistem yang diuji tidak memenuhi persyaratan produk yang ditetapkan atau harapan; dalam istilah biasa, kemungkinan bug. (Black, 2009:607) Saat tim proyek mengembangkan atau memelihara sistem, tim proyek terkena berbagai resiko yang terkait dengan tidak menerapkan semua fitur dengan memuaskan dan menerapkan beberapa yang tidak benar. Resiko ini dapat secara kolektif disebut resiko kualitas, karena resiko ini berkaitan dengan kemungkinan hasil yang tidak diinginkan terkait dengan kualitas sistem. Proses pengujian harus memungkinkan tes organisasi untuk menilai kualitas resiko dan memahami kegagalan yang ada di sistem yang diuji. (Black, 2009:11) 2.2.3.22 Subsystem breakdown Subsystem adalah bagan sederhana dengan pesan penting, untuk memberitahu subsistem yang mengalami paling banyak bug. Seperti grafik root cause, Subsystem breakdown berguna untuk memformat sebagai grafik Pareto, seperti yang ditunjukkan pada gambar dibawah, karena biasanya dua atau tiga subsystem yang paling banyak menderita masalah. (Black, 2009:186) Menambahkan bidang Subsystem memungkinkan untuk menangkap komponen dari sistem yang menanggung beban gejala pada masingmasing bug. (Black, 2009:167-168) Pembagian sistem menjadi subsistem bersifat acak. Dalam beberapa kasus, khususnya proyek-proyek di mana tim bekerja pada setiap subsistem, tugas menjadi lebih mudah. Terlepas dari itu, perlu dibuatkan rincian subsistem yang bermakna untuk setiap proyek, karena tidak bisa dikategorikan jika semua orang memutuskan sendiri apa subsistem yang diuji yang ada di sistem. (Black, 2009:167-168)
26 Gambar 2. 10 Contoh Subsystem Breakdown (Black, 2009:186) 2.2.4 C# dan.net Framework Sintaks C# menyederhanakan banyak kompleksitas C dan menyediakan fitur canggih seperti jenis nilai nullable, enumerations, delegasi, ekspresi lambda dan memori langsung akses, yang tidak ditemukan di Java. Sebagai sebuah bahasa berorientasi objek, C# mendukung konsep enkapsulasi, pewarisan dan polimorfisme. (Microsoft) Sebagai tambahan, C# membuatnya mudah untuk mengembangkan komponen perangkat lunak melalui beberapa inovatif bahasa konstruksi, termasuk yang berikut: Metode enkapsulasi yang disebut delegasi, yang mengaktifkan type-safe event notifications. Properti, yang berfungsi sebagai accesor untuk variabel anggota pribadi. Atribut, yang memberikan deklaratif metadata tentang jenis pada jangka waktu. Inline XML dokumentasi komentar. Language-Integrated Query (LINQ) yang menyediakan kemampuan built-in query di berbagai sumber data. (Microsoft)
27 2.2.5 Unified Model Diagram 2.2.5.1 Activity Diagram Menurut Satzinger, Jackson, dan Burd (2010:141), activity diagram adalah sebuah diagram alur kerja yang menggambarkan berbagai aktivitas user atau sistem, yang melakukan setiap kegiatan, dan aliran kegiatan yang sekuensial. Starting activity (pseudo) menggambarkan titik awal dimulainya suatu aktivitas dari diagram tersebut. Transition arrow menggambarkan alur aktivitas. Activity menggambarkan aktivitas yang ada dalam suatu proses bisnis. Ending activity (pseudo) menggambarkan titik berakhirnya pelaksanaan aktivitas dalam suatu proses bisnis. Synchronization bar digunakan untuk menggambarkan aktivitas-aktivitas yang dilakukan secara bersamaan. Decision activity digunakan untuk menggambarkan pengambilan keputusan yang dilakukan oleh pelaku bisnis. Gambar 2. 11 Simbol-simbol pada Activity Diagram (Satzinger, Jackson, & Burd, 2010) 2.2.5.2 Use Case Diagram Menurut Satzinger, Jackson, dan Burd (2010:141), Use Case Diagram adalah diagram yang menunjukkan berbagai peran user dan cara berinteraksi user dengan sistem.
28 Actor adalah simbol yang menerangkan peran user. Connecting Line adalah suatu simbol yang menunjukkan hubungan antara user dengan kegiatan yang dilakukannya. 2.2.5.3 Use Case Description Menurut Satzinger, Jackson, dan Burd (2010:141), Use Case Description adalah penjelasan suatu use case dengan lebih spesifik. Use Case Description dibagi menjadi tiga, yaitu: Brief Description adalah penjelasan use case secara ringkas dengan menampilkan gambaran tentang use case tersebut. Intermediate Description adalah penjelasan suatu use case yang meliputi tahapan-tahapan dan kondisi pengecualian. Fully Developed Description adalah penjelasan use case yang lebih lengkap, yaitu menggabungkan Brief Description dan Intermediate Description serta menambahkan user yang terlibat, use cases yang terhubung, stakeholders, preconditions, dan postconditions. 2.2.6 Functional System Design Dokumen ini berisi spesifikasi desain layanan TI untuk proyek Service Desk GA. Spesifikasi desain dalam dokumen ini meliputi spesifikasi desain functional requirement dan non functional requirement. Dokumen ini digunakan sebagai dasar untuk : 1. Membangun layanan TI baik yang berupa aplikasi maupun infrastruktur 2. Menetapkan spesifikasi kebutuhan barang ataupun jasa yang akan dibeli (sumber: PT Integrasi Solutions)
29 2.3 Kerangka Pikir ini: Berikut ini merupakan gambaran kerangka pikir dalam penyusunan skripsi Mempelajari proses bisnis dan aplikasi yang ingin ditesting Merancang pengujian Membuat Test Case Melakukan Testing Melakukan Functionality Testing Melakukan Integration Testing Membuat Test Spreadsheet Membuat Bug Report Rekomendasi Testing Gambar 2. 12 Kerangka Pikir Penjelasan kerangka pikir: 1. Langkah yang dilakukan pertama kali adalah mempelajari proses bisnis e-procurement yang sedang berjalan dalam perusahaan XYZ dan menggambarkan proses aplikasi yang sedang dikembangkan. Setelah mempelajarinya maka kita sudah dapat menentukan ruang lingkup dalam proses testing yang ingin di lakukan. 2. Setelah mempelajari proses bisnis dan aplikasi, selanjutnya kami merancang pengujian yang ingin kita lakukan. Kami membuat test scenario dan FMEA (Failure Mode and Effects Analysis) 3. Setelah itu kami menentukan test case yang sesuai dengan test scenario dan FMEA yang telah dibuat sebelumnya.
30 4. Selanjutnya kami mulai melakukan pengujian functionality testing dan integration testing. 5. Selama proses testing, bug tracking spreadsheet akan terus di-update selama proses testing dan juga setelah proses testing selesai dilaksanakan. 6. Dari pelaksanaan testing akan ditemukan bug bug yang harus didata kemudian membuat bug report dan diinformasikan ke pihak yang terkait agar bug dapat diperbaiki. 7. Setelah bug report selesai dibuat maka hasil dari bug report dapat dijadikan rekomendasi untuk memberitahukan informasi mengenai kelemahan atau kekurangan yang ada pada aplikasi yang sedang dikembangkan dan memberikan saran untuk menangani kelemahan yang ada dalam aplikasi