SAP Business One serta IReap POS ialah 2 aplikasi yang diterapkan di area yang berbeda, di mana SAP Business One dimaksudkan bikin back- end user serta 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 hanya itu, terdapat pula data- information yang diinput berasal dari SAP Business One hendak dikirimkan ke IReap POS buat keperluan operasional.
Tidak semua 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 antara IReap POS bersama dengan SAP Business One mampu dicermati terhadap foto dibawah ini.
Informasi yang dikirim berasal dari SAP Business One ke SAP Business One memakai format XML, begitu pula bersama Info yang dikirimkan dari IReap POS ke IReap POS. Kedua aplikasi tersebut bersama dengan menciptakan file XML, tapi format struktur Info yang dihasilkan pastinya berbeda. Buat membandingkan format/ template susunan Info pada ke dua aplikasi tersebut diperlukan proses transformasi. Secara rinci, tersedia 6 sistem utama di dalam integrasi pada IReap POS bersama SAP Business One. Keenam proses berikut 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 dikala terkait sistem import– export serta inbound– outbound, masih banyak proses perinci yang dilaksanakan bertepatan. Buat lebih detailnya mampu diamati terhadap foto dibawah ini.
Test Tracking Spreadsheet
Buat mempermudah pengelolaan pada penerapan pengujian mampu digunakan suatu perlengkapan yang dinamakan selaku test tracking spreadsheet. Dengan pemakaian test tracking spreadsheet, hendak membolehkan tester bikin mencari tiap status dari test case, mengetahui konfigurasi yang digunakan serta mengenali siapa yang sudah jalankan pengujian terhadap suatu hal test case.( Black, 2009: 200)
Kolom awal dari test tracking spreadsheet selanjutnya memuat namatest suite/ test case berasal dari sesuatu pengujian. Kolom state menggambarkan status dari masing- masing test case. Bila kolom state ini kosong, sampai mengindikasikan kecuali test case berikut tetap dalam antrian bikin dicoba pengujian. Bila kolom ini berisi pass, sampai bermakna jikalau pengujian membuat test case berikut tidak menciptakan bug. Bila berisi fail, sampai bermakna terdapat bug yang ditemui berasal dari pengujian test case selanjutnya baik satu ataupun lebih.
Kolom system config berisi penjelasan identifikasi membuat mengetahui konfigurasi sistem 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 membuat mencari bug berikut serta mereferensikannya terhadap bug report yang terbuat dalam bug tracking database.
Kolom by berisi nama samaran dari tester yang sudah jalankan pengujian pada test case. Kolom comment berisi pendapat dari tester ataupun knowledge bonus menimpa standing berasal dari masing- masing test case. Kolom roll up berisi ringkasan berasal dari information menimpa status dari masing- masing test case. Kolom ini dibagi jadi 3 kolom, ialah:
a) Kolom T memuat nilai 1 misalnya ialah test case.
b) Kolom F memuat nilai 1 andaikan standing berasal dari test case merupakan fail.
c) Kolom P berisi nilai 1 jika status berasal dari test case merupakan pass.
Bug Report
Mengacu terhadap komentar Black( 2009: 146), bug report merupakan dokumen teknis yang digunakan buat membatasi beraneka indikasi maupun kegagalan yang berhubungan dengan suatu hal bug tertentu secara khusus. Sesuatu dokumen bug report yang dirancang bersama dengan baik bisa membagikan knowledge yang tepat untuk regu manajemen proyek menimpa bug tersebut sehingga bisa menyita keputusan yang pas( misalnya, apakah bug tersebut harus lekas diperbaiki ataupun tidak). Tidak hanya itu, bug report pula bisa digunakan oleh para programmer ataupun pengembang buat mengenali knowledge rinci menimpa sesuatu bug supaya mempermudah penyelesaian bug tersebut.
Field Bug ID berisi pengidentifikasi berasal dari sesuatu bug yang bisa dijadikan rujukan dari suatu hal test tracking spreadsheet. Field Project Name berisi knowledge menimpa nama proyek dimana bug berikut ditemui. Field Tester memuat information menimpa namatester yang menciptakan bug tersebut. Field Date Opened memuat information menimpa bertepatan terhadap bug berikut dimasukkan ke dalam bug tracking database.
Field Quality Risk Category: Perinci memuat data menimpa type rinci berasal dari quality risk yang didetetapkan secara tertentu bersumber pada bug tersebut. Field Subsystem memuat information menimpa subsystem di mana bug berikut ditemui. Field Configuration berisi information menimpa konfigurasi yang digunakan disaat laksanakan pengujian.
Field Severity dan juga Priority diisi dengan skala yang mirip bersama yang udah dipaparkan terhadap bagian failure fashion and effects analysis. Field RPN terhadap bug report didapat dari perkalian antara evaluasi severity serta priority. Dengan demikian, range dari RPN merupakan berkisar antara 1– 25, dimana nilai 1 mengindikasikan kecuali bug tersebut sangat beresiko serta nilai 25 mengindikasikan kalau bug tersebut hanya mengenai sepele yang dapat diabaikan.
Field summary memuat penjelasan pendek menimpa bug. Field steps to reproduce sediakan suatu hal deskripsi yang tepat dan juga sadar perihal gimana menciptakan kembali bug tersebut. Field isolation memuat knowledge bikin menyakinkan pengembang/ programmer kalau bug yang ditemui selanjutnya merupakan betul- betul bug. Perihal ini dapat bersama dengan menyatakan tanda- sinyal timbulnya bug selanjutnya dan juga sanggup pula bersama dengan menarangkan akibat dan pemicu dari timbulnya bug tersebut.
Field log memuat data rinci menimpa siklus hidup dari sesuatu bug jadi berasal dari dini selagi bug tersebut di- entry ke dalam bug tracking database. Ada pula cerminan siklus hidup dari bug report sanggup dilihat terhadap foto di bawah ini.
State review melukiskan status bug dimana bug sudah di- input ke dalam bug tracking database dan juga tunggu buat di- review oleh reviewer selagi sebelum akan bug tersebut diinformasikan kepada segala regu proyek pengembangan. State rejected menggambarkan status dimana bug selanjutnya ditolak oleh reviewer gara-gara harus riset ataupun information lebih lanjut menimpa bug tersebut. State open melukiskan status di mana bug tersebut udah di- lihat serta di kira relevan bersama dengan data rinci menimpa bug selanjutnya serta diinformasikan keberadaannya kepada segala regu proyek pengembangan.
State assigned melukiskan standing di mana bug berikut ditugaskan kepada pengembang bikin melacak data lanjut menimpa bug selanjutnya dan menyelesaikannya. State test menggambarkan standing di mana bug tersebut udah berakhir diperbaiki oleh pengembang dan mesti diuji bikin membenarkan jika bug tersebut betul- betul udah diperbaiki.
State reopened menggambarkan standing dimana bug diakses lagi buat diperbaiki lagi oleh pengembang.
State closed melukiskan status dimana bug telah berakhir diperbaiki dan juga udah dikonfirmasi kebenarannya lewat pengujian. State deferred sanggup digunakan oleh bagian regu proyek membuat menunda revisi bug berikut andaikan mereka perhitungkan jika bug selanjutnya membawa prioritas yang rendah.
State cancelled dapat digunakan oleh bagian regu proyek bikin membatalkan revisi pada bug berikut dikarenakan dinilai telah tidak relevan lagi. Field Pemilik pada bug report menampilkan nama orang yang bertanggung jawab terhadap bug tersebut. Dengan terdapatnya field ini dikehendaki manajer proyek mampu bersama lebih enteng mencari ataupun melacak data yang lebih rinci lagi menimpa bug tersebut.
Field Estimated Fixed memuat data menimpa ditaksir bertepatan terhadap bug berikut berakhir diperbaiki. Field Root Cause berisi information menimpa pangkal pemicu berasal dari terjadinya bug tersebut. Bagi Black root cause dari sesuatu bug secara universal bisa berbentuk:
a) Functional
Dari segi functional, pangkal pemicu berasal dari suatu hal bug sanggup berbentuk spesifikasi yang salah, ataupun spesifikasinya benar tetapi implementasinya salah, ataupun sistem berperan dengan benar tetapi hasil pengujian memberi paham error yang salah.
b) System
Dari segi system, pangkal pemicu berasal dari suatu hal bug mampu berupa gagalnya komunikasi sistem internal, gagalnya hardware, gagalnya operating system, aplikasi architecture yang terbuat salah, ataupun kesimpulan perancangan udah benar namun anggapan saat pelaksanaannya salah.
c) Process
Dari sisi process, pangkal pemicu dari suatu hal bug sanggup berwujud 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 dapat berwujud model Info yang digunakan salah, struktur informasi yang tidak benar ataupun pemicu yang lain yang berhubungan bersama informasi.
e) Code
Dari sisi code, pangkal pemicu dari sesuatu bug bisa berwujud salah pengetikan terhadap code.
f) Documentation
Dari segi documentation, pangkal pemicu dari sesuatu bug bisa berbentuk salahnya dokumentasi pada sistem.
gram) Standards
Dari sisi standards, pangkal pemicu berasal dari suatu hal bug bisa berupa tidak terpenuhnya standar yang selayaknya terhadap proses tersebut.
h) Other
Root cause dari bug dikategorikan ke di dalam other andaikata pangkal pemicu dari bug telah dikenal tapi tidak cocok bersama dengan jenis yang terdapat.
i) Duplicate
Root cause yang ini digunakan misalnya ada 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 uraian yang tidak benar oleh tester.
k) Bad Unit
Root cause ini digunakan jikalau bug selanjutnya berhubungan kata kegagalan hardware yang tidak diprediksi.
l) RCN
RCN( Root Cause Needed) digunakan apabila status berasal dari bug tersebut udah closed namun tidak terkandung yang mengenali pangkal pemicu berasal dari terbentuknya bug tersebut.
meter) Unknown
Root cause unknown digunakan sekiranya tidak terdapat orang yang mengenali apa yang terkait atas bug tersebut.
Field Phase Injected mendefinisikan fase dimana bug berikut dikenalkan, umumnya pada fase dini pas sebelum saat fase di mana bug selanjutnya teridentifikasi.
Field Phase Detected mendefinisikan fase dimana bug selanjutnya teridentifikasi.
Field Phase Removed mengartikan fase di mana bug selanjutnya berhasil diperbaiki.
Field Close Date menarangkan bertepatan terhadap dimana standing dari bug selanjutnya menjadi closed.
Field Resolution membatasi gimana bug selanjutnya diperbaiki.
Dari semua bug report yang udah dimasukkan ke di dalam bug tracking database sampai sanggup dibuat.
0 Komentar