Cara Menyemak dan Menguji Sistem Perniagaan Tersuai Sebelum Anda Menerimanya

Pembangun memberitahu anda bahawa sistem sudah siap, dan invois bayaran akhir sudah berada di atas meja anda. Inilah detik yang paling kurang disediakan oleh kebanyakan pemilik sistem perniagaan tersuai: anda diminta menerima sesuatu yang tidak pernah diajar cara menyemaknya. Ujian penerimaan ialah caranya. Ia bukan latihan teknikal. Ia ialah anda dan pasukan anda menggunakan sistem itu seperti perniagaan anda benar-benar berjalan, sebelum kerja diisytiharkan selesai dan bayaran terakhir tiba tempohnya. Panduan ini menunjukkan kepada pemilik bukan teknikal cara menjalankannya, langkah demi langkah.

Apa itu ujian penerimaan, dan apa yang bukan

Ujian penerimaan ialah peringkat apabila perniagaan mengesahkan bahawa sistem yang siap melakukan apa yang dipersetujui, menggunakan kerja sebenar dan bukan sekadar demonstrasi. Anda sering melihatnya dipanggil ujian penerimaan pengguna, atau UAT. Perkataan “pengguna” itu penting: orang yang menilai sistem ialah orang yang akan menggunakannya, bukan orang yang membinanya.

Adalah berguna untuk jelas tentang apa yang dicakup dan apa yang tidak:

• Ia bukan ujian oleh pembangun sendiri. Pembangun menyemak bahawa perisian berjalan tanpa ralat dan setiap ciri berfungsi seperti yang direka. Ujian penerimaan menyemak perkara lain: sama ada apa yang dibina sepadan dengan keperluan perniagaan anda.
• Ia bukan peluang untuk menambah idea baharu. Hasrat yang tidak pernah menjadi sebahagian daripada skop yang dipersetujui ialah perubahan, dan ia dihargakan serta dijadualkan secara berasingan. Mencampurkannya ke dalam ujian ialah cara terpantas untuk mengubah pengesahan yang bersih menjadi pertikaian.
• Ia bukan semakan kod. Anda tidak perlu membaca satu baris kod pun. Anda menilai hasilnya: apa yang dimasukkan, apa yang keluar dan sama ada ia betul.
• Ia bukan pilihan. Jika anda melangkaunya, anda menerima sistem atas dasar percaya, dan ujian sebenar yang pertama akan berlaku pada pelanggan dan rekod yang hidup.

Kedudukan peringkat ini dalam jadual, dan berapa lama projek pelbagai saiz biasanya mengambil masa, dibincangkan dalam berapa lama sistem perniagaan tersuai mengambil masa. Panduan ini tentang apa yang perlu dilakukan dalam peringkat itu.

Mengapa pemilik yang perlu melakukannya, bukan pembangun

Orang yang membina sesebuah sistem ialah orang yang paling tidak sesuai untuk mengujinya. Pembangun tahu dengan tepat bagaimana setiap skrin sepatutnya digunakan, jadi tanpa sedar mereka mengikut laluan yang mereka bina. Mereka tidak tahu bahawa kiraan stok hari Jumaat anda sentiasa ada tiga pengecualian, bahawa seorang pelanggan mempunyai dua nama syarikat, atau bahawa kakitangan kaunter anda memasukkan pesanan dengan sebelah tangan sambil melayan orang lain.

Ada juga sebab praktikal. Penerimaan ialah titik apabila projek bertukar daripada “sedang dibina” kepada “siap”. Sebelum itu, pembangun bekerja untuk membetulkan perkara. Selepas itu, masalah cenderung dikendalikan sebagai permintaan sokongan atau kerja baharu, bergantung pada perjanjian anda. Itulah detik anda mempunyai pengaruh paling besar, dan detik semakan teliti memerlukan kos paling kecil.

Inilah sebabnya jadual bayaran penting. Sebut harga yang munasabah mengaitkan bayaran akhir dengan peluang anda menguji sistem berbanding apa yang dipersetujui, bukan dengan tarikh kalendar. Jika anda masih membandingkan pembekal, panduan kami untuk membandingkan dua sebut harga perisian tersuai menunjukkan cara menyemaknya sebelum anda menandatangani.

Langkah pertama: persetujui maksud “siap” sebelum ujian bermula

Anda tidak boleh lulus atau gagalkan sistem berdasarkan perasaan. Kriteria penerimaan ialah pernyataan bertulis yang ringkas dan boleh disemak tentang apa yang mesti dilakukan oleh sistem yang siap. Idealnya ia datang terus daripada skop dalam sebut harga anda. Jika skop ditulis secara longgar, jadikannya senarai sekarang dan persetujuilah dengan pembangun secara bertulis sebelum ujian bermula, supaya kedua-dua pihak bekerja mengikut halaman yang sama.

