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- information yang dimasukkan melalui IReap POS hendak dikirimkan ke SAP Business One bikin diolah lagi. Tidak cuma itu, terdapat pula data- information yang diinput dari SAP Business One hendak dikirimkan ke IReap POS bikin keperluan operasional.
Tidak seluruh informasi 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 antara IReap POS dengan SAP Business One dapat dicermati terhadap foto dibawah ini.
Informasi yang dikirim berasal dari SAP Business One ke SAP Business One kenakan format XML, begitu pula bersama dengan Info yang dikirimkan berasal dari IReap POS ke IReap POS. Kedua aplikasi selanjutnya bersama dengan menciptakan file XML, tapi format struktur Info yang dihasilkan sudah pasti berbeda. Buat membandingkan format/ template susunan informasi antara kedua aplikasi tersebut diperlukan sistem transformasi. Secara rinci, ada 6 proses utama didalam integrasi pada IReap POS dengan 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 berasal dari SAP Business One
5. Transformasi berasal dari dokumen SAP Business One ke dokumen IReap POS
6. Import ke POS Server
Pada dikala berhubungan sistem import– export serta inbound– outbound, tetap banyak proses perinci yang dilakukan bertepatan. Buat lebih detailnya dapat dicermati terhadap foto dibawah ini.
Test Tracking Spreadsheet
Buat mempermudah pengelolaan terhadap penerapan pengujian sanggup digunakan suatu perlengkapan yang dinamakan selaku test tracking spreadsheet. Dengan penggunaan test tracking spreadsheet, hendak membolehkan tester membuat mencari tiap status berasal dari test case, mengetahui konfigurasi yang digunakan serta mengenali siapa yang telah laksanakan pengujian pada sesuatu test case.( Black, 2009: 200)
Kolom awal dari test tracking spreadsheet selanjutnya memuat namatest suite/ test case berasal dari suatu hal pengujian. Kolom state melukiskan status dari masing- masing test case. Bila kolom state ini kosong, hingga mengindikasikan jikalau test case berikut masih dalam antrian bikin dicoba pengujian. Bila kolom ini memuat pass, hingga berarti terkecuali pengujian bikin test case selanjutnya tidak menciptakan bug. Bila memuat fail, hingga bermakna terkandung bug yang ditemui dari pengujian test case selanjutnya baik satu ataupun lebih.
Kolom system config memuat penjelasan identifikasi membuat mengenali 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 melacak bug berikut serta mereferensikannya terhadap bug report yang terbuat didalam bug tracking database.
Kolom by berisi nama samaran dari tester yang telah melakukan pengujian terhadap test case. Kolom comment memuat pendapat berasal dari tester ataupun information bonus menimpa status berasal 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 berisi nilai 1 jikalau standing berasal dari test case merupakan fail.
c) Kolom P berisi nilai 1 seumpama standing berasal dari test case merupakan pass.
Bug Report
Mengacu terhadap komentar Black( 2009: 146), bug report merupakan dokumen tekhnis yang digunakan buat mengartikan beragam indikasi maupun kegagalan yang terkait bersama dengan suatu hal bug spesifik secara khusus. Sesuatu dokumen bug report yang dirancang dengan baik bisa membagikan data yang tepat untuk regu manajemen proyek menimpa bug tersebut agar dapat mengambil ketentuan yang pas( misalnya, apakah bug selanjutnya perlu lekas diperbaiki ataupun tidak). Tidak cuma itu, bug report pula mampu digunakan oleh para programmer ataupun pengembang bikin mengenali data rinci menimpa sesuatu bug sehingga mempermudah penyelesaian bug tersebut.
Field Bug ID berisi pengidentifikasi dari suatu hal bug yang mampu dijadikan rujukan berasal dari sesuatu test tracking spreadsheet. Field Project Name memuat knowledge menimpa nama proyek dimana bug selanjutnya ditemui. Field Tester memuat data menimpa namatester yang menciptakan bug tersebut. Field Date Opened memuat information menimpa bertepatan pada bug selanjutnya dimasukkan ke didalam bug tracking database.
Field Quality Risk Category: Perinci berisi knowledge menimpa type rinci dari quality risk yang didetetapkan secara tertentu bersumber pada bug tersebut. Field Subsystem memuat information menimpa subsystem di mana bug selanjutnya ditemui. Field Configuration memuat data menimpa konfigurasi yang digunakan ketika melaksanakan pengujian.
Field Severity serta Priority diisi bersama dengan skala yang sama bersama yang udah dipaparkan terhadap bagian failure fashion plus 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 jikalau bug tersebut terlalu beresiko serta nilai 25 mengindikasikan jikalau bug selanjutnya cuma mengenai sepele yang mampu diabaikan.
Field summary berisi penjelasan pendek menimpa bug. Field steps to reproduce menyediakan sesuatu gambaran yang tepat serta sadar mengenai gimana menciptakan ulang bug tersebut. Field isolation berisi data buat menyakinkan pengembang/ programmer jika bug yang ditemui berikut merupakan betul- betul bug. Perihal ini bisa bersama dengan menyatakan tanda- sinyal timbulnya bug selanjutnya dan juga mampu pula dengan menarangkan akibat dan pemicu dari timbulnya bug tersebut.
Field log memuat information rinci menimpa siklus hidup berasal dari suatu hal bug menjadi dari dini pas bug tersebut di- entry ke dalam bug tracking database. Ada pula cerminan siklus hidup berasal dari bug report mampu diamati pada foto dibawah ini.
State simak menggambarkan standing bug di mana bug udah di- input ke di dalam bug tracking database dan juga menanti membuat di- review oleh reviewer selagi sebelum bug selanjutnya diberitakan kepada segala regu proyek pengembangan. State rejected melukiskan status dimana bug selanjutnya tidak diterima oleh reviewer gara-gara mesti riset ataupun knowledge lebih lanjut menimpa bug tersebut. State open menggambarkan standing dimana bug berikut telah di- lihat dan juga di kira relevan dengan knowledge rinci menimpa bug tersebut dan juga diinformasikan keberadaannya kepada segala regu proyek pengembangan.
State assigned menggambarkan status di mana bug berikut ditugaskan kepada pengembang membuat melacak data lanjut menimpa bug berikut dan menyelesaikannya. State test menggambarkan standing di mana bug berikut telah berakhir diperbaiki oleh pengembang dan perlu diuji buat membenarkan jika bug selanjutnya betul- betul udah diperbaiki.
State reopened menggambarkan status di mana bug dibuka ulang bikin diperbaiki lagi oleh pengembang.
State closed menggambarkan status dimana bug udah berakhir diperbaiki dan juga telah dilakukan konfirmasi kebenarannya melalui pengujian. State deferred sanggup digunakan oleh anggota regu proyek membuat menunda revisi bug tersebut seumpama mereka pertimbangkan jikalau bug tersebut membawa prioritas yang rendah.
State cancelled mampu digunakan oleh bagian regu proyek buat membatalkan revisi pada bug tersebut dikarenakan dinilai telah tidak relevan lagi. Field Pemilik terhadap bug report menampilkan nama orang yang bertanggung jawab terhadap bug tersebut. Dengan terdapatnya field ini dikehendaki manajer proyek mampu bersama dengan lebih gampang mencari ataupun mencari data yang lebih rinci kembali menimpa bug tersebut.
Field Estimated Fixed berisi data menimpa ditaksir bertepatan pada bug tersebut berakhir diperbaiki. Field Root Cause berisi data menimpa pangkal pemicu berasal dari terjadinya bug tersebut. Bagi Black root cause dari sesuatu bug secara universal dapat berbentuk:
a) Functional
Dari segi functional, pangkal pemicu dari suatu hal bug mampu berwujud spesifikasi yang salah, ataupun spesifikasinya benar tetapi implementasinya salah, ataupun proses berperan bersama dengan benar namun hasil pengujian berikan menyadari error yang salah.
b) System
Dari segi system, pangkal pemicu berasal dari sesuatu bug bisa berwujud gagalnya komunikasi proses internal, gagalnya hardware, gagalnya operating system, aplikasi architecture yang terbuat salah, ataupun anggapan perancangan sudah benar tetapi kesimpulan disaat pelaksanaannya salah.
c) Process
Dari sisi process, pangkal pemicu berasal dari sesuatu bug sanggup berupa 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 dari sesuatu bug sanggup berupa model informasi yang digunakan salah, susunan informasi yang keliru ataupun pemicu yang lain yang terkait dengan informasi.
e) Code
Dari segi code, pangkal pemicu dari sesuatu bug sanggup bersifat keliru pengetikan terhadap code.
f) Documentation
Dari segi documentation, pangkal pemicu dari suatu hal bug mampu berbentuk salahnya dokumentasi pada sistem.
gram) Standards
Dari sisi standards, pangkal pemicu berasal dari sesuatu bug dapat berupa tidak terpenuhnya standar yang semestinya pada proses tersebut.
h) Other
Root cause dari bug dikategorikan ke didalam other jika pangkal pemicu dari bug udah dikenal tetapi tidak sesuai bersama style yang terdapat.
i) Duplicate
Root cause yang ini digunakan apabila ada 2 maupun lebih bug report yang mendeskripsikan bug yang sama.
j) NAP
Dikategorikan selaku NAP( Not a Problem) andaikan bug yang dilaporkan berikut cuma gara-gara deskripsi yang salah oleh tester.
k) Bad Unit
Root cause ini digunakan apabila bug berikut terkait kata kegagalan hardware yang tidak diprediksi.
l) RCN
RCN( Root Cause Needed) digunakan jikalau status dari bug selanjutnya udah closed tetapi tidak terdapat yang mengenali pangkal pemicu dari terbentuknya bug tersebut.
meter) Unknown
Root cause unknown digunakan misalnya tidak terdapat orang yang mengenali apa yang terkait atas bug tersebut.
Field Phase Injected membatasi fase dimana bug selanjutnya dikenalkan, kebanyakan pada fase dini selagi sebelum akan fase dimana bug berikut teridentifikasi.
Field Phase Detected mendeskripsikan fase dimana bug berikut teridentifikasi.
Field Phase Removed mengartikan fase dimana bug berikut berhasil diperbaiki.
Field Close Date menarangkan bertepatan terhadap di mana standing berasal dari bug selanjutnya jadi closed.
Field Resolution mengartikan gimana bug tersebut diperbaiki.
Dari seluruh bug report yang telah dimasukkan ke di dalam bug tracking database sampai sanggup dibuat.
0 Komentar