Pengujian Berbasis Risiko

Untuk memastikan kualitas produk informasi dalam kedokteran, asuransi, perbankan dan industri lainnya, bersama dengan metode pengujian lainnya, penting untuk menggunakan pengujian berbasis risiko. Untuk verifikasi, area paling berisiko dari perangkat lunak yang sedang dibuat dipilih. Ini memungkinkan kami untuk mengantisipasi skenario negatif dan berhasil mengimplementasikan tujuan bisnis pelanggan.

Dalam artikel tersebut, kami akan memberi tahu bagaimana kami di SimbirSoft bekerja dengan risiko (menggunakan sistem akuisisi Internet dan proyek-proyek lain sebagai contoh) dan metode penilaian risiko dan manajemen apa yang kami gunakan dalam proyek pelanggan.

Risiko pada awal proyek

Untuk memulai, kami memberikan contoh dari praktik kami dalam pengembangan untuk sektor perbankan.

Usulan pelanggan: untuk fokus pada versi web bank untuk individu.

Risiko yang kami identifikasi: kemungkinan hilangnya pemirsa karena rendahnya permintaan versi web untuk individu, tidak seperti bank klien seluler.

Argumen kami: statistik preferensi pengguna berdasarkan ulasan dan distribusi audiens berdasarkan versi seluler dan web.

Kesimpulan: untuk perorangan, versi seluler lebih nyaman, karena ponsel selalu siap sedia. Operasinya cepat, sistem otorisasi memungkinkan Anda untuk mengakses semua layanan yang nyaman. Dalam hal ini, akses cepat ke fungsi terbatas yang paling populer adalah penting.

Untuk badan hukum, kelengkapan fungsi yang disediakan, kemampuan untuk mengunggah, mencetak, dan bekerja dengan sejumlah besar informasi adalah penting. Untuk ini, versi web lebih nyaman.

Solusi kami: untuk fokus pada bank klien seluler untuk individu.
Pada awal pekerjaan dengan proyek ini, penting untuk memilih strategi pengujian dengan benar. Mari kita lihat contoh mengapa itu penting dan bagaimana memilihnya.

Strategi pengujian harus memenuhi tujuan bisnis

Cepat atau lambat, semua perusahaan dihadapkan pada kebutuhan untuk mengatur proses pengujian dan memahami bahwa membangun strateginya merupakan tahap penting dalam pengembangan perangkat lunak. Terkadang - melalui pengalaman pahit mereka sendiri. Sangat berbahaya untuk meremehkan peran pengujian dan pemilihan strategi dalam pengembangan proyek skala besar. Proses pengujian harus dipilih sesuai dengan tujuan bisnis dan spesifik proyek, jika tidak maka tidak akan menghasilkan hasil yang positif baik dalam sebulan atau satu tahun.

Misalnya, pertimbangkan untuk menguji aplikasi seluler dan web untuk bank. Pada awal proyek, kami memilih strategi berdasarkan persyaratan dengan tingkat detail yang rendah. Kami menggunakan daftar periksa untuk mengurangi waktu pengujian dan mendukung dasar pengujian. Dengan tumbuhnya fungsionalitas, penambahan perolehan, otorisasi sms dan notifikasi, sistem yang lebih kompleks, daftar periksa tidak lagi menangani tugas mereka. Seiring waktu, semakin banyak spesialis QA bergabung dengan tim, perlu untuk mengirimkan informasi dan mengoordinasikan tindakan mereka. Dengan komplikasi produk, perubahan apa pun dapat mempengaruhi fungsi terkait, yaitu risiko regresi meningkat. Perlunya otomatisasi tes regresi sedang dibuat, jadi kami beralih ke uji kasus.

Kesimpulan: tergantung pada proyek, spesifik atau tahap pengembangan, strategi pengujian berubah.

Strategi harus dipilih untuk tujuan proyek untuk memastikan produk dengan kualitas terbaik. Dia menjawab pertanyaan "apa", "di mana" dan "kapan" akan diuji. Setiap saat dalam waktu, Anda tahu di mana Anda berada dan di mana Anda akan datang di masa depan - sesuai dengan strategi.

