SAP Business One serta IReap POS ialah 2 aplikasi yang diterapkan di daerah yang berbeda, di mana SAP Business One dimaksudkan membuat back- end user dan juga IReap POS bikin 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, terkandung pula data- information yang diinput dari SAP Business One hendak dikirimkan ke IReap POS buat kebutuhan operasional.
Tidak seluruh informasi yang dimasukkan melalui IReap POS dikirimkan ke SAP Business One. Begitu pula kebalikannya, tidak semua informasi yang dimasukkan melalui SAP Business One hendak dikirimkan ke IReap POS. Secara garis besar, integrasi antara IReap POS dengan SAP Business One dapat diamati terhadap foto di bawah ini.
Informasi yang dikirim dari SAP Business One ke SAP Business One kenakan format XML, begitu pula bersama dengan Info yang dikirimkan dari IReap POS ke IReap POS. Kedua aplikasi berikut bersama menciptakan file XML, tetapi format struktur informasi yang dihasilkan tentu saja berbeda. Buat membandingkan format/ template susunan Info antara ke dua aplikasi tersebut diperlukan proses transformasi. Secara rinci, ada 6 proses utama didalam integrasi pada IReap POS dengan SAP Business One. Keenam proses tersebut merupakan selaku berikut:
1. Export dari POS Server
2. Tranformasi berasal 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 disaat terkait sistem import– export serta inbound– outbound, tetap banyak proses perinci yang dilaksanakan bertepatan. Buat lebih detailnya dapat diamati terhadap foto dibawah ini.
Test Tracking Spreadsheet
Buat mempermudah pengelolaan terhadap penerapan pengujian dapat digunakan suatu perlengkapan yang dinamakan selaku test tracking spreadsheet. Dengan pemakaian test tracking spreadsheet, hendak membolehkan tester membuat melacak tiap standing berasal dari test case, mengetahui konfigurasi yang digunakan dan juga mengetahui siapa yang sudah lakukan pengujian terhadap 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 standing dari masing- masing test case. Bila kolom state ini kosong, sampai mengindikasikan kecuali test case selanjutnya masih didalam antrian bikin dicoba pengujian. Bila kolom ini berisi pass, sampai bermakna terkecuali pengujian buat test case berikut tidak menciptakan bug. Bila memuat fail, sampai bermakna terdapat bug yang ditemui dari pengujian test case tersebut baik satu ataupun lebih.
Kolom system config berisi penjelasan identifikasi buat mengetahui 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 membuat mencari bug selanjutnya dan juga mereferensikannya pada bug report yang terbuat dalam bug tracking database.
Kolom by berisi nama samaran dari tester yang sudah laksanakan pengujian terhadap test case. Kolom comment berisi pendapat dari tester ataupun information bonus menimpa status berasal dari masing- masing test case. Kolom roll up memuat ringkasan dari data menimpa standing berasal dari masing- masing test case. Kolom ini dibagi menjadi 3 kolom, ialah:
a) Kolom T memuat nilai 1 andaikan ialah test case.
b) Kolom F berisi nilai 1 jika status berasal dari test case merupakan fail.
c) Kolom P berisi nilai 1 misalnya standing berasal dari test case merupakan pass.
Bug Report
Mengacu terhadap komentar Black( 2009: 146), bug report merupakan dokumen tekhnis yang digunakan bikin mendeskripsikan beragam indikasi maupun kegagalan yang terkait bersama dengan sesuatu bug spesifik secara khusus. Sesuatu dokumen bug report yang dirancang dengan baik dapat membagikan knowledge yang pas untuk regu manajemen proyek menimpa bug selanjutnya supaya mampu mengambil ketentuan yang pas( misalnya, apakah bug berikut perlu lekas diperbaiki ataupun tidak). Tidak hanya itu, bug report pula sanggup digunakan oleh para programmer ataupun pengembang buat mengenali data rinci menimpa sesuatu bug sehingga mempermudah penyelesaian bug tersebut.
Field Bug ID berisi pengidentifikasi dari suatu hal bug yang dapat dijadikan rujukan dari sesuatu test tracking spreadsheet. Field Project Name memuat information menimpa nama proyek di mana bug berikut ditemui. Field Tester memuat knowledge menimpa namatester yang menciptakan bug tersebut. Field Date Opened memuat knowledge menimpa bertepatan terhadap bug berikut dimasukkan ke di dalam bug tracking database.
Field Quality Risk Category: Perinci memuat information menimpa style rinci dari quality risk yang didetetapkan secara tertentu bersumber terhadap bug tersebut. Field Subsystem berisi information menimpa subsystem di mana bug tersebut ditemui. Field Configuration memuat information menimpa konfigurasi yang digunakan ketika jalankan pengujian.
Field Severity serta Priority diisi bersama dengan skala yang sama bersama yang telah dipaparkan pada bagian failure fashion and effects analysis. Field RPN terhadap bug report didapat berasal dari perkalian antara evaluasi severity serta priority. Dengan demikian, range dari RPN merupakan berkisar pada 1– 25, di mana nilai 1 mengindikasikan kecuali bug berikut terlampau beresiko dan juga nilai 25 mengindikasikan kecuali bug selanjutnya hanya berkenaan sepele yang bisa diabaikan.
Field summary berisi penjelasan pendek menimpa bug. Field steps to reproduce menyediakan sesuatu deskripsi yang tepat serta menyadari mengenai gimana menciptakan ulang bug tersebut. Field isolation memuat data buat menyakinkan pengembang/ programmer jikalau bug yang ditemui selanjutnya merupakan betul- betul bug. Perihal ini mampu dengan menyatakan tanda- sinyal munculnya bug selanjutnya dan juga sanggup pula bersama menarangkan akibat dan pemicu dari timbulnya bug tersebut.
Field log berisi information rinci menimpa siklus hidup berasal dari sesuatu bug terasa dari dini pas bug selanjutnya di- entry ke dalam bug tracking database. Ada pula cerminan siklus hidup berasal dari bug report mampu diamati terhadap foto dibawah ini.
State review menggambarkan standing bug dimana bug telah di- input ke didalam bug tracking database serta menanti membuat di- liat oleh reviewer sementara sebelum akan bug tersebut diberitakan kepada segala regu proyek pengembangan. State rejected melukiskan status dimana bug berikut ditolak oleh reviewer sebab harus riset ataupun data lebih lanjut menimpa bug tersebut. State open melukiskan standing di mana bug selanjutnya sudah di- liat dan juga di anggap relevan bersama data rinci menimpa bug berikut dan juga di informasikan keberadaannya kepada segala regu proyek pengembangan.
State assigned menggambarkan standing dimana bug berikut ditugaskan kepada pengembang bikin melacak data lanjut menimpa bug tersebut dan menyelesaikannya. State test menggambarkan status dimana bug selanjutnya sudah berakhir diperbaiki oleh pengembang dan perlu diuji bikin membenarkan kecuali bug berikut betul- betul telah diperbaiki.
State reopened melukiskan standing dimana bug dibuka lagi membuat diperbaiki kembali oleh pengembang.
State closed melukiskan standing dimana bug udah berakhir diperbaiki serta udah di konfirmasi kebenarannya melalui pengujian. State deferred mampu digunakan oleh anggota regu proyek buat menunda revisi bug selanjutnya jikalau mereka memperhitungkan terkecuali bug tersebut membawa prioritas yang rendah.
State cancelled dapat digunakan oleh anggota regu proyek bikin membatalkan revisi terhadap bug berikut karena dinilai telah tidak relevan lagi. Field Pemilik pada bug report menampilkan nama orang yang bertanggung jawab pada bug tersebut. Dengan ada field ini dikehendaki manajer proyek mampu 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 selanjutnya 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 mampu berbentuk:
a) Functional
Dari segi functional, pangkal pemicu dari sesuatu bug bisa berwujud spesifikasi yang salah, ataupun spesifikasinya benar tapi implementasinya salah, ataupun proses berperan dengan benar namun hasil pengujian berikan memahami error yang salah.
b) System
Dari sisi system, pangkal pemicu dari sesuatu bug sanggup berbentuk gagalnya komunikasi proses internal, gagalnya hardware, gagalnya operating system, aplikasi architecture yang terbuat salah, ataupun anggapan perancangan udah benar tapi kesimpulan ketika pelaksanaannya salah.
c) Process
Dari segi process, pangkal pemicu dari suatu hal bug mampu berbentuk salahnya operasional aritmatika yang diterapkan, proses inisialisasi yang salah, control ataupun sequence yang salah, maupun error di dalam pemrosesan.
d) Data
Dari segi informasi, pangkal pemicu dari sesuatu bug bisa berupa type Info yang digunakan salah, susunan informasi yang tidak benar ataupun pemicu yang lain yang terjalin bersama dengan informasi.
e) Code
Dari sisi code, pangkal pemicu berasal dari sesuatu bug bisa berwujud keliru pengetikan pada code.
f) Documentation
Dari segi documentation, pangkal pemicu dari sesuatu bug mampu bersifat salahnya dokumentasi pada sistem.
gram) Standards
Dari segi standards, pangkal pemicu dari suatu hal bug sanggup berupa tidak terpenuhnya standar yang sepatutnya pada proses tersebut.
h) Other
Root cause berasal dari bug dikategorikan ke dalam other andaikata pangkal pemicu dari bug sudah dikenal namun tidak sesuai dengan style yang terdapat.
i) Duplicate
Root cause yang ini digunakan kalau ada 2 maupun lebih bug report yang mendeskripsikan bug yang sama.
j) NAP
Dikategorikan selaku NAP( Not a Problem) sekiranya bug yang dilaporkan berikut cuma dikarenakan deskripsi yang keliru oleh tester.
k) Bad Unit
Root cause ini digunakan andaikan bug tersebut berhubungan kata kegagalan hardware yang tidak diprediksi.
l) RCN
RCN( Root Cause Needed) digunakan andaikan status dari bug berikut sudah closed namun tidak terkandung yang mengetahui pangkal pemicu berasal dari terbentuknya bug tersebut.
meter) Unknown
Root cause unknown digunakan andaikan tidak terdapat orang yang mengetahui apa yang berhubungan atas bug tersebut.
Field Phase Injected mengartikan fase di mana bug tersebut dikenalkan, umumnya terhadap fase dini selagi sebelum fase di mana bug tersebut teridentifikasi.
Field Phase Detected membatasi fase di mana bug selanjutnya teridentifikasi.
Field Phase Removed mengartikan fase di mana bug selanjutnya berhasil diperbaiki.
Field Close Date menarangkan bertepatan terhadap dimana status dari bug selanjutnya menjadi closed.
Field Resolution membatasi gimana bug tersebut diperbaiki.
Dari semua bug report yang udah dimasukkan ke dalam bug tracking database sampai mampu dibuat.
0 Komentar