SAP Business One dan juga IReap POS ialah 2 aplikasi yang diterapkan di tempat yang berbeda, dimana SAP Business One dimaksudkan membuat back- end user dan juga IReap POS membuat front- end user. Keduanya silih berkaitan, data- knowledge yang dimasukkan melalui IReap POS hendak dikirimkan ke SAP Business One bikin diolah lagi. Tidak cuma itu, terkandung pula data- data yang diinput berasal dari SAP Business One hendak dikirimkan ke IReap POS bikin keperluan operasional.
Tidak semua Info yang dimasukkan lewat IReap POS dikirimkan ke SAP Business One. Begitu pula kebalikannya, tidak seluruh Info yang dimasukkan lewat SAP Business One hendak dikirimkan ke IReap POS. Secara garis besar, integrasi antara IReap POS bersama SAP Business One bisa dicermati pada foto di bawah ini.
Informasi yang dikirim dari SAP Business One ke SAP Business One Mengenakan format XML, begitu pula dengan informasi yang dikirimkan berasal dari IReap POS ke IReap POS. Kedua aplikasi berikut bersama dengan menciptakan file XML, tapi format susunan informasi yang dihasilkan tentunya berbeda. Buat membandingkan format/ template susunan Info antara ke-2 aplikasi tersebut diperlukan sistem transformasi. Secara rinci, tersedia 6 proses utama didalam integrasi antara IReap POS bersama SAP Business One. Keenam proses berikut merupakan selaku berikut:
1. Export 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 disaat terkait proses import– export serta inbound– outbound, masih banyak sistem perinci yang dijalankan bertepatan. Buat lebih detailnya dapat diamati terhadap foto di bawah 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 standing berasal dari test case, mengenali konfigurasi yang digunakan dan juga mengetahui siapa yang telah laksanakan pengujian terhadap suatu hal test case.( Black, 2009: 200)
Kolom awal berasal dari test tracking spreadsheet berikut memuat namatest suite/ test case dari sesuatu pengujian. Kolom state melukiskan status berasal dari masing- masing test case. Bila kolom state ini kosong, sampai mengindikasikan jikalau test case berikut tetap di dalam antrian membuat dicoba pengujian. Bila kolom ini memuat pass, sampai berarti kecuali pengujian buat test case tersebut tidak menciptakan bug. Bila berisi fail, hingga artinya terkandung bug yang ditemui dari pengujian test case selanjutnya baik satu ataupun lebih.
Kolom system config memuat penjelasan identifikasi buat mengenali konfigurasi proses yang digunakan oleh masing- masing test case. Kolom bug id berisi 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 memuat nama samaran dari tester yang telah laksanakan pengujian pada test case. Kolom comment berisi pendapat berasal dari tester ataupun information bonus menimpa standing dari masing- masing test case. Kolom roll up berisi ringkasan dari information menimpa status dari masing- masing test case. Kolom ini dibagi menjadi 3 kolom, ialah:
a) Kolom T memuat nilai 1 jikalau ialah test case.
b) Kolom F berisi nilai 1 sekiranya status dari test case merupakan fail.
c) Kolom P berisi nilai 1 andaikata status dari test case merupakan pass.
Bug Report
Mengacu terhadap komentar Black( 2009: 146), bug report merupakan dokumen tehnis yang digunakan membuat mendeskripsikan beraneka indikasi maupun kegagalan yang berhubungan bersama dengan sesuatu bug tertentu secara khusus. Sesuatu dokumen bug report yang dirancang bersama dengan baik mampu membagikan information yang pas untuk regu manajemen proyek menimpa bug berikut supaya dapat mengambil ketentuan yang pas( misalnya, apakah bug berikut wajib lekas diperbaiki ataupun tidak). Tidak hanya itu, bug report pula bisa digunakan oleh para programmer ataupun pengembang bikin mengetahui knowledge rinci menimpa sesuatu bug sehingga mempermudah penyelesaian bug tersebut.
Field Bug ID memuat pengidentifikasi dari sesuatu bug yang bisa dijadikan rujukan dari suatu hal test tracking spreadsheet. Field Project Name memuat knowledge menimpa nama proyek di mana bug selanjutnya ditemui. Field Tester berisi information menimpa namatester yang menciptakan bug tersebut. Field Date Opened berisi information menimpa bertepatan terhadap bug tersebut dimasukkan ke dalam bug tracking database.
Field Quality Risk Category: Perinci berisi information menimpa type rinci berasal dari quality risk yang didetetapkan secara tertentu bersumber pada bug tersebut. Field Subsystem berisi information menimpa subsystem dimana bug selanjutnya ditemui. Field Configuration berisi data menimpa konfigurasi yang digunakan dikala melakukan pengujian.
Field Severity dan juga Priority diisi dengan skala yang sama bersama yang udah dipaparkan pada bagian failure fashion and effects analysis. Field RPN terhadap bug report didapat dari perkalian pada evaluasi severity serta priority. Dengan demikian, range berasal dari RPN merupakan berkisar antara 1– 25, di mana nilai 1 mengindikasikan kalau bug selanjutnya sangat berbahaya dan juga nilai 25 mengindikasikan jika bug selanjutnya cuma perihal sepele yang dapat diabaikan.
Field summary berisi penjelasan pendek menimpa bug. Field steps to reproduce menyediakan sesuatu gambaran yang pas serta menyadari tentang gimana menciptakan ulang bug tersebut. Field isolation memuat data buat menyakinkan pengembang/ programmer kalau bug yang ditemui berikut merupakan betul- betul bug. Perihal ini sanggup dengan menjelaskan tanda- tanda munculnya bug berikut serta dapat pula bersama menarangkan akibat dan pemicu berasal dari timbulnya bug tersebut.
Field log memuat data rinci menimpa siklus hidup dari suatu hal bug menjadi berasal dari dini kala bug selanjutnya di- entry ke di dalam bug tracking database. Ada pula cerminan siklus hidup berasal dari bug report bisa diamati terhadap foto dibawah ini.
State lihat menggambarkan standing bug dimana bug sudah di- input ke dalam bug tracking database serta tunggu bikin di- liat oleh reviewer saat sebelum saat bug berikut diinformasikan kepada segala regu proyek pengembangan. State rejected melukiskan standing di mana bug selanjutnya tidak diterima oleh reviewer dikarenakan harus riset ataupun information lebih lanjut menimpa bug tersebut. State open menggambarkan standing dimana bug tersebut udah di- lihat dan juga dikira relevan dengan data rinci menimpa bug berikut dan juga diinformasikan keberadaannya kepada segala regu proyek pengembangan.
State assigned melukiskan status dimana bug berikut ditugaskan kepada pengembang membuat melacak information lanjut menimpa bug tersebut dan menyelesaikannya. State test menggambarkan status di mana bug tersebut sudah berakhir diperbaiki oleh pengembang dan kudu diuji bikin membenarkan terkecuali bug tersebut betul- betul telah diperbaiki.
State reopened menggambarkan status dimana bug diakses kembali buat diperbaiki ulang oleh pengembang.
State closed menggambarkan status dimana bug sudah berakhir diperbaiki serta udah di konfirmasi kebenarannya melalui pengujian. State deferred mampu digunakan oleh bagian regu proyek bikin menunda revisi bug tersebut jika mereka memperhitungkan kalau bug berikut mempunyai prioritas yang rendah.
State cancelled bisa digunakan oleh bagian regu proyek membuat membatalkan revisi pada bug berikut gara-gara dinilai sudah tidak relevan lagi. Field Pemilik terhadap bug report menampilkan nama orang yang bertanggung jawab pada bug tersebut. Dengan ada field ini dikehendaki manajer proyek sanggup dengan lebih enteng melacak ataupun melacak knowledge yang lebih rinci lagi menimpa bug tersebut.
Field Estimated Fixed berisi data menimpa ditaksir bertepatan pada bug tersebut berakhir diperbaiki. Field Root Cause memuat information menimpa pangkal pemicu berasal dari terjadinya bug tersebut. Bagi Black root cause dari sesuatu bug secara universal bisa berbentuk:
a) Functional
Dari sisi functional, pangkal pemicu dari sesuatu bug mampu berbentuk spesifikasi yang salah, ataupun spesifikasinya benar namun implementasinya salah, ataupun sistem berperan dengan benar tetapi hasil pengujian berikan mengetahui error yang salah.
b) System
Dari segi system, pangkal pemicu dari sesuatu bug mampu berbentuk gagalnya komunikasi proses internal, gagalnya hardware, gagalnya operating system, aplikasi architecture yang terbuat salah, ataupun asumsi perancangan sudah benar tetapi anggapan ketika 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 di dalam pemrosesan.
d) Data
Dari segi informasi, pangkal pemicu berasal dari suatu hal bug mampu berbentuk type informasi yang digunakan salah, struktur Info yang tidak benar ataupun pemicu yang lain yang terkait bersama informasi.
e) Code
Dari sisi code, pangkal pemicu berasal dari sesuatu bug sanggup berupa tidak benar pengetikan terhadap code.
f) Documentation
Dari segi documentation, pangkal pemicu dari sesuatu bug sanggup bersifat salahnya dokumentasi pada sistem.
gram) Standards
Dari segi standards, pangkal pemicu dari sesuatu bug mampu berbentuk tidak terpenuhnya standar yang selayaknya terhadap proses tersebut.
h) Other
Root cause berasal dari bug dikategorikan ke di dalam other kalau pangkal pemicu dari bug sudah dikenal tapi tidak cocok bersama type yang terdapat.
i) Duplicate
Root cause yang ini digunakan andaikan tersedia 2 maupun lebih bug report yang mengartikan bug yang sama.
j) NAP
Dikategorikan selaku NAP( Not a Problem) misalnya bug yang dilaporkan selanjutnya cuma karena gambaran yang keliru oleh tester.
k) Bad Unit
Root cause ini digunakan jika bug selanjutnya terjalin kata kegagalan hardware yang tidak diprediksi.
l) RCN
RCN( Root Cause Needed) digunakan jika status dari bug selanjutnya sudah closed tapi tidak terdapat yang mengenali pangkal pemicu dari terbentuknya bug tersebut.
meter) Unknown
Root cause unknown digunakan jika tidak terdapat orang yang mengetahui apa yang berhubungan atas bug tersebut.
Field Phase Injected mengartikan fase di mana bug tersebut dikenalkan, umumnya pada fase dini selagi sebelum akan fase dimana bug tersebut teridentifikasi.
Field Phase Detected mengartikan fase dimana bug berikut teridentifikasi.
Field Phase Removed mengartikan fase di mana bug tersebut sukses diperbaiki.
Field Close Date menarangkan bertepatan pada dimana standing dari bug tersebut menjadi closed.
Field Resolution mendefinisikan gimana bug selanjutnya diperbaiki.
Dari semua bug report yang telah dimasukkan ke dalam bug tracking database hingga dapat dibuat.
0 Komentar