Test Maturity Model: bagaimana tester dapat mengevaluasi suatu proyek dan merencanakan proses

Hai Nama saya Misha dan saya Senior QA dengan pengalaman komersial lebih dari 6 tahun. Sekarang saya bekerja di Provectus, tetapi saya memulai jalur penguji saya sebagai siswa ketika saya mengambil bagian dalam tes alfa dan beta dari berbagai permainan. Pada titik tertentu saya berpikir: "Mengapa tidak mulai melakukan ini secara profesional?" Dan kita berangkat. Selama waktu ini saya berhasil berpartisipasi dalam berbagai proyek: mulai dari awal hingga perusahaan, dari game unit pendidikan kecil hingga aplikasi besar dengan logika bisnis yang kuat.

Tapi sering saya diperkenalkan ke tim kecil, di mana ada dari 5 pengembang untuk 1-2 penguji dan, sebagai aturan, ada banyak panas dalam proyek ini. Sebenarnya, saya ingin berbagi dengan Anda bagaimana belajar memahami di mana Anda berada dan bagaimana untuk mulai maju dalam perumusan proses QA.

Pertama-tama, Anda harus memahami proyek yang sedang Anda jalani.

Setelah mendapatkan pengalaman dari berpartisipasi dalam proyek, saya secara kondisional akan membaginya menjadi 3 jenis:

• proyek tanpa pengujian;
• proyek dengan pengujian yang tidak adil;
• proyek pengujian.

Pada saat keterlibatan saya, masing-masing dari mereka berada pada tahap perkembangan. Saya mulai mengamati situasi ini dan mulai mengembangkan visi saya - bagaimana mempromosikan proses pengujian pada mereka. Setelah beberapa waktu, saya menemukan Model Maturity, dan dia berbaring satu-satu di atas landasan saya. Ini memperkuat keyakinan saya bahwa ini adalah tempatnya.

Apa itu Model Kematangan

Dan di sini saya secara cerdik memasukkan kutipan dari Wikipedia :

Capability Maturity Model Integration (CMMI) - serangkaian model (metodologi) untuk meningkatkan proses dalam organisasi dengan berbagai ukuran dan kegiatan. CMMI berisi serangkaian rekomendasi dalam bentuk praktik, yang implementasinya, menurut para pengembang model, memungkinkan Anda untuk mewujudkan tujuan yang diperlukan untuk implementasi penuh bidang kegiatan tertentu.

Singkatnya dan sederhana, ini adalah seperangkat model yang menunjukkan seberapa baik proses yang terorganisir dalam organisasi sesuai dengan kriteria tertentu. Dengan penilaian seperti itu, orang dapat dengan tenang menilai apakah layak memberikan satu atau lain perintah kepada kontraktor tertentu.

Sebenarnya, dari sinilah perkembangan Model Kematangan dimulai. Pada tahun 80-an, Departemen Pertahanan AS menyadari bahwa ia tidak dapat secara akurat menilai kualitas pekerjaan kontraktor pengembangan perangkat lunak. Dan karena struktur pemerintahan ini juga setingkat itu, ini tidak dapat diterima. Uang itu milik negara, tenggat waktu jelas digambarkan, dan perangkat lunak senjata yang andal akan memungkinkan setiap orang tidur lebih damai. Berdasarkan hal ini, Kementerian menginstruksikan Institut Rekayasa Perangkat Lunak untuk membuat sistem penilaian dan setahun kemudian kuesioner pertama dibuat, dan 4 tahun kemudian versi pertama model dibuat.

Level Model Kematangan

Ini adalah 5 level, di mana pekerjaan / keandalan / stabilitas perusahaan dievaluasi.

Di mana dalam Maturity Model sedang diuji

Untuk penguji ada MM khusus, itu disebut TMMi. Ini juga berisi 5 level, di mana saya ingin tinggal lebih detail dan mempertimbangkan apa yang khas untuk masing-masing.

Level pertama adalah "Pemula"

