Saat bug mencapai produksi, penyebabnya sering kali bukan karena seseorang lupa menjalankan pengujian. Persyaratannya tidak pernah dipertanyakan, data pengujian salah atau tidak ada yang setuju dengan apa yang dimaksud dengan “selesai”. siklus hidup pengujian perangkat lunak mengatasi masalah tersebut dengan memberikan struktur pengujian yang jelas mulai dari persyaratan pertama hingga laporan akhir.

Panduan ini menjelaskan setiap fase, lalu mengikuti satu fitur ilustrasi melalui semuanya: halaman login yang mengunci akun setelah lima kali gagal. Sumber tidak sepenuhnya setuju mengenai jumlah fase. Anda akan melihat model dengan tujuh atau delapan, tetapi sebagian besar membagi pekerjaan yang sama secara berbeda. Kami menggunakan versi enam fase yang diajarkan secara luas.

Apa itu STLC?

STLC adalah serangkaian aktivitas pengujian yang dilakukan untuk memastikan bahwa perangkat lunak memenuhi persyaratannya. Tiap tahap mempunyai tujuan, masukan dan keluaran, sehingga pengujian direncanakan dan dapat ditelusuri, bukan hanya sekedar improvisasi di akhir.

Manfaatnya praktis. Penguji terlibat sejak dini, ketika kerusakan lebih murah untuk diperbaiki. Upaya menuju pada risiko tertinggi. Dan ketika seorang manajer bertanya “apakah kami siap untuk merilis?”, tim dapat menjawab dengan bukti.

Sekilas tentang enam fase STLC

Kriteria masuk adalah kondisi yang harus dipenuhi sebelum suatu fase dimulai. Kriteria keluar adalah kondisi yang harus dipenuhi sebelum berakhir. Mereka menghentikan tim, misalnya, menjalankan pengujian pada bangunan yang rusak dan membuang-buang waktu seharian.

Fase 1: Analisis kebutuhan

Penguji mempelajari persyaratan untuk mengetahui apa yang dapat diuji dan apa yang tidak jelas. Ini sering kali merupakan tempat termurah untuk mencegah bug, karena biaya pertanyaan jauh lebih murah dibandingkan perbaikan produksi.

• Entri: dokumen persyaratan atau cerita pengguna tersedia.
• Aktivitas: mengidentifikasi kebutuhan fungsional dan non-fungsional, mengajukan pertanyaan, menilai risiko, dan memutuskan apa yang dapat diotomatisasi.
• Keluar: pertanyaan terbuka terjawab dan matriks ketertelusuran persyaratan (RTM) dimulai.
• Hasil Kerja: daftar persyaratan yang dapat diuji, dan RTM.

Contoh login. Ceritanya mengatakan “kunci akun setelah lima kali gagal”. Seorang penguji yang baik bertanya: lima dalam periode berapa? Bagaimana cara membuka kuncinya? Apakah login yang berhasil akan mengatur ulang hitungannya? Pesan apa yang ditampilkan? Setiap jawaban menjadi sesuatu yang dapat diuji.

Fase 2: Perencanaan tes

Tim memutuskan ruang lingkup, pendekatan, orang, alat, jadwal dan risiko. Pemimpin tes biasanya memiliki fase ini.

• Entri: menganalisis persyaratan dan penilaian risiko awal.
• Aktivitas: menentukan ruang lingkup, memperkirakan upaya, memilih alat, menetapkan peran, dan menetapkan kriteria keluar untuk fase selanjutnya.
• Keluar: rencana pengujian ditinjau dan disetujui.
• Hasil: rencana pengujian dan perkiraan upaya.

Contoh login. Dalam cakupan: aturan penguncian, reset, dan pesan kesalahan di web dan seluler. Di luar cakupan: sistem masuk tunggal, ditangani oleh tim lain. Risiko terbesarnya adalah mengunci pengguna asli, sehingga hal ini mendapat perhatian paling besar. Jika Anda tidak yakin apa perbedaan antara rencana dan strategi, baca rencana pengujian vs strategi pengujian.

Fase 3: Pengembangan kasus uji

Di sinilah penguji menulis kasus pengujian terperinci, skrip otomatisasi, dan data pengujian.

• Entri: rencana pengujian yang disetujui dan persyaratan stabil.
• Aktivitas: menulis dan meninjau kasus uji, menyiapkan data, membuat skrip pemeriksaan otomatis, dan memperbarui RTM.
• Keluar: kasus uji dan data ditinjau dan siap.
• Hasil: kasus uji, skrip, dan data pengujian.

Perhatikan bahwa TC-01 dan TC-02 menguji kedua sisi batas, yang berasal dari analisis nilai batas. Untuk mengetahui lebih lanjut tentang cara menulis kasus uji dengan baik, lihat cara menulis kasus uji.

Fase 4: Uji pengaturan lingkungan

Pengujian memerlukan tempat yang realistis untuk dijalankan: server, data, akun, browser, dan akses jaringan yang tepat. Fase ini sering kali berjalan paralel dengan fase 3, dan mungkin ditangani oleh pengembang atau tim DevOps.

• Entri: rencana pengujian, ikhtisar arsitektur, dan persyaratan lingkungan.
• Aktivitas: menyiapkan perangkat keras atau container, memuat data, mengonfigurasi akses, dan menginstal build.
• Keluar: lingkungan sudah siap dan uji asap berhasil dilakukan.
• Hasil: lingkungan kerja dan hasil tes asap.

