Anda tentu dapat melakukannya tanpa strategi pengujian jika Anda memiliki jumlah karyawan yang memenuhi syarat, waktu dan uang yang tak terbatas. Singkatnya, kemampuan untuk memotong satu rilis selama bertahun-tahun. Dalam kondisi ideal hipotetis seperti itu, tidak ada strategi yang diperlukan, karena Anda dapat menguji produk Anda dalam semua cara yang ada selama Anda suka, menerapkan teknik dalam urutan apa pun, untuk beberapa lingkaran, dan cepat atau lambat dalam beberapa cara Anda akan datang ke kualitas siap produksi.

Pada kenyataannya, proyek selalu memenuhi tenggat waktu, kemampuan / keterampilan kerja tim bukan karet, dan persyaratan produk terus berkembang - dan di sini Anda tidak dapat melakukannya tanpa rencana yang baik. Karena itu, strategi pengujian datang untuk menyelamatkan.

Dalam artikel ini, kami akan menawarkan pertanyaan yang perlu dibahas untuk menyusun strategi pengujian, dan menunjukkan dengan contoh bagaimana keputusan dibuat tentang alat pengujian dalam kasus tertentu.

0. Mari kita cari tahu di pantai

Mengapa kita membutuhkan strategi pengujian?

• Untuk mengatur proses dalam kondisi sumber daya terbatas. Karena itu, untuk memulai, alangkah baiknya untuk merealisasikan sumber daya yang kita miliki.
• Agar semua peserta proyek memahami peran pengujian, apa yang dapat diberikannya, keuntungan apa yang akan kita dapatkan dari ini. Sehingga setiap orang memiliki harapan dan pemahaman yang sama tentang apa yang terjadi di bidang kontrol kualitas. Dan juga untuk mengidentifikasi kemungkinan masalah yang mau tidak mau akan menjadi jelas dalam proses diskusi.

Siapa yang menyusun strategi?

Pertama-tama, tentu saja, QA dan manajer proyek.

Jadi, ambil penguji proyek manajer atau penguji penguji, tuangkan kopi, ambil kertas, spidol, laptop, dan ... ayo pergi!

1. Jenis pengujian apa yang akan kita gunakan pada proyek dan mengapa

Pada awalnya, kami menawarkan untuk mengingat semua jenis pengujian yang ada dan memutuskan masing-masing: apakah kami akan menggunakannya dan mengapa. Mari kita lihat beberapa contoh bagaimana Anda dapat memutuskan kebutuhan untuk jenis pengujian tertentu.

Instalasi Versi Pengujian

Bagaimanapun, bahkan jika aplikasi tersebut benar-benar baru dan sedang diinstal (dikerahkan) untuk pertama kalinya, Anda perlu memeriksa bagaimana itu lepas: apakah itu dimulai, apakah mungkin untuk mulai bekerja dengannya. Baik itu aplikasi seluler, desktop, atau web.

Untuk aplikasi web, akan bermanfaat untuk membahas bagaimana kami memverifikasi bahwa data setelah pembaruan tidak hilang. Perilaku seperti apa yang kita harapkan dari sesi aktif.

Untuk aplikasi desktop dan seluler, Anda perlu memikirkan cara untuk mengirimkan distribusi baru kepada pengguna dan proses pembaruan, yang diluncurkan oleh pengguna.

Untuk semua proyek, penting untuk mendiskusikan hal-hal seperti pemanasan sistem: menginstal direktori, mengatur pengguna dan data lain yang diperlukan pengguna untuk memulai dengan sistem.

Pengujian kinerja

Faktor-faktor seperti itu akan mempengaruhi keputusan: berapa banyak pengguna akan bekerja dalam sistem, berapa banyak data yang akan diproses.

Diberikan	Solusi
Kita tahu bahwa 10 orang akan menggunakan produk. Dan kita tahu bahwa mereka akan menyerahkan tabel beberapa ribu catatan.	Masuk akal untuk merencanakan pengujian volume dengan sejumlah besar data.
Kami tahu bahwa dalam proses menggunakan produk, pengguna akan mengunggah banyak file media ke server pelanggan.	Anda perlu mencari tahu jenis beban yang dirancang untuk server ini, dan ingatlah data ini.
Aplikasi ini digunakan oleh beberapa orang seminggu, jumlah datanya minimal.	Pengujian kinerja tidak diperlukan.

