STLC – Pengujian dan Tahapan Siklus Hidup Perangkat Lunak

STLC – Pengujian dan Tahapan Siklus Hidup Perangkat Lunak

Apa itu Software Testing Life Cycle (STLC)?

Software Testing Life Cycle (STLC) adalah serangkaian aktifitas spesifik yang dilakukan selama proses pengujian untuk memastikan sasaran kualitas perangkat lunak terpenuhi. STLC melibatkan kegiatan virifikasi dan validasi. Pengujian perangkat lunak bukanlah aktivitas tunggal. Pengujian terdiri dari serangkaian kegiatan yang dilakukan secara metodologis untuk membantu menjamin produk perangkat lunak anda.

Diagaram STLC

Berikut adalah fase-fase STLC:

·         Analisis Kebutuhan

·         Perencanaan Pengujian

·         Pengembangan Test Case (Uji Kasus)

·         Pengaturan Linkungan Pengujian

·         Eksekusi Pengujian

·         Penutupan Siklus Pengujian

Masing-masing tahap ini memiliki kriteria masuk dan keluar yang pasti, aktivitas dan hasil kerja yang terkait dengannya.

Apa itu Kriteria Masuk dan Keluar

·         Kriteria Masuk: kriteria masuk memberikan iterm prasyarat yang harus dilakukan sebelum pengujian dimulai.

·         Kriteria Keluar: kriteria keluar menentukan item yang harus diselesaikan sebelum pengujian dapat disimpulkan

Anda memiliki kriteria masuk dan keluar untuk semua tingkatan dalam siklus hidup pengujian perangkat lunak (STLC).

Secara ideal, Anda tidak akan memasuki tahap berikutnya sampai kriteria keluar untuk tahap sebelumnya terpenuhi. Tetapi pada praktiknya ini tidak selalu memungkinkan. Jadi pada pembahasan ini kita fokus pada kegiatan dan hasil untuk setiap tahap dalam siklus hidup STLC.

Analisis Kebutuhan/Persyaratan (Requrement Analisis)

Selama fase ini, tim uji mempelajari persyaratan dari sudut pandang pengujian untuk mengidentifikasi persyaratan yang dapat diuji.

Tim QA dapat berinteraksi dengan beberapa pemangku kepentingan (Klien, Analis Bisnis, Pimpinan Teknis, Arsitek sistem dll). Untuk memahami persyaratan secara rinci.

Persyaratan dapat berupa fungsional (menentukan apa yang harus dilakukan perangkat lunak) atau non fungsional (mendefinisikan kinerja sistem / ketersediaan keamanan).

Automation Feasibylity (kelayakan otomatis) untuk projek pengujian yang diberikan juga dilakukan pada tahap ini.

Aktivities (Kegiatan)

·         Identifikasi jenis tes yang akan dilakukan. 

·         Kumpulkan detail tentang prioritas dan fokus pengujian.

·         Mempersiapkan Requirements Traceability Matrix (RTM) .

·         Identifikasi detail lingkungan pengujian dimana pengujian seharusnya dilakukan. 

·         Analisis kelayakan otomasi (jika diperlukan).

Deliverables (hasil)

·         RTM

·         Laporan kelayakan otomasi. (jika ada)

Perencanaan Tes (Test Planning)

Biasanya, pada tahap ini, seorang manajer QA Senior akan menentukan perkiraan upaya dan biaya untuk proyek dan akan menyiapkan dan menyelesaikan Rencana Tes. Dalam fase ini, Strategi Tes juga ditentukan.

Aktivities (Kegiatan)

·         Persiapan rencana uji / dokumen strategi untuk berbagai jenis pengujian

·         Pemilihan alat uji

·         Perkiraan upaya pengujian

·         Perencanaan sumber daya dan menentukan peran dan tanggung jawab.

·         Persyaratan pelatihan

Deliverables (hasil)

·         Rencana uji / dokumen strategi.

·         Dokumen estimasi upaya .

Pengembangan Uji Kasus (Test Case Development)

Fase ini melibatkan pembuatan, verifikasi, dan pengerjaan ulang kasus uji & skrip pengujian. Data uji , diidentifikasi / dibuat dan ditinjau dan kemudian dikerjakan ulang juga.

Aktivities (Kegiatan)

·         Buat kotak uji, skrip otomatisasi (jika ada)

