Halo semuanya!

Saya memimpin sektor pengujian di departemen analisis dan pengujian sistem dari departemen sistem perusahaan LANIT. Saya telah berada di bidang ini selama 14 tahun. Pada 2009, untuk pertama kalinya saya dihadapkan dengan pengujian sistem informasi negara. Dan untuk LANIT, dan untuk pelanggan - itu adalah proyek besar dan signifikan. Ini telah beroperasi secara komersial selama lebih dari sembilan tahun.

Sumber

Teks ini akan memperkenalkan Anda pada pendekatan untuk menguji GIS, yang digunakan di perusahaan kami. Khususnya, Anda akan menemukan (tautan itu membawa Anda ke fragmen artikel yang dirujuk dalam paragraf tertentu):

Sebelum LANIT, saya bekerja dalam kelompok pengujian yang terdiri dari lima orang, di mana tugas-tugas tersebut diberikan kepada pemimpin tim. Ketika saya datang ke LANIT, saya ditugaskan untuk mengelola tim pengujian yang didistribusikan secara geografis dari empat penguji, yang terlibat pada awal proyek untuk menguji sistem informasi negara. Seiring perkembangan proyek, jumlah penguji dalam grup meningkat sebanding dengan peningkatan fungsionalitas.

Bab 1. Mulai proyek pengujian GIS pertama

Ketika kami mulai bekerja dengan GIS, pertama-tama, kami harus berurusan dengan sejumlah besar fungsionalitas (beberapa lusin subsistem, masing-masing dengan ratusan fungsi) yang perlu diuji dalam waktu singkat. Tim memiliki tugas untuk tidak menjadi bingung dalam lingkup fungsi dan meminimalkan risiko cacat yang terlewatkan.

Dokumentasi normatif, berdasarkan spesifikasi teknis yang dikembangkan, terus berubah, dan seluruh tim harus beradaptasi dengan inovasi: kami merevisi spesifikasi teknis untuk pengembangan dan prioritas proyek (sebagai hasilnya, rencana pengujian berubah).

Sulit bagi analis untuk beradaptasi dengan seringnya perubahan dokumentasi regulasi, yang menyebabkan kurangnya pemahaman tentang bagaimana menjaga spesifikasi teknis tetap terbaru, bagaimana selalu memiliki satu set spesifikasi yang relevan untuk setiap versi sistem, bagaimana dan di mana menampilkan tingkat pengaruh perubahan dalam satu spesifikasi pada banyak dokumen terkait lainnya .

Karena hasil kerja para analis digunakan oleh pengembang dan penguji, pertanyaan tentang relevansi spesifikasi teknis, kelengkapan sejarah spesifikasi, kesesuaian set spesifikasi teknis dari versi rilis mendatang, adalah akut untuk semua peserta dalam tim proyek. Konsekuensi kebingungan dengan dokumentasi, versi spesifikasi teknis mempengaruhi biaya proyek.

Terkadang situasinya berubah 180 derajat. Setuju, ketika sebuah kereta melaju dengan kecepatan tinggi, tidak mungkin untuk mengubah arah secara tajam tanpa konsekuensi.

Saya secara teratur menghadiri pertemuan dan memahami alasan perubahan dalam proyek. Bagian yang paling sulit adalah menjelaskan kepada penguji jarak jauh mengapa kami menguji registri baru selama sebulan, dan sekarang kami harus melupakan semuanya dan bersiap-siap untuk menguji fungsionalitas yang sepenuhnya didesain ulang dari registri ini. Orang-orang mulai merasa seperti roda penggerak dalam mesin raksasa, dan pekerjaan mereka dianggap sama sekali tidak berguna.

Pada awalnya, perubahan seperti itu mengganggu tim dan sangat terdemotivasi. Tetapi tim menerima kenyataan bahwa tidak mungkin untuk mempengaruhi perubahan dalam spesifikasi teknis, tetapi Anda dapat belajar bagaimana bekerja dengannya. Dalam periode yang sulit untuk proyek tersebut, tim pengujian memiliki tugas baru, yang biasanya tidak ada pada proyek yang lebih kecil - persyaratan pengujian.

Akibatnya, kerugian dari perubahan persyaratan berubah menjadi keuntungan bagi penguji dalam bentuk tugas baru untuk pengujian dan kemampuan untuk mempengaruhi hasil akhir proyek.

Selain berinteraksi dengan analis, tim penguji ternyata bergantung pada komunikasi dengan sistem eksternal yang harus mereka integrasikan. Tidak semua dari mereka siap untuk memberikan rangkaian pengujian mereka dan memberi tahu sistem pihak ketiga tentang tanggal rilis mereka dan bertukar informasi tentang perubahan layanan. Desinkronisasi dalam komunikasi atau sikap ceroboh terhadap pemberitahuan komposisi perubahan layanan web oleh sistem eksternal menyebabkan kesalahan produk dan kesulitan dalam melakukan pengujian integrasi. Penguji harus menjalin komunikasi dengan sistem eksternal, mengembangkan keterampilan pengujian integrasi dan menarik pengembang untuk mengimplementasikan rintisan.

Seluruh tim pengujian yang berpartisipasi dalam proyek dihadapkan dengan kebutuhan untuk membenamkan tim pengembangan dalam proses produksi. Pada awal proyek, tim pengembangan mulai mencari pendekatan baru untuk organisasi kerja, memperkenalkan model percabangan Fitur Branch Workflow dan model Gitflow. Pengembangan proyek-proyek kecil yang sebelumnya dilakukan tanpa banyak cabang, semua orang merasa nyaman. Tetapi dihadapkan dengan masalah ketidakmampuan untuk menstabilkan versi selama beberapa bulan untuk demonstrasi selanjutnya dari tahap menengah proyek kepada pelanggan, setelah menganalisis alasannya, manajer pengembangan dan arsitek sampai pada kesimpulan bahwa proses pembuatan perangkat lunak perlu diubah. Kemudian mereka mulai aktif menggunakan Feature Branch Workflow dan Gitflow pada proyek. Tugas baru lain untuk pengujian muncul - mempelajari prinsip kerja model pengembangan untuk beradaptasi dengan proses pembuatan perangkat lunak.

