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