·         Review dan uji kasus dasar dan skrip awal

·         Buat data uji (Jika Lingkungan Uji tersedia)

Deliverables (hasil)

·         Uji kasus / skrip

·         Uji data

Pengaturan Lingkungan Tes (Test Environtment Setup)

Lingkungan pengujian menentukan kondisi perangkat lunak dan perangkat keras tempat produk kerja diuji. Pengaturan lingkungan pengujian adalah salah satu aspek penting dari proses pengujian dan dapat dilakukan secara paralel dengan Tahap Pengembangan Kasus Uji . Tim uji mungkin tidak terlibat dalam aktivitas ini jika pelanggan / tim pengembangan menyediakan lingkungan pengujian dalam hal ini tim uji diminta untuk melakukan pemeriksaan kesiapan (Smoke Testing) dari lingkungan yang diberikan.

Aktivities (Kegiatan)

·         Memahami arsitektur yang diperlukan, pengaturan lingkungan, dan menyiapkan daftar persyaratan perangkat keras dan perangkat lunak untuk Lingkungan Pengujian.

·         Tes pengaturan Lingkungan dan data uji

·         Lakukan tes asap di gedung

Deliverables (hasil)

·         Lingkungan siap dengan pengaturan data uji

·         Hasil Uji Asap (Smoke Testing).

Eksekusi Tes (Test Excecution)

Selama fase ini, penguji akan melakukan pengujian berdasarkan rencana pengujian dan kasus uji yang disiapkan. Bug akan dilaporkan kembali ke tim pengembangan untuk koreksi dan pengujian ulang akan dilakukan.

Aktivities (Kegiatan)

·         Jalankan tes sesuai rencana

·         Dokumentasikan hasil tes, dan log cacat untuk kasus yang gagal

·         Map Defects untuk menguji kasus dalam RTM

·         Coba ulang perbaikan Cacat

·         Lacak cacat yang akan ditutup

Deliverables (hasil)

·         RTM lengkap dengan status eksekusi

·         Kasus uji diperbarui dengan hasil

·         Laporan cacat

Penutupan Siklus Tes

Tim pengujian akan bertemu, membahas dan menganalisis hasil pengujian untuk mengidentifikasi strategi yang harus diterapkan di masa depan, mengambil pelajaran dari siklus pengujian saat ini. Idenya adalah untuk menghilangkan hambatan proses untuk siklus pengujian di masa depan dan berbagi best practice (praktik terbaik) untuk proyek serupa di masa depan.

Aktivities (Kegiatan)

·         Mengevaluasi kriteria penyelesaian siklus berdasarkan Waktu, Cakupan Tes, Biaya, Perangkat Lunak, Tujuan Bisnis Kritis, Kualitas

·         Siapkan metrik pengujian berdasarkan parameter di atas.

·         Dokumentasikan pembelajaran dari proyek

·         Mempersiapkan laporan penutupan Tes

·         Pelaporan kualitatif dan kuantitatif kualitas produk kerja kepada pelanggan.

·         Uji hasil analisis untuk mengetahui distribusi cacat berdasarkan jenis dan tingkat keparahan.

Deliverables (hasil)

·         Laporan Uji Penutupan

·         Metrik uji

Fase STLC bersama dengan Kriteria Masuk dan Keluar

