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