GIS melibatkan membagi proyek menjadi blok fungsional, yang masing-masing mencakup serangkaian komponen yang terkait erat satu sama lain oleh bisnis dan / atau melakukan fungsi teknis independen. Jika pada awal proyek semua penguji memeriksa blok fungsional yang baru tiba, dan semua orang dalam tim dapat dipertukarkan, memiliki tingkat pengetahuan yang sama dari semua blok, maka ketika proyek diperluas, jumlah penguji juga harus ditingkatkan dan dibagi menjadi kelompok-kelompok. Pertumbuhan tim menyebabkan proses pemisahan menjadi kelompok uji, alokasi peran proyek dalam setiap kelompok.

Sebagai proyek yang dikembangkan, fitur sistem informasi negara mulai muncul.

Bab 2. Fitur GIS. Bagaimana penguji hidup dan bekerja dengan mereka

Pertama-tama, SIG besar tunduk pada peningkatan persyaratan untuk keandalan dan beban, operasi sistem - 24/7, kerusakan sistem seharusnya tidak menyebabkan kehilangan data, waktu pemulihan sistem - tidak lebih dari 1 jam, waktu respons - tidak lebih dari 2 detik dan lebih banyak.

Karena itu adalah portal web, penguji harus terjun ke dalam proses pengujian portal web multi-pengguna dan membangun pendekatan untuk menguji desain dan proses pengujian, dengan mempertimbangkan kekhasan antarmuka web.

Aplikasi web dapat digunakan oleh sejumlah besar pengguna secara bersamaan. Itu diperlukan untuk memberikan pengujian beban pada bagian terbuka GIS yang digunakan oleh semua pengguna, untuk memprediksi model beban dan melakukan pengujian beban.

Pengguna dapat memiliki tingkat aksesnya sendiri. Itu diperlukan untuk menguji matriks peran pengguna dalam subsistem administrasi aplikasi menggunakan teknik desain uji.

Pengguna dapat mengakses satu entitas, yang mengarah ke akses kompetitif. Agar data input dari satu pengguna tidak menimpa data dari pengguna lain, kami harus melakukan analisis uji situasi di mana dimungkinkan untuk secara bersamaan mengubah data dalam dashboard pribadi pengguna, untuk memasukkan dalam tes pemeriksaan pengujian yang benar dengan pesan diagnostik.

Salah satu fitur sistem adalah penggunaan mesin pencari SphinxSearch.dimana tim penguji tidak tahu bagaimana cara kerjanya. Untuk memahami seluk-beluk pengujian, Sphinx harus berkonsultasi dengan pengembang dan memahami bagaimana pengindeksan data terjadi.

Penguji menguasai fitur pengujian pencarian menurut bentuk kata, fragmen kata, sinonim, dengan mencari di dalam dokumen terlampir, mereka mulai memahami mengapa data pencarian yang baru dibuat tidak muncul dalam hasil pencarian, dan apakah ini merupakan kesalahan.

Proyek ini memiliki subsistem administrasi yang diterapkan, yang mencakup tidak hanya pendaftaran pengguna, tetapi juga diperumit dengan adanya matriks peran pengguna. Itu dikonfigurasi dalam akun pribadi administrator organisasi. Jumlah kombinasi cek dari matriks peran sangat besar dan jumlah jenis organisasi juga tidak sedikit, yaitu, jumlah kombinasi cek tumbuh secara eksponensial. Itu perlu untuk mengubah pendekatan akrab untuk merancang tes yang digunakan sebelumnya pada proyek-proyek kecil.

Karena sistem diasumsikan sebagai antarmuka web, maka perlu dilakukan pengujian lintas-browser, yang pada awalnya tidak direncanakan. Ketika proyek baru dimulai, Internet Explorer 7.0 adalah satu-satunya browser yang mendukung kriptografi domestik, dan sebagian besar pengguna menggunakan browser ini. Oleh karena itu, pada awal proyek, untuk menguji logika dan fungsionalitas pekerjaan akun pribadi, hanya IE versi ini yang digunakan, tetapi untuk bagian terbuka portal, dukungan diperlukan untuk semua browser yang ada saat itu. Namun, pada saat itu mereka tidak memikirkan pengujian lintas-browser.

Ketika mereka bertanya kepada saya: "Bagaimana sistem berperilaku di semua versi browser yang dikenal?" - Saya panik, secara sederhana, karena volume model uji sangat besar (sekitar 4.000 kasus uji), set uji regresi sekitar 1.500 kasus uji, dan tim pengujian memeriksa seluruh kerumunan secara eksklusif pada satu browser yang dipilih secara default. Kasing ini harus dipecahkan dengan sangat cepat dan menggunakan kecerdikan untuk menangkap tenggat waktu untuk rilis pertama dan menutupi versi peramban utama dengan tes.

Di Internet kemudian ada beberapa artikel tentang pengujian, pengembangan model pengujian. Untuk tim kami, pada waktu itu, tugas yang tidak dapat dipahami adalah bagaimana membuat, di mana menyimpan dan bagaimana menjaga model uji besar tetap up to date. Tidak jelas bagaimana cara lolos dari pengujian penelitian, yang bisa menjadi tak terbatas, dan tidak ada sumber daya untuk ujian tanpa akhir: baik manusia maupun sementara.

Setelah GIS dimasukkan ke dalam operasi uji coba, dan kemudian ke dalam industri, tugas baru muncul - menangani insiden pengguna.

Sebelum layanan dukungan pengguna GIS lengkap dibuat, klik pertama permintaan pengguna dipenuhi oleh tim pengujian, sebagai yang paling terbenam dalam rincian sistem, mencoba untuk menggabungkan tugas-tugas utama pengujian peningkatan baru, serta proses tepat waktu insiden yang masuk yang ditumpangkan oleh SLA.

Tim pengujian belum pernah mengalami tugas seperti itu sebelumnya. Alur insiden perlu diproses, disistematisasikan, dilokalkan, diperbaiki, diverifikasi dan dimasukkan ke dalam siklus rilis baru.

Tingkat pemahaman dan kematangan proses operasi tumbuh dan membaik seiring dengan pertumbuhan sistem itu sendiri.

Saya hanya mencantumkan sebagian fitur yang ditemui tim pengujian saat bekerja dengan GIS.

Bab 3. Masalah pengujian GIS dan metode untuk menyelesaikannya. Rekomendasi untuk menguji manajer tim.

