Test Scenario dan Test Cases

Test Scenario

    Test Scenario didefinisikan sebagai fungsionalitas apa pun yang dapat diuji, memberikan gagasan tingkat tinggi tentang apa yang perlu diuji. Test Scenario merupakan serangkaian kasus pengujian kolektif yang membantu tim pengujian untuk menentukan karakteristik positif dan negatif dari sebuah proyek.

Mengapa diperlukan menulis Test Scenario?

  • Memverifikasi fungsionalitas lengkap dari aplikasi perangkat lunak
  • Memastikan bahwa proses dan alur bisnis telah sesuai dengan persyaratan fungsional
  • Memastikan bahwa perangkat lunak berfungsi untuk kasus penggunaan yang paling umum
  • Test Scenario dapat disetujui oleh berbagai pemangku kepentingan seperti Analis Bisnis, Developer, Client untuk memastikan Aplikasi diuji secara menyeluruh
  • Menentukan upaya kerja pengujian dengan cepat (membuat proposal atau mengatur tenaga kerja)
  • Membantu menentukan transaksi end-to-end dari real user
  • Setelah Test Scenario ini diselesaikan, Test Case dapat dengan mudah diturunkan dari Test Scenario

Contoh penulisan test scenario

  • Test Scenario 1: Periksa Fungsi Pencarian
  • Test Scenario 2: Periksa Fungsi Pemesanan
  • Test Scenario 3: Periksa Fungsi Pembayaran

Caraterbaikuntukmembuat Test Scenario

  • Test Scenario sebagian besar merupakan pernyataan baris tunggal yang memberi tahu apa yang harus diuji
  • Deskripsi skenario harus sederhana dan mudah dipahami
  • Analisa yang cermat terhadap requirement
  • Alat dan sumber daya yang diperlukan untuk pengujian perlu dikumpulkan sebelum dimulainya proses pengujian

Test Cases

    Test Cases adalah serangkaian tindakan berurutan yang dijalankan untuk memverifikasi fitur atau fungsionalitas tertentu dari sebuah software. Pada dasarnya, Test Case merinci langkah-langkah, data, prasyarat, dan pasca kondisi yang diperlukan untuk memverifikasi fitur.

    Test Case akan menjabarkan variabel tertentu dan QA perlu membandingkan antara hasil yang diharapkan dan hasil yang aktual untuk menyimpulkan apakah fitur tersebut berfungsi sebagaimana mestinya. Komponen Test Case terdiri dari input, eksekusi, dan output/respon yang diharapkan. Pada dasarnya, Test Case memberi tahu apa yang harus dilakukan, bagaimana melakukannya dan hasil apa yang dapat diterima.

Mengapa diperlukan menulis Test Case?

  • Memvalidasi fitur dan fungsi spesifik dari perangkat lunak.
  • Memandu tester melalui aktivitas pengujian secara langsung.
  • Merekam langkah-langkah yang dilakukan, yang dapat ditinjau kembali jika ditemukan cacat.
  • Memberikan cetak biru untuk proyek dan tester masa depan sehingga mereka tidak harus mulai bekerja dari awal.
  • Membantu mendeteksi masalah kegunaan dan kesenjangan desain sejak dini.
  • Membantu tester dan developer baru, bahkan jika mereka bergabung di tengah-tengah proyek yang sedang berlangsung.

Format Standar Test Case

  • ID Test Case
  • Test Scenario
  • Prasyarat / Prerequisites
  • Langkah Uji / Test Steps
  • Data Uji / Test Data
  • Hasil yang Diharapkan / Dimaksudkan
  • Hasil yang didapatkan / Actual Results
  • Status Tes – Lulus / Gagal Test Case Example Format

Saat menulis test case, ingatlah untuk menyertakan:

  • Deskripsi yang masuk akal tentang persyaratan
  • Deskripsi proses pengujian
  • Detail yang terkait dengan pengaturan pengujian: versi perangkat lunak yang diuji, titik data, OS, perangkat keras, izin keamanan, tanggal, waktu, prasyarat, dll.
  • Dokumen atau lampiran terkait apa pun yang diperlukan oleh penguji
  • Alternatif untuk prasyarat, jika ada

