Teori Pengujian Fundamental

Pengujian bukanlah ilmu pasti. Tidak ada definisi yang jelas dan mapan yang dapat dikumpulkan dalam kamus dan dipelajari sebelum wawancara. Setiap proyek TI adalah unik, yang menghasilkan sejumlah besar informasi yang berbeda, seringkali kontradiktif. Memahami proses dan pendekatan menjadi penting dalam pengujian, seperti dalam profesi apa pun. Penting tidak hanya untuk mengetahui nama proses ini atau itu, jenis pengujian, tetapi apa itu dan mengapa itu diperlukan dalam proyek.

Mari beralih ke konsep dasar.

Pengujian Perangkat Lunak adalah verifikasi kesesuaian hasil aktual dan yang diharapkan dari perilaku program, yang dilakukan pada serangkaian pengujian terbatas yang dipilih dengan cara tertentu.



Tujuan pengujian adalah untuk memverifikasi bahwa perangkat lunak memenuhi persyaratan, untuk memastikan kepercayaan pada kualitas perangkat lunak, untuk mencari kesalahan yang jelas dalam perangkat lunak, yang harus diidentifikasi sebelum pengguna program menemukannya.



Mengapa pengujian perangkat lunak diperlukan?

• Proses pengujian memastikan bahwa perangkat lunak akan berfungsi sesuai kebutuhan.
• Ini mengurangi siklus pengkodean dengan mengidentifikasi masalah di awal fase pengembangan. Mendeteksi masalah lebih awal dalam fase pengembangan memastikan penggunaan sumber daya yang benar dan mencegah kenaikan biaya.
• , .
• , , , .

• 1 — (Testing shows presence of defects). , , , . , , .
• 2 — (Exhaustive testing is impossible). , . , .
• 3 — (Early testing). , , .
• 4 — (Defects clustering). – . . , .
• 5 — (Pesticide paradox). , . « », , , , , .
• 6 — (Testing is concept depending). - . , , , , .
• Prinsip 7 - Kesalahpahaman tentang tidak adanya kesalahan (akhiri Absen-kesalahan The fallacy) . Tidak adanya cacat yang ditemukan selama pengujian tidak selalu berarti bahwa produk siap untuk dirilis. Sistem harus ramah pengguna dan memenuhi harapan serta kebutuhan pengguna.

Quality Assurance (QA) dan Quality Control (QC) - istilah ini mirip dengan istilah yang dapat dipertukarkan, tetapi masih terdapat perbedaan antara jaminan kualitas dan pengendalian kualitas, meskipun dalam praktiknya proses tersebut memiliki beberapa kesamaan.



QC (Quality Control) - Kontrol kualitas produk - analisis hasil pengujian dan kualitas versi baru dari produk yang dirilis.

Tugas kendali mutu meliputi:

• memeriksa kesiapan perangkat lunak untuk rilis;
• verifikasi kepatuhan dengan persyaratan dan kualitas proyek ini.

QA (Quality Assurance) - Jaminan kualitas produk - menjajaki peluang untuk mengubah dan meningkatkan proses pengembangan, meningkatkan komunikasi dalam tim, di mana pengujian hanyalah salah satu aspek jaminan kualitas.



Tujuan jaminan kualitas meliputi:

• verifikasi karakteristik teknis dan persyaratan perangkat lunak;
• tugas beresiko;
• penjadwalan tugas untuk meningkatkan kualitas produk;
• persiapan dokumentasi, lingkungan pengujian dan data;
• pengujian;
• analisis hasil tes, serta penyusunan laporan dan dokumen lainnya.

Verifikasi dan validasi adalah dua konsep yang terkait erat dengan proses pengujian dan jaminan kualitas. Sayangnya, mereka sering bingung, padahal perbedaan di antara keduanya cukup signifikan.



Verifikasi adalah proses evaluasi suatu sistem untuk melihat apakah hasil tahap pengembangan saat ini memenuhi kondisi yang telah dirumuskan di awal.



Validasi adalah penentuan kesesuaian perangkat lunak yang dikembangkan dengan harapan dan kebutuhan pengguna, persyaratannya untuk sistem.



: 310, , «», . , , «». , . , , , . «» — , «» — . , .







