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