rangkuman dari bagian “Test Case Development” (tutorial 10-14)

First steps Test case Development Untuk seorang pemula, mudah untuk mengasumsikan bahwa Pengujian melaksanakan berbagai bagian kode, atas dasar ad-hoc dan memverifikasi hasil. Tapi di dunia nyata, Pengujian adalah kegiatan yang sangat formal, dan didokumentasikan secara rinci. Tingkat formalitas tergantung pada jenis aplikasi yang diuji, dan standar yang diikuti oleh organisasi organisasi dan maturity dalam proses pembangunan.

Skenario test – Skenario adalah setiap fungsi yang dapat diuji.Hal ini juga disebut Uji Kondisi, atau Kemungkinan Test. Untuk Reservasi Penerbangan Aplikasi beberapa skenario akan  memerikasa 1) Periksa Fungsi Login 2) Periksa bahwa Orde Baru dapat dibuat 3) Periksa bahwa Orde yang ada dapat dibuka 4) Periksa bahwa seorang pengguna, dapat FAX perintah 5) Periksa bahwa informasi yang ditampilkan di bagian HELP benar 6) Periksa bahwa informasi yang ditampilkan pada Tentang bagian, seperti versi, nama programmer, salinan informasi yang benar adalah benar. Terlepas dari enam skenario diatas, kemudian mencoba dan daftar semua skenario lainnya untuk aplikasi. Dalam skernario ini telah banyak mengidentifikasikan sesuatu yang lebih seperti Update Order, Order Hapus, Periksa Laporan, Periksa Grafik, dan sebagainya..

Test case spesifications Dalam pertimbangkan skenario Test Login Pemeriksaan Fungsi akan ada banyak kemungkinan kasus yang terjadi seperti respon pemeriksaan Nama Agen yang masih berlaku & Password, respon Pemeriksaan memasuki Nama Agen yang tidak valid & Password, Periksa respon ketika Nama Agen Kosong & Login Button ditekan, dan banyak lagi.  Ini tidak lain hanyalah suatu Test Case. skenario pengujian yang agak samar dan mencakup dalam berbagai kemungkinan. Pada pemeriksaan respon dalam memasuki Nama Agen dan password yang valid  jelas bahwa hal uji kebutuhan nilai input Nama viz.Agent & Password  Ini tidak lain hanyalah Data Uji. Untuk mengidentifikasi data uji dapat memakan waktu dan mungkin beberapa kali membuat uji lagi dan memerlukan data. Alasan itu perlu didokumentasikan  Sebelum melanjutkan langkah selanjutnya.

Test basis Pertimbangkan skenario, di mana client mengirimkan dalam permintaan untuk menambah fungsionalitas dan untuk Penerbangan Reservasi yang memungkinkan pengiriman memesan melalui email. Dalam hal ini adalah menentukan bidang GUI dan tombol yang diinginkan. Meskipun aplikasi belum dikembangkan,  namun mencoba dan mengembangkan beberapa uji kasus untuk uji kasus requirement dapat dilakukan. beberapa di antaranya adalah bisa memikirkan dalam Pemeriksaa respon ketika Email ID yang masuk dan mengirim ditekan pada hari yang ditentukan. Serta Pemeriksaan respon ketika email tidak valid ID yang masuk dan mengirim saat tombol ditekan. untuk menciptakan uji kasus, perlu kiranya  melihat sesuatu sebagai dasar pengujian. Ini tidak lain hanyalah Uji Dasar dan Dasar pengujian ini bisa menjadi aktual Aplikasi Under Test (AUT),  seperti dalam hal ini didasarkan pada dokumen Bahkan, inilah yang terjadi pada fase yang berbeda V-Model dimana rencana uji dibuat dengan menggunakan dokumen yang sesuai dan saat kode siap, maka pengujian dilakukan.

Tracebility matrix Kebutuhan tracebility matrix dapat digunakan untuk memeriksa atau untuk melihat apakah persyaratan proyek dalam testing terpenuhi atau tidak. Untuk mempermudah pembuatan matriks traceability, disarankan untuk menambahkan hubungan ke dokumen sumber untuk kedua penelusuran mundur dan mampu telusur ke depan. Dengan kata lain, ketika item berubah dalam satu dokumen baselined, mudah untuk melihat apa yang perlu diubah dalam lainnya.

( link removed by admin based on link owner request )