Pengujian regresi

Pemeriksaan penuh dari seluruh sistem selalu membutuhkan banyak waktu. Oleh karena itu, untuk membuat keputusan, perlu mengevaluasi kesesuaian: berapa banyak waktu yang diperlukan untuk regresi lengkap, dan risiko yang mungkin terjadi jika kita tidak melakukannya.

Diberikan	Solusi
Kami meluncurkan versi pertama dari produk atau modul program.	Pengujian regresi tidak diperlukan.
Proyek ini sangat besar, dan regresi penuh sebelum rilis fitur baru membutuhkan waktu yang sebanding dengan periode pengembangan. Tingkat penawaran yang diperlukan tidak memungkinkan hal ini.	Kami memutuskan bahwa kami tidak melakukan pengujian regresi, tetapi lebih memperhatikan jenis pengujian dan pemantauan lainnya.
Interaksi antara layanan microsoft dicakup oleh tes kontrak.	Regresi total tidak praktis. Dalam rangka pengujian manual, kami melakukan regresi fungsionalitas atas rekomendasi pengembang.

Pengujian integrasi

Untuk menentukan kebutuhan akan pengujian integrasi, akan berguna untuk membuat daftar semua sistem eksternal yang dengannya produk berinteraksi dan menunjukkan data mana yang kami terima dan kirimkan.

Diberikan	Solusi
Data penjualan dari portal ditransfer ke sistem analitik.	Penting tidak hanya untuk memverifikasi bahwa penjualan hilang, pergi dalam format yang benar, tetapi juga bahwa mereka datang dalam format yang benar - tidak ada yang hilang di sepanjang jalan.

Pengujian lokalisasi

Penting untuk menjawab pertanyaan tentang proyek:

• bahasa mana yang harus didukung
• apakah kami menyediakan koneksi lokalisasi tambahan selama pengoperasian solusi,
• Di negara mana pengguna kami akan bekerja,
• apakah akan ada penjualan dan dalam mata uang apa
• Apakah Anda perlu bekerja dengan zona waktu?

Diberikan	Solusi
Sistem ini memiliki 2 bahasa: Rusia dan Inggris.	Masuk akal untuk membahas bagaimana kita akan memahami antarmuka dalam bahasa apa yang ditampilkan kepada pengguna.
Pelanggan meminta untuk membuat aplikasi multibahasa.	Sebaiknya Anda menjawab sendiri pertanyaan-pertanyaan tentang bagaimana kami akan memverifikasi teks, dari mana kami akan mendapatkan teks dalam bahasa Arab, bagaimana layar akan disesuaikan untuk teks yang ditulis dari kanan ke kiri.

Cross-browser dan cross-platform

Kami tidak dapat memverifikasi operasi aplikasi seluler yang benar di semua perangkat secara umum. Dalam hal aplikasi web, pertanyaan segera muncul: apakah kita akan mendukung IE9? Sebelum memasukkan jenis pengujian ini ke dalam strategi, kami menganalisis (jika solusinya sudah berfungsi) atau berasumsi (jika belum berfungsi) untuk apa mereka akan menggunakannya.

Diberikan	Solusi
Pengguna aplikasi seluler adalah karyawan di seluruh negeri.	Kami melihat statistik yang ada tentang penggunaan platform aplikasi kami dan membuat keputusan yang akan kami uji.
Aplikasi kami memiliki pengguna korporat di mesin stasioner.	Kemungkinan besar, kami dapat merekomendasikan hanya menggunakan satu browser. Dan dengan demikian mengurangi waktu untuk pengujian dan dukungan untuk kompatibilitas lintas-browser.

Demikian pula, Anda harus menguraikan semua jenis pengujian lainnya:

• Fungsional (dilakukan atau tidak),
• Penerimaan (siapa yang memimpin dan bagaimana),
• UX / UI (apa kriteria objektif untuk antarmuka yang baik)
• Modular dan unit (yang menulis tes kontrak, yang menulis tes unit dan apakah kami menulisnya sama sekali),
• Pengujian keamanan (yang menjamin keamanan data, dan seberapa tahan sistem terhadap peretasan),
• Kegagalan dan pemulihan (bagaimana sistem akan berperilaku dalam keadaan darurat)

