9
BAB 2
LANDASAN TEORI
2.1. Teori-Teori Dasar/Umum
Dalam mendukung penulisan skripsi ini, maka berikut teori-teori dasar yang digunakan oleh penulis sebagai referensi.
2.1.1. Pengertian Data
Menurut Considine et al (2012: 7), data adalah fakta mentah yang berhubungan atau menjelaskan suatu kejadian. Sedangkan menurut Rainer, dan Cegielski (2011: 10), Data merujuk pada deskripsi dasar suatu benda, kejadian, aktivitas dan transaksi yang direkam, diklasifikasikan,dan disimpan tetapi tidak disusun untuk mengungkapkan arti tertentu. Contohnya angka, huruf, figur, suara, dan gambar.
2.1.2. Pengertian Informasi
Menurut Rainer, dan Cegielski (2011: 10), informasi adalah data yang telah disusun sehingga data-data tersebu memiliki arti dan nilai bagi penerimanya. Menurut Considine et al (2012: 103), informasi berasal dari fakta atau data yang diproses dalam bentuk yang bermakna. Bentuk dari informasi harus memenuhi tujuan dari informasi tersebut.
2.1.3. Pengertian Sistem
Menurut Satzinger, Jackson, dan Burd (2010: 6 ), sistem adalah kumpulan dari komponen-kompenen yang saling berkaitan yang bekerja bersama untuk mencapai beberapa tujuan. Sistem apapun dapat mempunyai
subsistem. Subsistem adalah sebuah sistem yang merupakan bagian dari sistem yang lain. Jadi subsistem dapat menjadi satu cara untuk berpikir tentang komponen dari sebuah sistem. Pemahaman sistem sebagai gabungan antara subsistem sangat berguna untuk para analis karena memampuhkan para analis untuk memfokuskan diri pada suatu area tertentu. Supersistem adalah sistem yang lebih besar yang mempunyai sistem-sistem yang lebih kecil di dalamnya.
2.1.4. Pengertian Sistem Informasi
Menurut Satzinger, Jackson, dan Burd (2010: 6), sistem informasi adalah sekumpulan dari komponen-komponen yang berkaitan yang mengumpulkan, memproses, dan menyediakannya sebagai output informasi yang dibutuhkan untuk menyelesaikan tugas-tugas bisnis.
2.1.5. Pengertian Implementasi
Menurut McLeod dan Schell (2004: 144), implementasi adalah kegiatan memperoleh dan mengintegrasikan sumber daya fisik dan konseptual yang menghasilkan suatu sistem yang bekerja.
2.1.6. Pendekatan Implementasi Sistem
Menurut McLeod dan Schell (2004 : 147), ada empat pendekatan dasar dalam tahap implementasi sistem:
a. Pilot adalah suatu sistem percobaan yang diterapkan dalam satu subset dari keseluruhan operasi seperti satu kantor atau daerah tertentu.
b. Immediate adalah pendekatan yang paling sederhana, yaitu peralihan dari sistem lama ke sistem baru pada satu hari tertentu. Namun pendekatan ini hanya layak bagi perusahaan kecil atau sistem kecil, karena permasalahan waktu semakin besar saat skala operasi meningkat.
c. Phased adalah pendekatan dimana sistem yang baru digunakan bagian per bagian pada suatu waktu.
d. Parallel adalah pendekatan dimana sistem lama harus dipertahankan sampai sistem baru diperiksa secara menyeluruh. Pendekatan ini memberikan pengamanan yang paling baik terhadap kegagalan tetapi merupakan yang paling mahal karena kedua sumber daya dipertahankan.
2.1.7. Pengertian ERP(Enterprise Resources Planning)
Menurut O’Brien (2006 : 320), Enterprise Resources Planning (ERP) adalah suatu tulang punggung lintas fungsi perusahaan yang mengintegrasikan dan mengotomatisasi banyak proses internal dan sistem informasi dalam hal fungsi produksi, logistik, distribusi, akuntansi, keuangan, dan sumber data manusia perusahaan. Menurut Brady (2001 :2), perangkat lunak Enterprise Resources Planning (ERP) membantu untuk mengatur proses bisnis perusahaan, menggunakan database umum dan pengaturan peralatan perlaporan bersama. ERP mendukung operasi yang efisien dari proses bisnis dengan mengintegrasikan aktivitas bisnis, termasuk penjualan, pemasaran, manufaktur, keuangan, dan sumber daya manusia.
2.1.8. SAP
Menurut Brady, Monk, dan Wagner (2001 :21), SAP diperkenalkan pada tahun 1972, berasal dari bahas Jerman yang berarti systeme, anwendungen, and produkte in derdatenverarbeitung, dan dalam bahasa inggris yaitu systems and applications, and products in data processing. SAP merupakan vendor utama software ERP di Mannheim, Jerman yang dibangun oleh 5 orang dari IBM.
Menurut Brady, Monk, dan Wagner (2001 :23), modul-modul SAP terdiri dari :
a. Sales and Distribution (SD)
Modul Sales and Distribution (SD) mencatat pesanan dan pengiriman yang telah terjadwal. Informasi tentang pelanggan (harga, bagaimana dan dimana produk akan dikirim, bagaimana pelanggan membayar tagihan, dan sebagainya) diatur dan diakses dalam modul ini.
b. Material Management (MM)
Modul Material Management (MM) mengelola pengadaan bahan baku dari supplier dan kemudian menangani inventory bahan baku, dari penyimpanan untuk barang yang sedang diproses hingga inventory barang jadi.
c. Production Planning (PP)
Modul Production Planning (PP) memelihara informasi mengenai produksi. Disinilah produksi direncanakan dan dijadwalkan, dan aktivitas produksi yang sesungguhnya dicatat.
d. Quality Management (QM)
Modul Quality Management (QM) membantu perencanaan dan pencatatan aktivitas pengendalian kualitas, seperti inspeksi produk dan keterangan material.
e. Plant Maintenance (PM)
Modul Plant Maintenance (PM) memungkinkan perencanaan untuk pemeliharaan mesin-mesin pabrik, dan mengelola pemeliharaan sumber daya, sehingga gangguan peralatan dapat diminimalisasi.
f. Human Resource (HR)
Modul Human Resource (HR) memudahkan perekrutan, penyewaan, dan pelatihan karyawan, termasuk juga penggajian dan laba.
g. Financial Accounting (FI)
Modul Financial Accounting (FI) mencatat transaksi dalam akun buku besar. Ini menghasilkan financial statement untuk tujuan laporan eksternal.
h. Controlling (CO)
Modul Controlling (CO) digunakan untuk tujuan manajemen internal. Disini, biaya perusahaan manufaktur ditetapkan untuk produksi dan untuk cost center, mempermudahkan analisis biaya.
i. Asset Management (AM)
Modul Asset Management (AM) membantu perusahaan untuk mengatur pembelian aset tetap (pabrik dan mesin) dan depresiasi nilai yang berhubungan.
j. Project System(PS)
Modul Project System(PS) memungkinkan perencanaan dan mengendalikan R&D, kontruksi, dan proyek pemasaran yang baru. Modul ini memungkinkan biaya proyek dikumpulkan dan seringkali digunakan untuk mengatur implementasi sistem SAP.
k. Workflow(WF)
Modul Workflow(WF) dapat digunakan untuk mengotomastisasi beberapa aktivitas dalam sistem. Ini dapat menunjukkan analisis aliran tugas dan karyawan dengan cepat dan tepat jika mereka membutuhkan suatu aksi.
l. Industry Solution (IS)
Modul Industry Solution (IS) mengandung pengaturan konfigurasi yang telah ditemukan SAP cocok dengan industri khusus. Pengaturan ini menyederhanakan implementasi dan memungkinkan pembeli mengambil keuntungan dalam pengalaman industri SAP.
2.2. Teori-Teori Khusus
Teori-teori pendukung lain yang penulis gunakan sebagai referensi adalah sebagai berikut.
2.2.1Pengertian Manajemen Sumber Daya Manusia
Menurut Robbins dan Coulter (2004 : 305), proses manajemen sumber daya manusia adalah berbagai kegiatan yang diperlukan untuk mengisi staf dan mempertahankan karyawan yang berkinerja tinggi. Gambar 2.1 dapat menunjukkan proses manajeman sumber daya manusia.
Gambar 2. 1 Proses manajemen sumber daya manusia
2.2.1.1Pengertian Perencanaan Sumber Daya Manusia
Menurut Robbins dan Coulter (2004 : 307), perencanaan sumber daya adalah proses yang dilakukan para manajer untuk menjamin bahwa mereka memiliki jumlah dan jenis orang yang tepat, dan pada saat yang tepat, yang mampu menyelesaikan sejumlah tugas yang dibebankan secara efektif dan efisien. Perencanaan sumber daya manusia dapat diringkas menjadi tiga langkah:
a. Menilai sumber daya manusia yang ada sekarang. b. Menilai kebutuhan sumber daya manusia di masa depan.
c. Menyusun program untuk memenuhi kebutuhan di masa depan tersebut.
2.2.1.2 Pengertian Perekrutan dan Pelepasan
Menurut Robbins dan Coulter (2004 : 309), perekrutan adalah proses mencari, mengidentifikasi, dan menarik para calon yang berkemampuan,
sedangkan pelepasan adalah sejumlah teknik untuk mengurangi pasokan tenaga kerja di dalam organisasi.
2.2.1.3 Pengertian Penyeleksian
Menurut Robbins dan Coulter (2004 : 310), proses seleksi adalah proses penyaringan pelamar kerja untuk memastikan bahwa kandidat yang paling layak yang akan dipekerjakan. Perangkat-perangkat yang dapat digunakan dalam seleksi antara lain : formulir aplikasi, tes tertulis, tes simulasi kinerja, wawancara, penyelidikan latar belakang dan pemeriksaan fiksi.
2.2.1.4Pengertian Orientasi
Menurut Robbins dan Coulter (2004 : 316), orientasi adalah perkenalan karyawan baru dengan pekerjaan dan organisasinya. Ada dua jenis orientasi :
a. Orientasi unit kerja : mengakrabkan karyawan itu dengan sasaran unit kerja tersebut, memperjelas bagaimana pekerjaannya menyumbang pada sasaran unit itu, dan mencakup perkenalan dengan rekan-rekan kerja barunya.
b. Orientasi organisasi: memberi tahu karyawan baru mengenai tujuan, riwayat, filosofi, prosedur, dan peraturan organisasi tersebut. Itu harus mencakup tunjangan kebijakan dan tunjangan sumber daya manusia yang relevan seperti jam kerja, prosedur penggajian, tuntutan lembur, dan tunjangan tambahan.
2.2.1.5 Pengertian Pelatihan
Menurut Robbins dan Coulter (2004 : 317), keterampilan karyawan dapat dikelompokkan menjadi tiga kategori: keterampilan teknis, antar pribadi, dan penyelesaian masalah.Kebanyakan pelatihan diarahkan untuk meningkatkan dan memperbaiki keterampilan teknis karyawan, yang mencakup keterampilan dasar-kemampuan membaca, menulis, dan melakukan perhitungan matematik- maupun kompetensi khusus yang berkaitan dengan pekerjaan.
2.2.1.6 Pengertian Manajemen Kinerja
Menurut Robbins dan Coulter (2004 : 319), sistem manajemen kinerja adalah suatu proses menetapkan standard kinerja dan menilai kinerja untuk tiba pada keputusan SDM yang obyektif sehingga dapat memberikan dokumentasi untuk mendukung keputusan itu. Metode penilaian kinerja yang dapat dipilih adalah sebagai berikut:
a. Essay tertulis : suatu teknik penilaian kinerja dimana seorang penilai menuliskan deskripsi dari keunggulan dan kelemahan karyawan, kinerja masa lalu, dan potensinya.
b. Insiden kritis :suatu teknik penilaian kinerja dimana seorang penilai berfokus pada sikap yang menonjol yang memisahkan kinerja pekerjaan yang efektif dan tak efektif.
c. Skala pemeringkat grafis : Teknik penilaian kinerja dimana karyawan dinilai berdasar serangkaian faktor kinerja.
d. BARS(skala pemeringkat berdasarkan perilaku): Teknik penilaian kinerja yang menilai karyawan berdasarkan contoh perilaku yang sebenarnya.
e. Perbandingan banyak orang : Teknik penilaian kinerja yang membandingkan kinerja seseorang dengan satu orang lain atau lebih. f. MBO (manajemen berdasar tujuan): para karyawan dievaluasi berdasar
seberapa baik mereka mencapai serangkaian sasaran tertentu yang telah ditentukan sebagai faktor penentu keberhasilan penyelesaian pekerjaan. g. Penilaian 360 derajat : metode penilaian kinerja yang menggunakan
umpan balik dari karyawan, dan rekan kerja.
2.2.1.7 Pengertian Kompensasi dan Tunjangan
Menurut Robbins dan Coulter (2004 : 321), menyusun sistem kompensasi yang efektif dan efisien merupakan bagian penting proses manajemen atau pengelolaan sumber daya manusia. Sistem kompensasi yang efektif dan memadai dapat membantu menarik dan mempertahankan orang-orang yang kompeten dan berbakat yang dapat membantu organisasi tersebut mencapai misi dan sasarannya. Selain itu, sistem kompensasi sebuah organisasi telah terbukti mempunyai dampak pada kinerja strategis. Beberapa faktor yang dapat mempengaruhi kompensasi dan tunjangan karyawan adalah :
a. Jabatan dan kinerja karyawan : Berapa lamakah karyawan bekerja di perusahaan dan bagaimana kinerjanya?
b. Jenis pekerjaan yang dilakukan : Apakah pekerjaan memerlukan tingkatan keahlian yang tinggi?
c. Jenis bisnis : Termasuk dalam industri apakah perkerjaan ini? d. Serikat buruh: Apakah perusahaan ini berserikat?
e. Padat tenaga kerja atau padat modal : Apakah perusahaan ini padat tenaga kerja atau padat modal?
f. Filosofi manajemen : Apakah filosofi manajemen mengenai pengupahan?
g. Lokasi geografis : Di manakah organisasi itu terletak?
h. Profitabilitas perusahaan : Seberapa besar profitabilitas perusahaan ini? i. Ukuran perusahaan : Seberapa besarkah perusahaan ini?
2.2.1.8 Pengertian Pengembangan Karir
Menurut Robbins dan Coulter (2004 : 322), salah satu keputusan karier pertama harus dibuat adalah pemilihan karier. Pilihan karier yang optimum adalah pilihan yang memberikan kecocokan yang paling baik antara apa yang dikehendaki dari hidup dan minat, kemampuan, serta peluang pasar. Hasil pilihan karier yang baik harus menghasilkan serangkaian posisi yang memberi peluang untuk menjadi pekerja yang berkinerja tinggi, meningkatkan keinginan untuk mempertahankan komitmen terhadap karier , menghasilkan pekerjaan yang sangat memuaskan, dan memberi keseimbangan yang wajar antara kehidupan kerja dan kehidupan pribadi.
2.2.2 mySAP ERP Human Capital Management
Menurut Anonim 2 (2006:6-2), perusahaan dapat memaksimalkan nilai dari karyawan dan menyeleraskan kemampuan, aktivitas dan insentif yang dimiliki karyawan dengan tujuan dan strategi bisnis. mySAP ERP HCM juga menyediakan tools untuk mengatur, mengukur, dan memberi penghargaan terhadap konstribusi dari individu maupun tim.
Menurut Anonim 2 (2006: 6-3), Elemen-elemen mySAP ERP HCM a. Organizational management
b. Applicant data
c. Personnel management
d. Personnel development
e. Training and event management
f. Time management
g. Appraisal h. Payroll
i. Personnel cost planning
2.2.2.1 The Organizational Plan/ Organizational Management
Elemen Organizational Management digunakan untuk memetakan struktur organisasi perusahaan dan struktur pelaporan organisasi yang relevan dengan objek dengan cepat dan efektif.
Menurut Anonim1 (2006:27),Organizational Plan adalah sebuah model yang komperhensif dan dinamis dari lingkungan struktural dan personil suatu perusahaan.
Menurut Anonim2 (2006:6-3), Istilah-istilah kunci yang digunakan dalam Organizational Management :
a. Organizational Unit
Organizational Unit menggambarkan berbagai unit bisnis yang ada pada suatu organisasi. Organizationa Unit dapat dibagi berdasarkan kriteria fungsional dan regional
b. Jobs
Jobs adalah deskripsi umum atau template yang berlaku untuk beberapa posisi dengan persyaratan, tugas dan karakteristik yang sebanding.
c. Positions
Positions adalah unit organisasional terkecil dalam struktur organisasi. Positions menggambarkan pendistribusian tugas kepada karyawan dalam suatu organisasi.
d. Persons
Orang yang menempati suatu posisi dalam struktur organisasi. Persons mewakili karyawan-karyawan yang ada pada organisasi. Data dari karyawan tersebut dimaintained di Personel Management.
2.2.2.2 Recruitment
Menurut Anonim1 (2006:54) ,komponen Recruitment digunakan untuk menangani seluruh proses perekrutan dari memasukkan data pelamar sampai menentukan posisi staff. Hal ini berlaku bagi pelamar eksternal dan karyawan internal yang ingin mengganti posisi. Menurut Anonim2 (2006:6-4), persyaratan kepegawaian digambarkan dalam Vacancies. Vacancies adalah posisi yang perlu diisi. mySAP ERP HCM menggambarkan persyaratan karyawan, periklanan, mengatur dan memilih pelamar, dan korespondensi dari pelamar.
Proses umum dalam recruitment:
a. Posisi yang kosong akan diumumkan pada iklan lowongan pekerjaan.
b. Data pelamar dimasukkan kedalam sistem (nama, alamat, kualifikasi, dsb)
c. Proses seleksi yang rumit, keputusan dibuat.
d. Kontrak pekerjaan dibuat untuk pelamar yang diterima. e. Data pelamar ditransfer ke master data HCM
2.2.2.3 Personnel Management
Menurut Anonim2 (2006:6-6), integrasi antara Recruitment dan Personnel Administration memungkinkan data pelamar ditransfer sebagai data karyawan. Data karyawan disimpan pada mySAP ERP HCM sebagai infotype. Data tersebut dapat ditampilkan, di-copy, dikoreksi, dan dihapus. Infotype dapat dimaintain dengan beberapa cara, yaitu:
a. Single-screen maintainance (satu infotype untuk satu orang) b. Personnel actions (serangkaian infotype untuk satu orang) c. Fast entry (satu infotype untuk banyak orang)
2.2.2.4 Personnel Development
Menurut Anonim2 (2006:6-8), dengan komponen Personnel Development, anda dapat merencanakan dan menyadari pengembangan personil dan pendidikan serta training lebih lanjut untuk karyawan. Persyaratan Personnel Development didapat dari perbandingan antara kebutuhan dari suatu pekerjaan dan kualifikasi yang dimiliki karyawan.
2.2.2.5 Training and Event Management
Menurut Anonim2 (2006:6-9), Training and Event Management adalah komponen yang sangat terintegrasi yang membantu dalam
merencanakan, melaksanakan, mengatur training dan event bisnis. Ada 4 proses utama dalam training and event management, yaitu:
a. Business Event Preparation
Meliputi semua data yang dibutuhkan pada saat membuat business event catalog tersebut digambarkan dengan menggunakan hirarki yang terdiri dari business event group dan business event type.
b. The Business Event Catalog
The Business Event Catalog kemudian dibuat, tanggal event yang direncanakan dan dibuat di dalam sistem.
c. Ketika tanggal telah tersedia, day-to day activities seperti booking, rebooking, atau pembatalan business event untuk peserta internal maupun eksternal mungkin saja terjadi.
d. Recurring Activities sangat erat hubungannya dengan day-to-day activities. Setelah sebuah training, peserta dapat menulis penilaian atas training tersebut. Jika peserta internal, kualifikasi baru dapat ditransfer ke subprofiles di personnel development
2.2.2.6 Time Management
Menurut Anonim2 (2006:6-11), komponen Time Management dapat digunakan untuk mendukung semua proses yang berhubungan dengan perencanaan, pencatatan dan penilaian waktu kehadiran dan ketidakhadiran karyawan.
Ada beberapa pilihan untuk mencatat data waktu seperti waktu kerja, perjalanan off-site work, atau penggantian, yaitu sebagai berikut:
b. Menggunakan sistem pencatatan waktu front-end
c. Menggunakan mySAP ERP Cross-Application Time Sheet(CATS)
2.2.2.7 Appraisal
Menurut Anonim2 (2006:6-12), fungsionalitas Appraisal mendukung proses Appraisal yang fleksibel yang dapat digunakan untuk melaksanakan standar Appraisal dengan objektivitas tertinggi. Hal ini berlaku tidak hanya pada penilaian personil yang tradisional, tetapi juga berlaku bagi penilaian business event dan karyawan online ataupun survey pelanggan dengan menggunakan layanan internet maupun intranet.
Tahap-tahap dari suatu proses Appraisal meliputi semua tahap-tahap yang biasanya terdapat pada proses appraisal seperti perencanaan, review dan pelaksanaan penilaian serta evaluasi dari Appraisal yang diajukan.
2.2.2.8 Payroll
Menurut Anonim2 (2006:6-13), pada umumnya Payroll terkonsentrasi pada perhitungan gaji karyawan, secara lebih spesifik, payroll meliputi banyak proses, seperti pembuatan hasil penggajian dan laporan gaji, transfer bank, dan pembayaran dengan cek. Proses tersebut meliputi sejumlah aktivitas yang berkesinambungan seperti pengiriman hasil penggajian ke mySAP ERP Financial.
Perhitungan pemberian gaji dilakukan dengan tahap berikut ini: a. Mengumpulkan elemen gaji dan hasilnya adalah gaji kotor. b. Pengurangan secara hukum dan sukarela hasilnya adalah gaji
2.2.2.9 Personnel Cost Planning
Menurut Anonim2 (2006:6-14), personnel Cost Planning mendukung proses bisnis yang melampaui batas-batas departemen dan aplikasi. Informasi mengenai pembayaran didapat dari berbagai sumber, informasi tersebut digunakan untuk membuat perencanaan biaya untuk Personil.
Ketika perencanaan tersebut telah dibuat, data tersebut dapat digunakan untuk banyak proses, seperti:
a. Membuat anggaran training untuk Training and Event Management
b. Transfer data ke Controlling.
c. Pembuatan proyeksi biaya untuk analisis lebih lanjut pada SAP Business Information Warehouse.
2.2.3 Pengertian Testing
Menurut Quadri dan Farooq (2010: 1), pengujian software adalah proses verifikasi dan validasi apakah sebuah aplikasi software atau program memenuhi persyaratan bisnis dan persyaratan teknis yang mengarahkan desain dan pengembangan dan cara kerjanya seperti yang diharapkan dan juga mengidentifikasi kesalahan yang penting yang digolongkan berdasarkan tingkat severity pada aplikasi yang harus diperbaiki.
Menurut Nidhra dan Dondeti (2012:1), pengujian software adalah teknik yang sering digunakan untuk verifikasi dan validasi kualitas suatu software. Pengujian software adalah prosedur untuk eksekusi sebuah program atau sistem dengan tujuan untuk menemukan kesalahan.
Kesimpulan yang dapat diambil dari pendapat-pendapat tersebut adalah pengujian software merupakan proses verifikasi dan validasi apakah software memenuhi requirement dan mengidentifikasi kesalahan-kesalahan yang ditemukan saat eksekusi program.
2.2.4 Granularity Test
Menurut Black (2009 :2), test granularity mengacu pada kehalusan atau kekasaran fokus tes. Test case yang halus mengijinkan tester untuk memeriksa detil pada tingkat rendah, biasa pada internal sistem. Test case yang kasar memberikan informasi tentang perilaku sistem secara umum kepada tester.
Ada tiga spektrum pada test granularity, yaitu : a. Structural(White Box) Tests
b. Behavioral (Black Box) Tests c. Live Tests
2.2.4.1 Structural (White-Box Test)
Menurut Black (2009 :2), Structural test (atau yang biasa disebut white-box tests dan glass-box tests) menemukan bug dalam elemen struktur tingkat rendah seperti yang terjadi di tingkatan code , data base scemas, chips, subassemblies dan interfaces. Pengujian struktural ini didasarkan pada bagaimana suatu sistem beroperasi. Contohnya, pengujian struktural akan mengungkapkan tempat penyimpanan database masih memiliki ruang penyimpanan username sebanyak 80 karakter, tetapi pada kenyataannya hanya memungkinkan menyimpan 40 karakter.
Pengujian struktural melibatkan pengetahuan teknis terperinci dari sistem. Untuk menguji software, tester membuat pengujian yang paling struktural dengan melihat kode dan struktur data itu sendiri. Untuk pengujian hardware, tester membuat pengujian struktural untuk membandingkan spesifikasi chip untuk pembacaan oscilloscopes atau meter tegangan.
2.2.4.2 Behavioral (Black-Box) Tests
Menurut Black (2009 :3), Tester menggunakan behavioral test (disebut juga Black-Box Tests), sering digunakan untuk menemukan bug dalam high level operations, pada tingkatan fitur, profil operasional dan skenario customer. Tester dapat membuat pengujian fungsional black box berdasarkan pada apa yang harus sistem lakukan. Behavioral testing melibatkan pemahaman rinci mengenai domain aplikasi, masalah bisnis yang dipecahkan oleh sistem dan misi yang dilakukan sistem. Behavioral test paling baik dilakukan oleh penguji yang memahami desain sistem, setidaknya pada tingkat yang tinggi sehingga mereka dapat secara efektif menemukan bug umum untuk jenis desain.
Menurut Nidhra dan Dondeti (2012:1), black box testing juga disebut functional testing, sebuah teknik pengujian fungsional yang merancang test case berdasarkan informasi dari spesifikasi.
2.2.4.3 Live Test
Menurut Black (2009 :4), Live test mengikutsertakan customer, content experts, early adopter, dan end user lainnya dalam pengujian sistem. Dalam beberapa kasus, penulis mendorong tester untuk mencoba
menelusuri sistem tersebut. Beta testing merupakan salah satu bug-driven live test yang dikenal.
2.2.5Pengertian Product Specification
Menurut McArthur dan Shepard (2000 :108) product specification menyediakan semua rincian teknis suatu produk yang dihasilkan. Hal ini diberikan kepada orang-orang yang akan memproduksi produk. Ini membantu memastikan bahwa produk tersebut identik dan memiliki kualitas yang diperlukan.
2.2.6Pengertian Technical Specification
Menurut Berkun (2008 : 139) technical specification menjelaskan detil gambaran dari komponen yang paling rumit atau komponen yang digunakan kembali oleh programmer lain dan untuk menyediakan petunjuk untuk pekerjaan yang membutuhkan spesifikasi fitur.
2.2.7Pengertian Quality Risk Analysis
Menurut Shirouyehzad, Dabestani, dan Badakhshian (2011:1) Risk analysis adalah suatu pendekatan yang tepat untuk membedakan dan mengevaluasi critical failure factors (CFF). Identifikasi resiko menghasilkan daftar spesifik proyek dan resiko yang kemungkinan mengakibatkan kegagalan proyek. Salah satu metode yang dapat mengidentifikasi dan memprioritaskan CFF adalah failure mode and effect analysis (FMEA).
2.2.8Pengertian Failure Mode and Effect Analysis (FMEA)
Menurut Black (2009 :32), pada dasarnya FMEA adalah suatu teknik untuk memahami dan memprioritaskan failure modes atau quality risk dalam fungsi sistem, fitur, atribut, perilaku, komponen, dan interface. Contoh FMEA :
Gambar 2. 2 Contoh FMEA Ada beberapa kolom pada FMEA yaitu :
a. System Function or Feature
Kolom ini merupakan titik mulai dari analisis FMEA, berisi deksripsi fungsi dari suatu kategori. Untuk memperoleh level detil yang tepat cukup rumit. Dengan detil yang telalu banyak, akan tercipta chart yang telalu panjang dan sulit untuk dibaca. Dengan detil yang telalu sedikit, akan tecipta banyak failure modes yang dihubungkan pada setiap fungsi.
b. Potential Failure Mode(s)-Quality Risk (s)
Pada kolom ini, untuk setiap fungsi atau fitur akan diidentifikasi cara untuk menemukan kesalahan tersebut. Quality risk berhubungan
dengan hilangnya fungsi sistem tertentu. Setiap fungsi atau fitur tertentu dapat memiliki banyak failure modes.
c. Potential Effect(s) of Failure
Pada kolom Potential Effect(s) of Failure, akan dijabarkan bagaimana setiap failure mode dapat mempengaruhi user.
d. Critical
Pada kolom ini, diidentifikasi apakah pengaruh yang potensial memberikan konsekuensi yang kritis bagi user. Apakah fitur produk atau fungsi sepenuhnya tidak berguna jika failure mode terjadi? e. Severity
Pada kolom ini berisi nilai efek dari kesalahan pada sistem( baik yang langsung atau tidak). Sebagai contoh skala yang dapat digunakan pada kolom ini dari 1(paling tinggi)-5(paling rendah) menandakan tingkatan efek.
f. Potential Cause(s) of Failure
Kolom ini berisi daftar faktor-faktor yang memungkinkan untuk menicu terjadinya kesalahan.
g. Priority
Kolom priority berisi nilai efek kesalahan pada user, customer, atau operator. Sebagai contoh skala yang dapat digunakan pada kolom ini dari 1(paling tinggi)-5(paling rendah) menandakan tingkatan efek. h. Detection Method(s)
Kolom ini berisi metode atau prosedur yang ada sekarang , sebagai contoh development activities atau vendor testing, yang dapat membantu menemukan masalah sebelum mempengaruhi user.
i. Likelihood
Kolom ini berisi angka-angka yang merepresentasikan kerentanan kesalahan sistem berdasarkan keberadaan dalam produk (contoh berdasarkan faktor resiko teknis seperti kompleksitas dan historis kecacatan), lepas dari proses development, dan gangguan pada operasi user. Sebagai contoh skala yang dapat digunakan pada kolom ini dari 1(paling tinggi)-5(paling rendah) menandakan tingkatan kerentanan sistem.
j. Risk Pri No
Kolom yang memberikan informasi seberapa penting untuk menguji failure mode tertentu. RPN merupakan hasil perkalian dari nilai severity,priority, dan likelihood. Berdasarkan contoh nilai dari ketiga parameter tersebut 1-5 maka nilai RPN antar 1-125.
k. Recommended Action
Kolom ini mengandung satau atau lebih action item sederhana untuk setiap efek potensial untuk mengurangi resiko tersebut.
l. Who/When?
Kolom ini mengidentifikasi siapa yang bertanggung jawab terhadap tiap aksi yang diusulkan dan kapan tanggung jawab tersebut akan dijalankan.
m. References
Kolom ini menyediakan referensi untuk informasi lebih tentang quality risk. Biasanya mengacu pada product specification, dokumen requirement, atau dokumen lainnya.
2.2.9 Test Phases
Menurut Black (2009 :4), perusahaan cenderung untuk mengadopsi sebuah pendekatan partitioning testing hingga urutan dalam fase-fase (biasanya disebut level). Berikut adalah bermacam-macam fase pengujian :
a. Unit Testing
Unit testing memfokuskan pada sebuah potongan kode. Dengan bahasa pemograman seperti C, unit testing harus mengikutsertakan suatu fungsi tunggal.
b. Component atau subsystem testing
Componen testing berlaku untuk sekelompok unit yang menyajikan beberapa set kemampuan sistem. Jadi, component testing adalah pengujian terhadap sekelompok unit sistem yang memberikan suatuset fungsi tertentu.
c. Integration atau product testing
Integration atau product testing berfokus pada hubungan dan interface antara pasangan komponen dan kelompok komponen dalam sistem yang sedang diuji.
d. String testing
String testing berfokus pada masalah dalam penggunaan script tertentu dan string operasional customer. Pengujian string mungkin mengikutsertakan kasus seperti dokumen enkripsi dan dekripsi dokumen, atau pembuatan, pencetakan, dan menyimpan sebuah dokumen.
System testing mencakup seluruh sistem yang terintegrasi. Biasanya seperti pada installation dan usability testing, pengujian ini melihat suatu sistem dari pandangan customer dan end user.
f. User Acceptance Testing
Tujuan dari pengujian ini adalah mendemonstrasikan bahwa sistem memenuhi persyaratan. Pada pengembangan software and hardware komersial, acceptance test kadang-kadang disebut alpha dan beta test. Alpha dan beta test dijalankan untuk mendemonstrasikan kesiapan suatu produk di pasaran, walaupun banyak organisasi juga menggunakan pengujian ini untuk menemukan bug yang tidak terdekteksi saat proses pengujian sistem.
g. Pilot Testing
Pilot testing menguji kemampuan perakitan untuk produksi masal sistem yang telah diselesaikan.
Berdasarkan penjelasan di atas, maka pengujian sistem SAP HR Sinarmas Land, digunakan metode Component atau subsystem testing yang disebut juga Functionality testing dan Integration atau product testing.
2.2.10 Report Testing
Menurut Protiviti (2010:2), report testing adalah proses menelaah keakuratan dan kelengkapan laporan-laporan utama. Akurat merupakan ketepatan atau kebenaran dari dokumen-dokumen sumber yang ada pada laporan seperti komponen-komponen yang muncul dalam laporan yang dapat ditelusuri ke dokumen sumbernya dan dikonfirmasikan kebenarannya.
Kelengkapan berarti dapat dimengertinya dan tersedianya data-data yang diinginkan dalam laporan.
Pendekatan pengujian laporan menurut Protiviti (2010:4) adalah : a. Recalculation : Tergantung pada jenis laporan, recalculation
dapat dijalankan berdasarkan porsi dari laporan atau dengan menjumlahkan berbagai macam subtotal untuk melaporkan grand total dalam laporan. Digunakan dalam laporan atau paket laporan yang melakukan kalkulasi yang diinginkan.
b. Accuracy Testing : Pengujian ini melibatkan "back-tracing" pada contoh transaksi pada pengujian performa laporan terhadap sumber data. Dapat disimpulkan bahwa pengujian akurasi ini mencocokan kesesuaian data yang ditampilkan pada laporan dengan sumber data.
c. Completeness Testing : Pengujian ini melibatkan "forward -tracing" pada contoh transaksi dari sumber data ke laporan. Memastikan bahwa element dari contoh data yang harus muncul pada laporan, pada kenyataan muncul dalam laporan dan memberikan kepastian bahwa laporan menampilkan satu set lengkap informasi bagi end user.
2.2.11 Transitions
Menurut Black (2009 :56), pada setiap fase pengujian, sistem yang diuji harus memenuhi satu set kualifikasi minimal sebelum organisasi pengujian dapat menjalankan pengujian secara efektif dan efisien. Transition harus dapat menjabarkan kriteria yang penting untuk memulai dan menyelesaikan berbagai fase pengujian (dan untuk melanjutkan sebuah
proses pengujian yang efektif dan efisien). Kriteria yang biasanya digunakan adalah :
a. Entry Criteria
Entry Criteria menjabarkan apa yang harus terjadi untuk mengijinkan sebuah sistem dilanjutkan ke tahap pengujian berikutnya.
b. Stopping Criteria
Stopping Criteria merupakan kriteria yang digunakan oleh penguji profesional yang menentukan kapan pengujian harus berhenti sesuai dengan kondisi yang telah dijabarkan pada kriteria ini.
c. Continuation Criteria
Continuation Criteria mendefiniskan kondisi dan situasi yang harus berlaku dalam proses pengujian untuk mengijinkan pengujian dilanjutkan secara efektif dan efisien.
d. Exit Criteria
Exit Criteria menjelaskan bagaimana menentukan kapan proyek telah selesai melakukan pengujian.
2.2.12 Pengertian Test Case
Menurut Black (2009 :610), Test case adalah urutan langkah-langkah, substep, dan tindakan-tindakan lain yang dilakukan secara bertahap atau paralel, atau kombinasi turutan, yang membuat kondisi pengujian yang dirancang untuk dievaluasi dari test case.
Quadri dan Farooq (2010: 2) mengatakan bahwa user requirement harus diketahui sebelum merancang test case. Sebuah test case harus
mengandung sebuah deskripsi dari output yang benar dari program untuk satu set input data.
2.2.13 Test Case Life Cycle
Gambar 2. 3 Test case life cycle
Menurut Black (2009 :208), ada beberapa kemungkinan status test case. Beberapa siklus hidup test case yang digunakan antara lain(seperti pada gambar 2.3) :
a. Queue
Test case siap untuk dijalankan, dan diassign pada tester untuk dieksekusi.
b. In Progress
Pengujian sedang dijalankan dan akan dilanjutkan untuk beberapa saat.
c.Block
Kondisi seperti kehilangan potongan fungsi atau kekurangan sebuah komponen penting dalam pengujian sehingga menghalangi tester untuk menjalankan pengujian.
d. Skip
Pengujian dilewati karena prioritas pengujiannya yang relatif rendah. Tester dapat melakukan pengujian namun tester tidak ingin menjalankan pengujian tersebut.
e. Pass
Test case berhasil dijalankan dan tester hanya menemukan hasil yang diharapkan , status dan perilaku yang diharapkan.
f. Fail
Dalam satu atau dua cara, tester menemukan hasil, status dan perilaku yang tidak diharapkan yang mempertanyakan kualitas sistem pada pencapaian tujuan pengujian.
g. Warn
Dalam satu atau dua cara, tester menemukan hasil, status dan perilaku yang tidak diharapkan, tapi kualitas sistem tidak menggangu pencapaian tujuan pengujian.
h. Closed
Untuk test case yang telah ditandai dengan fail atau warn dalam siklus pengujian yang pertama, dan untuk rilis pengujian berikutnya bug tersebut telah diperbaiki.
2.2.14 Pengertian Bug
Menurut Black (2009 :601), bug adalah sebuah masalah yang ada pada sistem yang sedang diuji yang mengakibatkan sistem gagal untuk memenuhi hasil yang diharapkan, biasanya disebut juga cacat. Gejala dari bug adalah kegagalan atau kesalahan.
2.2.14.1 Pengertian Bug Report
Black (2009 :146) mengatakan bahwa bug report adalah sebuah dokumen teknis yang mendeskripsikan berbagai gejala atau model
kesalahan yang berhubungan dengan satu bug tertentu. Sebuah bug report yang baik menangkap informasi yang dibutuhkan oleh seorang programmer untuk memperbaiki masalah. Contoh Bug report :
Gambar 2. 4 Bug detail report
2.2.14.2 Bug Report Life Cycle
Dalam pengujian tester dapat menemukan bug dalam sistem yang akan dicatat dalam laporan bug atau bug report. Untuk mempermudah dalam pengelolaan bug yang dilaporkan maka diberikan status untuk bug yang dilaporkan. Menurut Black (2009 :158), ada beberapa status dalam siklus hidup laporan bug, yaitu :
Gambar 2. 5 Bug report life cycle a. Review
Ketika tester memasukkan data laporan bug yang baru ke dalam database bug, database bug menahan data bug untuk ditinjau sebelum dapat dilihat oleh orang diluar test team.
b. Rejected
Jika peninjau laporan memutuskan bahwa laporan perlu untuk dikerjakan ulang baik dengan penelitian dan informasi lebih lanjut atau peningkatan kata-kata, peninjau akan menolak laporan tersebut.
c. Open
Jika tester telah mengkategorikan dan mengisolasi masalah, peninjau akan melakukan open laporan, sehingga laporan tersebut dapat diketahui dunia sebagai bug.
d. Assigned
Project team mengassign laporan kepada manager pengembangan yang kemudian akan diassign kembali ke developer untuk diperbaiki.
e. Test
Setelah bagian development memperbaiki masalah, maka laporan bug siap untuk diuji kembali.
f. Reopened
Jika perbaikan yang dilakukan gagal pada pengujian, tester akan melakukan reopened pada laporan bug.
g. Closed
Jika perbaikan telah melewati pengujian, tester akan menutup laporan pengujian tersebut.
h. Deffered
Jika anggota project team memutuskan bahwa masalah benar adanya namun bug memiliki prioritas yang rendah atau dijadwalkan untuk diperbaiki pada rilis berikutnya, maka laporan bug ini ditunda.
i. Cancelled
Jika project team memutuskan bahwa masalah tidak benar adanya, maka laporan bug akan dicancel.
2.2.15 Pengertian Test Tracking Spreadsheet
Menurut Black (2009 :199), test tracking spreadsheet merupakan suatu alat yang digunakan untuk mengelola eksekusi pengujian. Test Tracking Spreadsheet ini dapat terdiri dari 2 bagian yaitu :
a. Test case summary
Summary ini 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 case summary juga memiliki versi extended dimana test case summary dilengkapi dengan Bug ID , Bug RPN, tanggal pengujian, dan sebagainya. Kolom-kolom ini dapat disesuaikan dengan kebutuhan penguji.
Contoh Test Case Summary:
Gambar 2. 6 Test Case Summary b. Test suite summary
Test suite summary berisi data jumlah test case dalam setiap suite dan berapa test case dalam status (Fail, Pass,Skip,In queue, dan Block) (Black, 2009:203). Kolom-kolom ini dapat disesuaikan dengan kebutuhan penguji. Contoh Test suite Summary :
Gambar 2. 7 Test suite Summary 2.2.16 Pengertian Use case
Menurut Satzinger, Jackson, dan Burd (2010: 161), sebuah use case adalah aktivitas yang dilakukan oleh sistem , biasanya sebagai respon terhadap request dari user. Use case pada dasarnya sama dengan proses atau aktivitas.
2.2.17 Pengertian Activity Diagram
Menurut Satzinger, Jackson, dan Burd (2010: 141), Activity Diagram adalah jenis dari workflow diagram yang mendeskripsikan aktivitas-aktivitas berbagai user (atau sistem) dan alur-alurnya. Workflow adalah urutan dari langkah-langkah pemrosesan yang secara lengkap mengatur satu transaksi bisnis atau permintaan customer. Contoh Activity Diagram:
Gambar 2. 8 Contoh Activity Diagram berdasarkan Satzinger, Jackson, dan Burd(2010: 143)
2.3Kerangka Pikir
Berikut adalah kerangka pikir dari pengujian sistem SAP HR Sinarmas Land:
Berikut adalah penjelasan kerangka pikir :
a. Analisis proses bisnis dengan activity diagram : memberikan penjelasan terhadap proses bisnis yang berjalan pada perusahaan untuk dipetakan ke dalam sistem dengan memberikan requirement dari proses bisnis tersebut.
b. Pemetaan alur proses bisnis : memberikan gambaran terhadap hubungan antar satu proses bisnis dengan proses bisnis lainnya. c. Product specification :Menjelaskan karakteristik dari setiap submodul
termasuk input apa yang diperlukan dan output apa yang dihasilkan. d. Technical specification : membuat spesifikasi teknis dari modul yang
diuji, seperti penjelasan fungsi button dan field pada user interface. e. Quality Risk Analysis (FMEA) : Membuat analisis kemungkinan
kesalahan yang dapat mengurangi kualitas sistem yang diharapkan untuk menentukan bagian mana yang harus diuji.
f. Membuat Test Case : Membuat daftar item-item yang akan diuji dalam Functionality testing.
g. Membuat skenario pengujian : menyusun test case ke dalam kemungkinan-kemungkinan alur proses bisnis yang akan diuji dalam integration testing.
h. Membuat user manual : membuat panduan langkah-langkah penggunaan sistem bagi user .
i. Functionality Testing : melakukan pengujian terhadap komponen-komponen atau unit- unit dalam sistem.
j. Integration Testing : melakukan pengujian terhadap integrasi masing-masing submodul secara berurutan.
k. Report Testing : melakukan pengujian terhadap laporan dan keakuratan serta kelengkapan isi laporan berdasarkan data hasil pengujian pada tahan Integration testing.
l. Membuat bug report : Melakukan dokumentasi akan bug atau error yang terjadi selama functionality testing, integration testing, dan report testing.
m. Membuat bug graphic :Merangkum bug atau error yang ditemukan selama pengujian ke dalam bentuk grafik.
