Apa itu Pengujian Asap?

Apa itu Pengujian Asap?

Pengujian Asap adalah proses pengujian perangkat lunak yang menentukan apakah perangkat lunak yang digunakan stabil atau tidak. Pengujian asap merupakan konfirmasi bagi tim QA untuk melanjutkan pengujian perangkat lunak lebih lanjut. Pengujian ini terdiri dari serangkaian pengujian minimal yang dijalankan pada setiap perangkat untuk menguji fungsionalitas perangkat lunak. Pengujian asap juga dikenal sebagai “Pengujian Verifikasi Perangkat” atau “Pengujian Keyakinan.”

Secara sederhana, smoke testing berarti memverifikasi bahwa fitur-fitur penting berfungsi dan tidak ada masalah serius dalam build yang sedang diuji. Ini adalah pengujian regresi mini dan cepat terhadap fungsionalitas utama. Hal ini membantu menentukan apakah build tersebut cacat sehingga pengujian lebih lanjut menjadi sia-sia dan membuang waktu serta sumber daya.

Bandingkan Pengujian Asap Vs Kewarasan

Mengapa kita melakukan Smoke Testing?

Pengujian asap (smoke testing) memainkan peran penting dalam pengembangan perangkat lunak karena memastikan kebenaran sistem pada tahap awal. Dengan cara ini, kita dapat menghemat upaya pengujian. Setelah kita menyelesaikan pengujian asap, barulah kita memulai pengujian fungsional.

• Semua kendala utama dalam pembangunan akan diidentifikasi dengan melakukan pengujian fungsionalitas dasar (smoke testing).
• Dengan bantuan pengujian asap, sebagian besar kerusakan dapat diidentifikasi pada tahap awal. pengembangan perangkat lunak.
• Dengan pengujian asap, kami menyederhanakan deteksi dan koreksi cacat besar.
• Dengan pengujian asap, tim QA dapat menemukan cacat pada fungsi aplikasi yang mungkin muncul karena kode baru.
• Pengujian asap menemukan cacat yang paling parah.

Contoh 1: Jendela logging: Dapat berpindah ke jendela berikutnya dengan nama pengguna dan kata sandi yang valid dengan mengklik tombol kirim.

Contoh 2: Pengguna tidak dapat keluar dari halaman web.

Kapan kita melakukan Smoke Testing?

Manfaat tersebut hanya akan terwujud jika pemeriksaan dipicu pada saat yang tepat. Smoke Testing dilakukan setiap kali fungsionalitas baru perangkat lunak dikembangkan dan diintegrasikan dengan build yang sudah ada yang diimplementasikan di lingkungan QA/staging. Ini memastikan bahwa semua fungsionalitas penting berfungsi dengan benar atau tidak. Diagram di bawah ini menunjukkan bagaimana sebuah build mencapai lingkungan QA sebelum smoke testing dimulai.

Dalam metode pengujian ini, tim pengembangan menerapkan build di lingkungan QA. Sebagian kecil kasus uji diambil dan dijalankan oleh penguji terhadap fungsionalitas kritis dari build tersebut. Serangkaian kasus uji ini dirancang untuk mengungkap kesalahan yang ada dalam build. Jika pengujian ini berhasil, tim QA melanjutkan ke tahap selanjutnya. Pengujian Fungsional.

Kegagalan apa pun menunjukkan perlunya menangani sistem kembali ke tim pengembangan. Setiap kali ada perubahan pada build, kami melakukan Pengujian Asap untuk memastikan stabilitasnya.

Example: -Tombol registrasi baru ditambahkan di jendela login dan build diterapkan dengan kode baru. Kami melakukan pengujian asap pada build baru.

Pengujian fungsionalitas dasar (smoke test) bertujuan untuk mengklasifikasikan build agar memenuhi syarat untuk pengujian formal lebih lanjut dan dirancang untuk menunjukkan stabilitas sistem dan kesesuaian dengan persyaratan. Tujuan utamanya adalah untuk mendeteksi masalah besar sejak dini. Sebuah build mencakup semua file data, pustaka, modul yang dapat digunakan kembali, dan komponen rekayasa yang diperlukan untuk mengimplementasikan satu atau lebih fungsi produk.