Dalam proses tim pengujian bekerja pada beberapa SIG besar, kami datang dengan rekomendasi untuk manajer pengujian. Kemudian mereka ditransformasikan menjadi metodologi proses pengujian sistem semacam itu di departemen kami dan terus membaik ketika memecahkan masalah baru dalam proyek-proyek dengan skala yang sama.

Apa yang harus dilakukan ketika banyak fungsi?

Jangan panik dan memecah fungsional menjadi blok / modul / fungsi, menghubungkan analis dengan audit hasil, pastikan bahwa visi blok fungsional sudah benar.

Kami merekomendasikan untuk membuat:

.

, , , , production. , .
//.

, , — , ///. , , , - , , , / // , , « » , .

Apa yang harus dilakukan dengan matriks pengetahuan dan cakupan persyaratan fungsional?

Fungsionalitas tidak menjadi lebih kecil. Sekarang masih banyak, tetapi dalam representasi baru (dalam bentuk matriks). Penting untuk menentukan fungsi mana yang paling penting dari sudut pandang bisnis dan apa yang tidak dapat diberikan kepada pengguna dalam bentuk mentah. Maka mulailah memprioritaskan fungsionalitas. Idealnya, jika analis membantu penguji dalam hal ini. Paling tidak, dia akan menghargai kebenaran dari prioritas yang diberikan oleh pengujian.

Fungsi / blok / modul yang paling penting akan diberi prioritas tinggi untuk pengujian, yang kurang penting akan dicakup oleh tes prioritas kedua, sisanya akan menjadi yang ketiga, atau jika “tenggat waktu aktif”, Anda dapat menunda pengujian mereka untuk waktu yang lebih tenang.

Dengan demikian, kami memiliki kesempatan untuk menguji fungsionalitas yang sangat penting bagi pelanggan. Kami membereskan berbagai fungsi, kami memahami apa yang dicakup oleh tes, dan apa yang masih harus dicakup, kami tahu bahwa di dalamnya perlu untuk memperkuat pengujian, dalam hal penyakit / pemberhentian penguji yang bertanggung jawab, kami memahami penguji mana yang harus dilewati oleh tim penguji untuk perbaikan (di korespondensi dengan matriks pengetahuan), apa fungsi / modul / subsistem baru yang menarik yang dapat saya tawarkan bersyarat Vasya, Pete, Lisa, ketika mereka lelah menguji hal yang sama. Artinya, saya mendapat alat visual untuk memotivasi penguji yang ingin belajar sesuatu yang baru di proyek.

Apa yang harus dilakukan ketika persyaratan tidak mendukung historisitas, bingung, diduplikasi, bagaimana cara penguji bekerja dengan ini?

Kami merekomendasikan penerapan proses pengujian persyaratan pada proyek. Semakin awal suatu cacat ditemukan, semakin rendah biayanya.

Penguji didistribusikan oleh matriks pengetahuan, setelah kesiapan spesifikasi teknis untuk pengembangan, segera mulai mempelajari dan memverifikasinya. Untuk menjelaskan kepada semua orang apa kesalahan dalam persyaratan, seperangkat aturan untuk analis "Resep untuk Persyaratan Kualitas" dikembangkan, sesuai dengan yang mereka coba tulis persyaratan, dan template untuk spesifikasi teknis dibuat untuk menggambarkan mereka dalam satu gaya. Aturan untuk format spesifikasi teknis dan rekomendasi untuk deskripsi persyaratan dikeluarkan untuk penguji untuk memahami kesalahan apa yang harus dicari dalam persyaratan.

Tentu saja, tugas utama dari penguji adalah untuk menemukan inkonsistensi logis atau momen-momen pengaruh yang tidak terhitung pada fungsi / subsistem / modul terkait yang bisa dilewatkan oleh analis. Setelah mendeteksi cacat, mereka diperbaiki di bugtracker, ditugaskan kepada penulis persyaratan, analis menghentikan pengembangan dan / atau mengobrol dengan penguji dan pengembang menginformasikan bahwa kondisi akan diubah sesuai dengan cacat (sehingga tidak memperlambat pengembangan), melakukan koreksi dan menerbitkan versi yang dikoreksi Persyaratan. Penguji memeriksa dan menutup pekerjaan pada cacat dengan persyaratan. Prosedur ini memberi keyakinan tim bahwa setelah beberapa minggu pengembangan, masalah yang terdeteksi pasti tidak akan muncul dalam tes.

Selain deteksi dini cacat, kami menerima alat yang kuat untuk mengumpulkan metrik pada kualitas pekerjaan analis. Memiliki statistik tentang jumlah kesalahan dalam persyaratan, analis utama proyek dapat mengambil langkah-langkah untuk meningkatkan kualitas pekerjaan dalam kelompoknya.

Apa yang harus dilakukan ketika perlu melakukan pengujian beban?

Penting untuk mempelajari persyaratan untuk muatan, menghasilkan modelnya, mengembangkan kasus uji, mengoordinasikan model uji beban dengan analis dan mengembangkan skrip beban dengan melibatkan spesialis yang kompeten dalam pengujian beban.

Tentu saja, Anda tidak dapat menebak beban dengan model pengujian, tetapi untuk hasil yang lebih akurat, selain analis, Anda dapat menarik seorang arsitek atau spesialis DevOps yang, setelah menganalisis informasi, statistik, metrik, dapat mengetahui kasus-kasus lain apa yang diperlukan dalam model pemuatan yang diusulkan.

Penting juga untuk mengimplementasikan proses menjalankan tes beban, mengambil hasil beban dan meneruskannya ke pengembang untuk menghilangkan hambatan.

Proses pemuatan harus dilakukan secara teratur sebelum pelepasan setiap pelepasan, secara berkala ubah model muatan untuk mengidentifikasi kemacetan baru.

Apa yang harus dilakukan ketika perlu melakukan pengujian integrasi di mana tidak ada pengalaman?

Ada beberapa cara dasar: misalnya, Anda dapat mengambil kursus pelatihan lanjutan tentang masalah pengujian API Istirahat, membaca artikel di Internet, mendapatkan pertukaran pengalaman dengan kolega melalui Skype, dengan peragaan proses, merekrut spesialis yang berpengalaman dalam pengujian API Istirahat ke grup pengujian.

