SAP Business One dan juga IReap POS ialah 2 aplikasi yang diterapkan di daerah yang berbeda, dimana SAP Business One ditujukan buat back- end user dan juga IReap POS membuat front- end user. Keduanya silih berkaitan, data- knowledge yang dimasukkan lewat IReap POS hendak dikirimkan ke SAP Business One buat diolah lagi. Tidak cuma itu, terkandung pula data- knowledge yang diinput dari SAP Business One hendak dikirimkan ke IReap POS membuat keperluan operasional.
Tidak seluruh informasi yang dimasukkan melalui IReap POS dikirimkan ke SAP Business One. Begitu pula kebalikannya, tidak semua Info yang dimasukkan melalui SAP Business One hendak dikirimkan ke IReap POS. Secara garis besar, integrasi pada IReap POS bersama dengan SAP Business One dapat dicermati pada foto dibawah ini.
Informasi yang dikirim berasal dari SAP Business One ke SAP Business One memakai format XML, begitu pula bersama Info yang dikirimkan dari IReap POS ke IReap POS. Kedua aplikasi selanjutnya bersama menciptakan file XML, namun format susunan Info yang dihasilkan pastinya berbeda. Buat memperbandingkan format/ template struktur Info pada kedua aplikasi selanjutnya diperlukan proses transformasi. Secara rinci, tersedia 6 sistem utama di dalam integrasi pada IReap POS bersama SAP Business One. Keenam proses selanjutnya 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 berasal dari SAP Business One
5. Transformasi berasal dari dokumen SAP Business One ke dokumen IReap POS
6. Import ke POS Server
Pada saat terkait proses import– export serta inbound– outbound, tetap banyak proses perinci yang dilakukan bertepatan. Buat lebih detailnya dapat diamati pada foto di bawah ini.
Test Tracking Spreadsheet
Buat mempermudah pengelolaan pada penerapan pengujian sanggup digunakan suatu perlengkapan yang dinamakan selaku test tracking spreadsheet. Dengan pemakaian test tracking spreadsheet, hendak membolehkan tester bikin melacak tiap standing dari test case, mengenali konfigurasi yang digunakan serta mengenali siapa yang sudah melaksanakan pengujian terhadap sesuatu test case.( Black, 2009: 200)
Kolom awal dari test tracking spreadsheet tersebut berisi namatest suite/ test case berasal dari suatu hal pengujian. Kolom state menggambarkan standing dari masing- masing test case. Bila kolom state ini kosong, sampai mengindikasikan kalau test case berikut masih didalam antrian buat dicoba pengujian. Bila kolom ini berisi pass, sampai berarti kalau pengujian membuat test case tersebut tidak menciptakan bug. Bila memuat fail, hingga bermakna terkandung bug yang ditemui berasal dari pengujian test case berikut baik satu ataupun lebih.
Kolom system config berisi penjelasan identifikasi buat mengenali konfigurasi proses yang digunakan oleh masing- masing test case. Kolom bug id berisi bukti diri dari bug yang ditemui dari hasil pengujian test case. Kolom ini yang nantinya hendak mempermudah test team membuat melacak bug berikut serta mereferensikannya terhadap bug report yang terbuat dalam bug tracking database.
Kolom by memuat nama samaran dari tester yang sudah jalankan pengujian pada test case. Kolom comment memuat 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 kalau ialah test case.
b) Kolom F berisi nilai 1 andaikan status berasal dari test case merupakan fail.
c) Kolom P memuat nilai 1 seandainya standing dari test case merupakan pass.
Bug Report
Mengacu terhadap komentar Black( 2009: 146), bug report merupakan dokumen tekhnis yang digunakan membuat mendefinisikan beraneka indikasi maupun kegagalan yang berhubungan bersama dengan sesuatu bug khusus secara khusus. Sesuatu dokumen bug report yang dirancang bersama baik bisa membagikan data yang tepat untuk regu manajemen proyek menimpa bug tersebut agar mampu menyita keputusan yang pas( misalnya, apakah bug tersebut perlu lekas diperbaiki ataupun tidak). Tidak cuma itu, bug report pula dapat digunakan oleh para programmer ataupun pengembang bikin mengetahui information rinci menimpa sesuatu bug agar mempermudah penyelesaian bug tersebut.
Field Bug ID memuat pengidentifikasi berasal dari suatu hal bug yang bisa dijadikan rujukan berasal dari sesuatu test tracking spreadsheet. Field Project Name memuat knowledge menimpa nama proyek dimana bug selanjutnya ditemui. Field Tester berisi data menimpa namatester yang menciptakan bug tersebut. Field Date Opened berisi data menimpa bertepatan pada bug selanjutnya dimasukkan ke didalam bug tracking database.
Field Quality Risk Category: Perinci memuat information menimpa type rinci dari quality risk yang didetetapkan secara spesifik bersumber pada bug tersebut. Field Subsystem berisi knowledge menimpa subsystem dimana bug selanjutnya ditemui. Field Configuration berisi knowledge menimpa konfigurasi yang digunakan ketika lakukan pengujian.
Field Severity dan juga Priority diisi bersama dengan skala yang sama dengan yang udah dipaparkan pada anggota failure fashion plus effects analysis. Field RPN pada bug report didapat berasal dari perkalian antara evaluasi severity dan juga priority. Dengan demikian, range berasal dari RPN merupakan berkisar pada 1– 25, di mana nilai 1 mengindikasikan jikalau bug tersebut benar-benar berbahaya dan juga nilai 25 mengindikasikan jikalau bug tersebut cuma tentang sepele yang dapat diabaikan.
Field summary memuat penjelasan pendek menimpa bug. Field steps to reproduce sediakan suatu hal deskripsi yang tepat dan juga mengerti tentang gimana menciptakan kembali bug tersebut. Field isolation berisi knowledge membuat menyakinkan pengembang/ programmer kecuali bug yang ditemui tersebut merupakan betul- betul bug. Perihal ini bisa bersama dengan menjelaskan tanda- sinyal munculnya bug selanjutnya serta sanggup pula bersama menarangkan akibat dan pemicu dari timbulnya bug tersebut.
Field log memuat information rinci menimpa siklus hidup berasal dari suatu hal bug jadi dari dini selagi bug selanjutnya di- entry ke didalam bug tracking database. Ada pula cerminan siklus hidup dari bug report mampu dicermati terhadap foto dibawah ini.
State lihat menggambarkan status bug di mana bug sudah di- input ke didalam bug tracking database serta menunggu membuat di- review oleh reviewer saat sebelum bug berikut diberitakan kepada segala regu proyek pengembangan. State rejected melukiskan standing dimana bug tersebut tidak diterima oleh reviewer sebab mesti riset ataupun information lebih lanjut menimpa bug tersebut. State open melukiskan status dimana bug tersebut udah di- review dan juga dikira relevan dengan information rinci menimpa bug berikut dan juga diberitakan keberadaannya kepada segala regu proyek pengembangan.
State assigned melukiskan standing di mana bug tersebut ditugaskan kepada pengembang buat melacak information lanjut menimpa bug berikut dan menyelesaikannya. State test melukiskan status dimana bug tersebut telah berakhir diperbaiki oleh pengembang dan perlu diuji bikin membetulkan terkecuali bug selanjutnya betul- betul telah diperbaiki.
State reopened melukiskan standing dimana bug dibuka kembali buat diperbaiki lagi oleh pengembang.
State closed melukiskan standing dimana bug telah berakhir diperbaiki serta telah dilakukan konfirmasi kebenarannya lewat pengujian. State deferred dapat digunakan oleh anggota regu proyek buat menunda revisi bug tersebut jika mereka memperhitungkan kalau bug tersebut mempunyai prioritas yang rendah.
State cancelled mampu digunakan oleh bagian regu proyek buat membatalkan revisi terhadap bug selanjutnya dikarenakan dinilai udah tidak relevan lagi. Field Pemilik terhadap bug report menampilkan nama orang yang bertanggung jawab pada bug tersebut. Dengan terdapatnya field ini diharapkan manajer proyek bisa dengan lebih enteng mencari ataupun mencari knowledge yang lebih rinci ulang menimpa bug tersebut.
Field Estimated Fixed berisi knowledge menimpa ditaksir bertepatan terhadap bug berikut berakhir diperbaiki. Field Root Cause memuat knowledge menimpa pangkal pemicu berasal dari terjadinya bug tersebut. Bagi Black root cause dari sesuatu bug secara universal mampu berbentuk:
a) Functional
Dari segi functional, pangkal pemicu dari sesuatu bug mampu berwujud spesifikasi yang salah, ataupun spesifikasinya benar tetapi implementasinya salah, ataupun sistem berperan bersama dengan benar tapi hasil pengujian memberi mengetahui error yang salah.
b) System
Dari sisi system, pangkal pemicu berasal dari suatu hal bug dapat berbentuk gagalnya komunikasi sistem internal, gagalnya hardware, gagalnya operating system, aplikasi architecture yang terbuat salah, ataupun pemikiran perancangan sudah benar namun anggapan dikala pelaksanaannya salah.
c) Process
Dari segi process, pangkal pemicu dari suatu hal bug dapat berwujud 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 berwujud tipe informasi yang digunakan salah, susunan informasi yang salah ataupun pemicu yang lain yang terkait dengan informasi.
e) Code
Dari sisi code, pangkal pemicu berasal dari suatu hal bug mampu berwujud tidak benar pengetikan terhadap code.
f) Documentation
Dari sisi documentation, pangkal pemicu dari suatu hal bug bisa bersifat salahnya dokumentasi terhadap sistem.
gram) Standards
Dari segi standards, pangkal pemicu berasal dari sesuatu bug sanggup bersifat tidak terpenuhnya standar yang sewajarnya pada sistem tersebut.
h) Other
Root cause dari bug dikategorikan ke di dalam other seandainya pangkal pemicu dari bug udah dikenal tetapi tidak cocok bersama jenis yang terdapat.
i) Duplicate
Root cause yang ini digunakan jikalau ada 2 maupun lebih bug report yang membatasi bug yang sama.
j) NAP
Dikategorikan selaku NAP( Not a Problem) jika bug yang dilaporkan berikut cuma gara-gara uraian yang tidak benar oleh tester.
k) Bad Unit
Root cause ini digunakan sekiranya bug tersebut terkait kata kegagalan hardware yang tidak diprediksi.
l) RCN
RCN( Root Cause Needed) digunakan jikalau status berasal dari bug selanjutnya udah closed namun tidak terkandung yang mengenali pangkal pemicu dari terbentuknya bug tersebut.
meter) Unknown
Root cause unknown digunakan andaikan tidak terdapat orang yang mengetahui apa yang terkait atas bug tersebut.
Field Phase Injected mengartikan fase dimana bug selanjutnya dikenalkan, umumnya terhadap fase dini pas sebelum akan fase dimana bug berikut teridentifikasi.
Field Phase Detected membatasi fase dimana bug selanjutnya teridentifikasi.
Field Phase Removed mengartikan fase dimana bug berikut berhasil diperbaiki.
Field Close Date menarangkan bertepatan terhadap di mana standing dari bug tersebut jadi closed.
Field Resolution membatasi gimana bug selanjutnya diperbaiki.
Dari seluruh bug report yang udah dimasukkan ke dalam bug tracking database hingga sanggup dibuat.
0 Komentar