Software Testing Life Cycle

    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 pengujian
  • Aktivitas merupakan kegiatan yang diperlukan untuk melakukan pengujian
  • Deliverable merupakan hasil setelah menyelesaikan pengujian

Fase STLC

    Berbagai jenis pengujian dilakukan untuk mengidentifikasi tidak hanya bug tetapi juga gangguan kecil sehingga klien benar-benar puas dengan kinerja dan kualitas produk. Adapun fase dalam siklus hidup pengujian perangkat lunak, yaitu:

1. Requirement Analysis / Requirement Phase Testing (Requirements software dari stakeholder) dianalisa oleh QA untuk:

  • Mengetahui detail software, modul, fitur dan fungsi yang akan di bangun Review dan melakukan validasi jika masih ada kekurangan dan atau untuk melengkapi kejelasan requirement tersebut
  • Menganalisa apa saja yang dapat diuji secara manual dan automation
  • Menganalisa cakupan fungsi atau fitur mana saja yang akan diuji secara fungsional (Contoh: button login, button delete apakah berfungsi) dan non-fungsional (Contoh: pengujian performa kecepatan).

2. Test Planning STLC

    Pada tahap ini QA mempersiapkan rencana untuk melakukan pengujian berdasarkan requirement analysis. Tahap ini akan ditentukan tools (Contoh: Postman) yang akan digunakan untuk menguji dan hal-hal yang di deliver setelah pengujian, estimasi waktu dan sumber daya, time line, pembagian peran serta tanggung jawab pada tim QA

3. Test Case Development Phase

    Tahap ini berisi hal-hal yang akan menjadi acuan dalam pengujian yang melibatkan untuk membuat test case, membuat test data, membuat script automation test berdasarkan test case

4. Test Environment Setup

    Tahap ini proses yang dilakukan adalah memastikan Environment test dapat berjalan dengan baik dan sesuai harapan. Melakukan smoke test untuk memastikan Environment test apakah sudah benar-benar siap dan modul-modul utama siap dijalankan. Smoke test case adalah kasus uji positif yang dijalankan untuk melihat apakah perangkat lunak memenuhi kriteria penerimaan build. Misalnya, Smoke test untuk aplikasi perbankan online akan memeriksa apakah fungsi masuk aplikasi berfungsi, apakah antarmuka sedang dimuat, apakah setiap opsi yang dapat diklik di beranda berfungsi, dll.

5. Test Execution Phase

    Pengujian dilakukan berdasarkan test plan dan test case yang disepakati. Ada dua cara eksekusi: manual dan otomatis. Dalam pengujian manual, seorang QA secara manual melakukan test case dan mencatat hasilnya. Sedangkan untuk pengujian otomatis, skrip pengujian dikembangkan yang dijalankan secara otomatis di alat pengujian otomatis untuk memeriksa hasil setiap test case. Jika fitur yang berjalan sudah sesuai dengan test requirements, status fitur tersebut adalah pass atau berhasil dan siap masuk tahap deployment. Jika tidak sesuai requirements, maka error yang ditemukan akan dimasukkan ke dalam test report tim QA beerta Bug ID lalu dilaporkan ke tim developer yang memperbaiki bug. Setelah diperbaiki, QA akan menguji ulang untuk memastikan bahwa fungsionalitas bekerja dengan sempurna.

6. Test Closure

    Tahap penutup dari siklus pengujian perangkat lunak. Ketika tahap pelaksanaan pengujian selesai, laporan penutupan disiapkan. Laporan penutupan adalah dokumen yang mengevaluasi seluruh proses dan semua fase pengujian perangkat lunak. Ini mengevaluasi proses berdasarkan tujuan, waktu, biaya, cakupan, dan jumlah cacat dan bug yang diidentifikasi. Akan dilakuakan meeting anggota team untuk mengidentifikasi dan menganalisis rencana yang akan di lakukan dan evaluasi terhadap STLC yang dijalankan saat ini

Requirement Traceability Matrix (RTM)

    Tabel dokumen yang digunakan untuk mengetahui kebutuhan pada pengembangan software pada fase testing. Berguna melakukan verifikasi apakah kebutuhan tersebut sudah terpenuhi atau belum. Berupa daftar-daftar kebutuhan yang dapat memudahkan dalam melakukan testing.