Pada tingkat pertama, pengujian tidak terstruktur dan kacau. Tidak ada lingkungan yang stabil untuk mendukung proses pengujian. Tim tidak memperhatikan perencanaan dan standar.

Tujuan utamanya adalah mengantarkan produk tepat waktu tanpa masalah kritis, karena pengujian hanya digunakan di sini untuk menunjukkan bahwa aplikasi berfungsi tanpa gangguan serius. Seringkali keberhasilan proyek semacam itu semata-mata bergantung pada kepahlawanan dan keterampilan individu, dan bukannya proses yang telah ditetapkan.

Sebagai hasilnya:

• tidak ada dokumentasi tes;
• produk tidak stabil;
• penolakan proses selama situasi masalah;
• pengujian tidak lebih dari bantuan debugging.

Tingkat kedua - "Berulang"

Pada level kedua, pengujian menjadi proses yang terkontrol. Disiplin dan kemajuan dibuat memastikan bahwa praktik-praktik ini dipertahankan selama stres. Pengujian masih dianggap sebagai aktivitas yang mengikuti pengembangan. Rencana pengujian dikembangkan dan diimplementasikan, dengan bantuan yang dengan jelas menentukan jenis pengujian apa yang diperlukan, kapan dan oleh siapa.

Tujuan utamanya adalah untuk memastikan bahwa produk tersebut memenuhi persyaratan yang ditentukan.

Sebagai hasilnya:

• ada jenis dan tipe pengujian utama (integrasi, modular, regresi, penerimaan);
• rencana uji diimplementasikan;
• kegiatan pengujian dimonitor dan dikendalikan;
• prosesnya didokumentasikan dan dapat diulang.

Tingkat ketiga - "Didefinisikan"

Pada level ketiga, pengujian tidak lagi dianggap sebagai aktivitas setelah pemrograman. Pengujian sepenuhnya terintegrasi ke dalam proyek. Perencanaan tes dilakukan pada tahap sebelumnya dan ditetapkan dalam rencana induk. Pengujian non-fungsional (mis. Kegunaan) sedang diperkenalkan.

Sebagai hasilnya:

• pengujian dimulai dengan fase persyaratan;
• ditambahkan kegiatan yang memungkinkan Anda bekerja lebih efisien (pelatihan internal, ulasan tambahan);
• pengujian non-fungsional sedang diperkenalkan.

Tingkat Keempat - “Terukur”

Pada tingkat keempat, pengujian adalah proses yang didefinisikan dengan baik, mapan dan terukur. Pengujian dianggap sebagai penilaian dan terdiri dari semua operasi siklus hidup pengembangan perangkat lunak. Praktik mengukur kualitas pengujian sedang diperkenalkan. Pengukuran ini digunakan untuk memprediksi kinerja dan biaya pengujian.

Sebagai hasilnya:

• pengujian sebagai proses yang terukur;
• pengukuran digunakan untuk peramalan;
• tim sedang mencari cara untuk membuat proses pengujian lebih efisien.

Tingkat kelima - "Inovatif"

Pada tingkat kelima, semua pendekatan dan proses telah ditetapkan dengan baik. Tim tidak berhenti pada tahap ini, tetapi terus meningkatkan proses secara sistematis, terus-menerus berusaha mengurangi waktu siklus pengujian dan waktu-ke-pasar tanpa mengurangi kualitas proyek. Pengujian berfokus pada pencegahan. Otomasi ditambahkan untuk penggunaan sumber daya yang lebih efisien.

Sebagai hasilnya:

• perbaikan proses yang berkelanjutan;
• fokus pada pencegahan dan optimalisasi.

Bagaimana pengetahuan tentang struktur ini membantu

Kasus No. 1. Pengujian tidak adil

Suatu ketika saya sampai di sebuah proyek kecil tempat pengujian dilakukan oleh seorang pelanggan, teman-temannya, atau seekor kucing. Setelah menilai situasi dan melihat modelnya, kita dapat memahami bahwa kita berada di level 1 dan bahwa kita harus fokus pada level 2 selama perencanaan kegiatan. Setelah membereskan Jira, di mana ada sejumlah besar bug (sebagian besar merupakan duplikat atau tidak dapat direproduksi), saya mulai menyusun dokumentasi uji dalam bentuk daftar periksa dan mengatur proses pengujian dasar. Seperti pengujian regresi dan pemeriksaan kewarasan selama perubahan besar.