Contoh login. Staging mendapatkan akun pengujian dalam status yang diketahui, bersama dengan pengatur waktu penguncian yang dipersingkat sehingga penguji tidak perlu menunggu. Tes asap cepat mengonfirmasi bahwa login dimuat sebelum proses penuh dimulai. Kontainer membantu menjaga konsistensi lingkungan, seperti yang ditunjukkan dalam tutorial Docker Compose kami.

Fase 5: Eksekusi uji

Penguji menjalankan pengujian yang direncanakan, membandingkan hasil aktual dan yang diharapkan, serta melaporkan kerusakan. Bug yang diperbaiki diuji ulang, dan area terkait menerima pengujian regresi.

• Entri: kasus uji sudah siap, lingkungan berfungsi dan build telah dikirimkan.
• Aktivitas: menjalankan pengujian, mencatat hasil, mencatat kerusakan, menguji ulang perbaikan, dan memperbarui RTM.
• Keluar: pengujian yang direncanakan dijalankan, dan cacat diperbaiki atau diterima secara resmi.
• Hasil Kerja: hasil pengujian dan laporan kerusakan.

Contoh login. TC-04 gagal: dengan dua browser, penghitung hanya mencapai empat. Penguji mencatat bug dengan langkah dan bukti yang jelas, seperti yang dijelaskan dalam cara menulis laporan bug. Setelah diperbaiki, TC-04 dijalankan kembali, dan pemeriksaan login terkait dilakukan melalui daftar periksa regresi.

Fase 6: Penutupan tes

Fase ini biasanya dilewati, dan ini sangat disayangkan, karena inilah cara tim berkembang. Tim mengevaluasi siklus tersebut, mengarsipkan pekerjaannya dan mencatat apa yang dipelajari.

• Entri: eksekusi selesai dan status cacat diketahui.
• Aktivitas: memeriksa kriteria keluar, menganalisis tren kerusakan, mengarsipkan aset pengujian, dan mengadakan retrospektif.
• Keluar: laporan penutupan ditandatangani.
• Hasil: laporan penutupan dan pembelajaran.

Contoh login. Laporan menunjukkan bahwa kelima kasus berhasil diselesaikan setelah satu perbaikan. Pelajarannya adalah konkurensi baru diuji terlambat, jadi fitur-fitur masa depan dengan penghitung akan menambahkan skenario tersebut selama desain.

STLC vs SDLC

SDLC, atau siklus hidup pengembangan perangkat lunak, mencakup pembuatan keseluruhan produk. STLC adalah bagian yang berfokus pada pengujian, dan berjalan di sampingnya.

Analisis persyaratan dalam SDLC memasukkan analisis persyaratan dalam STLC, dan pengembangan memberikan build ke dalam eksekusi pengujian. Pengujian tidak harus menunggu hingga pengkodean berakhir. Memulai lebih awal itulah yang orang maksud dengan “bergeser ke kiri”.

STLC di Agile dan DevOps

Fase-fase tersebut mungkin terdengar seperti proses yang panjang dan satu arah, namun sebenarnya tidak harus demikian. Di Agile, aktivitas yang sama menyusut dan berulang dalam setiap sprint, seringkali dalam hitungan jam, bukan minggu:

• Analisis persyaratan terjadi dalam penyempurnaan backlog, melalui pertanyaan pada kisah pengguna.
• Perencanaan terjadi dalam perencanaan sprint, dengan catatan ringan menggantikan dokumen yang panjang.
• Desain pengujian terjadi bersamaan dengan pengkodean, sering kali sebagai kriteria penerimaan dan pengujian otomatis.
• Penyiapan lingkungan diotomatisasi melalui container dan infrastruktur sebagai kode.
• Eksekusi berjalan terus-menerus dalam pipeline CI/CD.
• Penutupan menjadi bagian dari tinjauan sprint dan retrospektif.

Simpan apa yang berguna dan skalakan dokumen sesuai risikonya. Perangkat internal yang kecil mungkin memerlukan daftar periksa yang singkat, sementara sistem perbankan mungkin memerlukan persetujuan formal karena alasan peraturan.

Kesalahan umum

• Membawa penguji terlambat. Bug yang ditemukan dalam persyaratan jauh lebih murah dibandingkan bug yang ditemukan setelah rilis.
• Kriteria keluar yang tidak jelas. Tanpa kriteria tersebut, tenggat waktu akan menentukan keputusan Anda.
• Pengujian di lingkungan yang buruk. Kegagalan yang disebabkan oleh data atau konfigurasi yang buruk membuang-buang waktu dan mengikis kepercayaan.
• Melewati penutupan. Tim kemudian mengulangi kesalahan yang sama pada siklus berikutnya.
• Mengikutinya terlalu kaku. STLC adalah panduannya. Dokumen yang berat tidak serta merta berarti kualitasnya lebih baik.

Penutup

Siklus hidup pengujian perangkat lunak hanyalah jawaban disiplin atas enam pertanyaan: apa yang kita uji, bagaimana, dengan kasus apa, di mana, apa yang terjadi, dan apa yang kita pelajari? Lihat fitur Anda berikutnya dan periksa pertanyaan mana yang biasanya dilewati tim Anda. Memperbaiki satu kesenjangan kemungkinan besar akan memberi Anda keuntungan terbesar.

Pertanyaan yang sering diajukan

Teruslah belajar