Ada banyak cara untuk melibatkan diri dalam jenis pengujian ini. Seorang spesialis berpengalaman dipekerjakan di tim saya, yang di masa depan melatih saya dan seluruh tim pengujian, mengembangkan manual: apa yang harus dicari ketika menguji API Istirahat, cara menyusun desain pengujian untuk memverifikasi integrasi, melakukan webinar dengan demonstrasi proses pengujian untuk seluruh tim.

Kami datang dengan tugas-tugas pengujian di mana setiap orang memiliki kesempatan untuk berlatih dan membenamkan diri dalam proses ini. Sekarang materi yang telah dikembangkan selama bertahun-tahun hanya membaik, dan proses belajar dan menyelam ke pengujian API sisanya membutuhkan 1-2 minggu, sementara sebelumnya butuh satu bulan atau lebih untuk menyelam, tergantung pada kompleksitas proyek dan volume model pengujian.

Sumber

Bagaimana tidak bingung dalam cabang kode, berdiri, penyebaran dan menguji kode yang diperlukan?

Sementara GIS berada pada tahap awal pengembangan, hanya ada dua cabang kode: master dan rilis. Yang kedua dipisahkan pada tahap stabilisasi untuk melakukan tes regresi akhir dan memperbaiki titik koreksi dari regresi.

Ketika cabang rilis dikirim ke produksi dan iterasi pengembangan berikutnya dimulai, di beberapa titik kami memutuskan untuk memaralelkan pengembangan tugas baru sehingga tugas yang lebih besar yang direncanakan melalui rilis dapat diselesaikan tepat waktu. Pada titik tertentu, ada 3-4 atau lebih cabang seperti itu. Ada lebih dari tiga stan uji yang digunakan dengan tujuan memulai pengujian pengujian rilis di masa depan sesegera mungkin.

Penguji yakin bahwa spesialis infrastruktur diinstal, misalnya, revisi No. 10001 di salah satu dudukan uji, melakukan semuanya dengan benar, dan mereka dapat memulai pengujian. Spesialis infrastruktur melakukan penyebaran dari cabang kode, melaporkan bahwa dudukan dipasang, kode dipasang, dan itu dapat diuji.

Kami memulai tes dan memahami bahwa:

ada kesalahan yang sudah diperbaiki;
fungsi dari blok yang ada berbeda secara signifikan dari fungsi yang sama yang berdiri di bangku tes lain dan sedang mempersiapkan untuk rilis yang direncanakan berikutnya, sementara seharusnya tidak ada modifikasi untuk itu dalam cabang kode yang ditransfer;
kita mulai mendaftarkan cacat, pengembang mengembalikannya, holivar dimulai dalam obrolan desain dan mencari tahu apa yang sebenarnya kita instal dan mengapa tidak apa yang kita harapkan.

Kami melakukan analisis dan menemukan bahwa pengembang tidak memberikan instruksi spesialis infrastruktur dari cabang mana yang akan digunakan, karyawan yang dikumpulkan dari cabang pengembangan, dan pengembang hanya berhasil menggabungkan sebagian kode dari cabang fitur ke cabang pengembangan.

Penguji, yang sama sekali tidak memahami manajemen cabang, mendapatkan tugas dan tautan ke stan, berlari untuk menguji, menghabiskan waktu, mendapat banyak cacat, kebanyakan dari mereka tidak relevan karena semua kebingungan ini.

Apa yang kami lakukan untuk menghindari situasi serupa di masa depan:

pengembang menyiapkan instruksi untuk spesialis infrastruktur yang menunjukkan dari mana akan digunakan penyebaran, instruksi tersebut diteruskan melalui tugas ke jira;
spesialis infrastruktur tidak bingung dan melakukan apa yang diberikan kepadanya;
GIT, , jira ;
jira :
Gitflow , , hotfixes develop, .

, , ?

Kami menyarankan Anda membuat strategi pengujian terlebih dahulu, tetapi karena Anda melewatkan poin ini, pengalaman saya mungkin akan berguna.

Pertama, Anda perlu memahami browser mana yang ditentukan dalam persyaratan. Jika Anda telah memutuskan ini, tetapi sama sekali tidak ada waktu, kami melihat statistik peramban yang paling umum digunakan, misalnya, di sini . Kemudian kami mencoba menjangkau tiga atau lima browser paling populer.

Karena proyeknya besar dan tim pengujiannya besar, secara fisik dimungkinkan untuk mengalokasikan satu peramban populer menurut statistik masing-masing penguji. Dia melakukan kasus regresi pada versi browser khusus, perhatian khusus harus diberikan pada tata letak, klik tombol dan tautan. Proses ini terlihat seperti ini: misalnya, ada 100 skrip untuk tes regresi, tim memiliki 5 penguji, masing-masing dapat mengambil 20 skrip untuk bekerja, masing-masing ditugaskan browser. Untuk satu uji regresi, setiap penguji memeriksa kasus mereka di salah satu browser. Cakupan pada akhirnya tidak lengkap, tetapi karena banyak skenario masih diulang sampai satu derajat atau yang lain, persentase cakupan meningkat karena berlalunya bagian dari skrip regresi oleh browser yang berbeda.

Tentu saja, ini tidak memberikan cakupan pengujian 100% dari semua fungsionalitas, tetapi hal itu memungkinkan untuk secara signifikan mengurangi risiko cacat lintas-browser ke dalam produksi sesuai dengan skenario bisnis utama dalam sistem.

Lebih lanjut, tidak hanya pada regresi, tetapi juga pada pengujian peningkatan dan validasi cacat, kami melakukan pemeriksaan pada browser yang berbeda, memperluas cakupan kompatibilitas lintas-browser.

Di masa depan, mereka mulai menerapkan pendekatan dengan mendistribusikan penguji oleh browser pada uji penyempurnaan, tanpa menunggu tahap pengujian regresi, dengan demikian semakin meningkatkan persentase pengujian yang mencakup berbagai versi browser.

Apa yang kita dapatkan:

biaya pengujian yang dioptimalkan, baik finansial maupun waktu, untuk satu interval waktu kami memeriksa baik uji regresi maupun lintas-browser;
, Severity;
, , .

?

Cukup cepat, kami memiliki pertanyaan tentang menjalankan tes dalam satu repositori, menjaganya agar tetap terbaru dan tentang kemampuan untuk menjalankan uji coba dengan tanda pada hasil eksekusi.