Dokumentasi yang digunakan pada proyek pengembangan perangkat lunak secara kasar dapat dibagi menjadi dua kelompok:

1. Dokumentasi proyek - mencakup semua yang terkait dengan proyek secara keseluruhan.
2. Dokumentasi produk adalah bagian dari dokumentasi desain, dialokasikan secara terpisah, yang berhubungan langsung dengan aplikasi atau sistem yang dikembangkan.

Tahapan pengujian:

1. Analisis produk
2. Bekerja dengan persyaratan
3. Mengembangkan strategi pengujian dan prosedur pengendalian kualitas perencanaan
4. Pembuatan dokumentasi tes
5. Pengujian prototipe
6. Pengujian dasar
7. Stabilisasi
8. Eksploitasi

Tahapan pengembangan perangkat lunak - tahapan yang dilalui tim pengembangan perangkat lunak sebelum program tersedia untuk berbagai pengguna.



Produk perangkat lunak melewati tahapan berikut:

1. analisis kebutuhan proyek;
2. rancangan;
3. penerapan;
4. pengujian produk;
5. implementasi dan dukungan.

Persyaratan

Persyaratan adalah spesifikasi (uraian) tentang apa yang perlu dilaksanakan.

Persyaratan menjelaskan apa yang perlu diterapkan tanpa merinci sisi teknis dari solusi tersebut.



Persyaratan untuk persyaratan:

1. Ketepatan - setiap persyaratan harus menjelaskan fungsionalitas yang diinginkan secara akurat.
2. Dapat diverifikasi - persyaratan harus dirumuskan sedemikian rupa sehingga ada cara untuk memeriksa dengan jelas apakah itu dipenuhi atau tidak.
3. Kelengkapan - setiap persyaratan harus berisi semua informasi yang diperlukan pengembang untuk mengimplementasikan fungsionalitas tersebut.
4. Tidak ambigu - persyaratan dijelaskan tanpa singkatan yang tidak jelas dan kata-kata yang tidak jelas dan hanya memungkinkan interpretasi yang tidak ambigu dari apa yang tertulis.
5. — .
6. — ( ). .
7. — .
8. — .
9. — , .

Cacat (bug) - penyimpangan hasil aktual dari yang diharapkan.



Laporan bug adalah dokumen yang menjelaskan situasi yang mengarah pada penemuan cacat, menunjukkan alasan dan hasil yang diharapkan.



Atribut laporan cacat:

1. Pengidentifikasi unik (ID) - ditetapkan secara otomatis oleh sistem.
   
   
2. Topik (deskripsi singkat, Ringkasan) - esensi cacat yang dirumuskan secara singkat sesuai dengan aturan "Apa? Dimana? Kapan?"
3. Deskripsi rinci (Deskripsi) - deskripsi yang lebih luas tentang esensi cacat (ditentukan secara opsional).
   
   ...
4. Langkah Untuk Mereproduksi - deskripsi berurutan dari tindakan yang mengarah ke identifikasi cacat. Penting untuk mendeskripsikan sedetail mungkin, yang menunjukkan nilai input spesifik.
   
   
5. (Actual result) — , , .
6. (Expected result) — , , .
   
   
7. (Attachments) — , -.
8. (, Severity) — .
9. (, Priority) — .
10. (Status) — . - .
11. (environment) – , .

Severity vs Priority

Keparahan menunjukkan tingkat kerusakan yang disebabkan oleh proyek karena adanya cacat. Tingkat keparahan diungkapkan oleh penguji.



Penilaian Tingkat Keparahan Cacat:

• 
  
  Pengujian pemblokiran (S1 - Blocker) dari sebagian besar fungsionalitas tidak tersedia sama sekali. Kesalahan pemblokiran yang membuat aplikasi tidak beroperasi, akibatnya bekerja lebih lanjut dengan sistem yang sedang diuji atau fungsi utamanya menjadi tidak mungkin.
• (S2 – Critical)
  
  , -, , , , - , workaround ( / ), .
• (S3 – Major)
  
  - /-, , workaround, - . visibility – , , , .
• (S4 – Minor)
  
  GUI, , . , .
