SAP Business One serta IReap POS ialah 2 aplikasi yang diterapkan di tempat yang berbeda, di mana SAP Business One ditujukan buat back- end user dan juga IReap POS membuat front- end user. Keduanya silih berkaitan, data- knowledge yang dimasukkan melalui IReap POS hendak dikirimkan ke SAP Business One membuat 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 lewat IReap POS dikirimkan ke SAP Business One. Begitu pula kebalikannya, tidak semua informasi yang dimasukkan lewat SAP Business One hendak dikirimkan ke IReap POS. Secara garis besar, integrasi pada IReap POS dengan SAP Business One bisa dilihat terhadap foto di bawah ini.
Informasi yang dikirim dari SAP Business One ke SAP Business One Mengenakan format XML, begitu pula bersama dengan informasi yang dikirimkan dari IReap POS ke IReap POS. Kedua aplikasi tersebut bersama menciptakan file XML, tetapi format struktur informasi yang dihasilkan sudah pasti berbeda. Buat memperbandingkan format/ template susunan informasi pada kedua aplikasi tersebut dibutuhkan proses transformasi. Secara rinci, tersedia 6 sistem utama didalam integrasi pada IReap POS dengan SAP Business One. Keenam proses selanjutnya 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 dari SAP Business One
5. Transformasi dari dokumen SAP Business One ke dokumen IReap POS
6. Import ke POS Server
Pada kala berhubungan proses import– export dan juga inbound– outbound, masih banyak sistem perinci yang dijalankan bertepatan. Buat lebih detailnya sanggup dicermati terhadap foto di bawah ini.
Test Tracking Spreadsheet
Buat mempermudah pengelolaan terhadap penerapan pengujian dapat 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, mengenali konfigurasi yang digunakan serta mengetahui siapa yang udah melakukan pengujian pada sesuatu test case.( Black, 2009: 200)
Kolom awal berasal dari test tracking spreadsheet tersebut berisi namatest suite/ test case berasal dari suatu hal pengujian. Kolom state menggambarkan standing berasal dari masing- masing test case. Bila kolom state ini kosong, hingga mengindikasikan terkecuali test case berikut masih didalam antrian membuat dicoba pengujian. Bila kolom ini memuat pass, sampai bermakna jika pengujian bikin test case tersebut tidak menciptakan bug. Bila berisi fail, hingga berarti terdapat bug yang ditemui berasal dari pengujian test case tersebut 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 berasal dari bug yang ditemui berasal dari hasil pengujian test case. Kolom ini yang nantinya hendak mempermudah test team bikin melacak bug berikut dan juga mereferensikannya terhadap bug report yang terbuat didalam bug tracking database.
Kolom by berisi nama samaran dari tester yang sudah melaksanakan pengujian terhadap test case. Kolom comment memuat pendapat dari tester ataupun knowledge bonus menimpa status dari masing- masing test case. Kolom roll up memuat ringkasan dari information menimpa status 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 sekiranya standing dari test case merupakan fail.
c) Kolom P berisi nilai 1 apabila status dari test case merupakan pass.
Bug Report
Mengacu terhadap komentar Black( 2009: 146), bug report merupakan dokumen tehnis yang digunakan buat membatasi bermacam indikasi maupun kegagalan yang terkait dengan suatu hal bug tertentu secara khusus. Sesuatu dokumen bug report yang dirancang bersama dengan baik mampu membagikan information yang pas untuk regu manajemen proyek menimpa bug selanjutnya supaya mampu mengambil ketetapan yang pas( misalnya, apakah bug selanjutnya perlu lekas diperbaiki ataupun tidak). Tidak hanya itu, bug report pula sanggup digunakan oleh para programmer ataupun pengembang bikin mengenali knowledge rinci menimpa sesuatu bug supaya mempermudah penyelesaian bug tersebut.
Field Bug ID berisi pengidentifikasi berasal dari suatu hal bug yang bisa dijadikan rujukan dari sesuatu test tracking spreadsheet. Field Project Name berisi knowledge menimpa nama proyek di mana bug berikut ditemui. Field Tester berisi knowledge menimpa namatester yang menciptakan bug tersebut. Field Date Opened memuat knowledge menimpa bertepatan terhadap bug tersebut dimasukkan ke didalam bug tracking database.
Field Quality Risk Category: Perinci berisi knowledge menimpa tipe rinci berasal dari quality risk yang didetetapkan secara spesifik bersumber terhadap bug tersebut. Field Subsystem berisi data menimpa subsystem dimana bug berikut ditemui. Field Configuration memuat knowledge menimpa konfigurasi yang digunakan kala lakukan pengujian.
Field Severity dan juga Priority diisi dengan skala yang mirip dengan yang udah dipaparkan terhadap anggota failure fashion plus effects analysis. Field RPN terhadap bug report didapat dari perkalian pada evaluasi severity serta priority. Dengan demikian, range dari RPN merupakan berkisar antara 1– 25, di mana nilai 1 mengindikasikan kecuali bug selanjutnya sangat beresiko serta nilai 25 mengindikasikan jikalau bug selanjutnya hanya berkenaan sepele yang sanggup diabaikan.
Field summary memuat penjelasan pendek menimpa bug. Field steps to reproduce menyediakan suatu hal gambaran yang pas dan juga sadar perihal gimana menciptakan kembali bug tersebut. Field isolation memuat data bikin menyakinkan pengembang/ programmer kalau bug yang ditemui selanjutnya merupakan betul- betul bug. Perihal ini sanggup bersama dengan menjelaskan tanda- sinyal munculnya bug selanjutnya serta mampu pula dengan menarangkan akibat dan pemicu dari munculnya bug tersebut.
Field log memuat information rinci menimpa siklus hidup dari suatu hal bug mulai dari dini waktu bug berikut di- entry ke di dalam bug tracking database. Ada pula cerminan siklus hidup dari bug report bisa dilihat terhadap foto di bawah ini.
State simak menggambarkan standing bug di mana bug sudah di- input ke didalam bug tracking database serta menanti buat di- review oleh reviewer saat sebelum bug selanjutnya diinformasikan kepada segala regu proyek pengembangan. State rejected melukiskan status di mana bug tersebut ditolak oleh reviewer dikarenakan harus riset ataupun information lebih lanjut menimpa bug tersebut. State open menggambarkan standing dimana bug berikut sudah di- simak serta di kira relevan dengan data rinci menimpa bug selanjutnya dan juga diinformasikan keberadaannya kepada segala regu proyek pengembangan.
State assigned melukiskan standing dimana bug selanjutnya ditugaskan kepada pengembang bikin mencari information lanjut menimpa bug selanjutnya dan menyelesaikannya. State test menggambarkan status dimana bug berikut udah berakhir diperbaiki oleh pengembang dan wajib diuji buat membetulkan jikalau bug selanjutnya betul- betul sudah diperbaiki.
State reopened melukiskan status dimana bug diakses ulang bikin diperbaiki kembali oleh pengembang.
State closed menggambarkan status dimana bug sudah berakhir diperbaiki serta udah dilakukan konfirmasi kebenarannya lewat pengujian. State deferred bisa digunakan oleh anggota regu proyek buat menunda revisi bug selanjutnya jika mereka perhitungkan jikalau bug berikut membawa prioritas yang rendah.
State cancelled bisa digunakan oleh bagian regu proyek buat membatalkan revisi pada bug selanjutnya karena dinilai sudah tidak relevan lagi. Field Pemilik terhadap bug report menampilkan nama orang yang bertanggung jawab pada bug tersebut. Dengan terdapatnya field ini diinginkan manajer proyek sanggup bersama dengan lebih gampang melacak ataupun mencari information yang lebih rinci lagi menimpa bug tersebut.
Field Estimated Fixed memuat information menimpa ditaksir bertepatan pada bug selanjutnya berakhir diperbaiki. Field Root Cause berisi data menimpa pangkal pemicu dari terjadinya bug tersebut. Bagi Black root cause dari suatu hal bug secara universal sanggup berbentuk:
a) Functional
Dari segi functional, pangkal pemicu dari suatu hal bug bisa berupa spesifikasi yang salah, ataupun spesifikasinya benar tapi implementasinya salah, ataupun sistem berperan dengan benar tapi hasil pengujian memberi tahu error yang salah.
b) System
Dari segi 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 sudah benar tetapi pemikiran saat pelaksanaannya salah.
c) Process
Dari segi process, pangkal pemicu berasal dari sesuatu bug bisa berwujud salahnya operasional aritmatika yang diterapkan, proses inisialisasi yang salah, control ataupun sequence yang salah, maupun error dalam pemrosesan.
d) Data
Dari segi informasi, pangkal pemicu dari sesuatu bug mampu berbentuk tipe informasi yang digunakan salah, struktur informasi yang keliru ataupun pemicu yang lain yang berhubungan dengan informasi.
e) Code
Dari sisi code, pangkal pemicu berasal dari sesuatu bug sanggup berupa keliru pengetikan pada code.
f) Documentation
Dari sisi documentation, pangkal pemicu dari sesuatu bug dapat berwujud salahnya dokumentasi pada sistem.
gram) Standards
Dari sisi standards, pangkal pemicu dari suatu hal bug dapat berupa tidak terpenuhnya standar yang mestinya terhadap sistem tersebut.
h) Other
Root cause berasal dari bug dikategorikan ke didalam other seumpama pangkal pemicu dari bug telah dikenal tapi tidak sesuai bersama dengan model yang terdapat.
i) Duplicate
Root cause yang ini digunakan jikalau tersedia 2 maupun lebih bug report yang mendefinisikan bug yang sama.
j) NAP
Dikategorikan selaku NAP( Not a Problem) apabila bug yang dilaporkan berikut hanya karena deskripsi yang keliru oleh tester.
k) Bad Unit
Root cause ini digunakan bila bug berikut berhubungan kata kegagalan hardware yang tidak diprediksi.
l) RCN
RCN( Root Cause Needed) digunakan andaikata status berasal dari bug tersebut telah closed namun tidak terdapat yang mengenali pangkal pemicu berasal dari terbentuknya bug tersebut.
meter) Unknown
Root cause unknown digunakan andaikata tidak terkandung orang yang mengetahui apa yang terkait atas bug tersebut.
Field Phase Injected mendeskripsikan fase di mana bug berikut dikenalkan, kebanyakan pada fase dini sementara sebelum fase di mana bug tersebut teridentifikasi.
Field Phase Detected mengartikan fase di mana bug tersebut teridentifikasi.
Field Phase Removed mendeskripsikan fase di mana bug tersebut sukses diperbaiki.
Field Close Date menarangkan bertepatan pada dimana status dari bug berikut jadi closed.
Field Resolution mendefinisikan gimana bug selanjutnya diperbaiki.
Dari semua bug report yang sudah dimasukkan ke di dalam bug tracking database sampai sanggup dibuat.
0 Komentar