Tim ini melibatkan karyawan yang berpengalaman dengan sistem manajemen pengujian TestLink . Ini adalah satu-satunya sistem manajemen uji kasus sumber terbuka, sehingga dipilih untuk bekerja. Dalam sistem ini, antarmuka dan desain grafis yang sangat sederhana tanpa embel-embel yang tidak perlu. Kami dengan cepat mengisi program dengan tes, muncul pertanyaan tentang bagaimana mempertahankannya. Pada awalnya, banyak sumber daya dihabiskan untuk memperbarui kasus untuk setiap revisi, opsi ini ternyata tidak beroperasi.

Setelah berkonsultasi dengan analis dan tim pengujian, kami memutuskan bahwa tidak perlu selalu memperbarui model pengujian sebesar itu karena biaya dukungannya.

Semua kasus dibagi sesuai dengan matriks persyaratan fungsional ke dalam folder, setiap modul fungsional / subsistem menyimpan satu set kasus dalam folder terpisah. Ini memungkinkan kami untuk menyusun kasus uji secara visual. Kata kunci dibuat di TestLink, dengan bantuan yang kasusnya milik kelompok tertentu, misalnya:

asap - digunakan untuk kasus uji yang termasuk dalam uji asap ( melakukan serangkaian tes minimum untuk mendeteksi cacat fungsi kritis yang jelas );
tes otomatis - digunakan untuk kasus uji yang dikembangkan autotest;
Prioritas 1 - digunakan untuk kasus uji yang berkaitan dengan fungsi bisnis berlabel Prioritas 1.

Akibatnya, desain pengujian selalu dirancang untuk peningkatan baru, akibatnya muncul dokumen daftar periksa. Di dalamnya, pemeriksaan diprioritaskan, dan hanya sebagian cek yang berada di bawah "Prioritas 1" atau kasus uji asap dan regresi telah dibuat pada mereka dalam sistem TestLink.

Bagaimana selalu memiliki model kasus regresi aktual untuk rilis yang direncanakan dan HotFix tiba-tiba pada produksi?

Sebelum dimulainya tes regresi, semua pekerjaan persiapan, termasuk memperbarui atau menambahkan kasus baru ke regresi, telah selesai. Dan ini berarti bahwa jika Anda menjalankan uji coba yang relevan untuk rilis baru, mereka dapat menyebabkan cacat saat memeriksa HotFix pada uji kasus tersebut.

Koreksi HotFix dilakukan pada kode cabang lama (rilis terakhir) dan perubahan dilakukan pada kode dengan perbaikan cacat, sementara kasus uji saat ini dapat dimodifikasi dari perbaikan rilis yang akan datang. Artinya, menjalankan uji kasus yang relevan untuk rilis di masa mendatang dapat menyebabkan pendaftaran cacat palsu dan menunda rilis HotFix.

Untuk menghindari pendaftaran cacat palsu dan gangguan tenggat waktu pengujian HotFix, kami memutuskan untuk menggunakan mekanisme yang agak mirip dengan mempertahankan cabang kode. Hanya menggabungkan dan memperbarui kasus antar cabang (baca “folder”) dari TestLink dilakukan secara manual oleh penguji sesuai dengan algoritma tertentu, sedangkan dalam model Gitflow ini dilakukan secara otomatis oleh Git.

Berikut adalah satu set kasus uji dalam TestLink:

Proses memperbarui kasus di TestLink diciptakan

Manajer tes menyalin folder dengan case "Test Project 1.0.0" dan membuat suite pengujian baru, yang diberi nama nomor rilis yang direncanakan berikutnya. Ternyata folder dengan kasus "Proyek uji 2.0.0."
Setelah mempelajari perbaikan untuk rilis di masa mendatang, uji kasus dari folder "Proyek Uji 2.0.0" dianalisis untuk kebutuhan memperbarui mereka untuk perbaikan baru.

Jika perlu, perbarui kasus:

tester yang bertanggung jawab untuk revisi membuat perubahan pada test case di set "Test project 2.0.0";
jika Anda perlu menghapus suatu test case, pertama Anda perlu memindahkannya ke folder "Delete", ini dilakukan untuk dapat memulihkan beberapa test case yang tidak sengaja terhapus atau jika persyaratan dikembalikan dan case test kembali diminati (test) case hanya dari folder yang sesuai dengan test suite dari rilis yang direncanakan di masa depan, di mana test case ini tidak akan relevan);
jika kita menambahkan test case, maka ini perlu dilakukan hanya dalam folder yang sesuai dengan test suite dari rilis yang direncanakan di masa depan;
uji kasus yang berubah ditandai dengan kata kunci "Dimodifikasi" (diperlukan untuk mengevaluasi metrik tingkat pengaruh peningkatan pada fungsional regresi);
case yang ditambahkan ditandai dengan kata kunci “Added” (diperlukan untuk mengevaluasi metrik dengan efek perbaikan pada fungsi regresi).

Dengan demikian, kami selalu memiliki rangkaian uji kasus yang sesuai dengan versi rilis sistem sebelumnya dan menggunakannya untuk tes HotFix, serta bekerja untuk memperbarui rangkaian uji baru, mempersiapkan pengujian regresi dan proses menstabilkan rilis yang direncanakan baru. Pada titik tertentu, pada saat yang sama, 3-4 cabang uji (baca “folder”) dari TestLink, yang berkaitan dengan berbagai versi sistem, dapat diperoleh sekaligus, yang sangat penting saat menguji peningkatan di cabang-cabang fitur.

Setelah setiap rilis, kami dapat memperkirakan berapa banyak model regresi kami telah berubah, berdasarkan label "ditambahkan" / "diubah".

Jika model regresi meningkat sangat banyak, sementara volume perbaikan dalam rilis tidak berubah secara signifikan dibandingkan dengan rilis sebelumnya, maka ini adalah kesempatan untuk berpikir tentang kebenaran pengaturan prioritas dalam daftar periksa pemeriksaan revisi. Mungkin tester membuat pilihan kasus yang salah untuk regresi dan perlu mengambil langkah-langkah: misalnya, menjelaskan kepada tester prinsip memprioritaskan, melibatkan analis dalam mengoordinasikan prioritas, mengubah model regresi yang dihasilkan dengan menghapus kasus uji yang berlebihan.

