Standar Uji Perangkat Lunak - Functional Testing

Dibuat Oleh pada

Assalamualaikum Wr. Wb.

Pada postingan ini saya akan membagikan sebuah materi Tipe Testing. Tujuan saya membuat postingan ini adalah untuk memenuhi Tugas Materi 6 pada Mata Perkuliahan STANDAR UJI PERANGKAT LUNAK.

Berikut adalah pembahsannya



A. Pengerjian Functional Testing

Pengujian fungsional adalah proses jaminan kualitas dan jenis pengujian kotak hitam yang mendasarkan kasus pengujiannya pada spesifikasi komponen perangkat lunak yang diuji. Fungsi diuji dengan memberi mereka masukan dan memeriksa keluaran, dan struktur program internal jarang dipertimbangkan (tidak seperti pengujian kotak putih). Pengujian fungsional dilakukan untuk mengevaluasi kesesuaian suatu sistem atau komponen dengan persyaratan fungsional tertentu. Pengujian fungsional biasanya menggambarkan apa yang dilakukan sistem.

Karena pengujian fungsional adalah jenis pengujian kotak hitam, fungsionalitas perangkat lunak dapat diuji tanpa mengetahui cara kerja internal perangkat lunak. Artinya penguji tidak perlu mengetahui bahasa pemrograman atau bagaimana perangkat lunak tersebut diimplementasikan. Hal ini, pada gilirannya, dapat mengurangi bias pengembang (atau bias konfirmasi) dalam pengujian karena penguji tidak terlibat dalam pengembangan perangkat lunak.

Pengujian fungsional tidak menyiratkan bahwa Anda menguji fungsi (metode) modul atau kelas Anda. Pengujian fungsional menguji sepotong fungsionalitas dari keseluruhan sistem.


B. Metode Pengujian Keamanan

Berikut adalah 5 metode functional testing:

1. Smoke Testing

    Smoke Testing adalah sejenis Pengujian Perangkat Lunak yang dilakukan setelah perangkat lunak di build untuk memastikan bahwa fungsi penting dari program ini bekerja dengan baik. Ini dijalankan “sebelum” setiap tes fungsional atau regresi rinci dijalankan pada perangkat lunak membangun. Tujuannya adalah untuk menolak aplikasi yang rusak parah, sehingga tim QA tidak membuang waktu menginstal dan menguji aplikasi perangkat lunak.

    Dalam Pengujian Asap, kasus uji yang dipilih mencakup fungsionalitas atau komponen sistem yang paling penting. Tujuannya bukan untuk melakukan pengujian yang mendalam, tetapi untuk memverifikasi bahwa fungsionalitas kritis dari sistem bekerja dengan baik.

    Sebagai contoh, tes asap tipikal adalah Verifikasi bahwa aplikasi berhasil Log In, Sign Up, Posting, Logout, Fitur utama (required), Periksa apakah GUI responsif … dll. Smoke testing bisa dilakukan secara automated (otomatis) untuk membantu mempercepat testing menentukan untuk tahap testing selanjutnya atau fail dan harus rebuild perangkat lunak.


2. Sanity Testing

    Pemeriksaan kewarasan (Sanity Testing) adalah pengujian dasar untuk mengevaluasi dengan cepat apakah suatu klaim atau hasil perhitungan mungkin benar. Ini adalah pemeriksaan sederhana untuk melihat apakah materi yang dihasilkan itu rasional (bahwa pencipta materi itu berpikir secara rasional, menerapkan kewarasan). Inti dari uji kewarasan adalah untuk mengesampingkan kelas-kelas tertentu dengan hasil yang jelas salah, bukan untuk menangkap setiap kemungkinan kesalahan. Sebuah aturan-of-thumb atau back-of-the-amplop perhitungan dapat diperiksa untuk melakukan tes. Keuntungan melakukan uji kewarasan awal adalah mengevaluasi fungsi dasar dengan cepat.

    Sanity Testing adalah Jenis software testing yang dilakukan setelah software sudah hampir jadi dengan fungsi-fungsi lengkap nya sudah jadi, dan bug-bug yang ditemukan pada saat smoke testing berhasil di perbaiki. Tujuan sanity testing untuk memastikan bahwa bug telah diperbaiki dan tidak ada masalah lebih lanjut serta untuk menentukan bahwa fungsi yang diusulkan bekerja seperti yang diharapkan. Jika sanity test gagal maka aplikasi akan di reject untuk menghemat waktu dan biaya yang terlibat dalam pengujian lebih lanjut.