Apa yang terjadi jika kita tidak melakukan Smoke Testing?

Jika kita tidak melakukan pengujian asap (smoke testing) pada tahap awal, cacat mungkin akan ditemukan pada tahap selanjutnya dan dapat menimbulkan biaya yang mahal. A Cacat Kesalahan yang ditemukan pada tahap selanjutnya dapat menjadi penghambat yang memengaruhi perilisan hasil pekerjaan.

Siapa yang akan melakukan Smoke Testing?

Setelah merilis build ke lingkungan QA, Pengujian Asap dilakukan oleh teknisi QA/pimpinan QA. Setiap kali ada versi baru, tim QA menentukan fungsi utama dalam aplikasi untuk melakukan pengujian asap. Tim QA memeriksa penghenti pertunjukan di aplikasi yang sedang diuji.

Bagaimana cara melakukan Smoke Testing?

Pengujian Asap biasanya dilakukan secara manual meskipun ada kemungkinan untuk mencapai hal yang sama melalui otomatisasi. Ini mungkin berbeda dari satu organisasi ke organisasi lainnya.

Pengujian Asap Manual

Pengujian asap (smoke testing) dilakukan untuk memastikan navigasi jalur kritis sesuai harapan dan tidak menghambat fungsionalitas. Kasus uji fungsionalitas prioritas tinggi diambil dan diuji untuk menemukan cacat kritis dalam sistem. Jika pengujian berhasil, kami melanjutkan pengujian fungsional. Jika pengujian gagal, build ditolak dan dikembalikan ke tim pengembangan untuk diperbaiki.

Tim QA kembali memulai smoke testing dengan versi build baru. Smoke testing dilakukan pada build baru dan akan diintegrasikan dengan build lama untuk menjaga kebenaran sistem. Sebelum melakukan smoke testing, tim QA harus memeriksa versi build yang benar.

Pengujian Fungsional (Smoke Testing) dengan Otomatisasi

Pengujian Otomatisasi digunakan untuk Pengujian RegresiNamun, kita juga dapat menggunakan serangkaian kasus uji otomatis untuk dijalankan terhadap Smoke Test. Dengan bantuan pengujian otomatis, pengembang dapat memeriksa build secara langsung, setiap kali ada build baru yang siap untuk diimplementasikan.

Alih-alih melakukan pengujian berulang secara manual setiap kali perangkat lunak baru diterapkan, kasus uji coba asap yang terekam dijalankan terhadap perangkat lunak tersebut. Hal ini memverifikasi apakah fungsi utama masih beroperasi dengan baik. Jika pengujian gagal, maka mereka dapat memperbaiki perangkat lunak tersebut dan menerapkan ulang perangkat lunak tersebut dengan segera. Dengan ini, kami dapat menghemat waktu dan memastikan perangkat lunak berkualitas untuk lingkungan QA.

Dengan menggunakan alat otomatis, teknisi pengujian mencatat semua langkah manual yang dilakukan dalam pembuatan perangkat lunak.

Siklus Pengujian Asap

Diagram alur di bawah ini menunjukkan bagaimana Smoke Testing dijalankan. Setelah build di-deploy di QA dan smoke test berhasil, kita melanjutkan ke pengujian fungsional. Jika smoke test gagal, kita menghentikan pengujian hingga masalah pada build tersebut diperbaiki.

Praktik Terbaik untuk Mendesain Kasus Uji Coba Awal (Smoke Test)

Mengetahui siklus adalah satu hal; terusping Rangkaian perangkat lunak yang membuatnya dapat diandalkan adalah hal lain. Rangkaian perangkat lunak yang baik hanya layak mendapat tempat jika tetap ringkas, cepat, dan dapat diulang.