Tujuan bisnis mungkin untuk memastikan keamanan data pelanggan, serta perangkat lunak itu sendiri pada tahap produksi. Keamanan dimulai dengan proses pengembangan dan berlanjut melalui fase pengujian.

Misalnya, di salah satu proyek, kami menciptakan lingkungan yang aman untuk pengembangan dan pengujian, menggunakan infrastruktur yang memenuhi semua persyaratan dan membantu melindungi data. Kami meminta token tersertifikasi dan flash drive berbasis nama untuk setiap spesialis QA untuk mengakses infrastruktur pengujian. Dengan demikian, kami memastikan tujuan bisnis proyek dalam keamanan perangkat lunak dan menjaga kerahasiaan data klien dan pengguna.

Karena strategi pengujian, penekanan dapat ditempatkan pada aspek yang sangat penting untuk proyek tertentu. Adalah logis bahwa pelepasan game mobile atau sistem CRM perbankan yang kompleks memerlukan pendekatan pengujian yang berbeda.

Strategi Pengujian Perbankan

Dalam praktik kami, kami di SimbirSoft menggunakan seluruh jajaran metodologi pengembangan, tetapi teknologi fleksibel selalu tetap menjadi prioritas kami. Dan bahkan di mana, karena sejumlah alasan, tidak mungkin untuk menggunakannya, tim mengadopsi praktik terbaik dan menerapkannya dalam pekerjaan sehari-hari. Pengujian menjadi bagian integral dari keseluruhan proses dan bergabung ke dalam alur kerja keseluruhan. Dalam hal ini, bertanggung jawab tidak hanya untuk kualitas produk, tetapi bahkan untuk kualitas seluruh proses kerja.

Teknologi apa yang kami gunakan:

• perencanaan dan persiapan fleksibel rilis internal;
• persiapan cerita pengguna;
• mengadakan aksi unjuk rasa;
• melakukan retrospektif.

Dengan kekuatan penuh, strategi pengujian mengungkapkan dirinya dalam proyek-proyek dengan logika bisnis yang kompleks. Misalnya, perangkat lunak untuk dukungan informasi bank, pembangunan sistem akuisisi Internet, platform perdagangan otomatis. Dalam proyek tersebut, penting untuk menerapkan strategi pengujian yang sesuai, karena harga beberapa kesalahan dapat menyebabkan kerugian nyata dan sangat mempengaruhi reputasi perusahaan menjadi lebih buruk.

Juga, tujuan utama pengujian - pencarian cacat dan verifikasi perangkat lunak untuk kepatuhan - dapat ditambahkan tambahan. Sebagai contoh, penting bagi bank untuk segera menerapkan persyaratan baru dari Bank Sentral. Ini berarti bahwa pengujian tepat waktu dengan kualitas yang diperlukan untuk tugas-tugas penting akan ditambahkan ke tujuan utama.

Baru-baru ini, dalam proyek perbankan, kami dihadapkan dengan perubahan dalam hukum federal - kenaikan tingkat PPN dari 18% menjadi 20%. Banyak pekerjaan pendahuluan yang dilakukan untuk beradaptasi dengan perubahan undang-undang, karena perubahan tidak hanya menyangkut penggantian bentuk, antarmuka, tetapi juga perubahan logika dari beberapa rumus perhitungan. Itu perlu untuk memastikan tampilan yang benar pada banyak platform. Juga dalam fungsi pembayaran yang ditangguhkan, perlu diperhitungkan periode transisi dengan tarif 18% dan 20%.

Sekarang kita akan berbicara lebih detail tentang bagaimana kita membangun strategi kita dan mengapa kita sering memilih pengujian berbasis risiko.

Pro pengujian berbasis risiko

Ada beberapa strategi pengujian yang dipilih untuk tujuan tertentu:

• berdasarkan persyaratan;
• metodis;
• strategi reaktif;
• strategi penasehat.

Dalam kasus bekerja dengan proyek-proyek dengan logika bisnis yang kompleks, perlu untuk menentukan persyaratan ketat dalam desain sistem yang menjadi dasar pengujian. Alat yang cocok adalah pengujian berbasis persyaratan.