3. Acceptance Testing

    Pengujian penerimaan (Acceptance Testing) adalah pengujian yang dilakukan untuk menentukan apakah persyaratan suatu spesifikasi atau kontrak terpenuhi. Dalam pengujian perangkat lunak, ISTQB mendefinisikan pengujian penerimaan sebagai: Pengujian formal berkenaan dengan kebutuhan pengguna, persyaratan, dan proses bisnis dilakukan untuk menentukan apakah suatu sistem memenuhi kriteria penerimaan dan untuk memungkinkan pengguna, pelanggan atau entitas resmi lainnya untuk menentukan apakah akan menerima sistem.

    Rangkaian pengujian penerimaan mungkin perlu dilakukan beberapa kali, karena semua kasus pengujian mungkin tidak dijalankan dalam satu iterasi pengujian. Rangkaian pengujian penerimaan dijalankan menggunakan prosedur pengujian penerimaan yang telah ditetapkan untuk mengarahkan penguji data mana yang akan digunakan, proses langkah demi langkah yang harus diikuti, dan hasil yang diharapkan setelah eksekusi.

    Hasil aktual disimpan untuk perbandingan dengan hasil yang diharapkan. Jika hasil aktual sesuai dengan hasil yang diharapkan untuk setiap kasus uji, kasus uji dikatakan lulus. Jika jumlah kasus uji yang tidak lulus tidak melanggar ambang batas proyek yang telah ditentukan, rangkaian uji dikatakan lulus. Jika ya, sistem dapat ditolak atau diterima dengan ketentuan yang telah disepakati sebelumnya antara sponsor dan produsen.

    Hasil yang diantisipasi dari eksekusi uji yang berhasil:

  • kasus uji dijalankan, menggunakan data yang telah ditentukan sebelumnya
  • hasil aktual dicatat
  • hasil aktual dan yang diharapkan dibandingkan, dan
  • hasil tes ditentukan.

    Tujuannya adalah untuk memberikan keyakinan bahwa produk yang dikembangkan memenuhi persyaratan fungsional dan non-fungsional. Tujuan dari melakukan pengujian penerimaan adalah bahwa setelah selesai, dan dengan syarat kriteria penerimaan terpenuhi, diharapkan pihak sponsor akan menandatangani pengembangan / peningkatan produk sebagai memenuhi persyaratan yang ditentukan (sebelumnya disepakati antara bisnis dan penyedia / pengembang produk).


4. Regression Testing

    Pengujian regresi menjalankan kembali pengujian fungsional dan non-fungsional untuk memastikan bahwa perangkat lunak yang dikembangkan dan diuji sebelumnya masih berfungsi setelah perubahan. Jika tidak, itu akan disebut regresi. Perubahan yang mungkin memerlukan pengujian regresi termasuk perbaikan bug, peningkatan perangkat lunak, perubahan konfigurasi, dan bahkan penggantian komponen elektronik. Karena rangkaian pengujian regresi cenderung tumbuh dengan setiap cacat yang ditemukan, otomatisasi pengujian sering kali terlibat. Terkadang analisis dampak perubahandilakukan untuk menentukan subset tes yang sesuai (analisis non-regresi).

    Regresi pengujian melibatkan pengujian dilakukan untuk memastikan tidak ada perubahan yang dilakukan selama proses pembangunan telah menyebabkan bug baru. Hal ini juga memastikan tidak ada bug tua muncul dari penambahan modul software baru dari waktu ke waktu.

    Pengujian regresi dapat digunakan tidak hanya untuk menguji kebenaran suatu program tetapi seringkali juga untuk melacak kualitas keluarannya. Misalnya, dalam desain kompilator, pengujian regresi dapat melacak ukuran kode dan waktu yang diperlukan untuk mengompilasi dan menjalankan kasus rangkaian pengujian.

    Juga sebagai konsekuensi dari pengenalan bug baru, pemeliharaan program membutuhkan lebih banyak pengujian sistem per pernyataan tertulis daripada pemrograman lainnya. Secara teoritis, setelah setiap perbaikan, seseorang harus menjalankan seluruh batch kasus uji yang sebelumnya dijalankan terhadap sistem untuk memastikan bahwa itu tidak rusak dengan cara yang tidak jelas. Dalam praktiknya, pengujian regresi semacam itu memang harus mendekati ide teoretis ini, dan biayanya sangat mahal.

    Uji regresi dapat dikategorikan secara luas sebagai uji fungsional atau uji unit. Tes fungsional melatih program lengkap dengan berbagai masukan. Tes unit melatih fungsi individu, subrutin, atau metode objek. Alat pengujian fungsional dan alat pengujian unit cenderung otomatis dan seringkali merupakan produk pihak ketiga yang bukan bagian dari paket kompilator. Uji fungsional dapat berupa rangkaian input program yang ditulis skrip, bahkan mungkin melibatkan mekanisme otomatis untuk mengontrol gerakan dan klik mouse. Pengujian unit dapat berupa serangkaian fungsi terpisah di dalam kode itu sendiri atau lapisan driver yang terhubung ke kode tanpa mengubah kode yang sedang diuji.