Bagaimana model uji regresi dioptimalkan?

Kami mulai bekerja dengan model uji regresi, mengoptimalkan proses pengembangan uji kasus regresi dengan menyoroti prioritas dan hanya memasukkan kasus "Prioritas 1" dalam regresi. Dihadapkan pada kenyataan bahwa model pengujian, setelah beberapa saat, menjadi besar, biaya menjalankan kasusnya meningkat, dan kami berhenti jatuh ke dalam interval waktu yang dapat diterima untuk melakukan uji regresi pada proyek.

Waktunya telah tiba untuk mengimplementasikan otomatisasi pengujian, yang tujuannya adalah:

mengurangi waktu untuk menyelesaikan kasus uji regresi;
menggunakan uji otomatis untuk membuat prasyarat untuk melakukan pemeriksaan selanjutnya, sehingga mengoptimalkan waktu dan biaya manusia untuk membuat data uji;
untuk meningkatkan kualitas pengujian regresi dengan menghilangkan pengaruh faktor manusia pada hasil tes manual;
, .

Kerangka kerja dikembangkan untuk mengotomatisasi tes GUI di Jawa (GIT digunakan sebagai sistem versi kontrol sumber).

Tim pengujian otomatis terpisah terlibat dalam pengembangan autotest, yang berhasil mengatasi tugas tersebut. Untuk proyek masa depan dengan skala yang sama, di masa depan direncanakan untuk menerapkan perkembangan yang ada dan meluncurkan pengujian otomatis pada awal proyek untuk mendapatkan manfaat dari penggunaannya sesegera mungkin. Anda dapat membaca lebih lanjut tentang otomatisasi pengujian SIG besar dalam sebuah artikel oleh kolega saya yang terlibat langsung dalam pengorganisasian dan melakukan pengujian otomatis.

Pada bagian pengujian manual fungsional, model regresi juga dioptimalkan.

Dengan menggunakan dua SIG besar sebagai contoh, tim dan saya membuat dan menerapkan sesi pengujian atau tes wisata, yang intinya adalah sebagai berikut: perlu untuk menganalisis proses bisnis di setiap subsistem dan memikirkan sesi (tur) cek yang melewati proses bisnis ini, paling banyak mensimulasikan Tindakan pengguna yang sering dilakukan pada proses.

Pada satu proyek GIS ini disebut "sesi tes", yang lain disebut "tes tur". Tetapi esensinya tetap sama - kami memikirkan skenario bisnis utama end-to-end (melalui seluruh revisi) yang sepenuhnya mencakup ide bisnis dari revisi yang diterapkan (mungkin ada beberapa skenario seperti itu).

Skenario dari tes tur disetujui dengan analis, kasus uji regresi rinci dikembangkan dan, dalam kasus di mana mereka tidak berhasil melakukan uji regresi pada seluruh model uji, mereka dapat membatasi diri untuk melakukan "sesi regresi" atau "tes wisata", yang, sebagai aturan, mengambil lebih sedikit waktu dan memungkinkan untuk memahami dengan jelas apakah ada masalah dengan proses bisnis utama dalam sistem.

Di masa depan, tes tur dicakup oleh tes otomatis, dan penguji dibebaskan dari pemeriksaan rutin beralih ke pengujian peningkatan rilis yang direncanakan berikutnya.
Contoh tur uji: "membuat, mengedit, menerbitkan, dan membatalkan entitas".

Tes tur bisa rumit, misalnya:

memberikan hak untuk membuat, mengedit, dan membatalkan,
buat entitas di "Akun Pribadi" pengguna dengan peran "Spesialis",
,
,
,
« » «»,
, .

SLA?

Saya merekomendasikan untuk tidak memperlakukan proses pelokalan insiden dari pengguna sebagai tugas tingkat rendah. Anda harus mengambil ini sebagai bagian dari proses pengujian. Selain itu, ini adalah proses yang jauh lebih kreatif daripada, misalnya, memeriksa kasus uji. Hal ini diperlukan untuk menerapkan logika, pengalaman teknisi desain uji, untuk sampai ke dasar kesalahan, untuk menangkapnya dan meneruskannya ke dalam pengembangan.

Tentu saja, diinginkan untuk mengatur proses operasi GIS dengan tiga tingkat dukungan (idealnya) dan, sebagai akibatnya, insiden paling tidak jelas yang sering dilokalisasi oleh penguji hanya akan gagal pada tim pengujian, yang sudah disaring pada dua baris pertama.

Untuk mematuhi SLA, kami sarankanmenjadikan proses pelokalan insiden sebagai tugas dalam tim pengujian dengan prioritas tertinggi dan mencoba memperkenalkan metode pengoptimalan sehingga kecepatan pemutaran insiden setinggi mungkin.

Untuk mengoptimalkan waktu yang dihabiskan oleh penguji, Anda dapat:

memelihara basis pengetahuan proyek dengan pertanyaan SQL yang khas atau sering ditemui;
mengatur proses pemeringkatan tugas yang masuk dalam bugtracker sehingga pada panel indikator penguji segera melihat insiden yang jatuh dan membawanya untuk bekerja dalam prioritas pertama;
tambahkan penghitung waktu hitung mundur di JIRA untuk tugas yang memiliki SLA;
mengatur sistem peringatan untuk insiden;
production ( — ), , , , , , production;
« » « ». .

Tentang "matriks pengetahuan" ditulis di atas. Adapun "matriks tanggung jawab", ini adalah tabel di mana, dengan analogi dengan "matriks pengetahuan", blok fungsional / modul / subsistem ditulis dan siapa dari kelompok pengujian yang bertanggung jawab untuk menguji fungsional, sebagai aturan, ini adalah pemimpin tim atau senior / lead tester dalam sebuah grup.

Bagaimana jika tester dari satu blok fungsional / modul / subsistem tidak memahami keseluruhan gambaran proses bisnis pada proyek?

