SAP Business One dan juga IReap POS ialah 2 aplikasi yang diterapkan di tempat yang berbeda, di mana SAP Business One ditujukan membuat back- end user dan juga IReap POS bikin front- end user. Keduanya silih berkaitan, data- information yang dimasukkan melalui IReap POS hendak dikirimkan ke SAP Business One bikin diolah lagi. Tidak cuma itu, terdapat pula data- knowledge yang diinput dari SAP Business One hendak dikirimkan ke IReap POS bikin kebutuhan operasional.
Tidak semua informasi yang dimasukkan lewat IReap POS dikirimkan ke SAP Business One. Begitu pula kebalikannya, tidak semua Info yang dimasukkan melalui SAP Business One hendak dikirimkan ke IReap POS. Secara garis besar, integrasi antara IReap POS bersama SAP Business One mampu diamati terhadap foto dibawah ini.
Informasi yang dikirim 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 bersama dengan menciptakan file XML, tetapi format susunan informasi yang dihasilkan tentu saja berbeda. Buat membandingkan format/ template susunan informasi antara kedua aplikasi berikut dibutuhkan proses transformasi. Secara rinci, ada 6 proses utama dalam integrasi antara IReap POS dengan SAP Business One. Keenam proses tersebut 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 berasal dari dokumen SAP Business One ke dokumen IReap POS
6. Import ke POS Server
Pada saat berhubungan sistem import– export dan juga inbound– outbound, tetap banyak proses perinci yang dilakukan bertepatan. Buat lebih detailnya dapat dicermati pada foto di bawah ini.
Test Tracking Spreadsheet
Buat mempermudah pengelolaan pada penerapan pengujian mampu digunakan suatu perlengkapan yang dinamakan selaku test tracking spreadsheet. Dengan penggunaan test tracking spreadsheet, hendak membolehkan tester buat mencari tiap status dari test case, mengetahui konfigurasi yang digunakan dan juga mengetahui siapa yang sudah melakukan pengujian terhadap sesuatu test case.( Black, 2009: 200)
Kolom awal berasal dari test tracking spreadsheet berikut memuat namatest suite/ test case dari suatu hal pengujian. Kolom state menggambarkan standing berasal dari masing- masing test case. Bila kolom state ini kosong, hingga mengindikasikan jikalau test case tersebut masih dalam antrian buat dicoba pengujian. Bila kolom ini berisi pass, hingga berarti terkecuali pengujian buat test case tersebut tidak menciptakan bug. Bila berisi fail, hingga bermakna terdapat bug yang ditemui berasal dari pengujian test case berikut baik satu ataupun lebih.
Kolom system config berisi penjelasan identifikasi membuat mengenali konfigurasi sistem yang digunakan oleh masing- masing test case. Kolom bug id memuat bukti diri 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 dari tester yang telah melakukan pengujian terhadap test case. Kolom comment memuat pendapat dari tester ataupun information bonus menimpa standing berasal dari masing- masing test case. Kolom roll up berisi ringkasan dari data menimpa standing berasal dari masing- masing test case. Kolom ini dibagi menjadi 3 kolom, ialah:
a) Kolom T memuat nilai 1 misalnya ialah test case.
b) Kolom F berisi nilai 1 misalnya standing berasal dari test case merupakan fail.
c) Kolom P memuat nilai 1 seumpama standing berasal dari test case merupakan pass.
Bug Report
Mengacu terhadap komentar Black( 2009: 146), bug report merupakan dokumen tehnis yang digunakan membuat mengartikan beraneka indikasi maupun kegagalan yang berhubungan bersama suatu hal bug spesifik secara khusus. Sesuatu dokumen bug report yang dirancang bersama baik mampu membagikan information yang tepat untuk regu manajemen proyek menimpa bug selanjutnya sehingga sanggup menyita keputusan yang pas( misalnya, apakah bug berikut perlu lekas diperbaiki ataupun tidak). Tidak cuma itu, bug report pula dapat digunakan oleh para programmer ataupun pengembang buat mengetahui information rinci menimpa sesuatu bug agar mempermudah penyelesaian bug tersebut.
Field Bug ID memuat pengidentifikasi dari sesuatu bug yang dapat dijadikan rujukan dari suatu hal test tracking spreadsheet. Field Project Name memuat information menimpa nama proyek dimana bug tersebut ditemui. Field Tester memuat data menimpa namatester yang menciptakan bug tersebut. Field Date Opened memuat knowledge menimpa bertepatan pada bug selanjutnya dimasukkan ke didalam bug tracking database.
Field Quality Risk Category: Perinci memuat information menimpa jenis rinci dari quality risk yang didetetapkan secara spesifik bersumber terhadap bug tersebut. Field Subsystem berisi data menimpa subsystem di mana bug tersebut ditemui. Field Configuration memuat information menimpa konfigurasi yang digunakan kala melaksanakan pengujian.
Field Severity serta Priority diisi bersama skala yang mirip bersama dengan yang udah dipaparkan pada anggota failure fashion and effects analysis. Field RPN terhadap bug report didapat berasal dari perkalian antara evaluasi severity serta priority. Dengan demikian, range dari RPN merupakan berkisar pada 1– 25, dimana nilai 1 mengindikasikan kalau bug selanjutnya terlampau beresiko serta nilai 25 mengindikasikan kalau bug berikut hanya berkenaan sepele yang sanggup diabaikan.
Field summary memuat penjelasan pendek menimpa bug. Field steps to reproduce menyediakan sesuatu uraian yang pas serta mengerti tentang gimana menciptakan kembali bug tersebut. Field isolation memuat knowledge membuat menyakinkan pengembang/ programmer terkecuali bug yang ditemui selanjutnya merupakan betul- betul bug. Perihal ini sanggup bersama dengan menyebutkan tanda- sinyal munculnya bug tersebut dan juga dapat pula bersama dengan menarangkan akibat dan pemicu dari munculnya bug tersebut.
Field log berisi knowledge rinci menimpa siklus hidup berasal dari suatu hal bug merasa berasal dari dini waktu bug selanjutnya di- entry ke dalam bug tracking database. Ada pula cerminan siklus hidup dari bug report mampu dilihat terhadap foto di bawah ini.
State simak melukiskan status bug dimana bug sudah di- input ke didalam bug tracking database dan juga tunggu buat di- review oleh reviewer saat sebelum bug selanjutnya di informasikan kepada segala regu proyek pengembangan. State rejected menggambarkan standing di mana bug tersebut tidak diterima oleh reviewer gara-gara mesti riset ataupun knowledge lebih lanjut menimpa bug tersebut. State open menggambarkan status dimana bug tersebut udah di- lihat dan juga dianggap relevan bersama dengan information rinci menimpa bug berikut serta diinformasikan keberadaannya kepada segala regu proyek pengembangan.
State assigned menggambarkan status di mana bug berikut ditugaskan kepada pengembang buat mencari knowledge lanjut menimpa bug tersebut dan menyelesaikannya. State test menggambarkan status dimana bug berikut telah berakhir diperbaiki oleh pengembang dan kudu diuji bikin membetulkan kecuali bug selanjutnya betul- betul sudah diperbaiki.
State reopened melukiskan status dimana bug dibuka kembali membuat diperbaiki lagi oleh pengembang.
State closed melukiskan status di mana bug udah berakhir diperbaiki dan juga sudah dilakukan konfirmasi kebenarannya lewat pengujian. State deferred dapat digunakan oleh anggota regu proyek membuat menunda revisi bug selanjutnya bila mereka memperhitungkan kecuali bug selanjutnya membawa prioritas yang rendah.
State cancelled sanggup digunakan oleh anggota regu proyek bikin membatalkan revisi terhadap bug tersebut karena dinilai telah tidak relevan lagi. Field Pemilik terhadap bug report menampilkan nama orang yang bertanggung jawab pada bug tersebut. Dengan terdapatnya field ini diharapkan manajer proyek dapat bersama dengan lebih gampang melacak ataupun mencari knowledge yang lebih rinci ulang menimpa bug tersebut.
Field Estimated Fixed berisi information menimpa ditaksir bertepatan terhadap bug tersebut berakhir diperbaiki. Field Root Cause memuat data menimpa pangkal pemicu berasal dari terjadinya bug tersebut. Bagi Black root cause berasal dari suatu hal bug secara universal dapat berbentuk:
a) Functional
Dari segi functional, pangkal pemicu berasal dari suatu hal bug mampu berwujud spesifikasi yang salah, ataupun spesifikasinya benar tetapi implementasinya salah, ataupun proses berperan dengan benar tapi hasil pengujian memberi memahami error yang salah.
b) System
Dari segi system, pangkal pemicu berasal dari suatu hal bug sanggup berbentuk gagalnya komunikasi proses internal, gagalnya hardware, gagalnya operating system, aplikasi architecture yang terbuat salah, ataupun kesimpulan perancangan udah benar tetapi pemikiran disaat pelaksanaannya salah.
c) Process
Dari segi process, pangkal pemicu dari sesuatu bug sanggup berbentuk salahnya operasional aritmatika yang diterapkan, proses inisialisasi yang salah, control ataupun sequence yang salah, maupun error dalam pemrosesan.
d) Data
Dari sisi informasi, pangkal pemicu berasal dari sesuatu bug bisa berbentuk jenis informasi yang digunakan salah, susunan Info yang keliru ataupun pemicu yang lain yang terjalin dengan informasi.
e) Code
Dari sisi code, pangkal pemicu berasal dari suatu hal bug bisa berbentuk keliru pengetikan pada code.
f) Documentation
Dari segi documentation, pangkal pemicu dari suatu hal bug mampu berwujud salahnya dokumentasi terhadap sistem.
gram) Standards
Dari sisi standards, pangkal pemicu dari sesuatu bug dapat bersifat tidak terpenuhnya standar yang selayaknya terhadap proses tersebut.
h) Other
Root cause berasal dari bug dikategorikan ke didalam other andaikata pangkal pemicu dari bug udah dikenal tetapi tidak sesuai bersama dengan jenis yang terdapat.
i) Duplicate
Root cause yang ini digunakan andaikata ada 2 maupun lebih bug report yang membatasi bug yang sama.
j) NAP
Dikategorikan selaku NAP( Not a Problem) andaikata bug yang dilaporkan tersebut cuma sebab gambaran yang tidak benar oleh tester.
k) Bad Unit
Root cause ini digunakan misalnya bug selanjutnya terjalin kata kegagalan hardware yang tidak diprediksi.
l) RCN
RCN( Root Cause Needed) digunakan seandainya standing berasal dari bug berikut udah closed tapi tidak terkandung yang mengenali pangkal pemicu berasal dari terbentuknya bug tersebut.
meter) Unknown
Root cause unknown digunakan misalnya tidak terkandung orang yang mengetahui apa yang berhubungan atas bug tersebut.
Field Phase Injected mengartikan fase dimana bug berikut dikenalkan, biasanya pada fase dini saat sebelum fase dimana bug berikut teridentifikasi.
Field Phase Detected membatasi fase di mana bug berikut teridentifikasi.
Field Phase Removed mendeskripsikan fase di mana bug berikut berhasil diperbaiki.
Field Close Date menarangkan bertepatan pada di mana standing dari bug selanjutnya menjadi closed.
Field Resolution mengartikan gimana bug berikut diperbaiki.
Dari seluruh bug report yang udah dimasukkan ke di dalam bug tracking database hingga dapat dibuat.
0 Komentar