Fitur Umum Test Case

  •      Kemungkinan direvisi dan diperbarui secara berkala. Persyaratan perangkat lunak dapat berubah, tergantung pada perubahan prioritas bisnis atau preferensi pelanggan. Jika persyaratan berubah, test case harus diubah sesuai dengan itu. Deteksi bug dan langkah debugging mungkin juga memerlukan test case untuk diubah.
  •      Kemungkinan melibatkan pengelompokan. Test case dalam skenario pengujian tunggal biasanya harus dijalankan di urutan tertentu atau dalam kelompok. Dalam hal ini, prasyarat khusus dari satu test case akan berlaku untuk test case lain dalam urutan yang sama.
  •      Kemungkinan untuk saling bergantung. Seringkali, test case dapat bergantung satu sama lain. Ini terutama berlaku untuk aplikasi berlapis dengan logika bisnis multi-tingkat.
  •      Kemungkinan akan digunakan oleh penguji serta pengembang. Test case sangat membantu bagi dev serta tester. Misalnya, ketika dev memperbaiki bug, test case bisa sangat berguna untuk mereplikasi bug tersebut. Dalam Pengembangan Berbasis Uji (TDD), pengembang membuat test case untuk dibuat logika bisnis, mencakup beberapa test scenario, dan mulai menulis kode.

Pemahaman Test Case

    Test Case didesain untuk menjabarkan Test Scenario. Contoh test case yang dibuat dari test scenario "Periksa Fungsi Login" adalah

  1. Periksa perilaku sistem ketika id email dan kata sandi yang valid dimasukkan.
  2. Periksa perilaku sistem ketika id email yang tidak valid dan kata sandi yang valid dimasukkan.
  3. Periksa perilaku sistem ketika id email yang valid dan kata sandi yang tidak valid dimasukkan.
  4. Periksa perilaku sistem ketika id email yang tidak valid dan kata sandi yang tidak valid dimasukkan.
  5. Periksa perilaku sistem ketika id email dan kata sandi dibiarkan kosong.
  6. Periksa fungsionalitas Lupa kata sandi Anda.
  7. Periksa perilaku sistem ketika nomor telepon dan kata sandi yang valid/tidak valid dimasukkan.
  8. Periksa perilaku sistem ketika "Biarkan saya tetap masuk" dicentang.
  9. Periksa fungsionalitas button Log In.
Contoh Test Case berdasarkan skenario tertentu. Berikut adalah contoh kasus:

  • ID Test case: #TC001
  • Test Scenario: Untuk mengautentikasi login pengguna yang berhasil di Gmail.com
  • Test Steps:

  1. User melakukan navigasi ke www.gmail.com.
  2. Di kolom 'email', user memasukkan alamat email yang terdaftar.
  3. User mengklik tombol 'Berikutnya'.
  4. User memasukkan kata sandi yang terdaftar.
  5. User mengklik tombol 'Masuk.'

  • Prasyarat: ID Gmail terdaftar dengan nama pengguna dan sandi unik.
  • Browser: Chrome v 86. Perangkat: Samsung Galaxy Tab S7.
  • Test Data: Nama pengguna dan kata sandi yang sah.
  • Hasil yang Diharapkan: Setelah nama pengguna dan kata sandi dimasukkan, halaman web dialihkan ke kotak masuk pengguna, menampilkan dan menyorot email baru di bagian atas.
  • Hasil Aktual: Seperti yang Diharapkan
  • Status Tes - Lulus/Gagal: Lulus

Cara Terbaik untuk Menulis Test Case

  • Mengutamakan kejelasan dan transparansi. Bersikaplah jelas, singkat, dan tegas dalam menggambarkan apa yang harus dilakukan tester dan hasil apa yang idealnya mereka dapatkan.
  • Fokus pada persyaratan Pengguna Akhir saat menulis contoh Test Case. Petakan Test Case ke mencerminkan setiap aspek dari perjalanan pengguna. Gunakan Dokumen Spesifikasi dan Persyaratan Dokumen untuk melakukannya.
  • Hindari pengulangan. Jika beberapa tes dapat dijalankan dengan Test Case yang sama, gunakan ID Test Case untuk merujuk ke Test Case yang diperlukan.
  • Pertahankan Langkah Uji/ Test step seminimal mungkin. Idealnya hingga 10-15 langkah, jika memungkinkan.
  • Fokus pada pencapaian cakupan tes yang maksimal.
  • Buat Test Case untuk pengujian yang mengembalikan hasil yang sama tidak peduli siapa yang menjalankannya. Memastikan bahwa tes berdiri sendiri.

    Setelah Test Case dibentuk, pengujian yang sesuai harus dijalankan pada browser, perangkat, dan sistem operasi. Ingatlah bahwa fragmentasi perangkat merupakan perhatian yang signifikan untuk setiap pengembang dan penguji. Setiap situs web diharapkan dapat bekerja dengan mulus di banyak perangkat-kombinasi browser-OS. Secara global, semua perangkat lunak harus dioptimalkan untuk konfigurasi, area tampilan, dan layar yang resolusinya berbeda (responsive).

    Dalam keadaan ini, tidak ada emulator atau simulator yang dapat mereplikasi kondisi pengguna yang sebenarnya. Perangkat lunak perlu diuji pada perangkat nyata untuk bekerja dalam keadaan dunia nyata seperti baterai lemah, adanya panggilan masuk, kekuatan jaringan yang lemah, dan sebagainya.