Kasus No. 2. Tanpa pengujian

Menurut pendapat saya, proyek jenis ini dapat dalam tiga kasus:

• proyek baru saja dimulai;
• tidak perlu penguji pada proyek sementara ada sedikit fungsi;
• Tim tumpukan penuh menutup kekurangan penguji dengan ulasan kode kualitas dan pengujian dev.

Sekali dalam salah satu proyek ini, Anda sering dapat melihat manfaat dari fakta bahwa itu adalah pada level nol rahasia. Kita dapat melompati level pertama dan segera melakukan semuanya secara kualitatif dengan perasaan, perasaan, pengaturan yang baik, dipandu oleh tujuan-tujuan yang kedua. Seringkali kita dapat mengimplementasikan rencana pengujian, dengan dasar semua jenis pengujian yang diperlukan akan dilakukan. Anda dapat segera mengidentifikasi alur kerja yang sama dengan tim pengembangan, yang hilang pada proyek dari kasus pertama.

Kasus No. 3. Pengujian sebelumnya

Sebenarnya, kasus paling langka: seorang pria, karena peristiwa tertentu, memutuskan untuk mengubah tim / departemen / pekerjaannya dan memberi Anda idenya sendiri. Dalam situasi ini, Anda sudah memiliki sistem interaksi yang mapan dengan pengembang, basis dokumentasi uji tertentu. Jalur pengembangan lebih lanjut dapat mencakup meningkatkan proses yang telah ditetapkan, atau pindah ke tingkat ketiga - memperkenalkan pengujian pada tahap sebelumnya atau menambahkan pengujian non-fungsional.

Kasus nomor 4. Tiga dalam satu

Ketika saya datang ke proyek saya di Provectus, saya dihadapkan dengan situasi di mana hanya ada sedikit dari tiga kasus yang dijelaskan di atas. Seperti dalam kasus No. 1, hal pertama yang harus dilakukan adalah menertibkan Jira. Seperti dalam kasus kedua, diputuskan untuk segera melakukan semuanya dengan kualitas tinggi agar dapat segera dipandu oleh tingkat kedua. Oleh karena itu, saya segera mulai mengembangkan dokumentasi pengujian dan mengimplementasikan alat manajemen pengujian. Saya juga mencoba memeras yang paling banyak dari artefak iterasi masa lalu, seperti halnya pada kasus ketiga.

Setelah waktu yang sangat singkat, saya dapat dengan aman mengatakan bahwa kami telah dengan sengaja menuju ke tingkat ketiga - bahkan pengujian yang terhubung pada tahap persyaratan bisnis :)

Kesimpulan

Dalam pengalaman saya, sebagian besar proyek Ukraina, serta proyek yang tidak dirancang untuk waktu yang lama, dapat berhasil dibawa ke Go live di level 3. Tetapi jika Anda memiliki proyek jangka panjang, kemungkinan untuk memperbaikinya tidak terbatas dan Anda dapat dipandu dengan aman oleh pencapaian level tertinggi.

Sebagai kesimpulan, saya ingin mengatakan bahwa tujuan dari artikel ini adalah untuk menunjukkan tidak begitu banyak cara bekerja dengan MM atau TMM klasik itu sendiri, tetapi dengan bantuannya Anda dapat dengan jelas memahami pada tahap apa proyek Anda terlibat, dan gerakan mana yang harus dilakukan dan mana yang tidak sepadan. Selain itu, dengan mengambil prinsip-prinsipnya sebagai dasar, Anda dapat membuat model Anda sendiri, yang dapat diterapkan tidak hanya dalam pengembangan, tetapi juga di berbagai bidang kehidupan. Dan yang paling penting - ini diuji dan bekerja :)