Ujian bagi kriteria yang baik mudah: bolehkah dua orang berbeza menyemaknya dan mencapai jawapan yang sama? Jadual di bawah menunjukkan bagaimana ayat yang kabur menjadi sesuatu yang boleh diuji.

Pastikan senarai itu terhad kepada apa yang benar-benar dipersetujui. Apa-apa yang anda terfikir semasa ujian tetapi tiada dalam senarai dimasukkan ke dalam lajur “permintaan baharu” yang berasingan, seperti yang akan anda lihat di bawah. Sepuluh hingga tiga puluh kriteria yang jelas biasanya lebih berguna daripada seratus yang kabur.

Sediakan tugas sebenar dan data yang realistik

Sistem yang berfungsi dengan data contoh yang kemas masih boleh gagal pada perniagaan anda. Bina ujian anda daripada minggu yang sebenar, bukan minggu yang ideal.

• Tulis senario daripada minggu biasa. Senaraikan lapan hingga dua belas perkara yang benar-benar dilakukan perniagaan anda dengan sistem itu. Bagi setiap satu, catat siapa yang melakukannya, apa yang dia mulakan, apa yang dia lakukan dan apa yang sepatutnya berlaku pada akhirnya.
• Sertakan kes yang janggal. Bayaran balik, pembatalan, penghantaran separa, harga yang berubah pada pertengahan minggu, rekod pelanggan yang dimasukkan dua kali, pesanan yang dimulakan lalu ditinggalkan. Sistem lazimnya gagal pada pengecualian, dan pengecualian merupakan sebahagian besar kerja sebenar.
• Gunakan data sebenar atau yang realistik. Beberapa puluh rekod yang kelihatan tulen dalam pelbagai bentuk akan menemui lebih banyak masalah daripada segelintir rekod yang sempurna. Jika anda menggunakan salinan rekod pelanggan sebenar, hadkan siapa yang boleh melihat salinan ujian itu, dan tanya pembangun bagaimana ia diasingkan serta siapa yang mempunyai akses.
• Semak data yang dipindahkan dengan sumbernya. Jika rekod sedia ada anda dimuatkan ke dalam sistem baharu, ambil sampel dan banding setiap medan dengan hamparan atau alat lama yang asal. Memindahkan data anda ke sistem baharu menerangkan apa yang perlu disediakan dan apa yang lazimnya tidak menjadi.
• Minta salinan ujian yang berasingan. Ujian patut dilakukan pada salinan yang diasingkan daripada rekod hidup, supaya pesanan latihan dan kesilapan tidak sampai kepada pelanggan sebenar. Tanya pembangun bagaimana ini akan disediakan.

Pilih siapa yang menguji

Penerimaan hanya bermakna jika orang yang betul melakukannya. Pemilik atau pengurus patut mengambil bahagian, tetapi sistem itu juga patut dicuba oleh orang yang akan menggunakannya setiap hari.

• Seorang daripada setiap peranan. Jika sistem mempunyai juruwang, penyelia, pasukan gudang dan paparan pemilik, setiap peranan patut menguji skrinnya sendiri. Peranan berbeza melihat perkara berbeza, dan setiap log masuk memerlukan semakannya sendiri.
• Sekurang-kurangnya seorang yang ragu-ragu. Kakitangan yang menyukai hamparan lama amat berguna. Jika sistem memuaskan hatinya, ia mungkin memuaskan orang lain.
• Masa yang dilindungi. Ujian yang diselit di antara pelanggan menghasilkan keputusan yang tergesa-gesa dan sopan. Peruntukkan blok masa, walaupun hanya beberapa jam yang dibahagikan dalam beberapa hari.
• Kebenaran untuk bersikap menyusahkan. Beritahu penguji bahawa menemui masalah ialah tugas mereka. Penguji yang berkata “nampaknya okey” kerana segan lebih teruk daripada tiada penguji.
• Seorang yang mengumpul keputusan. Beberapa orang melapor melalui mesej dengan cara berbeza menyukarkan kerja pembangun. Seorang pemilik senarai memastikan ia konsisten.

Jika sistem dikongsi merentasi beberapa outlet atau cawangan, uji sekurang-kurangnya rutin sebenar satu outlet dari awal hingga akhir. Persediaan berbilang tapak menambah semakannya sendiri, seperti sama ada setiap cawangan hanya melihat datanya sendiri. Panduan sistem pengurusan berbilang outlet membincangkan apa yang perlu diperhatikan.

Jalankan ujian: rutin yang mudah