Ini adalah pokok bahasan yang kami temui di beberapa proyek SIG besar. Tim membuat "matriks pengetahuan", penguji melakukan penilaian diri sendiri dari tingkat perendaman dalam fungsional dan menugaskan diri mereka sendiri untuk sepotong fungsionalitas mereka. Tetapi pada titik tertentu, penguji berpengalaman yang berpartisipasi dari awal proyek keluar dari grup, dan spesialis baru belum tenggelam dalam semua proses bisnis dan tidak melihat gambaran lengkap. Ini mengarah pada fakta bahwa ketika menguji kasus dalam satu modul, hasil dari kasus ini seharusnya telah digunakan dalam modul berikutnya, dan sebagai hasilnya, jika hasil yang salah diberikan ke input dari modul kedua (prasyarat tidak ideal untuk membawa kasus dari modul sebelumnya), maka perlu untuk menganalisis situasi dan mencatat kesalahan.

Tetapi para penguji tidak memikirkan mengapa angka-angka seperti itu masuk ke input mereka dan hanya menyelesaikan kasus mereka. Secara formal, tes dilakukan, semuanya baik-baik saja, tidak ada cacat yang ditemukan, dan ketika analis menerima fungsional atau ketika mempersiapkan tes penerimaan, masalah signifikan dalam pekerjaan logika bisnis yang tidak terjawab pada tes diklarifikasi. Alasannya adalah kurangnya pemahaman tentang proses bisnis end-to-end yang dilakukan oleh sistem.

Dalam situasi ini, berikut ini dilakukan:

terbenam dalam fungsional dengan keterlibatan analis;
pelatihan dilakukan dalam kelompok pengujian, pertukaran pengalaman, cerita di demonstrasi tentang subsistemnya dan apa yang terjadi di dalamnya, diskusi tentang perbaikan baru yang direncanakan untuk subsistem dalam rilis yang direncanakan berikutnya;
menarik analis dan memperkenalkan templat informasi ke dalam spesifikasi spesifikasi tentang tingkat dampak peningkatan pada modul / subsistem pihak ketiga;
implementasi proses pengujian untuk sesi pengujian (tur), yang merupakan penguji dan mengoordinasikannya dengan analis (membantu mengurangi risiko salah paham proses bisnis oleh tim dan jumlah kesalahan bisnis dalam sistem).

Fuh! Saya mencoba mengumpulkan masalah utama dan rekomendasi untuk menghilangkannya, tetapi ini jauh dari semua informasi berguna yang ingin saya bagikan.

Bab 4. Metrik untuk menentukan kualitas proyek dan metodologi untuk menilai biaya tenaga kerja untuk pengujian

Sebelum memperkenalkan kumpulan metrik pada proyek, kami bertanya pada diri sendiri: "Mengapa kita harus melakukan ini?" Tujuan utama adalah untuk memantau kualitas tim pengujian, kualitas rilis yang diproduksi dalam produksi, dan memantau indikator kinerja peserta kelompok pengujian untuk memahami bagaimana mengembangkan tim.

Analisis dilakukan yang metrik yang diperlukan untuk mencapai tujuan. Kemudian mereka dibagi menjadi beberapa kelompok. Kemudian mereka memikirkan apa yang dapat diukur tanpa perubahan tambahan dalam proses, dan di mana bantuan dari anggota tim proyek lain akan dibutuhkan.

Ketika semua tahap persiapan selesai, perakitan metrik reguler dimulai: sebulan sekali / rilis / sprint / seperempat - tergantung pada proyek dan karakteristik proses produksi.

Setelah mengumpulkan metrik pertama, penting untuk menentukan indikator target yang ingin kami perjuangkan pada tahap pengembangan proyek ini. Selanjutnya, tetap untuk secara teratur mengambil metrik dan menganalisis alasan penyimpangan mereka dari indikator target, mengambil langkah-langkah yang bertujuan untuk meningkatkan indikator, yaitu, untuk mengoptimalkan tidak hanya proses pengujian, tetapi seluruh proses produksi pada proyek.

Tentu saja, tidak hanya penguji yang terlibat dalam meningkatkan kualitas, analis dan manajer pengembangan dan pelepasan juga terlibat dalam mengoptimalkan proses, para insinyur DevOps adalah semua peserta utama dalam proses tersebut, karena semua orang ingin meningkatkan kualitas rilis dan meningkatkan pekerjaan mereka.

Contoh bagaimana kumpulan metrik dan target pada salah satu proyek yang sudah selesai terlihat seperti:

Metodologi untuk menilai biaya tenaga kerja untuk pengujian

Untuk memberi tahu manajer proyek tentang tenggat waktu yang lebih akurat untuk menyelesaikan pengujian, berdasarkan pada pengumpulan metrik dari proyek serupa, metodologi dikembangkan untuk mengevaluasi upaya pengujian, yang memungkinkan pelaporan paling akurat dari waktu penyelesaian pengujian dan memberi tahu tentang risiko pengujian.

Teknik ini digunakan pada semua proyek implementasi SIG, perbedaannya hanya bisa dalam beberapa nilai metrik, tetapi prinsip perhitungannya sama.

Metrik yang digunakan untuk melakukan penilaian terperinci atas biaya pengujian

Metrik waktu diperoleh dengan pengukuran berulang dari biaya aktual penguji dari berbagai tingkat kompetensi pada proyek yang berbeda, rata-rata aritmatika diambil.

Waktu untuk mendaftar kesalahan adalah 10 menit (waktu untuk mendaftar 1 kesalahan dalam pelacak bug).
Waktu untuk memvalidasi kesalahan / perbaikan adalah 15 menit (waktu untuk memverifikasi kebenaran koreksi 1 kesalahan / perbaikan).
Waktu untuk menulis 1 TC (test case) - 20 menit (waktu untuk mengembangkan case test dalam sistem TestLink).
Waktu untuk menyelesaikan 1 TC - 15 menit (waktu untuk menyelesaikan pemeriksaan kasus uji dalam sistem TestLink).
Saatnya ujian. Total waktu yang diperoleh dengan menambahkan biaya dalam Daftar Periksa untuk kolom "Lead time, min."
Waktu Laporan Uji - 20 menit (waktu untuk menulis laporan sesuai dengan templat).
Waktunya untuk kesalahan . Waktu yang direncanakan untuk pendaftaran semua kesalahan / klarifikasi, (waktu untuk pendaftaran 1 kesalahan / klarifikasi * kemungkinan jumlah kesalahan / klarifikasi (10 kesalahan untuk revisi - perkiraan jumlah kesalahan per revisi)).
Total waktu dalam DV (validasi cacat) . Waktu yang direncanakan untuk validasi semua kesalahan / perbaikan yang ditemukan dan diperbaiki (waktu untuk validasi 1 kesalahan / perbaikan * perkiraan jumlah kesalahan / perbaikan).
Tes persiapan data. Waktu untuk menyiapkan data pengujian dihitung secara subyektif berdasarkan pengalaman pengujian tugas serupa pada proyek saat ini tergantung pada parameter yang berbeda (ruang lingkup tugas dari sudut pandang analis Uji, kompetensi tim pengembangan kode (tim tidak dikenal baru atau tim terbukti yang memiliki statistik pada kualitas pekerjaan) , integrasi antara berbagai modul, dll.).

