PENGUJIAN MOBIZ ERP SYSTEM PADA PT. M-ONE Wilson Suherman Bina Nusantara University, Jakarta, 085710022995,
[email protected]
Valiant Yurinah Bina Nusantara University, Jakarta, 085668473208,
[email protected]
Indah Wati Bina Nusantara University, Jakarta, 08567020305,
[email protected]
Johan, S.Kom M.M ABSTRAK Version upgrade is one of the solutions implemented by ERP software houses to continuously comply with client needs which are becoming more complicated. Testing is done on current system beforehand to minimize the impacts of old-system bugs on the new system. The discussed testing includes integration testing and report testing. The testing is done according to test cases and if any, the discovered system defects will be recorded in bug report. The bugs then will be further analyzed to extract more significant information, such as root cause, bug status, and bug fixing assignment. Integration testing encountered 12 bugs in which 6 of them are functionality bugs with Assigned status categorized as critical and need to be fixed; 1 Closed bug which is negligible; and other 5 non-critical Closed bugs categorized as test case failure. And report testing discovered 2 critical bugs (Assigned) regarding the accuracy of the information that need to be resolved at once; another critical bug concerning calculation with Assigned status which needs to be resolved as well; and 5 Closed bugs which are not critical and negligible. Keywords: testing, ERP products, upgrade version, integration testing, report testing, bugs/defects. Upgrade version merupakan salah satu solusi bagi perusahaan pengembang produk ERP untuk terus memenuhi kebutuhan client yang semakin kompleks. Sebelum dilakukan upgrade version, pengujian terhadap sistem lama akan dilakukan untuk memastikan resiko adanya kesalahan pada sistem lama yang akan berdampak pada Mobiz ERP System versi baru dapat diminimalisasi dan penambahan fitur-fitur baru pada sistem dapat dilakukan. Pengujian yang dilakukan berupa integration testing dan report testing. Pengujian dilakukan berdasarkan test case dan kesalahan yang ditemukan akan dicatat di dalam bug report. Kemudian kesalahan-kesalahan yang ditemukan akan dianalisis untuk mengetahui informasi yang lebih jelas mengenai kesalahan yang ada, seperti penyebab, status kesalahan dan kepada siapa kesalahan tersebut akan ditugaskan untuk diperbaiki. Hasil pengujian pada integration testing menunjukkan bahwa ditemukan 12 kesalahan yang terdiri dari 6 kesalahan fungsionalitas dengan status Assigned yang berarti kritis dan harus diperbaiki; 1 kesalahan pengujian dengan status Closed yang berarti tidak kritis dan dapat diabaikan; dan 5 kesalahan test case dengan status Closed yang berarti tidak kritis dan dapat diabaikan. Hasil pengujian pada report testing menunjukkan bahwa ditemukan 8 kesalahan yang terdiri dari 2 kesalahan keakuratan informasi (accuracy) dengan status Assigned yang
berarti kritis dan harus diperbaiki; 1 kesalahan kalkulasi/perhitungan (calculation) dengan status Assigned yang berarti kritis dan harus diperbaiki; dan 5 kesalahan test case dengan status Closed yang berarti tidak kritis dan dapat diabaikan. Kata kunci : pengujian, produk ERP, upgrade version, integration testing, report testing, kesalahan.
Pendahuluan Sistem informasi telah menjadi salah satu bentuk investasi sebagian besar perusahaan yang bergerak di berbagai bidang untuk mendukung proses bisnis agar menjadi lebih efektif dan efisien. Peranan sistem informasi yang terintegrasi sangat dibutuhkan tidak hanya sebagai solusi atas kompleksitas fungsional dan proses bisnis tetapi juga sebagai salah satu alat untuk bersaing. Enterprise Resource Planning (ERP) merupakan suatu konsep pengintegrasian proses bisnis yang berjalan dengan teknologi informasi yang ada sehingga membantu pendistribusian informasi ke seluruh area fungsional bisnis secara real-time. Penerapan ERP dapat membantu dalam mengelola operasional sehari-hari dan memberikan laporan yang lebih terstruktur, rinci, dan akurat sehingga pengambilan keputusan dapat dilakukan dengan lebih baik. Manfaat-manfaat yang dirasakan dalam penerapan ERP menjadikan ERP menjadi salah satu solusi untuk menjawab kebutuhan perusahaan saat ini. PT. M-One merupakan perusahaan yang bergerak di bidang teknologi informasi yang berdiri sejak tahun 2005. PT. M-One juga mengembangkan produk ERP, Mobiz ERP System, yang mengintegrasikan seluruh operasional bisnis dari pembelian, manajemen persediaan, penjualan dan distribusi, manajemen salesman, manajemen kas/bank hingga laporan akuntansi dan keuangan. Sebagai perusahaan pengembang produk ERP, PT. M-One selalu berusaha untuk memenuhi kebutuhan client yang semakin kompleks, sehingga PT. M-One terdorong untuk melakukan perubahan agar dapat memenuhi kebutuhan tersebut. Menurut Philip Holst Riis dan Petra Schubert (2012:4709), para pengguna sistem (sistem ERP) dituntut untuk melakukan upgrade version dari versi sistem sekarang. Tekanan untuk beralih ke versi baru atau melakukan upgrade version semakin tinggi dikarenakan perubahan lingkungan legal dan ekonomi, keinginan untuk meningkatkan sisi fungsionalitas dan kemudahan bagi pengguna (ease of use). Hal tersebut mendasari PT. M-One untuk melakukan upgrade version pada Mobiz ERP System dari versi 31 menjadi versi 33 dengan penambahan fitur-fitur ataupun komponen pada sistem sesuai dengan kebutuhan client. Sebelum melakukan upgrade version, PT. M-One mengharuskan pengujian ulang terhadap sistem yang lama. Proses pengujian tersebut dilakukan berdasarkan test case dan sesuai dengan prosedur yang telah ditetapkan sebelumnya. Dengan dilakukannya proses pengujian terlebih dahulu, resiko adanya kesalahan pada sistem lama yang akan berdampak pada Mobiz ERP System versi baru dapat diminimalisasi dan penambahan fitur-fitur baru pada sistem dapat dilakukan.
Metodologi 1.
2. 3.
Metodologi yang digunakan dalam pengujian ini mencakup: Obyek pengujian: − Mobiz ERP System. − Integration test case untuk periode bulan April (P6) dan bulan Mei (P7). − Report test case untuk periode bulan April (P6) dan bulan Mei (P7). Metode integration testing yang berdasarkan pada integration test case. Metode report testing yang berdasarkan pada report test case.
Hasil dan Bahasan Tools dan Equipments Berikut ini merupakan tools dan equipments yang diperlukan untuk melakukan integration testing dan report testing: 1. Personal Computer dengan menggunakan platform sistem operasi Windows 7 dan telah diinstalasi .NET framework 4.0. 2. Aplikasi M1Enterprise Versi 31. 3. Database M1System yang diperuntukan bagi M1Enterprise. 4. Database dengan struktur M1Company yang diperuntukan bagi aplikasi M1Enterprise.
1. 2. 3. 4. 5. 6.
Integration testing dan report testing dilakukan dengan bersumber pada beberapa test case, yaitu: TC-P6-Detail-STD-M1Enterprise-Perpetual (CUT OFF) untuk integration testing periode bulan April (P6). TC-P7-Detail-STD-M1Enterprise-Perpetual (CUT OFF) untuk integration testing periode bulan Mei (P7). TCR-P6-Inventr-STD-M1ERP-24-00 untuk report testing laporan Item Sales Order periode 6. TCR-P6-Acc-STD-M1Enterprise-24-00 untuk report testing laporan Account Receivable periode 6. TCR-P7-Inventr-STD-M1ERP-24-00 untuk report testing laporan Item Sales Order periode 7. TCR-P7-Acc-STD-M1Enterprise-24-00 untuk report testing laporan Account Receivable periode 7 .
Data Pengujian 1.
2. 3. 4. 5.
Data-data yang diperlukan dalam melakukan integration testing dan report testing adalah: Perusahaan yang digunakan dalam integration testing dan report testing adalah PT. Angin Ribut. PT. Angin Ribut merupakan perusahaan yang bergerak di bidang farmasi sebagai distributor obat-obatan kepada pelanggan. Data-data yang terkait dengan perusahan PT. Angin ribut merupakan fiktif yang hanya digunakan untuk keperluan pengujian. Data pelanggan. Data item atau barang. Daftar promo yang berisi sistem promo dalam bentuk free goods dan potongan nilai penjualan kepada pelanggan. Data proyek.
Hasil Pengujian Integration Testing Integration testing yang dilakukan untuk menguji modul Sales dan A/R dikelompokkan menjadi beberapa siklus untuk setiap periode test case yang diuji. Periode pengujian dibagi menjadi dua, yaitu periode bulan April (P6) dan periode bulan Mei (P7) di mana pada masing-masing periode dilakukan pengujian pada beberapa submodul yang berbeda. Submodul yang akan diuji pada periode bulan April (P6) meliputi Sales Order, Delivery Order, Sales Invoice, Direct Invoice, Tax Invoice, Sales Return, Credit Memo, Cash Bank Invoice, Cash Bank General, dan Multiple Cash Bank Receive. Submodul yang akan diuji pada periode bulan Mei (P7) meliputi Sales Order, Delivery Order, Sales Invoice, Direct Invoice, Sales Return, Credit Memo, Delivery Planning, Project Invoice, Cash Bank Invoice, Cash Bank General, dan Cash Bank Down Payment. Satu siklus pengujian merupakan siklus yang berisikan satu transaksi penjualan (yang mewakili awal siklus) dan transaksi-transaksi lain yang berkaitan dengan transaksi penjualan tersebut di mana transaksi-transaksi tersebut masih berada dalam periode yang diuji. Pengujian dilakukan dengan membandingkan hasil pada sistem dan expected result untuk masing-masing tahap pengujian yang berdasarkan pada test case. Hasil dari integration testing menunjukkan terdapat dua belas kesalahan yang ditemukan pada periode bulan April (P6) dan Mei (P7).
Hasil Pengujian Integration Testing Report testing dilakukan untuk menguji keakuratan laporan Sales akhir periode yang dihasilkan dengan melakukan perbandingan antara laporan yang dihasilkan oleh sistem dan laporan yang ada pada test case masing-masing periode. Report testing dilakukan dalam dua periode, yaitu periode 6 (bulan April 2009) dan periode 7 (bulan Mei 2009). Laporan yang akan diuji pada periode testing 6 dan 7 yaitu laporan Account Receivable (Summary dan Detail), dan laporan Item Sales Order (Summary dan Detail). Pengujian dilakukan dengan melakukan perbandingan antara hasil pada sistem dan hasil pada test case, misalnya data-data yang ditampilkan, format laporan yang diinginkan, atau pun hasil perhitungan. Hasil dari report testing menunjukkan terdapat delapan kesalahan yang ditemukan pada periode bulan April (P6) dan Mei (P7).
Bug Report Setelah pengujian selesai dilakukan, maka kesalahan-kesalahan yang ditemukan akan didokumentasikan ke dalam bug report. Bug Report berisi informasi mengenai bug ID yaitu identifikasi atau penomoran unik yang diberikan untuk setiap kesalahan yang ditemukan, summary merupakan penjelasan ringkas mengenai kesalahan yang ditemukan, sub module merupakan submodul pada sistem di mana kesalahan tersebut ditemukan, steps to reproduce merupakan penjelasan mengenai langkah-langkah bagaimana kesalahan tersebut ditemukan, dan isolation merupakan hasil atau informasi yang berhasil didapat oleh penguji untuk mengidentifikasikan faktor-faktor yang mempengaruhi manifestasi kesalahan.
Analisis Kesalahan Selanjutnya, kesalahan-kesalahan tersebut akan dianalisis untuk menentukan klasifikasi kesalahan (bug), penyebab kesalahan (root cause), berapa kali kesalahan ditemukan di dalam pengujian (Occ), severity (S), priority (P), risk priority number (RPN), status kesalahan (Current State), kepada siapa kesalahan tersebut ditugaskan untuk diperbaiki (Assigned to) dan solusi untuk memperbaiki kesalahan tersebut (Solution). Berikut ini merupakan hasil dari analisis kesalahan-kesalahan pada integration testing. Tabel 1 Analisis Kesalahan pada Integration Testing Bug ID
Bug
Sub Module
01
Format tanggal pada field ‘Due’ (tab Bank Information) masih salah. Link “View Items” yang berfungsi untuk menampilka n item invoice tidak berfungsi. Format nomor transaksi pada transaksi– transaksi
Bank Receive Invoice
02
03
Bug classifi cation Require ments failure
Root cause
Occ
S
Data Type
8
5
Tax Invoice Regular
Require ments failure
Initialization
3
2
Multiple Cash Bank
Test failure
Test
1
5
P RPN Curr Assigned Solution ent to State 4 20 Assig Progra Melakuned mmer kan perbaikan pada coding aplikasi. 3 6 Assig Progra Melakuned mmer kan perbaikan pada coding aplikasi.
3
15
Closed
Quality Control
Melakukan pengaturan format nomor
yang digenerate oleh sistem pada transaksi Multiple Cash Bank tidak sesuai.
04
05
06
07
transaksi Bank Receive Invoice dan Cash Receive Invoice pada sistem parameter sesuai dengan format nomor transaksi pada Test Case. Melakukan perbaikan pada coding aplikasi.
Kolom untuk menginput Voucher No. pada tab Cash Bank Accounts tidak berfungsi. Sistem tidak mengenerate nomor invoice sesuai dengan format yang telah diatur pada System Parameter. Perbedaan nilai akun Pendapatan Shipping pada jurnal posting Delivery Order.
Multiple Cash Bank
Require ments failure
Initialization
1
2
2
4
Assig ned
Progra mmer
Project Invoice Regular
Require ments failure
Arithmetic
1
3
3
9
Assig ned
Progra mmer
Melakukan perbaikan pada coding aplikasi.
Delivery Order
External failure
Documentati on
2
5
5
25
Closed
Analyst
Perbedaan nilai Grand Total
Sales Invoice Regular
External failure
Documentation
1
5
5
25
Closed
Analyst
Test Case perlu diperbaiki karena terjadi kesalahan perhitungan pada Test Case. Test Case perlu diperbaiki karena
terjadi kesalahan perhitungan pada TestCase Test Case perlu diperbaiki karena terjadi kesalahan perhitungan pada Test Case. Melakukan perbaikan pada coding aplikasi
08
Perbedaan Invoice Amount Confirmation
Sales Invoice Regular
External failure
Documentation
1
5
5
25
Closed
Analyst
09
Fungsi link “Detail” pada tab Customer tidak berfungsi
Require ments failure
Initialization
2
2
3
6
Assig ned
Progra mmer
10
Fungsi link “Billing Address” pada tab Payment tidak berfungsi. Perbedaan nilai Total to be Received dan Payment.
Project Invoice Regular dan Down Payment Project Invoice Regular dan Down Payment Bank Receive Invoice
Require ments failure
Initialization
2
2
3
6
Assig ned
Progra mmer
Melakukan perbaikan pada coding aplikasi
External failure
Documentation
1
5
5
25
Closed
Analyst
Bank Receive Invoice
External failure
Documentation
1
5
5
25
Closed
Analyst
Test Case perlu diperbaiki karena terjadi kesalahan perhitungan pada TestCase Test Case perlu diperbaiki karena terjadi kesalahan perhitungan pada TestCase
11
12
Perbedaan nilai akun Deposit in Transit dan Piutang Usaha.
1. 2. 3.
Hasil analisis di atas menunjukkan bahwa : jumlah kesalahan yang ditemukan pada tahap integration testing sebanyak 12 kesalahan. terdapat 6 kesalahan dengan status Assigned yang berarti kesalahan-kesalahan tersebut dianggap kritis dan harus dilakukan perbaikan pada sistem. terdapat 6 kesalahan dengan status Closed yang berarti kesalahan-kesalahan tersebut dianggap tidak kritis, dapat diabaikan, adanya kesalahan dari test case atau hasil dari pengujian, dan sistem masih dapat berfungsi dengan baik atau tidak mengurangi nilai dari sistem itu sendiri. Berikut ini merupakan hasil dari analisis kesalahan-kesalahan pada report testing. Tabel 2 Analisis Kesalahan pada Integration Testing
Bug ID
Bug
13
Atribut Related Delivery Order pada laporan yang ditampilkan oleh sistem tidak sesuai. ITEM N pada laporan yang ditampilkan oleh sistem tidak sesuai Perbedaan jumlah tagihan yang sudah dibayar (Paid).
ItemSales Order Summary
Perbedaan jumlah Non Clear. Bank.
14
15
16
Report
Bug classification Require ments failure
Root cause
Oc
S
P
4
R P N 20
Cu- Assigned Solution rrent to State Assig PrograMelaned mmer kukan perbaikan pada coding aplikasi
Static Logic
2
5
ItemSales Order Detail
Require ments failure
Static Logic
1
2
3
6
Assig ned
Programmer
Melakukan perbaikan pada coding aplikasi
Account Receivable Summary dan Detail
External Failure
Documentation
4
5
3
15
Closed
Analyst
Account Receivable
External Failure
Documentation
2
2
2
4
Closed
Analyst
Test Case perlu diperbaiki karena terjadi perbedaan perhitungan antara Test Case dan sistem. Test Case perlu diper-
Recv.
Summary dan Detail
17
Perbedaan nilai saldo awal (Beginning Balance).
Account Receivable Summary dan Detail
External Failure
Documentation
2
3
3
9
Closed
Analyst
18
Perbedaan nilai mutasi.
Laporan Account Receivable Summary dan Detail
External failure
Documentation
1
5
5
25
Closed
Analyst
19
Perbedaan jumlah tagihan atas Delivery Order.
Account Receivable Detail
External failure
Documentation
1
5
5
25
Closed
Analyst
20
Kesalahan perhitunga
Account
Require ments
Arithmetic
1
2
2
4
Assig ned
Programmer
baiki karena terjadi perbedaan perhitungan antara Test Case dan sistem. Test Case perlu diperbaiki karena terjadi perbedaan perhitungan antara Test Case dan sistem. Test Case perlu diperbaiki karena terjadi kesalahan perhitungan pada Test Case. Test Case perlu diperbaiki karena terjadi kesalahan perhitungan pada Test Case. Melakukan
n Grand Total.
1. 2.
3.
1. 2. 3. 4. 5.
6.
7.
Receivable Detail
failure
perbaikan pada coding aplikasi
Hasil analisis di atas menunjukkan bahwa : jumlah kesalahan yang ditemukan pada tahap integration testing sebanyak 8 kesalahan. terdapat 3 kesalahan dengan status Assigned yang berarti kesalahan-kesalahan tersebut dianggap kritis yang menyebabkan informasi pada laporan yang dihasilkan oleh sistem tidak lengkap atau tidak akurat sehingga harus dilakukan perbaikan pada sistem. terdapat 5 kesalahan dengan status Closed yang berarti kesalahan-kesalahan tersebut dianggap tidak kritis, dapat diabaikan, adanya kesalahan dari test case atau hasil dari pengujian, dan informasi pada laporan yang dihasilkan lengkap dan akurat. Analisis terhadap test case juga dilakukan untuk mengetahui informasi sebagai berikut: test suite/case yang menunjukkan nama dari test suite dan test case yang termasuk di dalam test suite tersebut. report yang menunjukkan nama laporan dan test case yang digunakan dalam pengujian laporan. state menunjukkan status dari test case yang dapat berupa PASS atau FAIL. bug ID menunjukkan ID kesalahan yang ditemukan pada saat test case tersebut diuji, Roll Up yang terdiri dari: a. kolom T yang berisi nilai 1 untuk setiap test case. b. kolom P yang berisi nilai 1 jika test case dengan status PASS. c. kolom F berisi nilai 1 untuk test case dengan status FAIL. Bug Classifiation untuk integration testing yang terdiri dari: a. kolom Functionality (FU) berisi nilai 1 jika kesalahan yang ditemukan diklasifikasikan ke dalam kesalahan yang bersifat fungsional. b. kolom Integration (I) berisi nilai 1 jika kesalahan yang ditemukan diklasifikasikan ke dalam kesalahan yang bersifat integrasi antar modul atau submodul. c. kolom Journal (J) berisi nilai 1 jika kesalahan yang ditemukan diklasifikasikan ke dalam kesalahan yang bersifat ketidaksesuaian jurnal. d. kolom Test Failure (TF) berisi nilai 1 jika kesalahan yang ditemukan diklasifikasikan ke dalam kesalahan yang bersifat kekeliruan atau kesalahan pengujian. e. kolom Test Case Failure (TCF) berisi nilai 1 jika kesalahan yang ditemukan diklasifikasikan ke dalam kesalahan yang bersifat kekeliruan atau kesalahan pada test case. Bug Classifiation untuk report testing yang terdiri dari: a. kolom Format (FO) berisi nilai 1 jika kesalahan yang ditemukan diklasifikasikan ke dalam kesalahan format laporan. b. kolom Accuracy (AC) berisi nilai 1 jika kesalahan yang ditemukan diklasifikasikan ke dalam kesalahan yang bersifat tidak akuratnya informasi yang dihasilkan. c. kolom Calculation (CA) berisi nilai 1 jika kesalahan yang ditemukan diklasifikasikan ke dalam kesalahan yang bersifat kesalahan perhitungan. d. kolom Completeness (CO) berisi nilai 1 jika kesalahan yang ditemukan diklasifikasikan ke dalam kesalahan yang bersifat tidak lengkapnya informasi pada laporan yang dihasilkan. e. kolom Test Failure (TF) berisi nilai 1 jika kesalahan yang ditemukan diklasifikasikan ke dalam kesalahan yang bersifat kekeliruan atau kesalahan pengujian. f. kolom Test Case Failure (TCF) berisi nilai 1 jika kesalahan yang ditemukan diklasifikasikan ke dalam kesalahan yang bersifat kekeliruan atau kesalahan pada test case.
Gambar 1 Hasil Analisis Kesalahan pada Integration Testing
1. 2. 3.
Hasil analisis test case untuk integration testing menunjukkan bahwa : jumlah keseluruhan test suite yang digunakan dalam integration testing sebanyak 23 test suite yang terdiri dari 84 test case. terdapat 66 test case dengan status PASS dan 18 test case dengan status FAIL. terdapat 6 kesalahan yang diklasifikasikan sebagai kesalahan fungsionalitas, yaitu kesalahan dengan ID 01, 02, 04, 05, 09 dan 10, 1 kesalahan diklasifikasikan sebagai kesalahan pengujian yaitu kesalahan dengan ID 03, dan 5 kesalahan diklasifikasikan sebagai kesalahan test case, yaitu kesalahan dengan ID 06, 07, 08, 11, dan 12.
Gambar 2 Hasil Analisis Kesalahan pada Report Testing
1. 2. 3.
Hasil analisis test case untuk report testing menunjukkan bahwa : jumlah keseluruhan laporan yang diuji sebanyak 4 laporan yang terdiri dari 8 test case. terdapat 1 test case dengan status PASS dan 7 test case dengan status FAIL. terdapat 2 kesalahan yang diklasifikasikan sebagai kesalahan keakuratan informasi, yaitu kesalahan dengan ID 13 dan 14, 1 kesalahan diklasifikasikan sebagai kesalahan kalkulasi atau perhitungan yaitu kesalahan dengan ID 20, dan 5 kesalahan diklasifikasikan sebagai kesalahan test case, yaitu kesalahan dengan ID 14, 15, 16, 17, dan 18.
Simpulan dan Saran Simpulan Berdasarkan hasil pengujian yang dilakukan pada Mobiz ERP System modul Sales dan A/R, dapat disimpulkan bahwa: 1. Integration testing yang dilakukan terdiri dari 2 periode yaitu bulan April (P6) dan bulan Mei (P7) di mana terdapat 12 kesalahan yang ditemukan. Kesalahan-kesalahan ditemukan pada transaksi Bank Receive Invoice, Tax Invoice Regular, Multiple Cash Bank, Project Invoice Regular, Delivery Order, Sales Invoice Regular, Project Invoiec Regular/Down Payment. 2. Report testing yang dilakukan terdiri dari 2 periode yaitu bulan April (P6) dan bulan Mei (P7) di mana terdapat 8 kesalahan yang ditemukan. Kesalahan-kesalahan ditemukan pada laporan ItemSales Order Summary, Item-Sales Order Detail, Account Receivable Summary, dan Account Receivable Detail. 3. Dua belas kesalahan yang ditemukan pada integration testing terdiri dari 6 kesalahan fungsionalitas dengan status Assigned yang berarti kritis dan harus diperbaiki; 1 kesalahan
pengujian dengan status Closed yang berarti tidak kritis dan dapat diabaikan; dan 5 kesalahan test case dengan status Closed yang berarti tidak kritis dan dapat diabaikan. Dan 8 kesalahan yang ditemukan pada report testing terdiri dari 2 kesalahan keakuratan informasi (accuracy) dengan status Assigned yang berarti kritis dan harus diperbaiki; 1 kesalahan kalkulasi/perhitungan (calculation) dengan status Assigned yang berarti kritis dan harus diperbaiki; dan 5 kesalahan test case dengan status Closed yang berarti tidak kritis dan dapat diabaikan.
Saran Berikut ini adalah saran yang dapat diberikan agar proses pengujian pada Mobiz ERP System modul Sales dan A/R dapat berjalan lebih baik dan memberikan hasil yang lebih akurat: 1. Melakukan perbaikan kesalahan-kesalahan yang ditemukan pada sistem sehingga hubungan antar modul dan fungsi dari setiap submodul dapat berjalan dengan baik. 2. Melakukan pengembangan dengan menambahkan skenario-skenario yang lebih unik atau skenario dengan kondisi di luar dugaan penguji dan memperbaiki kesalahan-kesalahan yang ditemukan pada test case sehingga test case yang digunakan dapat lebih baik dan komprehensif. 3. Penyesuaian konsep dalam pembuatan test case dan pengembangan sistem sehingga pengujian yang dilakukan dapat memberikan hasil yang lebih sinkron dan akurat.
Referensi Al-Hossan, Amel, Abdullah S. Al-Mudimigh. (2011). Practical Guidelines for Successful Erp Testing. 27(1): 11-18. Black, Rex. (2002). Managing the Testing Process: Practical Tools and Techniques for Managing Hardware and Software Testing 2nd Edition. USA: Wiley Publishing, Inc. Black, Rex. (2007). Pragmatic Software Testing: Becoming an Effective and Efficient Test Professional.USA: Wiley Publishing, Inc. Hossain, Liaquat, Jon David Patrick dan M.A. Rashid. (2002). Enterprise Resource Planning: Global Opportunities & Challenges. USA: Idea Group Publishing. Imran, Batada, Asmita Rahman. (2011). Selection, Implementation and Post Production of an ERP System. 38(7): 38-44. Jovanović, Irena (2009). Software Testing Methods and Techniques. 5(6): 30-41. Khan, Imran Akhtar, Roopa Singh. (2012). Quality Assurance and Integration Testing Aspects in Web Based Applications. 2(3): 109-116. Lewis, William E., (2009). Software testing and continuous quality improvement 3rd Edition. USA: Taylor & Francis Group, LLC. Monk, Ellen F., Bret J. Wagner. (2009). Concepts in Enterprise Resource Planning, 3rd Edition. Boston: Course Technology Cengage Learning. O'Brien, James A.,George M. Marakas. (2010). Introduction To Information Systems15th Edition. New York: The McGraw-Hill Companies, Inc. Perry, William E. (2006). Effective Methods for Software Testing 3rd Edition. USA: Wiley Publishing, Inc. Rainer, R. Kelly, Efraim Turban dan Richard E. Potter. (2007). Introduction to Information Systems: Supporting and Transforming Business. USA: John Wiley & Sons, Inc. Riis, Philip Holst, Petra Schubert. (2012). Upgrading to a New Version of an ERP System: A Multilevel Analysis of Influencing Factors in a Software Ecosystem. Dalam Ralph H. Sprague, Jr (Ed.), Proceedings of the 45th Hawaii International Conference on System Sciences (HICSS 2012) Maui, Hawaii, USA: IEEE Computer Society Press; (hal. 4709-4718). Satzinger, John W., Robert B. Jackson dan Stephen D. Burd. (2004). Object-Oriented Analysis & Design with the Unified Process. USA: Course Technology. Singh, Roopa, Imran Akhtar Khan. (2012). An Approach for Integration Testing in Online Retail Applications. 4(3): 141-158. Stair, R. M., G.W.Reynolds. (2010). Principles of Information Systems, a Managerial Approach 9th Edition. USA: Course Technology.
Riwayat Penulis Wilson Suherman lahir di kota Medan pada 23 Mei 1991. Penulis menamatkan pendidikan S1 di Bina NusantaraUniversity dalam bidang Ilmu Komputer pada 2013. Valiant Yurinah lahir di kota Tanjungpinang pada 22 Januari 1992. Penulis menamatkan pendidikan S1 di Bina Nusantara Univerity dalam bidang Ilmu Komputer pada 2013. Saat ini bekerja sebagai English Teacher di Exxion English Tuition. Indah Wati lahir di kota Pangkalpinang pada 10 November 1992. Penulis menamatkan pendidikan S1 di Bina NusantaraUniversity dalam bidang Ilmu Komputer pada 2013.
