SAP Business One dan juga IReap POS ialah 2 aplikasi yang diterapkan di area yang berbeda, di mana SAP Business One bertujuan buat back- end user serta IReap POS bikin front- end user. Keduanya silih berkaitan, data- information yang dimasukkan lewat IReap POS hendak dikirimkan ke SAP Business One buat diolah lagi. Tidak cuma itu, terdapat pula data- data yang diinput dari SAP Business One hendak dikirimkan ke IReap POS bikin kebutuhan operasional.
Tidak seluruh Info yang dimasukkan melalui IReap POS dikirimkan ke SAP Business One. Begitu pula kebalikannya, tidak seluruh Info yang dimasukkan lewat SAP Business One hendak dikirimkan ke IReap POS. Secara garis besar, integrasi antara IReap POS bersama SAP Business One dapat dicermati terhadap foto dibawah ini.
Informasi yang dikirim dari SAP Business One ke SAP Business One Mengenakan format XML, begitu pula dengan Info yang dikirimkan dari IReap POS ke IReap POS. Kedua aplikasi berikut bersama menciptakan file XML, namun format susunan Info yang dihasilkan pastinya berbeda. Buat membandingkan format/ template struktur Info antara ke-2 aplikasi tersebut dibutuhkan proses transformasi. Secara rinci, ada 6 proses utama di dalam integrasi pada IReap POS bersama SAP Business One. Keenam sistem selanjutnya merupakan selaku berikut:
1. Export berasal 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 dari dokumen SAP Business One ke dokumen IReap POS
6. Import ke POS Server
Pada ketika terkait proses import– export serta inbound– outbound, tetap banyak proses perinci yang ditunaikan bertepatan. Buat lebih detailnya mampu diamati 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 pemakaian test tracking spreadsheet, hendak membolehkan tester membuat melacak tiap status dari test case, mengetahui konfigurasi yang digunakan dan juga mengenali siapa yang sudah melaksanakan pengujian pada suatu hal test case.( Black, 2009: 200)
Kolom awal berasal dari test tracking spreadsheet selanjutnya memuat namatest suite/ test case berasal dari sesuatu pengujian. Kolom state menggambarkan standing dari masing- masing test case. Bila kolom state ini kosong, sampai mengindikasikan terkecuali test case tersebut tetap di dalam antrian bikin dicoba pengujian. Bila kolom ini memuat pass, hingga artinya kecuali pengujian membuat test case selanjutnya tidak menciptakan bug. Bila berisi fail, sampai bermakna terkandung bug yang ditemui dari pengujian test case berikut baik satu ataupun lebih.
Kolom system config berisi penjelasan identifikasi buat mengenali konfigurasi sistem yang digunakan oleh masing- masing test case. Kolom bug id memuat bukti diri dari bug yang ditemui dari hasil pengujian test case. Kolom ini yang nantinya hendak mempermudah test team membuat melacak bug tersebut serta mereferensikannya terhadap bug report yang terbuat dalam bug tracking database.
Kolom by berisi nama samaran berasal dari tester yang telah melakukan pengujian terhadap test case. Kolom comment berisi pendapat berasal dari tester ataupun data 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 jadi 3 kolom, ialah:
a) Kolom T memuat nilai 1 seandainya ialah test case.
b) Kolom F memuat nilai 1 seandainya standing 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 tehnis yang digunakan bikin mendeskripsikan bermacam indikasi maupun kegagalan yang terkait bersama suatu hal bug khusus secara khusus. Sesuatu dokumen bug report yang dirancang bersama baik sanggup membagikan data yang pas untuk regu manajemen proyek menimpa bug berikut supaya sanggup mengambil alih keputusan yang pas( misalnya, apakah bug selanjutnya kudu lekas diperbaiki ataupun tidak). Tidak cuma itu, bug report pula dapat digunakan oleh para programmer ataupun pengembang membuat mengetahui information rinci menimpa sesuatu bug supaya mempermudah penyelesaian bug tersebut.
Field Bug ID memuat pengidentifikasi dari sesuatu bug yang bisa dijadikan rujukan dari suatu hal test tracking spreadsheet. Field Project Name memuat information menimpa nama proyek di mana bug tersebut ditemui. Field Tester memuat information menimpa namatester yang menciptakan bug tersebut. Field Date Opened berisi data menimpa bertepatan terhadap bug selanjutnya dimasukkan ke didalam bug tracking database.
Field Quality Risk Category: Perinci berisi information menimpa model rinci berasal dari quality risk yang didetetapkan secara tertentu bersumber terhadap bug tersebut. Field Subsystem memuat knowledge menimpa subsystem di mana bug selanjutnya ditemui. Field Configuration berisi information menimpa konfigurasi yang digunakan dikala jalankan pengujian.
Field Severity serta Priority diisi bersama dengan skala yang mirip bersama dengan yang sudah 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 dari RPN merupakan berkisar antara 1– 25, dimana nilai 1 mengindikasikan jika bug selanjutnya terlalu berbahaya serta nilai 25 mengindikasikan kalau bug tersebut hanya berkenaan sepele yang mampu diabaikan.
Field summary memuat penjelasan pendek menimpa bug. Field steps to reproduce sedia kan suatu hal gambaran yang pas dan juga menyadari perihal gimana menciptakan kembali bug tersebut. Field isolation memuat knowledge membuat menyakinkan pengembang/ programmer kecuali bug yang ditemui tersebut merupakan betul- betul bug. Perihal ini bisa dengan mengatakan tanda- sinyal munculnya bug tersebut serta dapat pula bersama menarangkan akibat dan pemicu berasal dari munculnya bug tersebut.
Field log berisi information rinci menimpa siklus hidup dari sesuatu bug jadi dari dini kala bug tersebut di- entry ke didalam bug tracking database. Ada pula cerminan siklus hidup berasal dari bug report sanggup dilihat terhadap foto di bawah ini.
State lihat melukiskan status bug di mana bug sudah di- input ke dalam bug tracking database serta tunggu bikin di- simak oleh reviewer kala sebelum bug selanjutnya di informasikan kepada segala regu proyek pengembangan. State rejected menggambarkan standing di mana bug tersebut tidak diterima oleh reviewer sebab harus riset ataupun information lebih lanjut menimpa bug tersebut. State open melukiskan status dimana bug tersebut telah di- review serta di kira relevan bersama dengan knowledge rinci menimpa bug berikut serta di informasikan keberadaannya kepada segala regu proyek pengembangan.
State assigned menggambarkan standing dimana bug tersebut ditugaskan kepada pengembang membuat melacak data lanjut menimpa bug berikut dan menyelesaikannya. State test menggambarkan standing di mana bug tersebut telah berakhir diperbaiki oleh pengembang dan perlu diuji bikin membenarkan kalau bug tersebut betul- betul udah diperbaiki.
State reopened melukiskan status dimana bug dibuka lagi buat diperbaiki ulang oleh pengembang.
State closed menggambarkan standing di mana bug sudah berakhir diperbaiki serta udah dikonfirmasi kebenarannya melalui pengujian. State deferred bisa digunakan oleh bagian regu proyek buat menunda revisi bug tersebut apabila mereka memperhitungkan jika bug berikut membawa prioritas yang rendah.
State cancelled dapat digunakan oleh bagian regu proyek buat membatalkan revisi terhadap bug berikut karena dinilai sudah tidak relevan lagi. Field Pemilik pada bug report menampilkan nama orang yang bertanggung jawab terhadap bug tersebut. Dengan ada field ini dikehendaki manajer proyek dapat bersama dengan lebih mudah mencari ataupun mencari knowledge yang lebih rinci lagi menimpa bug tersebut.
Field Estimated Fixed berisi data menimpa ditaksir bertepatan terhadap bug tersebut berakhir diperbaiki. Field Root Cause memuat data menimpa pangkal pemicu dari terjadinya bug tersebut. Bagi Black root cause dari suatu hal bug secara universal dapat berbentuk:
a) Functional
Dari sisi functional, pangkal pemicu dari suatu hal bug mampu berbentuk spesifikasi yang salah, ataupun spesifikasinya benar tapi implementasinya salah, ataupun proses berperan bersama benar tetapi hasil pengujian berikan sadar error yang salah.
b) System
Dari segi system, pangkal pemicu berasal dari sesuatu bug dapat berbentuk gagalnya komunikasi proses internal, gagalnya hardware, gagalnya operating system, aplikasi architecture yang terbuat salah, ataupun pemikiran perancangan sudah benar namun asumsi saat pelaksanaannya salah.
c) Process
Dari sisi process, pangkal pemicu berasal dari sesuatu bug bisa berbentuk 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 berasal dari suatu hal bug sanggup berupa style Info yang digunakan salah, susunan informasi yang salah ataupun pemicu yang lain yang terkait bersama dengan informasi.
e) Code
Dari sisi code, pangkal pemicu dari suatu hal bug dapat berupa tidak benar pengetikan terhadap code.
f) Documentation
Dari segi documentation, pangkal pemicu berasal dari sesuatu bug mampu bersifat salahnya dokumentasi terhadap sistem.
gram) Standards
Dari segi standards, pangkal pemicu dari sesuatu bug bisa berupa tidak terpenuhnya standar yang sepatutnya pada proses tersebut.
h) Other
Root cause dari bug dikategorikan ke dalam other andaikata pangkal pemicu dari bug udah dikenal tapi tidak sesuai bersama type yang terdapat.
i) Duplicate
Root cause yang ini digunakan andaikata tersedia 2 maupun lebih bug report yang mengartikan bug yang sama.
j) NAP
Dikategorikan selaku NAP( Not a Problem) bila bug yang dilaporkan berikut cuma dikarenakan uraian yang keliru oleh tester.
k) Bad Unit
Root cause ini digunakan kalau bug selanjutnya berhubungan kata kegagalan hardware yang tidak diprediksi.
l) RCN
RCN( Root Cause Needed) digunakan kalau standing berasal dari bug berikut telah closed tapi tidak terkandung yang mengetahui pangkal pemicu berasal dari terbentuknya bug tersebut.
meter) Unknown
Root cause unknown digunakan andaikata tidak terkandung orang yang mengetahui apa yang berhubungan atas bug tersebut.
Field Phase Injected mendefinisikan fase dimana bug tersebut dikenalkan, umumnya pada fase dini kala sebelum akan fase di mana bug berikut teridentifikasi.
Field Phase Detected mendefinisikan fase dimana bug tersebut teridentifikasi.
Field Phase Removed mengartikan fase di mana bug berikut berhasil diperbaiki.
Field Close Date menarangkan bertepatan terhadap dimana standing dari bug tersebut menjadi closed.
Field Resolution mendefinisikan gimana bug berikut diperbaiki.
Dari semua bug report yang udah dimasukkan ke dalam bug tracking database hingga dapat dibuat.
0 Komentar