dan lainnya.

2. Prioritas dalam pengujian

Force majeure terjadi pada semua proyek, jadi sangat berguna untuk memiliki lembar contekan dengan rencana yang dipikirkan dengan matang, daripada menggunakan tombol acak.



Dalam mode normal, prioritas yang berarti juga penting. Misalnya, pengembangan autotest harus direncanakan dengan mempertimbangkan prioritas: pertama-tama, skenario yang paling kritis adalah otomatis (pengujian asap).

Diberikan	Solusi
Program kami digunakan di bandara untuk menjual layanan kepada penumpang saat naik pesawat. Dan jika pada saat ini terjadi semacam kesalahan, maka kita tidak akan punya waktu untuk perbaikan panas. Karena itu, seharusnya tidak ada kesalahan!	Kami memeriksa skenario penggunaan di bandara di tempat pertama.

3. Lingkungan untuk bekerja

Penting untuk memikirkan dan berkoordinasi dengan tim mana lingkungan yang diperlukan untuk pekerjaan, dan siapa yang akan menggunakannya. Sebagai aturan, 2-3 lingkungan dan penjualan sudah cukup.

Diberikan	Solusi
Pada proyek CD / CI, tes asap ditulis untuk pengujian awal fungsionalitas.	Kami membutuhkan lingkungan untuk perakitan kode utama dalam satu cabang, uji asap, di mana sistem eksternal ditutup oleh bertopik. Anda juga memerlukan lingkungan untuk pengujian manual dan integrasi dengan layanan pelanggan (QA).
Sesi pengujian beta diadakan secara teratur.	Kita membutuhkan lingkungan yang akan terlihat "di luar", lebih stabil daripada lingkungan QA.

4. Pekerjaan penguji pada proyek

Masuk akal untuk mendiskusikan terlebih dahulu semua kegiatan yang kita harapkan dari penguji pada proyek, karena mereka tidak harus sama pada semua proyek. Mungkin mengejutkan bagi seseorang di tim bahwa penguji melakukan sesuatu atau tidak melakukan sesuatu.

Item ini akan membantu manajer memahami tingkat kompetensi apa yang diperlukan dari tester, dan berapa lama waktu yang dibutuhkan. Untuk proyek yang ada, penting juga untuk menunjukkan bahwa kami (QA) mampu sehingga manajer memahami apa yang ia miliki.

Misalnya, bisa jadi:

• penilaian tujuan sprint untuk kelengkapan dan konsistensi,
• penilaian biaya tenaga kerja untuk pengujian,
• persiapan daftar periksa untuk pengujian (atau kasus uji),
• ulasan skrip autotest
• menulis autotest fungsional,
• pengujian manual langsung,
• penyebaran perubahan ke lingkungan,
• memperbarui strategi pengujian, dll.

5. Uji dokumentasi pada proyek

Hal ini diperlukan untuk menyepakati pantai, dan mungkin lebih jauh dan teratur meninjau format dokumentasi uji:

• dokumentasi uji apa yang akan kami lakukan pada proyek,
• akankah kita menulis kasus uji
• lakukan daftar periksa
• dan seberapa sering memperbarui dokumentasi ini.

Diberikan	Solusi
Sekitar 300 kasus uji telah ditulis untuk sekitar sepertiga dari fungsionalitas sistem. Mereka tidak hanya harus ditinjau secara berkala, tetapi juga diperbarui dari waktu ke waktu.	Dalam kondisi sumber daya yang terbatas, kami memutuskan untuk tidak bekerja dengan kasus uji, tetapi membatasi diri untuk memeriksa daftar untuk setiap tugas tertentu. Dan sebagai hasilnya, kami menghemat waktu untuk mendukung dokumentasi tanpa kehilangan kualitas pengujian.

6. Bagaimana uji kasus dihasilkan

Kondisi dan skenario pengoperasian tergantung pada solusi spesifik, jadi pastikan untuk membahas:

• teknik-teknik desain tes apa yang masuk akal untuk digunakan. Sebagai bagian dari paragraf ini, akan berguna untuk membuat daftar objek yang digunakan aplikasi dan kelas ekivalennya.
• apa heuristik dan pengalaman hidup dangkal membantu untuk menghasilkan skrip uji untuk proyek tertentu. Untuk aplikasi seluler, lebih mudah menggunakan heuristik standar, misalnya, "I SLICED UP FUN".

Diberikan	Solusi
Pada proyek asuransi, pengguna (agen) harus memeriksa mesin, di mana perlu untuk mengambil foto dan mengunggahnya ke server. Akal sehat menyatakan bahwa hampir tidak ada wifi di garasi. Dan terkadang, tidak ada koneksi seluler.	Jadi, Anda perlu memeriksa aplikasi tidak hanya ketika bekerja dengan 3G, tetapi juga karena tidak adanya komunikasi.
Setiap tindakan pengguna dalam aplikasi seluler maskapai adalah bagian dari sebuah skenario. Misalnya, Anda tidak dapat mengeluarkan tiket tanpa terlebih dahulu membuat reservasi.	Oleh karena itu, logis untuk menggunakan teknik "use case".

7. Prosedur untuk bekerja dengan pelacak

Di pelacak yang berbeda, kemungkinan dan jenis tugas berbeda. Berdasarkan kemampuan pelacak, kami menyarankan Anda untuk menyetujui siapa dan dengan prinsip apa yang menentukan prioritas tugas, dalam jenis tugas apa untuk mengatur bug dan tugas.

Bicaralah poin-poin penting dengan tim:

• Bagaimana kami membedakan antara kesalahan yang ditemukan oleh kami dan kesalahan yang ditemukan oleh pelanggan (dan apakah kami perlu membedakannya),
• Cara melakukan peningkatan
• Apakah perlu untuk membedakan perbaikan yang kami ciptakan sendiri dari yang diminta pelanggan. Bagaimana?
• Status apa yang harus dibuat kesalahan jika itu tidak terjadi lagi,
• Status apa yang dianggap final.

Diberikan	Solusi
Penguji membuat bug. Pengembang tidak dapat mereproduksi, menerjemahkannya ke status yang ditolak.	Penguji memeriksa kembali tugas dan menetapkan status ke Tertutup (final), jika kesalahan benar-benar hilang, atau memperbaiki deskripsi dan kembali ke Baru.
Pelanggan menetapkan tugas untuk revisi. Pengembang memahami bahwa ia tidak memiliki cukup data untuk diimplementasikan.	Pengembang menempatkan tugas dalam status Umpan Balik.

(Kami menulis lebih banyak tentang cara untuk menggambarkan bug dan riwayat pengguna di artikel ini ).

8. Kriteria untuk memulai dan mengakhiri pengujian

Jika tester mengambil tugas apa pun kapan saja, ini bukan pesanan, tetapi kekacauan. Karena tugasnya mungkin belum siap. Atau siap, tetapi tidak gratis. Atau siap, digunakan, tetapi tergantung pada tugas lain yang belum siap. Akibatnya, tester menghabiskan waktu dan saraf mencari dan memperbaiki kesalahan, tetapi sebenarnya Anda hanya harus menunggu. Oleh karena itu, kami setuju pada titik mana area tanggung jawab QA atas tugas dimulai dan berakhir.

Pada tahap awal pengembangan proyek, kesiapan tugas / versi ditentukan oleh mata.
Dengan tumbuhnya kesadaran diri, kami memahami bahwa kami membutuhkan kriteria yang jelas bahwa tugas / versi siap. Sehingga keputusan ini transparan untuk semua orang, dan bukan "tester merasakan barang rampasan bahwa semuanya normal." Misalnya, dalam konteks CD yang disetel, kami yakin bahwa tugas tersebut siap untuk pengujian segera setelah dikirim ke lingkungan QA dan memiliki status Terselesaikan.

