SAP Business One dan juga IReap POS ialah 2 aplikasi yang diterapkan di area yang berbeda, di mana SAP Business One ditujukan buat back- end user serta IReap POS buat front- end user. Keduanya silih berkaitan, data- knowledge yang dimasukkan melalui IReap POS hendak dikirimkan ke SAP Business One membuat diolah lagi. Tidak cuma itu, terdapat pula data- information yang diinput berasal dari SAP Business One hendak dikirimkan ke IReap POS buat kebutuhan operasional.
Tidak semua Info yang dimasukkan lewat 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 dengan SAP Business One bisa dicermati terhadap foto di bawah ini.
Informasi yang dikirim berasal dari SAP Business One ke SAP Business One kenakan format XML, begitu pula bersama informasi yang dikirimkan berasal dari IReap POS ke IReap POS. Kedua aplikasi selanjutnya bersama dengan menciptakan file XML, tapi format struktur Info yang dihasilkan pastinya berbeda. Buat memperbandingkan format/ template struktur informasi pada ke dua aplikasi selanjutnya diperlukan sistem transformasi. Secara rinci, ada 6 proses utama di dalam integrasi pada IReap POS bersama 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 dari SAP Business One
5. Transformasi berasal 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 dikerjakan bertepatan. Buat lebih detailnya sanggup dicermati terhadap foto di bawah ini.
Test Tracking Spreadsheet
Buat mempermudah pengelolaan pada penerapan pengujian sanggup digunakan suatu perlengkapan yang dinamakan selaku test tracking spreadsheet. Dengan pemanfaatan test tracking spreadsheet, hendak membolehkan tester bikin mencari tiap standing berasal dari test case, mengenali konfigurasi yang digunakan dan juga mengenali siapa yang udah melaksanakan pengujian terhadap suatu hal test case.( Black, 2009: 200)
Kolom awal berasal dari test tracking spreadsheet selanjutnya memuat namatest suite/ test case dari suatu hal pengujian. Kolom state menggambarkan status dari masing- masing test case. Bila kolom state ini kosong, sampai mengindikasikan kalau test case berikut tetap di dalam antrian membuat dicoba pengujian. Bila kolom ini memuat pass, hingga artinya kecuali pengujian buat test case berikut tidak menciptakan bug. Bila memuat fail, hingga artinya terdapat bug yang ditemui berasal dari pengujian test case berikut 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 dari hasil pengujian test case. Kolom ini yang nantinya hendak mempermudah test team membuat mencari bug tersebut dan juga mereferensikannya pada bug report yang terbuat didalam bug tracking database.
Kolom by berisi nama samaran dari tester yang telah lakukan pengujian terhadap test case. Kolom comment berisi pendapat dari tester ataupun knowledge bonus menimpa standing berasal dari masing- masing test case. Kolom roll up memuat ringkasan dari knowledge menimpa status berasal dari masing- masing test case. Kolom ini dibagi jadi 3 kolom, ialah:
a) Kolom T berisi nilai 1 kalau ialah test case.
b) Kolom F berisi nilai 1 bila status dari test case merupakan fail.
c) Kolom P berisi nilai 1 seandainya standing berasal dari test case merupakan pass.
Bug Report
Mengacu terhadap komentar Black( 2009: 146), bug report merupakan dokumen tekhnis yang digunakan buat membatasi berbagai indikasi maupun kegagalan yang terkait bersama dengan sesuatu bug khusus secara khusus. Sesuatu dokumen bug report yang dirancang dengan baik bisa membagikan information yang pas untuk regu manajemen proyek menimpa bug selanjutnya sehingga dapat mengambil alih keputusan yang pas( misalnya, apakah bug selanjutnya wajib lekas diperbaiki ataupun tidak). Tidak hanya itu, bug report pula mampu digunakan oleh para programmer ataupun pengembang membuat mengetahui knowledge rinci menimpa suatu hal bug agar mempermudah penyelesaian bug tersebut.
Field Bug ID berisi pengidentifikasi dari sesuatu bug yang bisa dijadikan rujukan dari sesuatu test tracking spreadsheet. Field Project Name memuat information menimpa nama proyek di mana bug tersebut ditemui. Field Tester memuat data menimpa namatester yang menciptakan bug tersebut. Field Date Opened berisi knowledge menimpa bertepatan terhadap bug berikut dimasukkan ke dalam bug tracking database.
Field Quality Risk Category: Perinci memuat information menimpa tipe rinci berasal dari quality risk yang didetetapkan secara khusus bersumber terhadap bug tersebut. Field Subsystem berisi information menimpa subsystem di mana bug berikut ditemui. Field Configuration memuat knowledge menimpa konfigurasi yang digunakan disaat laksanakan pengujian.
Field Severity dan juga Priority diisi bersama dengan skala yang serupa bersama yang udah dipaparkan pada anggota failure fashion plus effects analysis. Field RPN pada bug report didapat dari perkalian pada evaluasi severity dan juga priority. Dengan demikian, range berasal dari RPN merupakan berkisar pada 1– 25, dimana nilai 1 mengindikasikan kalau bug tersebut amat beresiko dan juga nilai 25 mengindikasikan terkecuali bug tersebut hanya perihal sepele yang bisa diabaikan.
Field summary memuat penjelasan pendek menimpa bug. Field steps to reproduce sediakan suatu hal gambaran yang pas serta mengetahui tentang gimana menciptakan lagi bug tersebut. Field isolation berisi knowledge bikin menyakinkan pengembang/ programmer terkecuali bug yang ditemui tersebut merupakan betul- betul bug. Perihal ini mampu dengan mengatakan tanda- tanda munculnya bug selanjutnya dan juga dapat pula bersama dengan menarangkan akibat dan pemicu berasal dari munculnya bug tersebut.
Field log berisi information rinci menimpa siklus hidup dari sesuatu bug mulai berasal dari dini waktu bug selanjutnya di- entry ke didalam bug tracking database. Ada pula cerminan siklus hidup berasal dari bug report mampu dilihat terhadap foto dibawah ini.
State lihat menggambarkan status bug di mana bug telah di- input ke di dalam bug tracking database serta menanti bikin di- simak oleh reviewer sementara sebelum bug tersebut di informasikan kepada segala regu proyek pengembangan. State rejected menggambarkan standing dimana bug berikut tidak diterima oleh reviewer dikarenakan kudu riset ataupun data lebih lanjut menimpa bug tersebut. State open melukiskan status dimana bug berikut sudah di- lihat dan juga di kira relevan bersama data rinci menimpa bug berikut serta diberitakan keberadaannya kepada segala regu proyek pengembangan.
State assigned melukiskan standing dimana bug tersebut ditugaskan kepada pengembang bikin melacak data lanjut menimpa bug berikut dan menyelesaikannya. State test menggambarkan standing dimana bug tersebut udah berakhir diperbaiki oleh pengembang dan kudu diuji bikin membenarkan kalau bug selanjutnya betul- betul sudah diperbaiki.
State reopened menggambarkan status dimana bug diakses ulang membuat diperbaiki kembali oleh pengembang.
State closed menggambarkan standing dimana bug sudah berakhir diperbaiki serta sudah dikonfirmasi kebenarannya lewat pengujian. State deferred dapat digunakan oleh bagian regu proyek buat menunda revisi bug selanjutnya misalnya mereka memperhitungkan kalau bug selanjutnya mempunyai prioritas yang rendah.
State cancelled mampu digunakan oleh bagian regu proyek bikin membatalkan revisi pada bug berikut sebab dinilai telah tidak relevan lagi. Field Pemilik terhadap bug report menampilkan nama orang yang bertanggung jawab pada bug tersebut. Dengan ada field ini diinginkan manajer proyek bisa bersama dengan lebih mudah melacak ataupun melacak knowledge yang lebih rinci lagi menimpa bug tersebut.
Field Estimated Fixed memuat data menimpa ditaksir bertepatan pada bug berikut berakhir diperbaiki. Field Root Cause berisi knowledge menimpa pangkal pemicu berasal dari terjadinya bug tersebut. Bagi Black root cause dari suatu hal bug secara universal dapat berbentuk:
a) Functional
Dari segi functional, pangkal pemicu berasal dari suatu hal bug mampu berupa spesifikasi yang salah, ataupun spesifikasinya benar namun implementasinya salah, ataupun proses berperan bersama dengan benar tapi hasil pengujian berikan tahu error yang salah.
b) System
Dari segi system, pangkal pemicu dari sesuatu bug sanggup berwujud gagalnya komunikasi sistem internal, gagalnya hardware, gagalnya operating system, aplikasi architecture yang terbuat salah, ataupun pemikiran perancangan udah benar tapi anggapan disaat pelaksanaannya salah.
c) Process
Dari sisi process, pangkal pemicu berasal dari suatu hal bug sanggup bersifat salahnya operasional aritmatika yang diterapkan, sistem inisialisasi yang salah, control ataupun sequence yang salah, maupun error didalam pemrosesan.
d) Data
Dari segi informasi, pangkal pemicu dari sesuatu bug dapat berbentuk jenis informasi yang digunakan salah, susunan informasi yang tidak benar ataupun pemicu yang lain yang terjalin bersama informasi.
e) Code
Dari sisi code, pangkal pemicu berasal dari sesuatu bug dapat berbentuk salah pengetikan terhadap code.
f) Documentation
Dari sisi documentation, pangkal pemicu berasal dari sesuatu bug bisa berbentuk salahnya dokumentasi pada sistem.
gram) Standards
Dari segi standards, pangkal pemicu berasal dari suatu hal bug sanggup bersifat tidak terpenuhnya standar yang sewajarnya pada proses tersebut.
h) Other
Root cause dari bug dikategorikan ke dalam other seumpama pangkal pemicu dari bug sudah dikenal namun tidak cocok bersama tipe yang terdapat.
i) Duplicate
Root cause yang ini digunakan sekiranya tersedia 2 maupun lebih bug report yang membatasi bug yang sama.
j) NAP
Dikategorikan selaku NAP( Not a Problem) andaikata bug yang dilaporkan selanjutnya hanya gara-gara deskripsi yang tidak benar oleh tester.
k) Bad Unit
Root cause ini digunakan seandainya bug selanjutnya terkait kata kegagalan hardware yang tidak diprediksi.
l) RCN
RCN( Root Cause Needed) digunakan jikalau standing berasal dari bug tersebut sudah closed tapi tidak terkandung yang mengetahui pangkal pemicu dari terbentuknya bug tersebut.
meter) Unknown
Root cause unknown digunakan misalnya tidak terdapat orang yang mengenali apa yang terjalin atas bug tersebut.
Field Phase Injected mengartikan fase dimana bug berikut dikenalkan, biasanya terhadap fase dini pas sebelum akan fase dimana bug tersebut teridentifikasi.
Field Phase Detected mendefinisikan fase dimana bug berikut teridentifikasi.
Field Phase Removed mendeskripsikan fase dimana bug selanjutnya sukses diperbaiki.
Field Close Date menarangkan bertepatan terhadap dimana standing dari bug tersebut jadi closed.
Field Resolution mendefinisikan gimana bug berikut diperbaiki.
Dari semua bug report yang telah dimasukkan ke dalam bug tracking database sampai dapat dibuat.
0 Komentar