Salah satu jenis strategi berbasis persyaratan adalah pengujian berbasis risiko. Selain itu, bagian-bagian dari fungsionalitas sistem yang paling rentan terhadap risiko diuji terlebih dahulu. Risiko adalah konsekuensi negatif yang mungkin terjadi dari sistem yang tidak berfungsi. Konsekuensinya adalah risiko di hadapan dua komponen, seperti peluang dan negatif.

Ada dua jenis risiko:

1. Risiko produk

Itu dapat dikelola dan tidak dikelola. Dalam contoh di atas, kami dihadapkan pada risiko yang dapat dikelola: pertumbuhan yang cepat dan kompleksitas fungsi, yang meningkatkan kemungkinan regresi. Di sini kami memecahkan masalah dengan memiliki basis pengujian yang dapat dimengerti dan otomatisasi berikutnya. Risiko yang tidak dapat kita pengaruhi adalah ketergantungan pada sistem eksternal dan kegagalannya dalam proses integrasi. Di sini kita meletakkan langkah-langkah yang akan mengurangi dampaknya pada sistem kita. Misalnya, menggunakan cadangan, menangani kasus luar biasa, menampilkan peringatan untuk pengguna.

2. Risiko proyek

Misalnya, pada suatu proyek, kami dihadapkan dengan fakta bahwa pelanggan sebelumnya tidak pernah bekerja dengan tim terdistribusi, dan oleh karena itu alur kerja yang digunakan tidak memenuhi persyaratan dan menciptakan masalah komunikasi tambahan: kurangnya pemahaman, duplikasi tugas, kinerja tugas yang saling eksklusif, dan sebagainya. Kami menyetujui restrukturisasi dan peningkatan proses - merevisi alur kerja, memperkenalkan semua anggota tim, mengadakan rapat umum, presentasi dan retrospektif. Akibatnya, pekerjaan berjalan ke arah yang benar.

Pendekatan berbasis risiko memungkinkan Anda untuk menyusun sejumlah risiko tertentu, untuk waktu yang singkat untuk menguji risiko dengan prioritas tinggi dan lebih lanjut memberi pelanggan metrik tentang seberapa baik mereka diuji, menunjukkan jumlah kasus yang direncanakan dan diselesaikan, serta jumlah cacat.

Implementasi pendekatan berbasis risiko pada proyek berlangsung dalam empat tahap:

Identifikasi Risiko - pada tahap ini, Anda perlu mengidentifikasi risiko dan mendapatkan daftar risiko.
Penilaian Risiko - di sini kami menganalisis daftar dan mengelompokkannya berdasarkan prioritas.
Mitigasi Risiko - pada tahap ini kami menentukan seberapa dalam kami akan menguji risiko.
Manajemen Risiko - di sini kami memutuskan bagaimana kami akan terus bekerja dengan mereka dan menjalaninya, mengidentifikasi risiko baru.

Risiko diidentifikasi dan dinilai oleh sekelompok pemangku kepentingan selama sesi curah pendapat. Tim harus menyertakan analis bisnis atau pembawa pengetahuan tentang sistem dari pelanggan, pengembang, manajer atau manajer proyek, arsitek, spesialis QA. Kami melibatkan spesialis keamanan informasi, karyawan yang bekerja langsung dengan sistem saat ini, dan analis bisnis yang terbenam dalam proses untuk mengidentifikasi dan menilai risiko.

Pertimbangkan pendekatan berbasis risiko dengan contoh pengujian sistem perolehan Internet.

Bekerja dengan risiko (pada contoh sistem akuisisi Internet)

Kami menetapkan persyaratan berikut:
D1.Menyediakan 1000 koneksi simultan ke sistem per detik.
D2. Keamanan Transaksi.
D3. Akses ke transaksi harus tersedia hanya untuk orang yang melakukan transaksi.
D4. Menyediakan dan mendukung standar SET (Secure Electronic Transaction).