5. Usability Testing

    Pengujian kegunaan (Usability Testing) adalah teknik yang digunakan dalam desain interaksi yang berpusat pada pengguna untuk mengevaluasi produk dengan mengujinya pada pengguna. Ini dapat dilihat sebagai praktik kegunaan yang tak tergantikan, karena memberikan masukan langsung tentang bagaimana pengguna sebenarnya menggunakan sistem.  Ini lebih peduli dengan intuisi desain produk dan diuji dengan pengguna yang tidak memiliki eksposur sebelumnya. Pengujian seperti itu sangat penting untuk keberhasilan produk akhir karena aplikasi yang berfungsi penuh yang membuat kebingungan di antara penggunanya tidak akan berlangsung lama. Ini berbeda dengan metode pemeriksaan kegunaan di mana para ahli menggunakan metode berbeda untuk mengevaluasi antarmuka pengguna tanpa melibatkan pengguna.

    Pengujian kegunaan berfokus pada pengukuran kapasitas produk buatan manusia untuk memenuhi tujuan yang dimaksudkan. Contoh produk yang umumnya mendapat manfaat dari pengujian kegunaan adalah makanan, produk konsumen, situs web atau aplikasi web, antarmuka komputer, dokumen, dan perangkat. Pengujian kegunaan mengukur kegunaan, atau kemudahan penggunaan, dari objek atau sekumpulan objek tertentu, sedangkan studi interaksi manusia-komputer secara umum berusaha untuk merumuskan prinsip-prinsip universal.

    Sebagai desainer atau product owner, teori dan pengetahuan mendalam seputar produk terkadang membuat permasalahan yang ada tidak terlihat. Maka dari itu, alasan utama usability testing sangat penting adalah karena uji coba ini dijalankan oleh user yang nantinya akan menggunakan produk tersebut. Dengan menjalankan usability testing, tim product development dapat melihat apakah user memahami alur dan cara kerja situsmu atau tidak. Tahapan ini penting untuk dijalankan agar nantinya, user yang bukan peserta uji coba tidak kebingungan dan bisa mendapatkan user experience yang baik.

    Heuristik kegunaan Nielsen, yang terus berkembang sebagai tanggapan terhadap penelitian pengguna dan perangkat baru, meliputi:

  • Visibilitas status sistem
  • Kecocokan antara sistem dan dunia nyata
  • Kontrol dan kebebasan pengguna
  • Konsistensi dan standar
  • Pencegahan kesalahan
  • Pengakuan daripada ingatan
  • Fleksibilitas dan efisiensi penggunaan
  • Desain estetika dan minimalis
  • Bantu pengguna mengenali, mendiagnosis, dan memulihkan dari kesalahan
  • Bantuan dan dokumentasi


Sekian materi yang saya posting di blog ini. Mohon maaf apabila ada kekurangan dan kesalahan dalam penulisan. Semoga dapat bermanfaat bagi kita semua

Terima Kasih

Wassalamualaikum Wr. Wb.

Penulis
Nama: Dharma Ajie Nur Rois
NPM: 1810 6311 70120
Kelas: 6G Fasilkom

-----------------------------------------------------------------------------------------------------------------------------------------------

Daftar Pustaka

  • https://en.m.wikipedia.org/wiki/Functional_testing
  • https://medium.com/@damar.mustikoaji/smoke-testing-f841f9632b84
  • https://en.wikipedia.org/wiki/Sanity_check
  • http://www.sistem-informasi.xyz/2017/04/pengertian-smoke-testing-dan-sanity.html
  • https://en.wikipedia.org/wiki/Acceptance_testing
  • https://en.wikipedia.org/wiki/Regression_testing
  • https://sis.binus.ac.id/2016/12/16/type-of-system-test/
  • https://en.wikipedia.org/wiki/Usability_testing
  • https://glints.com/id/lowongan/usability-testing-adalah/#.YGkReh8zbIU

Komentar

Posting Komentar