• Trivial (S5 - Trivial)
  
  hampir selalu cacat pada GUI - kesalahan ketik pada teks, ketidakcocokan font dan bayangan, dll., Atau kesalahan yang dapat direproduksi dengan buruk yang tidak menyangkut logika bisnis, masalah dengan pustaka atau layanan pihak ketiga, a masalah yang tidak berpengaruh pada kualitas produk secara keseluruhan.

Prioritas menunjukkan seberapa cepat kerusakan harus diperbaiki. Prioritas ditentukan oleh manajer, pimpinan tim atau pelanggan.Cacat Prioritas gradasi



(Prioritas):

• P1 Tinggi
  
  Kesalahan harus diperbaiki secepat mungkin. keberadaannya sangat penting untuk proyek.
• P2 Medium
  
  Kesalahan harus diperbaiki, keberadaannya tidak kritis, tetapi harus diselesaikan.
• P3 (Low)
  
  , .

:

• (epic) — , .
• (story) — (), 1 .
• (task) — , .
• - (sub-task) — / , .
• (bug) — , .

• (Development Env) – , , , Unit-. .
• (Test Env) – . . , , . .
• (Integration Env) – , . end-to-end , , . , . – , .
• (Preview, Preprod Env) – , : , - , . , «». end-to-end , / (User Acceptance Testing (UAT)), L3 L2 DryRun ( ). L3 .
• (Production Env) – , . L2 , , . L3.

• Pre-Alpha: . . . .
• Alpha: . — . - . . .
• Beta: . , .
• Kandidat Rilis (RC) : Berdasarkan masukan Uji Beta, Anda membuat perubahan perangkat lunak dan ingin menguji perbaikan bug. Pada titik ini, Anda tidak ingin melakukan perubahan drastis pada fungsionalitas, tetapi cukup periksa bug. RC juga dapat dirilis ke publik.
• Rilis: semuanya berfungsi, perangkat lunak dirilis ke publik.

Jenis utama pengujian perangkat lunak

Jenis pengujian adalah serangkaian aktivitas yang bertujuan untuk menguji karakteristik tertentu dari suatu sistem atau bagiannya, berdasarkan tujuan tertentu.

1. Klasifikasi dengan menjalankan kode untuk eksekusi:
   
   
   • — . , . «». — .
   • — . , / . — , . , , .
   
   
   
2. :
   
   
   • — , , // .
   • — , White Box Black Box . , .
   • — , – , .
   
   
   
3. :
   
   
   • — - ( , subprograms, subroutines, ) . , .
   • — , ( , ).
   • — , , .
   • — , - .
   
   
   
4. :
   
   
   • .
   • .
   
   
   
5. 
   
   
   • — , .
   • — , .
   
   
   
6. :
   
   
   • (smoke test) — , , .
   • (critical path) — , .
   • (extended) — .
   
   
   
7. :
   
   
   • - — . - .
   • - — . , .
   
   
   
8. :
   
   
   • (functional testing) — ( ).
   • (non-functional testing) — , , , « ».
     
     
     1. (performance testing) — , , .
     2. (load testing) — , , .
     3. (scalability testing) — .
     4. (volume testing) — , .
     5. (stress testing) — , .
     6. (installation testing) — , , .
     7. (GUI/UI testing) — .
     8. (usability testing) — , .
     9. (localization testing) — (, ).
     10. (security testing) — , .
     11. (reliability testing) — .
     12. Pengujian regresi - pengujian fungsionalitas yang diuji sebelumnya setelah membuat perubahan pada kode aplikasi, untuk memastikan bahwa perubahan ini tidak menimbulkan kesalahan di area yang belum diubah.
     13. Pengujian ulang / pengujian konfirmasi - pengujian di mana skrip pengujian yang mendeteksi kesalahan selama proses terakhir dijalankan untuk mengonfirmasi keberhasilan memperbaiki kesalahan ini.
   
   
   

Desain uji adalah tahap pengujian perangkat lunak, di mana kasus uji (test case) dirancang dan dibuat.



Teknik desain uji:

1. (equivalence partitioning) — , , ( ) .
2. (boundary value testing) — () .
3. (pairwise testing) — , -.
4. (State-Transition Testing) — .
5. (Decision Table Testing) — , , .
6. (Exploratory Testing) — , -: .
7. (Domain Analysis Testing) — , .
8. (Use Case Testing) — Use Case ( — ).