Sebagai risiko produk, kita dapat membedakan:
RP1. Sistem macet dengan koneksi simultan.
RP2. Menggunakan injeksi SQL selama transaksi.
RP3. Akses ke transaksi orang lain saat mengubah parameter di URL.
RP4. Kehilangan data saat koneksi dengan bank terputus pada saat transaksi.
RP5. Penggunaan sertifikat yang tidak valid saat menyediakan sistem SET (Secure Electronic Transaction).

Sebagai risiko organisasi:
RO1. Jatuhnya sistem yang dikembangkan karena tidak dapat diaksesnya sistem eksternal.
RO2. Adanya kasus yang sulit direproduksi yang tidak dapat dideteksi dalam lingkungan pengujian.

Dengan demikian, setiap risiko secara logis mengikuti dari persyaratan yang ada dalam sistem, tetapi tidak terbatas pada mereka. Risiko melengkapi persyaratan dan mengidentifikasi kasus-kasus tambahan yang mungkin timbul ketika bekerja dengan sistem.

Risiko dapat dikurangi atau dikompensasi tergantung pada tujuan proyek dan persyaratan sistem. Diterima bahwa risiko ditanggung oleh test case setidaknya sekali:

1. Untuk setiap risiko produk, satu set kasus uji RP1-RP4 disiapkan dengan ketentuan bahwa setiap persyaratan dan setiap risiko harus ditanggung oleh setidaknya satu kasus uji. Tergantung pada tujuan pengujian, set kasus uji diperluas ke tingkat detail tertentu.

2. Untuk setiap risiko organisasi, daftar kegiatan disiapkan yang dapat mengurangi dampak risiko pada produk yang sedang dikembangkan.

Penilaian Risiko dan Teknik Manajemen

Ada beberapa metode untuk menilai dan mengelola risiko: metode ringan (PRAM, PRISMA) dan lebih formal (FMEA, FTA).

Dengan model FMEA, tim proyek mengidentifikasi semua proses, komponen, modul sistem di mana kegagalan atau kesalahan sistem dapat terjadi yang dapat menyebabkan penurunan kualitas produk. Selama brainstorming, risiko sistem ditentukan oleh tiga indikator: keparahan, prioritas, probabilitas. Kemudian Nomor Prioritas Risiko dihitung untuk setiap risiko dan, tergantung pada indikator, kedalaman pengujian diletakkan.

Dengan model FTA, semua penyebab yang dapat menyebabkan cacat dalam proses bisnis sistem ditentukan secara bertahap. Analisis bergerak dari level tertinggi ke level terendah. Perbedaan antara FMEA dan FTA adalah bahwa pendekatan pertama berfokus pada fungsionalitas sistem, dan yang kedua pada proses bisnis.

Selain pendekatan formal dan berat ini, ada yang lebih fleksibel dan informal. Misalnya, metode PRAM (Analisis Pragmatis dan Manajemen Risiko) dan PRISMA (Manajemen Risiko Produk). Mereka berhasil dan mudah menggabungkan strategi berbasis risiko dan persyaratan. Pada dasarnya, pendekatan ini menggunakan spesifikasi persyaratan sebagai input, tetapi pemangku kepentingan juga dapat terlibat.

Metode analisis risiko ringan sangat mirip dengan yang formal. Mereka fokus pada risiko teknis atau komersial, menimbang kemungkinan terjadinya risiko dan faktor-faktor yang mempengaruhi probabilitas ini.

Namun, hanya dua faktor yang digunakan oleh metode ini adalah kemungkinan risiko dan dampaknya. Selain itu, pendekatan ini menggunakan penilaian kualitatif dan skala yang disederhanakan untuk membuat keputusan.

Tim kami menggunakan metode ringan yang fleksibel dan mengadaptasi pendekatan PRAM dan PRISMA untuk tujuan mereka.

Cara kami bekerja dengan pengujian berbasis risiko

Misalnya, pada salah satu proyek, kami mengidentifikasi risiko proyek dan produk yang mungkin berhasil. Untuk melakukan ini, analis, pengembang, dan QA berpartisipasi dalam analisis - satu wakil dari tim.