Perbedaan Test Scenario dan Test Cases

Test Scenario

  • Berisi dokumentasi tingkat tinggi yang menjelaskan end to end dari fungsionalitas yang akan diuji.
  • Lebih berfokus pada "apa yang harus diuji" daripada "bagaimana menguji".
  • Test Scenario adalah satu baris. Jadi, selalu ada kemungkinan ambiguitas selama pengujian.
  • Test Scenario diturunkan dari artefak pengujian seperti BRS, SRS, dll.
  • Ini membantu dengan cara yang gesit untuk menguji end to end dari fungsionalitas.
  • Test Scenario adalah tindakan tingkat tinggi.
  • Relatif lebih sedikit waktu dan sumber daya yang diperlukan untuk membuat & menguji menggunakan skenario.

Test Cases

  • Berisi langkah-langkah pengujian yang pasti, data, hasil yang diharapkan untuk menguji semua fitur aplikasi.
  • Berfokus pada "apa yang harus diuji" dan "bagaimana menguji".
  • Test Case telah menentukan langkah, prasyarat, hasil yang diharapkan, dll. Oleh karena itu, tidak ada ambiguitas dalam proses ini. 
  • Test Case sebagian besar berasal dari Test Scenario. Multiple Test case dapat diturunkan dari satu Test Scenario.
  • Ini membantu dalam pengujian aplikasi yang lengkap.
  • Test Case adalah tindakan tingkat rendah.
  • Lebih banyak sumber daya diperlukan untuk dokumentasi dan eksekusi kasus uji.


Komentar

Posting Komentar

Postingan populer dari blog ini

Software Testing Life Cycle

Gambar
     Pengujian adalah bagian mendasar dari setiap proses produksi. Apa pun produknya, selalu diuji kualitas dan cacatnya sebelum sampai ke pelanggan sehingga mereka menerima produk berkualitas yang berfungsi penuh. Hal yang sama berlaku untuk produk yang dikembangkan oleh perusahaan perangkat lunak juga. Dalam dunia perangkat lunak, proses pengujian secara resmi disebut Software Testing Life Cycle (STLC) .      Software Testing Life Cycle (STLC) merupakan tahapan proses pengujian yang dilaksanakan secara sistematis dan terencana. Dalam proses STLC, berbagai kegiatan dilakukan untuk meningkatkan kualitas produk. Semua fase STLC pada dasarnya mencakup daftar kegiatan yang perlu dilakukan dan memiliki entry criteria dan exit criteria yang ditetapkan. Entry Criteria dan Exit Criteria Entry Criteria merupakan suatu ketentuan yang harus kita penuhi sebelum pengujian dapat di mulai Exit Criteria merupakan ketentuan yang harus diselesaikan sebelum menyelesaikan pe...
Baca selengkapnya

API Testing using Postman

Gambar
       Ketika membuat sebuah aplikasi berupa REST API atau GraphQL. Terdapat tools atau alat yang dapat digunakan untuk membantu dalam proses pengujian aplikasi yang telah dibuat. Salah satu tools tersebut adalah Postman.      Postman merupakan salah satu tools yang paling populer untuk melakukan pengujian API. Postman muncul pada tahun 2012 sebagai proyek sampingan oleh Abhinav Asthana untuk menyederhanakan alur kerja API dalam pengujian dan pengembangan. API memungkinkan aplikasi perangkat lunak untuk berkomunikasi satu sama lain melalui panggilan API. 1. Registrasi dan Login Jika belum memiliki akun, daftar melalui link berikut  https://identity.getpostman.com/signup . Setelah melakukan registrasi, silahkan langsung login menggunakan data yang sudah diregistrasikan Setelah Login, kita dapat mengganti Team Name dan Team Domain melalui  https://qabootcamp.postman.co/settings/team/general . 2. Instalasi      A...
Baca selengkapnya