Pengujian kotak putih adalah metode pengujian perangkat lunak yang mengasumsikan bahwa struktur internal / perangkat / implementasi sistem diketahui oleh penguji.



Menurut ISTQB, pengujian white box adalah:

- pengujian berdasarkan analisis struktur internal suatu komponen atau sistem;

- desain uji berdasarkan teknik kotak putih - prosedur untuk menulis atau memilih kasus uji berdasarkan analisis struktur internal sistem atau komponen.

Mengapa White Box? Program yang diuji untuk penguji adalah kotak transparan, yang isinya dilihatnya dengan sempurna.



Pengujian kotak abu-abu- metode pengujian perangkat lunak, yang mengasumsikan kombinasi pendekatan White Box dan Black Box. Artinya, kami hanya mengetahui sebagian struktur internal program.



Pengujian kotak hitam - juga dikenal sebagai pengujian berbasis spesifikasi atau pengujian perilaku - adalah teknik pengujian yang hanya mengandalkan antarmuka eksternal dari sistem yang diuji.



Menurut ISTQB, pengujian black box adalah:

- pengujian, baik fungsional maupun non-fungsional, yang tidak melibatkan pengetahuan tentang struktur internal suatu komponen atau sistem;

- desain uji berdasarkan teknik kotak hitam - prosedur untuk menulis atau memilih kasus uji berdasarkan analisis spesifikasi fungsional atau non-fungsional dari suatu komponen atau sistem tanpa mengetahui struktur internalnya.

Dokumentasi Uji

Test Plan adalah dokumen yang menjelaskan seluruh ruang lingkup pengujian, mulai dari uraian fasilitas, strategi, jadwal, kriteria untuk memulai dan mengakhiri pengujian, hingga peralatan yang dibutuhkan dalam proses operasi, pengetahuan khusus, serta penilaian risiko. dengan pilihan untuk resolusi mereka. ...



Rencana pengujian harus menjawab pertanyaan-pertanyaan berikut:

• Apa yang harus diuji?
• Apa yang akan kamu uji?
• Bagaimana Anda akan menguji?
• Kapan Anda akan menguji?
• Uji kriteria mulai.
• Uji kriteria penghentian.

Poin utama dari rencana pengujian:



Standar IEEE 829 mencantumkan poin-poin yang harus terdiri dari rencana pengujian:

a) Pengenal rencana pengujian;

b) Pendahuluan;

c) Item uji;

d) Fitur yang akan diuji;

e) Fitur yang tidak untuk diuji;

f) Pendekatan;

g) Kriteria lolos / gagal item;

h) Kriteria penangguhan dan persyaratan dimulainya kembali;

i) Menguji kiriman;

j) Tugas pengujian;

k) Kebutuhan lingkungan;

l) Tanggung jawab;

m) Kebutuhan staf dan pelatihan;

n) Jadwal;

o) Risiko dan kontinjensi;

p) Persetujuan.



Daftar periksa adalah dokumen yang menjelaskan apa yang harus diuji. Daftar periksa dapat terdiri dari tingkat detail yang sangat berbeda.



Seringkali, daftar periksa hanya berisi tindakan, tanpa hasil yang diharapkan. Daftar periksa kurang formal.



Kasus uji adalah artefak yang mendeskripsikan serangkaian langkah, kondisi spesifik, dan parameter yang diperlukan untuk menguji implementasi fungsi yang sedang diuji atau sebagian darinya.



Atribut kasus uji:

• Prekondisi - daftar tindakan yang membawa sistem ke keadaan yang sesuai untuk melakukan pemeriksaan dasar. Atau daftar kondisi, yang pemenuhannya menunjukkan bahwa sistem dalam keadaan sesuai untuk melakukan pengujian utama.
• Langkah - daftar tindakan yang mentransfer sistem dari satu keadaan ke keadaan lain, untuk mendapatkan hasil, yang atas dasar itu dapat disimpulkan bahwa pelaksanaannya memenuhi persyaratan.
• Hasil yang diharapkan - apa yang seharusnya mereka dapatkan.

Ringkasan

Cobalah untuk memahami definisi, bukan menghafalnya. Dan jika Anda memiliki pertanyaan, Anda selalu dapat bertanya kepada kami di saluran telegram @qa_chillout .