Dengan mengukur biaya aktual dari salah satu proyek, berikut ini dihitung:

tidak lebih dari 1 jam per tugas hingga 60 jam pengembangan,
tidak lebih dari 3 jam per tugas hingga 150 jam pengembangan,
tidak lebih dari 4 jam per tugas hingga 300 jam pengembangan.

Dalam kasus khusus, biaya yang direncanakan untuk persiapan data uji dapat berubah sesuai dengan manajer pengujian.

Saatnya menulis TC . Waktu untuk menulis TC, yang diperkirakan setelah daftar periksa siap untuk diperiksa dan diprioritaskan untuk pengujian. Untuk uji regresi, TC ditandai dengan Prioritas 0 (jumlah pemeriksaan Prioritas 0 * 20 menit (waktu penulisan untuk 1 TC)).
Waktu untuk mundur sesuai dengan TC. Waktu untuk menyelesaikan satu iterasi pengujian regresi menurut TC dalam sistem TestLink (jumlah TC * waktu eksekusi rata-rata 1 TC (15 menit)).
Risiko 15% dari waktu untuk tes diletakkan (risiko berarti semua operasi manual, berdiri jatuh, masalah memblokir, dll).
Total waktu untuk pengujian.Total biaya pengujian untuk satu HL (persiapan data uji + pelaksanaan pengujian + waktu untuk mendaftar kesalahan / klarifikasi + validasi kesalahan / penyempurnaan + waktu untuk mundur sesuai dengan Prioritas TC 0 + risiko) dalam jam / jam.
Total waktu untuk tugas. Total biaya untuk seluruh tugas pengujian, dalam h / h (Total waktu untuk pengujian + waktu untuk laporan + waktu untuk menulis TC).

Semua metrik ini digunakan pada proyek untuk menyelesaikan berbagai tugas yang berkaitan dengan perencanaan, evaluasi kerja, baik sementara dan keuangan. Seperti yang telah ditunjukkan oleh praktik, perkiraan tersebut memberikan kesalahan minimum (tidak lebih dari 10%), yang merupakan indikator keandalan estimasi yang cukup tinggi.

Tentu saja, Anda tidak boleh menggunakan metrik atau metrik apa pun menurut statistik dapat sangat berbeda, tetapi prinsip memperkirakan biaya pekerjaan pengujian dapat diterapkan pada proyek apa pun dan memilih rumus perhitungan paling optimal untuk proyek dan tim Anda.

Bab 5. Resep untuk Proses Pengujian GIS yang Berhasil

Penting untuk menunjukkan kepada manajer pengujian dan penguji bahwa ketika dihadapkan dengan kesulitan dan tugas-tugas baru, Anda dapat menemukan solusi, mengoptimalkan proses pengujian dan mencoba menerapkan akumulasi pengalaman untuk proyek-proyek masa depan.

Saya menyiapkan kejutan untuk semua pembaca - resep untuk proses pengujian GIS yang sukses dan templat dokumen yang dapat Anda unduh dan gunakan pada proyek Anda.
Jadi, resep tentang bagaimana membuat proses pengujian sistem informasi yang besar berhasil, dan apa yang kami sarankan untuk dimasukkan dalam proses ini, saya akan mencoba untuk menyatakannya secara singkat dan singkat.

Dari proses analisis:

Menerapkan templat persyaratan teknis
menerapkan aturan untuk pengembangan persyaratan teknis dalam sekelompok analis;
untuk mengembangkan peraturan tentang pemberitahuan kesiapan persyaratan teknis tim proyek.

- ;
;
;
:

○ - ;
○ -;
○ ;
, , , , , ;
, , , , ;
;
;
;
;
(, , ..);
, , ;
gunakan rekomendasi dari kolega yang lebih berpengalaman, pengembangan dari proyek lain, lembar contekan siap pakai , melakukan sesi curah pendapat dengan tim dan mencari metode baru untuk mengoptimalkan dan meningkatkan proses.

Sekarang saya sedang bersiap-siap untuk menguji GIS baru. Ini adalah apa yang tampak seperti Wiki saya, yang sudah memperhitungkan banyak hal yang kami rekomendasikan untuk dilakukan:

Kejutan bagi pembaca yang sabar.

Jika Anda membaca artikel sampai akhir, Anda layak mendapatkan hadiah. Saya ingin berbagi dengan Anda templat bermanfaat yang dapat Anda gunakan dalam pekerjaan Anda:

templat daftar periksa , yang mencakup sekumpulan rekomendasi minimum untuk menguji elemen antarmuka bentuk layar (tentu saja, ada opsi yang lebih luas untuk pemeriksaan, ini hanya sebuah contoh), termasuk formula untuk menghitung biaya pengujian dengan penjelasan metode perhitungan;
templat laporan pengujian ;
template matriks : pengetahuan / distribusi oleh browser / platform / jadwal liburan dari tim proyek;
Daftar metrik utama untuk proyek dengan penjelasan.

Saya berharap rekomendasi, contoh, ide, tautan, dan templat kami akan membantu banyak tim secara kompeten membangun proses pengujian, mengoptimalkan biaya mereka, dan berhasil mengatasi tugas-tugas dalam proyek yang bertanggung jawab dan kompleks.

Jika Anda ingin bergabung dengan tim pengujian LANIT dan berpartisipasi dalam pengujian GIS, saya menyarankan Anda untuk melihat lowongan di perusahaan kami.

Datanglah ke Sekolah Pengujian kami!

, , .

Saya berharap Anda semua proyek menarik dan semoga berhasil!

PS Sangat memohon untuk melakukan survei kecil.

Apa yang kami pelajari dari pengujian sistem informasi negara