• Pertama-tama, petakan jalur-jalur kritisnya: Cantumkan alur kerja yang membuat produk dapat digunakan secara komersial, seperti login, pencarian, entri data, pembayaran, dan logout. Jika salah satu alur kerja tersebut rusak, maka build tersebut tidak memiliki nilai bagi penguji.
• Jaga agar suite tetap dangkal tetapi lebar: Sentuh setiap modul utama sekali saja, alih-alih mengeksplorasi satu modul secara mendalam. Nilai batas, data negatif, dan rumusan pesan kesalahan termasuk dalam pengujian fungsional, bukan di sini.
• Batasi waktu eksekusi: Sebagian besar tim menahan laju permainan antara sepuluh hingga lima belas menit dan membatasi ruang lingkup permainan sekitar dua puluh hingga tiga puluh menit. kasus ujiPerjalanan yang memakan waktu satu jam berhenti menjadi gerbang dan malah menjadi hambatan.
• Jalankan kasus yang sama pada setiap build: Konsistensi memungkinkan Anda untuk mengaitkan kegagalan dengan kode, bukan dengan perubahan pemilihan pengujian.
• Singkirkan kasus yang tidak stabil dan memiliki banyak ketergantungan: Kasus yang lolos dan gagal tanpa perubahan kode apa pun akan menghancurkan kepercayaan pada gerbang tersebut. Gunakan stub atau mock untuk layanan pihak ketiga yang tidak stabil di mana kerangka kerja otomatisasi pengujian memungkinkan.
• Catat satu putusan yang tegas: Setiap kasus memerlukan satu hasil yang diharapkan sehingga pembangunan dapat diterima atau ditolak tanpa perdebatan.
• Berikan versi pada paket perangkat lunak beserta versi build-nya: Simpan kasus uji coba (smoke case) di repositori yang sama dengan kode aplikasi agar gerbang (gate) selalu sesuai dengan rilis yang sedang diuji.

RevTinjau kembali rangkaian fitur di setiap rilis: hapus kasus untuk fitur yang tidak lagi penting dan tambahkan alur kerja baru yang penting.

Pengujian Fungsional (Smoke Testing) dalam Pipeline CI/CD

Rangkaian perangkat lunak yang dirancang seperti ini cukup murah untuk dijalankan pada setiap commit, yang merupakan tuntutan dari sistem pengiriman data modern. integrasi berkelanjutan server seperti Jenkins Proses ini mengkompilasi kode, menyebarkannya ke lingkungan staging, dan kemudian memicu rangkaian pengujian fungsional (smoke test) sebagai tahap otomatis pertama. Jika berhasil (berwarna hijau), artefak akan dipromosikan ke tahap fungsional dan regresi, sementara jika gagal (berwarna merah), pipeline akan gagal dan pengembang yang melakukan commit akan diberi tahu dalam hitungan menit.

Ada dua tahapan yang umum dilakukan. Tahapan pra-penggabungan (pre-merge) berfungsi untuk menjaga cabang utama dengan memvalidasi setiap permintaan penarikan (pull request), dan tahapan pasca-penyebaran (post-deployment) memastikan bahwa lingkungan yang diterapkan dapat dijangkau dan dikonfigurasi dengan benar. Tim yang menerapkan penyebaran berkelanjutan (continuous deployment) sering menambahkan tahapan ketiga yang lebih ringkas terhadap lingkungan produksi segera setelah rilis.

Karena pipeline mengeksekusi rangkaian pengujian berkali-kali dalam sehari, kasus-kasus tersebut harus non-interaktif, membersihkan diri sendiri, dan independen. Kasus apa pun yang menunggu keputusan manusia atau meninggalkan data pengujian akan memperlambat pipeline.

Keunggulan Pengujian Asap (Smoke Testing)

Berikut adalah beberapa keuntungan yang tercantum untuk Pengujian Asap.