Anda tidak memerlukan alat khas. Hamparan dikongsi, dokumen nota dan telefon untuk tangkapan skrin sudah memadai. Lalui senario dalam rutin yang tetap:

• Langkah 1: sahkan apa yang diuji. Tanya pembangun versi mana yang anda uji dan minta dia memberitahu anda jika ia berubah pada pertengahan pusingan. Keputusan kurang bermakna jika sistem terus berubah di bawah penguji.
• Langkah 2: lalui setiap senario mengikut turutan. Catat lulus atau gagal berbanding kriteria. Bagi setiap kegagalan, tulis langkah yang tepat, apa yang berlaku dan apa yang anda jangkakan, serta ambil tangkapan skrin.
• Langkah 3: cuba membuat kesilapan. Biarkan medan wajib kosong, taip huruf di tempat nombor, tekan butang kembali, muat semula halaman, masukkan perkara yang sama dua kali. Sistem yang baik memberitahu pengguna apa yang salah.
• Langkah 4: semak setiap output. Laporan, eksport, dokumen bercetak, e-mel dan pemberitahuan ialah apa yang benar-benar diharapkan oleh perniagaan. Banding angkanya dengan apa yang anda tahu benar.
• Langkah 5: uji dua orang serentak. Jika beberapa kakitangan menggunakan sistem bersama-sama, minta dua orang bekerja pada item atau stok yang sama pada masa yang sama dan lihat apa yang berlaku.
• Langkah 6: tutup satu hari atau satu bulan. Jalankan rutin akhir tempoh pada data ujian dan semak bahawa jumlahnya sepadan dengan apa yang anda masukkan.
• Langkah 7: hantar semuanya dalam satu kelompok. Serahkan kepada pembangun satu senarai yang teratur dan bukannya mesej yang datang setitik-setitik.

Simpan senarai isu (punch list), dan susun dengan jujur

Senarai isu atau punch list ialah rekod bernombor bagi setiap isu yang ditemui, disimpan di satu tempat. Beri setiap item nombor, senario asalnya, langkah untuk mengulanginya, apa yang berlaku, apa yang anda jangkakan, tangkapan skrin dan status seperti terbuka, dibetulkan atau perlu diuji semula. Senarai sebegini mengubah “ia tidak berfungsi dengan betul” menjadi sesuatu yang boleh ditindak oleh pembangun, dan kemudiannya membuktikan apa yang dibangkitkan serta bila.

Tidak semua item ialah jenis masalah yang sama, dan menganggapnya sama rata ialah punca projek tersekat. Susun setiap item semasa anda mencatatnya:

Baris terakhir ialah yang paling banyak menimbulkan geseran. Sesuatu yang tidak memenuhi senarai yang dipersetujui ialah kecacatan. Sesuatu yang anda mahu tetapi tidak pernah dipersetujui ialah perubahan. Kedua-duanya termasuk dalam senarai, tetapi dilabel secara berbeza, supaya sebarang perselisihan berlaku secara bertulis dan awal. Ia juga membantu untuk mengetahui lebih awal bagaimana sebut harga anda melayan setiap satu, itulah sebabnya terma selepas pelancaran wajar dibaca dengan teliti.

Uji semula, kemudian sahkan penerimaan secara bertulis

Membetulkan satu perkara boleh merosakkan perkara lain secara senyap. Selepas pembangun menyelesaikan senarai, uji semula setiap item yang dibetulkan, kemudian jalankan semula senario teras anda untuk memastikan tiada apa yang berdekatan berubah. Teruskan sehingga item yang menghalang kerja telah selesai.

Kemudian buat keputusan, dan buatnya dengan jelas. Hanya ada tiga hasil yang jujur:

• Diterima. Setiap kriteria yang dipersetujui lulus.
• Diterima dengan pengecualian yang disenaraikan. Item kecil masih tinggal, setiap satu ditulis dengan pemilik dan pengendalian yang dipersetujui, seperti pembetulan menjelang tarikh tertentu atau tempat dalam senarai perubahan.
• Tidak diterima. Satu atau lebih item yang menghalang masih tinggal. Senarai isu menjadi agenda untuk pusingan seterusnya.

Pengesahan penerimaan (sign-off) bertulis patut menyatakan versi mana yang diuji, tarikh, siapa yang menguji, kriteria mana yang lulus, dan dengan tepat item mana yang masih terbuka serta bagaimana setiap satu akan dikendalikan. Ia patut diberikan oleh orang dalam perniagaan yang mempunyai kuasa untuk menerimanya. Persetujuan lisan di lorong pejabat ialah cara pertikaian bermula.

