SAP Business One serta IReap POS ialah 2 aplikasi yang diterapkan di area yang berbeda, di mana SAP Business One dimaksudkan buat back- end user serta IReap POS bikin front- end user. Keduanya silih berkaitan, data- data yang dimasukkan melalui IReap POS hendak dikirimkan ke SAP Business One membuat diolah lagi. Tidak cuma itu, terkandung pula data- knowledge yang diinput dari SAP Business One hendak dikirimkan ke IReap POS buat keperluan operasional.
Tidak semua informasi yang dimasukkan lewat IReap POS dikirimkan ke SAP Business One. Begitu pula kebalikannya, tidak semua informasi yang dimasukkan melalui SAP Business One hendak dikirimkan ke IReap POS. Secara garis besar, integrasi pada IReap POS dengan SAP Business One sanggup diamati pada foto dibawah ini.
Informasi yang dikirim berasal dari SAP Business One ke SAP Business One kenakan format XML, begitu pula bersama dengan Info yang dikirimkan dari IReap POS ke IReap POS. Kedua aplikasi berikut dengan menciptakan file XML, tetapi format struktur informasi yang dihasilkan sudah pasti berbeda. Buat membandingkan format/ template struktur informasi pada kedua aplikasi berikut diperlukan sistem transformasi. Secara rinci, tersedia 6 sistem utama didalam integrasi antara IReap POS dengan SAP Business One. Keenam proses selanjutnya merupakan selaku berikut:
1. Export berasal dari POS Server
2. Tranformasi dari dokumen IReap POS ke dokumen SAP Business One
3. Inbound ke SAP Business One
4. Outbound dari SAP Business One
5. Transformasi dari dokumen SAP Business One ke dokumen IReap POS
6. Import ke POS Server
Pada ketika terkait proses import– export dan juga inbound– outbound, masih banyak proses perinci yang dikerjakan bertepatan. Buat lebih detailnya mampu dicermati terhadap foto dibawah ini.
Test Tracking Spreadsheet
Buat mempermudah pengelolaan pada penerapan pengujian bisa digunakan suatu perlengkapan yang dinamakan selaku test tracking spreadsheet. Dengan penggunaan test tracking spreadsheet, hendak membolehkan tester buat mencari tiap status dari test case, mengenali konfigurasi yang digunakan dan juga mengetahui siapa yang udah jalankan pengujian pada suatu hal test case.( Black, 2009: 200)
Kolom awal berasal dari test tracking spreadsheet tersebut berisi namatest suite/ test case dari suatu hal pengujian. Kolom state melukiskan standing dari masing- masing test case. Bila kolom state ini kosong, hingga mengindikasikan terkecuali test case selanjutnya masih didalam antrian buat dicoba pengujian. Bila kolom ini memuat pass, hingga berarti kalau pengujian bikin test case selanjutnya tidak menciptakan bug. Bila memuat fail, sampai berarti terkandung bug yang ditemui berasal dari pengujian test case tersebut baik satu ataupun lebih.
Kolom system config berisi penjelasan identifikasi membuat mengetahui konfigurasi proses yang digunakan oleh masing- masing test case. Kolom bug id berisi bukti diri berasal dari bug yang ditemui dari hasil pengujian test case. Kolom ini yang nantinya hendak mempermudah test team bikin melacak bug selanjutnya serta mereferensikannya terhadap bug report yang terbuat dalam bug tracking database.
Kolom by memuat nama samaran berasal dari tester yang sudah laksanakan pengujian terhadap test case. Kolom comment memuat pendapat berasal dari tester ataupun data bonus menimpa standing dari masing- masing test case. Kolom roll up berisi ringkasan berasal dari knowledge menimpa status berasal dari masing- masing test case. Kolom ini dibagi jadi 3 kolom, ialah:
a) Kolom T berisi nilai 1 apabila ialah test case.
b) Kolom F memuat nilai 1 jika status berasal dari test case merupakan fail.
c) Kolom P berisi nilai 1 apabila standing berasal dari test case merupakan pass.
Bug Report
Mengacu terhadap komentar Black( 2009: 146), bug report merupakan dokumen tekhnis yang digunakan buat membatasi bermacam indikasi maupun kegagalan yang terkait bersama sesuatu bug tertentu secara khusus. Sesuatu dokumen bug report yang dirancang dengan baik sanggup membagikan knowledge yang tepat untuk regu manajemen proyek menimpa bug tersebut agar dapat mengambil alih ketetapan yang pas( misalnya, apakah bug berikut perlu lekas diperbaiki ataupun tidak). Tidak cuma itu, bug report pula dapat digunakan oleh para programmer ataupun pengembang bikin mengenali knowledge rinci menimpa suatu hal bug sehingga mempermudah penyelesaian bug tersebut.
Field Bug ID berisi pengidentifikasi berasal dari suatu hal bug yang mampu dijadikan rujukan berasal dari suatu hal test tracking spreadsheet. Field Project Name berisi information menimpa nama proyek di mana bug tersebut ditemui. Field Tester berisi information menimpa namatester yang menciptakan bug tersebut. Field Date Opened memuat data menimpa bertepatan terhadap bug berikut dimasukkan ke didalam bug tracking database.
Field Quality Risk Category: Perinci berisi data menimpa tipe rinci dari quality risk yang didetetapkan secara khusus bersumber terhadap bug tersebut. Field Subsystem berisi knowledge menimpa subsystem di mana bug selanjutnya ditemui. Field Configuration berisi knowledge menimpa konfigurasi yang digunakan saat laksanakan pengujian.
Field Severity dan juga Priority diisi bersama dengan skala yang serupa bersama yang telah dipaparkan pada bagian failure fashion plus effects analysis. Field RPN terhadap bug report didapat berasal dari perkalian pada evaluasi severity serta priority. Dengan demikian, range berasal dari RPN merupakan berkisar pada 1– 25, di mana nilai 1 mengindikasikan jikalau bug selanjutnya benar-benar beresiko dan juga nilai 25 mengindikasikan jikalau bug tersebut cuma tentang sepele yang bisa diabaikan.
Field summary memuat penjelasan pendek menimpa bug. Field steps to reproduce sedia kan suatu hal uraian yang tepat serta tahu mengenai gimana menciptakan lagi bug tersebut. Field isolation memuat data membuat menyakinkan pengembang/ programmer jikalau bug yang ditemui tersebut merupakan betul- betul bug. Perihal ini mampu bersama dengan menjelaskan tanda- sinyal timbulnya bug berikut serta sanggup pula bersama dengan menarangkan akibat dan pemicu berasal dari munculnya bug tersebut.
Field log berisi information rinci menimpa siklus hidup dari sesuatu bug menjadi dari dini selagi bug berikut di- entry ke dalam bug tracking database. Ada pula cerminan siklus hidup berasal dari bug report dapat dicermati terhadap foto di bawah ini.
State liat menggambarkan status bug di mana bug telah di- input ke dalam bug tracking database serta tunggu buat di- liat oleh reviewer saat sebelum saat bug selanjutnya diinformasikan kepada segala regu proyek pengembangan. State rejected melukiskan status dimana bug selanjutnya ditolak oleh reviewer gara-gara harus riset ataupun data lebih lanjut menimpa bug tersebut. State open melukiskan standing dimana bug selanjutnya udah di- review serta dikira relevan bersama information rinci menimpa bug selanjutnya dan juga diinformasikan keberadaannya kepada segala regu proyek pengembangan.
State assigned melukiskan status di mana bug tersebut ditugaskan kepada pengembang bikin mencari data lanjut menimpa bug berikut dan menyelesaikannya. State test menggambarkan standing di mana bug selanjutnya telah berakhir diperbaiki oleh pengembang dan wajib diuji membuat membenarkan jika bug selanjutnya betul- betul sudah diperbaiki.
State reopened melukiskan status dimana bug dibuka lagi membuat diperbaiki lagi oleh pengembang.
State closed melukiskan standing dimana bug telah berakhir diperbaiki dan juga telah di konfirmasi kebenarannya lewat pengujian. State deferred mampu digunakan oleh bagian regu proyek bikin menunda revisi bug berikut bila mereka mempertimbangkan terkecuali bug selanjutnya membawa prioritas yang rendah.
State cancelled bisa digunakan oleh anggota regu proyek bikin membatalkan revisi pada bug tersebut karena dinilai udah tidak relevan lagi. Field Pemilik terhadap bug report menampilkan nama orang yang bertanggung jawab terhadap bug tersebut. Dengan terdapatnya field ini diharapkan manajer proyek sanggup bersama dengan lebih gampang mencari ataupun mencari data yang lebih rinci kembali menimpa bug tersebut.
Field Estimated Fixed berisi knowledge menimpa ditaksir bertepatan pada bug berikut berakhir diperbaiki. Field Root Cause berisi knowledge menimpa pangkal pemicu berasal dari terjadinya bug tersebut. Bagi Black root cause dari suatu hal bug secara universal mampu berbentuk:
a) Functional
Dari sisi functional, pangkal pemicu dari sesuatu bug sanggup bersifat spesifikasi yang salah, ataupun spesifikasinya benar tetapi implementasinya salah, ataupun sistem berperan dengan benar namun hasil pengujian berikan menyadari error yang salah.
b) System
Dari segi system, pangkal pemicu dari sesuatu bug bisa berbentuk gagalnya komunikasi proses internal, gagalnya hardware, gagalnya operating system, aplikasi architecture yang terbuat salah, ataupun anggapan perancangan telah benar tetapi asumsi dikala pelaksanaannya salah.
c) Process
Dari sisi process, pangkal pemicu dari suatu hal bug bisa berbentuk salahnya operasional aritmatika yang diterapkan, sistem inisialisasi yang salah, control ataupun sequence yang salah, maupun error dalam pemrosesan.
d) Data
Dari sisi informasi, pangkal pemicu dari suatu hal bug sanggup berbentuk style informasi yang digunakan salah, struktur Info yang tidak benar ataupun pemicu yang lain yang terjalin bersama dengan informasi.
e) Code
Dari sisi code, pangkal pemicu berasal dari suatu hal bug mampu berwujud salah pengetikan pada code.
f) Documentation
Dari sisi documentation, pangkal pemicu berasal dari suatu hal bug bisa berbentuk salahnya dokumentasi pada sistem.
gram) Standards
Dari segi standards, pangkal pemicu berasal dari sesuatu bug sanggup berbentuk tidak terpenuhnya standar yang selayaknya pada sistem tersebut.
h) Other
Root cause dari bug dikategorikan ke di dalam other kalau pangkal pemicu berasal dari bug sudah dikenal tapi tidak sesuai dengan model yang terdapat.
i) Duplicate
Root cause yang ini digunakan jika ada 2 maupun lebih bug report yang membatasi bug yang sama.
j) NAP
Dikategorikan selaku NAP( Not a Problem) seumpama bug yang dilaporkan tersebut cuma dikarenakan gambaran yang salah oleh tester.
k) Bad Unit
Root cause ini digunakan seandainya bug berikut terkait kata kegagalan hardware yang tidak diprediksi.
l) RCN
RCN( Root Cause Needed) digunakan misalnya status berasal dari bug berikut telah closed namun tidak terdapat yang mengetahui pangkal pemicu berasal dari terbentuknya bug tersebut.
meter) Unknown
Root cause unknown digunakan seandainya tidak terdapat orang yang mengetahui apa yang terkait atas bug tersebut.
Field Phase Injected membatasi fase dimana bug berikut dikenalkan, umumnya terhadap fase dini kala sebelum saat fase di mana bug selanjutnya teridentifikasi.
Field Phase Detected mengartikan fase dimana bug tersebut teridentifikasi.
Field Phase Removed membatasi fase dimana bug selanjutnya sukses diperbaiki.
Field Close Date menarangkan bertepatan pada dimana standing dari bug tersebut menjadi closed.
Field Resolution mendeskripsikan gimana bug tersebut diperbaiki.
Dari seluruh bug report yang telah dimasukkan ke didalam bug tracking database sampai bisa dibuat.
0 Komentar