Tahap STLC	Kriteria Entri/Masukan	Aktivitas/Kegiatan	Kriteria Keluar	Kiriman/Hasil
Analisis Kebutuhan	– Dokumen Persyaratan tersedia (baik fungsional maupun non fungsional) – Kriteria penerimaan didefinisikan. – Dokumen arsitektur aplikasi tersedia.	– Menganalisis fungsionalitas bisnis untuk mengetahui modul bisnis dan fungsi spesifik modul. – Identifikasi semua transaksi dalam modul. – Identifikasi semua profil pengguna. – Kumpulkan antarmuka / otentikasi pengguna, persyaratan penyebaran geografis. – Identifikasi jenis tes yang akan dilakukan. – Kumpulkan detail tentang prioritas dan fokus pengujian. – Mempersiapkan Requirements Traceability Matrix (RTM). – Identifikasi detail lingkungan pengujian tempat pengujian seharusnya dilakukan. – Analisis kelayakan otomasi (jika diperlukan).	– Menandatangani RTM – Laporan kelayakan otomatisasi uji ditandatangani oleh klien	– RTM – Laporan kelayakan otomatisasi (jika ada)
Perencanaan Tes	– Dokumen Persyaratan – Matriks Ketertelusuran Persyaratan. – Dokument Uji kelayakan otomasi.	– Menganalisis berbagai pendekatan pengujian yang tersedia. – Finalisasi pada pendekatan yang paling cocok. – Persiapan rencana uji / dokumen strategi untuk berbagai jenis pengujian. – Pemilihan alat uji. – Perkiraan upaya pengujian. – Perencanaan sumber daya dan menentukan peran dan tanggung jawab.	– Dokumen rencana uji / strategi yang disetujui. – Dokumen estimasi upaya ditandatangani.	– Rencana uji / dokumen strategi. – Dokumen estimasi upaya.
Pengembangan uji kasus	– Dokumen Persyaratan – RTM dan rencana uji – Laporan analisis otomasi	-Buat kotak uji, desain uji, skrip otomatisasi (jika ada) – Review dan uji kasus dasar dan skrip awal – Buat data uji	Ditinjau dan ditandatangani Kasuns / skrip uji – Meninjau dan menandatangani data uji	– Uji kasus / skrip – Uji data
Pengaturan Lingkungan Uji	– Desain Sistem dan dokumen arsitektur tersedia – Rencana pengaturan lingkungan tersedia	– Memahami arsitektur yang diperlukan, pengaturan lingkungan – Menyiapkan daftar persyaratan pengembangan perangkat keras dan perangkat lunak – Finalisasi persyaratan konektivitas – Siapkan daftar periksa pengaturan lingkungan – Tes pengaturan Lingkungan dan data uji – Lakukan tes asap pada saat build. – Terima / tolak build tergantung pada hasil tes asap	– Pengaturan lingkungan berfungsi sesuai rencana dan daftar periksa – Pengaturan data uji selesai – Tes asap berhasil	– Lingkungan siap dengan pengaturan data uji – Hasil Uji Asap.
Eksekusi Tes	– RTM Baselined, Rencana Tes, Test case / script tersedia – Lingkungan uji siap – Pengaturan data uji telah dilakukan – Laporan uji Unit / Integrasi untuk di build yang akan diuji tersedia	– Jalankan tes sesuai rencana – Dokumentasikan hasil tes, dan log cacat untuk kasus yang gagal – Perbarui rencana pengujian / uji kasus, jika perlu – Mapping Error untuk menguji kasus dalam RTM – Tes ulang perbaikan cacat – Pengujian Regresi aplikasi – Lacak cacat yang akan ditutup	– Semua tes yang direncanakan dijalankan – Cacat dicatat dan dilacak hingga ditutup	– RTM lengkap dengan status eksekusi – Kasus uji diperbarui dengan hasil – Laporan cacat
Penutupan siklus uji	– Pengujian telah selesai – Hasil tes tersedia – Log yang cacat tersedia	– Mengevaluasi kriteria penyelesaian siklus berdasarkan – Waktu, Cakupan pengujian , Biaya, Kualitas Perangkat Lunak, Tujuan Bisnis Kritis – Siapkan metrik pengujian berdasarkan parameter di atas. – Dokumentasikan pembelajaran dari proyek – Mempersiapkan laporan penutupan Tes – Pelaporan kualitatif dan kuantitatif kualitas produk kerja kepada pelanggan. – Uji hasil analisis untuk mengetahui distribusi cacat berdasarkan jenis dan tingkat keparahan	Laporan Uji Penutupan ditandatangani oleh	– Laporan Uji Penutupan – Metrik uji

V-Model dalam Pengujian Perangkat Lunak

V-Model dalam Pengujian Perangkat Lunak

Apa itu V-Model?

Adalah model SDLC yang memiliki fase pengujian yang sesuai dengan setiap tahap pengembangan dalam model waterfall. V-Model adalah perpanjangan dari model waterfall. Pengujian V-Model dilakukan bersamaan dengan pengembangan perangkat lunak. Ini sama saja dengan proses Verifikasi dan Validasi.

Ketentuan Utama Rekayasa Perangkat Lunak

