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