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