Diberikan	Solusi
Suatu proses telah diatur pada proyek bahwa daftar periksa untuk pengujian dikompilasi untuk setiap revisi.	Kami menganggap tugas diverifikasi jika kami telah melewati semua poin pada daftar periksa.
Proyek ini sedang mengerjakan sprint.	Sprint dianggap siap jika semua peningkatan dalam status Tertutup dan tidak ada kesalahan dengan prioritas Normal dan lebih tinggi.
Proyek ini menyusun daftar fungsi berdasarkan prioritas.	Kami percaya bahwa versi ini siap untuk dirilis jika fungsionalitas dari poin pertama dari daftar berhasil.
Proyek ini telah menulis uji kasus dan melakukan pengujian regresi sebelum rilis.	Versi dianggap siap untuk dirilis jika, berdasarkan hasil pengujian regresi, tidak ada kesalahan dengan prioritas Normal atau lebih tinggi ditemukan (atau persentase skenario yang gagal tidak lebih tinggi dari 5).

9. Alat untuk bekerja

Bagian ini berguna kemudian untuk mengatur tugas yang bertanggung jawab (ke administrator dan manajer) sudah pada tahap perencanaan pengujian dan untuk mendapatkan semua alat yang diperlukan pada awal pekerjaan.

Ada baiknya membahas masalah-masalah seperti:

• Alat apa yang kita butuhkan untuk melakukan dokumentasi pengujian,
• Alat apa yang dapat menyiapkan data uji,
• Alat apa yang diperlukan untuk otomasi.

Diberikan	Solusi
Untuk menggambarkan fungsionalitas yang diterapkan, kami memutuskan untuk menggunakan peta pikiran.	Orang-orang di tim bekerja pada platform yang berbeda, jadi Anda harus memilih format file mind-map yang dapat Anda gunakan di Windows, Linux, dan Mac.
Kami sepakat bahwa kami perlu otomatisasi pada proyek.	Jadi, kita membutuhkan alat yang akan memungkinkan kita untuk mempersiapkan data uji (misalnya, untuk menggulung skrip ke dalam basis data), memungkinkan kita untuk meluncurkan di dalam pipa (misalnya, newman), dan memungkinkan kita untuk membuat bertopik (misalnya, WireMock).

10. Alat penilaian dan pemantauan kualitas proyek

Pada bagian ini, kami mengusulkan untuk menyetujui apa KPI untuk menilai kesehatan aplikasi (di samping perhitungan yang jelas dari cakupan tes). Indikator ini harus dapat diukur dan dicapai. Secara khusus, pahami dan jawab pertanyaan-pertanyaan berikut:

• Bagaimana kami akan melacak kesalahan di prod
• Bagaimana kami mengumpulkan umpan balik dari pengguna,
• Bagaimana kami mengumpulkan statistik tentang penggunaan fitur kami.

Diberikan	Solusi
Setelah merilis fitur baru sistem, pemantauan penggunaan dikonfigurasikan (misalnya, jumlah penjualan layanan).	Penurunan itu menjadi pemicu penyelidikan. Mungkin fitur tidak berfungsi seperti yang diharapkan, atau kami tidak mengimplementasikan bagian dari skrip.
Kami telah mengkonfigurasi program untuk memantau kecepatan melakukan operasi dasar.	Kriteria untuk kualitas pekerjaan adalah bahwa dengan masuknya pengguna, kecepatan eksekusi tidak turun.

Kesimpulan

Strategi pengujian tunggal dan universal yang cocok untuk semua orang tidak ada. Ini dirancang secara individual untuk setiap proyek.

• Penting untuk memahami bahwa strategi tidak boleh menjadi tujuan itu sendiri - itu hanya alat yang memungkinkan kita untuk mencapai tujuan kita.
• Sangat normal bahwa tidak selalu mungkin untuk segera menjawab semua pertanyaan yang diajukan. Ini adalah kesempatan untuk berbicara lagi dengan pelanggan atau pengguna produk.
• Proyek ini berkembang, dan jika kemarin terlalu dini untuk memusingkan produktivitas, maka besok mungkin sudah saatnya. Karena itu, setelah menyusun strategi, penting untuk memperbarui dan mengisi kembali secara teratur dan membawa perubahan pada tim.
• Setelah menulis strategi, biasanya menjadi jelas di mana kegagalan dalam pengujian dan apa yang perlu dilakukan. Ini adalah kesempatan untuk menetapkan tujuan, menonton dinamika dan ... memperbarui strategi setelah beberapa waktu.