• Mudah dilakukan dan berjalan dengan cepat.
• Kesalahan dan cacat kritis mudah dideteksi dan diperbaiki pada tahap awal.
• Meningkatkan kualitas sistem
• Mengurangi risiko
• Kemajuan lebih mudah dinilai.
• Menghemat upaya dan waktu pengujian
• Meminimalkan risiko integrasi

⚠ Batasan yang perlu diperhatikan: Pengujian asap (smoke test) yang berhasil hanya menunjukkan bahwa build tersebut dapat diuji. Pengujian ini hanya menyentuh fungsionalitas utama secara dangkal, sehingga cacat kecil, kasus khusus, dan fitur yang jarang digunakan tetap tersembunyi hingga pengujian fungsional dan regresi dijalankan. Jangan pernah menganggap hasil pengujian asap hijau sebagai tanda bahwa build tersebut bebas dari cacat.

Pengujian Asap vs Pengujian Kewarasan vs Pengujian Regresi

Ketiganya dijalankan setelah perubahan kode, itulah sebabnya seringkali terjadi kebingungan. Ketiganya berbeda dalam cakupan, kedalaman, dan pertanyaan yang dijawab oleh masing-masing.

Pengujian yang dilakukan di lingkungan pengembangan pada kode untuk memastikan kebenaran aplikasi sebelum merilis build ke QA, ini dikenal sebagai pengujian Sanity. Ini adalah proses yang memverifikasi bahwa aplikasi yang sedang dikembangkan memenuhi persyaratan fungsional dasarnya.

Pengujian kewarasan menentukan selesainya tahap pengembangan dan mengambil keputusan lulus atau tidaknya produk perangkat lunak untuk tahap pengujian selanjutnya.

DASAR	PENGUJIAN ASAP	PENGUJIAN KEWARASAN	PENGUJIAN REGRESI
Cakupan	Lebar dan dangkal	Sempit dan dalam	Lebar dan dalam
Pertanyaan terjawab	Apakah versi ini cukup stabil untuk diuji?	Apakah perbaikan khusus ini berhasil?	Apakah ada sesuatu yang sebelumnya berfungsi kini rusak?
Urutan	Pertama, pada setiap pembangunan	Setelah pengujian asap berhasil	Setelah pengujian kewarasan
Durasi tipikal	10 hingga 15 menit	30 hingga 60 menit	Hours hingga hari
Otomatisasi yang sesuai	Sangat tinggi	Sedang, seringkali manual	Sangat tinggi

Dalam praktiknya, pengujian ini berjalan secara berurutan: pengujian fungsional (smoke testing) untuk menerima hasil build, pengujian validasi (sanity testing) untuk memverifikasi perubahan yang diberikan, dan pengujian regresi (regression testing) ketika jadwal memungkinkan.

Contoh Kasus Uji Asap Contoh

Tabel di bawah ini mendokumentasikan rangkaian simulasi asap singkat, satu baris per jalur kritis.

T.ID	SKENARIO UJI	DESKRIPSI	LANGKAH UJI	HASIL YANG DIHARAPKAN	HASIL SEBENARNYA	STATUS
1	Kredensial masuk yang valid	Uji fungsionalitas login aplikasi web untuk memastikan bahwa pengguna terdaftar diperbolehkan login dengan nama pengguna dan kata sandi	1.Luncurkan aplikasi 2.Navigasi halaman login 3.Masukkan nama pengguna yang valid 4.Masukkan kata sandi yang valid 5.Klik tombol masuk	Login seharusnya berhasil	seperti yang diharapkan	Lulus
2	Menambahkan fungsionalitas item	Dapat menambahkan item ke keranjang	1.Pilih daftar kategori 2.Tambahkan item ke keranjang	Item harus ditambahkan ke troli	Item tidak ditambahkan ke keranjang	Gagal
3	Fungsionalitas keluar	Periksa fungsionalitas keluar	1. pilih tombol keluar	Pengguna harus dapat keluar.	Pengguna tidak dapat keluar	Gagal

Pertanyaan Umum Demo Slot