Tabel risiko dibentuk dengan produk. Mereka menentukan penilaian probabilitas suatu risiko yang terjadi dan kemungkinan dampaknya pada sistem pada skala lima poin. Dalam tabel 1 - pengaruh terkuat, 5 - terlemah. Juga untuk probabilitas 1 - probabilitas tinggi, 5 - probabilitas rendah.

Bagaimana kami terus bekerja dengan risiko produk

Selanjutnya, untuk masing-masing dari mereka, cakupan risiko produk dilacak dengan kasus uji.

Kami memilih cek berikut:

TC1. Periksa beban dengan lebih dari 1000 koneksi ke sistem
TC2. Uji beban dengan 1000 koneksi sistem
TC3. Masukkan injeksi SQL selama transaksi
TC4. Masukkan injeksi SQL pada halaman transaksi yang sukses, dengan mengganti data lain
TC5. Memasukkan skrip XSS (Cross-Site Scripting) ke bidang yang tersedia untuk input saat melakukan transaksi
TC6. Simulasi koneksi internet terputus selama transaksi
TC7. Keluar dari Sesi Transaksi pada Langkah Verifikasi
TC8. Validasi sertifikat kadaluarsa selama transaksi



Dengan demikian, pemeriksaan prioritas adalah TC2, TC4, TC5.

TC6 dan TC8 memiliki dampak tinggi, tetapi kemungkinannya lebih kecil, sehingga prioritas untuk memeriksanya lebih rendah, tetapi juga diperlukan pemeriksaan.

TC7 tidak berlaku untuk semua persyaratan, tetapi memperluas pengujian untuk skenario negatif, yang dimungkinkan dengan pengoperasian sistem yang stabil.

Bagaimana kami terus bekerja dengan risiko proyek

Kami juga menentukan tindakan untuk risiko proyek, dimana kami menetapkan tindakan dan keputusan tambahan.

Beresiko “RO2. Adanya kasus yang sulit direproduksi yang tidak dapat dideteksi di lingkungan pengujian ”, Anda dapat mengambil yang berikut:

• Mempersiapkan stand pra-produksi, yang sedekat mungkin dengan lingkungan aplikasi nyata, dalam hubungannya dengan semua sistem eksternal;
• menulis skrip pengujian ujung-ke-ujung yang melewati semua sistem yang berdekatan dan memberikan verifikasi transaksi;
• setelah melakukan semua pemeriksaan prioritas, gunakan teknik menebak kesalahan sesuai dengan persyaratan dasar sistem dan skrip untuk pemeriksaan tambahan dalam peran "cracker sistem".

Rencana darurat

Penting untuk memiliki rencana tindakan jika salah satu dari produk atau risiko proyek berfungsi. Terkadang mungkin menyimpan pengaturan sistem cadangan proyek. Tidak selalu mungkin untuk mengurangi risiko ke tingkat minimum, tetapi harus mungkin untuk mengurangi setidaknya konsekuensinya. Posting kami "Kisah Natal" ada di topik ini: bagaimana risiko bisa bekerja, probabilitasnya cenderung nol.

Misalnya, kita harus sepenuhnya menghilangkan kehilangan data selama transaksi, tetapi menganggap semua kasus terlalu melelahkan. Karena itu, Anda perlu memiliki cara untuk menangani kasus-kasus seperti itu. Salah satu opsi untuk keamanan adalah pengembangan pembalakan yang lebih rinci. Ini akan memberikan titik pengembalian permanen ke tindakan sebelumnya jika terjadi kesalahan selama transaksi.

Kesimpulan

Pengujian berbasis risiko memungkinkan Anda untuk menutupi area yang paling berisiko dengan kasus pengujian, sehingga mengurangi dampak dan kemungkinan dipicu. Ini adalah strategi yang paling unggul untuk sistem dengan logika bisnis yang kompleks dan biaya kesalahan yang tinggi. Solusinya cocok untuk sektor perbankan, perusahaan asuransi, sistem CRM internal yang kompleks dari profil medis. Dengan pendekatan berbasis risiko, kami juga bekerja dengan risiko proyek, yang meningkatkan keseluruhan proses pengujian dan manajemen proyek.