Sebelum anda menandatangani, semak juga apa yang disertakan bersama sistem. Penyerahan patut merangkumi log masuk, dokumentasi dan akaun tempat sistem berjalan, atas nama perniagaan anda jika itu dipersetujui. Siapa yang memiliki kod sumber sistem perniagaan tersuai anda menerangkan apa yang perlu disahkan. Lepaskan bayaran akhir mengikut terma bayaran yang anda persetujui, dan hanya setelah anda berpuas hati bahawa pengesahan itu sepadan dengan apa yang anda uji.

Senarai semak penerimaan yang boleh digunakan semula

Salin jadual ini ke dalam hamparan dan tambah lajur keputusan bagi setiap bidang. Apa-apa yang tidak disahkan menjadi satu baris dalam senarai isu.

Kesilapan biasa

• Membiarkan pembangun menjalankan ujian. Demonstrasi menunjukkan sistem berfungsi seperti yang direka. Ia tidak menunjukkan bagaimana ia bertindak di tangan anda.
• Menguji laluan yang lancar sahaja. Jika setiap senario berjalan lancar, anda hanya menguji sedikit.
• Menggunakan data contoh yang kemas. Rekod yang sempurna menyembunyikan masalah yang didedahkan oleh rekod sebenar yang berselerak.
• Tidak melibatkan pengguna sebenar. Jika hanya pemilik yang menguji, orang yang perlu hidup dengan sistem itu menemui kecacatan selepas pelancaran.
• Mencampurkan hasrat dengan kecacatan. Idea baharu yang dilaporkan sebagai pepijat mengelirukan senarai dan merosakkan kepercayaan kedua-dua pihak.
• Bersetuju melalui mesej dan ingatan. Tanpa senarai kriteria bertulis dan pengesahan penerimaan bertulis, tiada siapa dapat menunjukkan kemudian apa yang telah diterima.
• Menandatangani di bawah tekanan masa. Tarikh pelancaran bukan sebab untuk menerima kecacatan yang menghalang. Catatkan pengecualian, atau tangguhkan pengesahan.
• Membayar sebelum menguji. Semak bahawa terma bayaran memberi anda peluang sebenar untuk menguji dahulu.

Di mana Gotka Technologies berperanan

Perkhidmatan Pembangunan Aplikasi & Sistem Gotka Technologies membina aplikasi web, sistem perniagaan dan aplikasi mudah alih, dengan harga permulaan indikatif RM8,000 untuk aplikasi web dan papan pemuka, RM12,000 untuk sistem perniagaan dan integrasi serta RM15,000 untuk aplikasi mudah alih, masing-masing disahkan melalui sebut harga bertulis setelah skop diketahui. Bagaimana ujian penerimaan berjalan pada mana-mana projek, termasuk berapa pusingan pembetulan yang dicakup dan bagaimana bayaran berkaitan dengan pengesahan penerimaan, patut dinyatakan dalam sebut harga bertulis itu, jadi mintalah secara bertulis daripada setiap pembekal yang anda hubungi, termasuk kami. Untuk menilai bahagian harga dahulu, lihat panduan kos aplikasi mudah alih kami, dan jika anda masih memilih antara membeli dengan membina, baca perisian sedia ada vs perisian tersuai. Sistem yang siap juga memerlukan tempat yang boleh dipercayai untuk berjalan, dan di situlah Pengehosan Awan Gotka berperanan.

Istilah utama digunakan dalam panduan ini

• Ujian penerimaan: peringkat apabila perniagaan menguji sistem yang siap berbanding apa yang dipersetujui, sebelum menerimanya.
• UAT (ujian penerimaan pengguna): ujian penerimaan yang dijalankan oleh orang yang akan menggunakan sistem itu.
• Kriteria penerimaan: pernyataan bertulis yang boleh disemak tentang apa yang mesti dilakukan oleh sistem yang siap.
• Senario ujian: tugas yang realistik, ditulis langkah demi langkah, dengan hasil yang anda jangkakan.
• Data ujian: rekod yang digunakan semasa ujian, idealnya sebenar atau realistik dari segi bentuk.
• Senarai isu (punch list): rekod bernombor bagi setiap isu yang ditemui semasa ujian, beserta statusnya.
• Kecacatan: sesuatu yang tidak melakukan apa yang dipersetujui.
• Permintaan perubahan: permintaan untuk menambah atau mengubah sesuatu yang tiada dalam skop yang dipersetujui.
• Ujian semula: menyemak sekali lagi bahawa item yang dibetulkan kini berfungsi dan tiada apa yang berdekatan rosak.
• Pengesahan penerimaan (sign-off): pengesahan bertulis bahawa perniagaan menerima sistem itu, termasuk sebarang pengecualian yang disenaraikan.