SDLC: SDLC adalah siklus hidup pengembangan perangkat lunak. Ini adalah urutan kegiatan yang dilakukan oleh pengembang untuk mendesain dan mengembangkan perangkat lunak berkualitas tinggi.

STLC: STLC adalah siklus hidup pengujian perangkat lunak. Ini terdiri dari serangkaian aktivitas yang dilakukan oleh penguji secara metodologis untuk menguji produk perangkat lunak anda.

Model Waterfall: Model waterfall adalah model yang dibagi menjadi beberapa fase kegiatan pengembangan perangkat lunak. Setiap tahap dirancang untuk melakukan aktivitas tertentu. Fase pengujian dalam model waterfall dimulai hanya setelah implementasi sistem dilakukan.

Contoh untuk memahami V-Model

Misalkan anda diberi sebuah tugas, untuk mengembangkan Custom Software untuk client. Kira-kira apa saja yang akan anda lakukan pertama kali untuk mengerjakan tugas tersebut.

Terlihat urutannya kurang tepat. Urutan yang benar adalah:

Fase-fase Siklus Hidup Perangkat Lunak	Aktivitas yang dilakukan setiap Tahap
Tahap mengumpulkan kebutuhan	mengumpulkan sebanyak mungkin informasi tentang detail dan spesifikasi perangkat lunak yang diinginkan oleh client. Ini tidak lain adalah tahap pengumpulan kebutuhan.
Tahap Desain	Merencanakan bahasa pemrograman seperti Java, PHP, .net; Database seperti oracle, MySQL, dan sebagainya, yang cocok untuk projek ini. Juga beberapa fungsi dan arsitektur tingkat tinggi.
Tahap pembangunan	Setelah tahap desain, adalah tahap pembangunan. Ini tidak lain pengkodean program yang sebenarnya.
Tahap Pengujian	Berikutnya, anda menguji perangkat lunak untuk memverifikasi bahwa perangkat lunak yang dibangun sesuai dengan yang diinginkan oleh client.
Tahap Penyebaran	Penyebaran aplikasi sesuai dengan lingkungannya masing-masing.
Tahap Maintenan	Setelah sistem anda siap digunakan, anda mungkin perlu memperbaiki kembali code sesuai keingingan client.

Semua level ini merupakan metode waterfall dari siklus hidup pengembangan perangkat lunak.

Permasalahan dengan Model Waterfall

Seperti yang anda amati, bahwa pengujian di dalam model dimulai hanya setelah implementasi dilakukan.

Tetapi apabila anda bekerja di dalam projek yang besar, dimana sistemnya komplek, ini mudah kehilangan detail utama yang menjadi persyaratan setiap tahapnya. Dalam kasus seperti itu, produk yang banyak kesalahan di kirimkan ke client. Anda mungkin harus mulai dari awal dengan projek tersebut atau jika anda berhasil mencatat persyaratan dengan benar tetapi membuat kesalahan serius dalam desain dan arsitektur perangkat lunak anda, anda harus mendesain ulang seluruh perangkat lunak untuk memperbaiki kesalahan.

Solusi: V-Model

Untuk mengatasi masalah ini, pengujian V-Model dikembangkan untuk setiap fase, dalam siklus hidup pengembangan ada fase pengujian yang sesuai.

·         Sisi kiri model adalah Software Development Live Cycle – SDLC

·         Sisi kanan model adalah Software Test Live Cycle – STLC

·         Seluruh gambar terlihat seperti huruf V, maka dinamakan V-Model

Terlepas dari V-Model, terlihat model pengembangan berulang, dimana pengembangan dilakukan secara bertahap, dengan setiap fase menambahkan fungsionalitas ke perangkat lunak. Setiap fase terdiri dari serangkaian kegiatan pengembangan dan pengujian yang independen.

Contoh yang baik dari siklus hidup pengembangan yang mengikuti interaktif motode adalah Rapid Application Development, dan Agile Development.

Kesimpulan

Terdapat banyak model siklus hidup pengembangan. Model yang dipilih untuk suatu proyek tergantung pada maksud dan tujuan dari proyek tersebut.

·         Pengujian bukanlah kegiatan yang berdiri sendiri, dan harus menyesuaikan model pengembangan yang dipilih untuk proyek.

·         Dalam model apapun, pengujian harus dilakukan di semua tingkatan yaitu mulai dari requirement (persyaratan) hingga pemeliharaan.