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