Keuntungan menggunakan RTM:

  1. Menunjukkan defect secara keseluruhan
  2. Meningkatkan proses manajemen ruang lingkup
  3. Membantu kontrol proses dan kualitas manajemen
  4. Memverifikasi bahwa semua persyaratan terpenuhi dan untuk mengidentifikasi perubahan pada ruang lingkup saat terjadi

STLC vs SDLC

    Perbedaan antara SDLC dan STLC sebenarnya sangat sederhana! SDLC menguraikan langkah-langkah proses pengembangan perangkat lunak secara keseluruhan, mulai dari pengumpulan persyaratan hingga penyebaran dan pemeliharaan perangkat lunak. Pengujian adalah langkah dalam SDLC yang dilakukan sebelum penerapan. Hal ini juga sering disebut sebagai Jaminan Kualitas.

STLC, di sisi lain, adalah serangkaian langkah yang dilakukan dalam fase pengujian. Ini menguraikan fase berurutan dan aktivitas yang dilakukan saat menguji produk perangkat lunak.

STLC untuk QA, SDLC untuk proses development.

Testing Principles

    Kita sudah memahami bahwa testing atau pengujian merupakan suatu proses untuk memvalidasi dan memverifikasi antara ekspetasi dengan hasil yang ditemui. Berikut adalah 7 prinsip dasar dari pengujian perangkat lunak.

7 Testing Principles





1. Testing shows the presence of defects

    Pengujian bukanlah suatu proses untuk memastikan bahwa produk yang dibangun terbebas dari cacat atau bug. Kecuali jika memang ruang lingkup produk yang dibangun sangat kecil sehingga hanya membutuhkan sedikit skenario pengujian. Namun pada dasarnya, pengujian ditujukan untuk menemukan cacat atau bug pada suatu software. Contoh: Galaxy note bisa 7 terbakar sendiri baik saat digunakan maupun tidak digunakan.

2. Exhausting Testing is impossible

    Menguji segala sesuatu termasuk semua kombinasi input dan prasyarat itu adalah tidak mungkin.

3. Early Testing saves time and money

    Dalam SDLC kegiatan pengujian harus dimulai sedini mungkin dan harus difokuskan pada tujuan yang telah ditetapkan, bisa berarti menguji persyaratan sebelum coding dimulai, misalnya – mengubah masalah pada tahap ini jauh lebih mudah dan lebih murah daripada melakukannya tepat di akhir siklus hidup produk, di mana pada saat  itu  seluruh  area   fungsionalitas   mungkin   perlu   ditulis   ulang,   mengarah  ke overruns dan melewatkan tenggat waktu.

4. Defect Clustering

    Mengelompokkan sesuai modul atau fitur. Hal ini memudahkan QA dalam mengidentifikasi. Mengetahui hal ini terbukti sangat berharga untuk pengujian, jika menemukan satu cacat pada modul atau fitur tertentu, ada kemungkinan besar untuk menemukan lebih banyak lagi di sana.

5. Pesticide Paradox

    Jika kita menggunakan pestisida yang sama terus menerus, maka seiring waktu hama bisa menjadi kebal. Jika jenis yang sama dari test diulangi lagi dan lagi, akhirnya set yang sama dari kasus uji tidak akan lagi menemukan bug baru. Penting untuk terus meninjau pengujian dan memodifikasi atau menambahkan skenario untuk membantu mencegah terjadinya paradoks pestisida. Bisa dengan menggunakan berbagai metode teknik pengujian, menggunakan variasi baru saat melakukan pengujian.

6. Testing is context dependent

    Pengujian pada dasarnya bergantung terhadap konteks. Metode dan jenis pengujian yang dilakukan dapat sepenuhnya bergantung pada konteks perangkat lunak atau sistem. Misalnya, testing software yang berkaitan erat dengan keamanan tentu berbeda dari testing software sebuah situs e-commerce. Setiap perangkat lunak memiliki cara pengujian masing-masing.

7. Absence of error fallacy

    Tidak ada bug merupakan kesalahan. Jika dalam pengujian tidak ditemukan bug maka perlu dicurigai apakah software tersebut sudah sesuai dengan kebutuhan pengguna.

    Memahami dan menerapkan prinsip dasar testing penting agar seorang tester bisa menemukan bug sebanyak-banyaknya. Aturan yang perlu diikuti, jika satu diabaikan dampaknya adalah pembengkakan biaya dalam proyek pengembangan software.

Sumber: 


Komentar

Posting Komentar

Postingan populer dari blog ini

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

Test Scenario dan Test Cases

Gambar
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 Te...
Baca selengkapnya