Pengujian Jaminan Kualitas Disempurnakan – Tutorial Alur Pengguna

Karena produk dan layanan menyebar lebih cepat dan lebih cepat, jaminan kualitas (QA) harus beradaptasi dengan lingkungan yang berkembang, terkadang mencapai tingkat cakupan yang sama dalam periode waktu yang lebih singkat. Bagaimana kita menghindari kesalahan Kuantitas atas Kualitas ? Bagaimana kita menutupi lebih banyak, meningkatkan efisiensi, dan tetap efektif dalam pekerjaan kita?

Kita semua tahu bahwa kasus uji membutuhkan waktu lama untuk dibuat. Kita harus menerapkan berbagai teknik, jenis pengujian, dan prasyarat dokumen, langkah-langkah, dan hasil yang diharapkan. Selain itu, kita harus membuat rencana pengujian.

Spesialis penjaminan mutu sering kali kehabisan waktu, terutama ketika mereka mencoba menyelesaikan semua fase dalam proses QA. Sakit kepala terbesar adalah perencanaan pengujian dan fase desain, berkisar pada pembuatan kasus uji dan dokumentasi pengujian. Ini bisa memakan waktu berjam-jam, kadang-kadang bahkan berhari-hari untuk menyelesaikan semua pekerjaan, dan biasanya, mereka memilih untuk melewatkan kiriman tertentu dan meringkas sebagai gantinya, meninggalkan informasi penting yang dapat menyebabkan tes dilupakan. Itu juga mengakibatkan hilangnya manfaat dari berbagi pengetahuan.

Pengujian QA Tradisional Memenuhi Alur Pengguna

Saya penggemar berat kasus uji tradisional dan rencana pengujian. Mereka tidak hanya membantu mengidentifikasi banyak kasus uji tetapi juga mendokumentasikan produk dengan sangat baik. Anda dapat menggunakannya dalam pelatihan, dan setiap orang di tim memahaminya. Anda tidak perlu terlalu mengandalkan pengalaman bagi seseorang untuk memulai pengujian. Rencana pengujian memiliki informasi lebih lanjut seperti merinci ruang lingkup, item pengujian, fitur yang Anda uji, dan yang tidak. Ada juga analisis risiko yang masuk ke dalam rencana pengujian. Ini hanya beberapa keuntungan, namun, keseluruhan waktu yang dibutuhkan terlalu lama dalam banyak kasus.

Tujuan dari rencana uji adalah cara komunikasi dan kesepakatan antara pemangku kepentingan proyek. Ini membantu merinci tujuan, sumber daya yang diperlukan, dan pendekatan atau strategi apa pun untuk menguji produk. Rencana tersebut membantu memastikan semuanya dipikirkan dan memberikan keyakinan kepada pemangku kepentingan bahwa proses penjaminan kualitas diinvestasikan secara strategis. Tidak ada aturan konkrit bahwa rencana ini harus 10 halaman. Kita dapat mendefinisikannya kembali agar sesuai dengan tim yang bergerak cepat.

Alternatifnya adalah dengan merampingkan kasus uji tradisional dan rencana pengujian dengan cara yang menghemat waktu investasi yang diperlukan tetapi memberikan cakupan dan dokumentasi yang sama, jika tidak lebih, yang masuk akal bagi semua pemangku kepentingan. Ini melibatkan satu sumber kebenaran, aliran pengguna dengan twist. Dengan menyusun dan mempertahankan alur pengguna, Anda akan memiliki sebagian besar desain kasus uji yang telah dilakukan untuk Anda. Ini dapat diterapkan pada produk atau tim apa pun dan serbaguna dalam hal detail dan strukturnya.

Menggunakan metode aliran akan membantu Anda mencapai waktu penyelesaian yang lebih cepat dengan dokumentasi pengujian Anda. Ini tidak hanya untuk QA manual tetapi juga untuk otomatisasi. Aliran juga dapat berkontribusi pada beberapa bagian dari rencana pengujian.

Mengikuti Arus

Tanpa penundaan lebih lanjut, mari kita langsung membangun alur pengguna untuk situs web perpesanan sederhana.

Pertama-tama kita membutuhkan alat pemetaan pikiran gratis. Saya pribadi menggunakan XMind. Jangan ragu untuk mengunduh alat apa pun yang Anda sukai—kami hanya akan menggunakan fitur dasar seperti menggambar diagram alur, menambahkan "catatan" ke beberapa topik, mewarnai kondisi yang berbeda, dan menggunakan label.

Langkah pertama kami adalah memahami produk. Biasanya, Anda akan mereferensikan gambar tiruan atau gambar rangka. Jika tidak ada yang tersedia, panggilan cepat dengan pengembang akan menghasilkan layar yang diharapkan. Jangan ragu untuk mengikuti dan berlatih saat kami melanjutkan. Alur tidak hanya terbatas pada antarmuka pengguna dan juga dapat digunakan untuk memetakan panggilan API-ke-API, diagram basis data, struktur ketergantungan, dan banyak lagi. Prinsip yang sama berlaku.

Kondisi, Status, Tindakan

Kami membatasi aliran kami dengan hanya menggunakan tiga aktor. Anda akan memiliki Kondisi , yang seperti pengguna dengan peran tertentu, cache yang dihapus, atau pengguna yang masuk untuk pertama kalinya. Kedua, kami memiliki State/Page , yang merupakan komponen GUI yang sebenarnya, seperti beranda atau jendela masuk. Berikutnya adalah Action , yang merupakan interaksi fisik pengguna yang menyebabkan keadaan berubah. Mari kita lihat ini dalam tindakan.

Menganalisis Persyaratan

Ini adalah beranda kami, yang merupakan Negara Bagian. Kami memiliki dua Tindakan yang mungkin: Daftar dan Masuk.

Kemudian, kami memiliki jendela Masuk, Negara lain. Tindakan di sini adalah Kembali dan Masuk. Perhatikan bahwa kami tidak mengklasifikasikan bidang input sebagai tindakan. Anda dipersilakan untuk melakukan ini. Dalam pengalaman saya, saya telah menemukan bahwa ketika bekerja pada sistem kompleks yang berjalan beberapa persepuluh dalam, akan sedikit sulit untuk mempertahankan, tetapi untuk aplikasi sederhana, itu bisa sangat cocok.

Terakhir, kita masuk ke dasbor yang akan digunakan pengguna ketika mereka berhasil masuk. Di sini, kita memiliki tiga tindakan—kita dapat Membuat, Mengedit, atau Menghapus pesan.

Kami sekarang memiliki informasi yang cukup untuk memulai alur pengguna. Mari kita simpulkan apa yang kita miliki. Kami mencatat status produk. Dari apa yang bisa kita lihat, ada empat halaman:

1. Beranda
2. Jendela Masuk
3. Daftar Jendela
4. Dasbor

Kami menuliskan tindakan kami pada setiap halaman/status yang dapat "berinteraksi" dengan:

1. Beranda
   1. Gabung
   2. Daftar
2. Jendela Masuk
   1. Masuk
   2. Membatalkan
3. Daftar Jendela
   1. TBD (tergantung produk)
4. Dasbor
   1. Membuat
   2. Sunting
   3. Menghapus

Kami mulai dengan Nama Produk , yang dapat diubah untuk beradaptasi dengan lingkungan Anda, tetapi ini cocok untuk sebagian besar tim dan produk mereka dan juga memberikan titik awal yang baik. Di bawah ini, kita akan melihat tanda tanya di sebelah Daftar .

Sering kali, Anda akan menemukan komponen di Agile yang belum ada dalam cakupan atau direncanakan untuk rilis di masa mendatang. Catat keberadaannya, tetapi biarkan sebagai yang tidak diketahui sampai kami mendapatkan informasi lebih lanjut.

Menggambar Diagram Alir

Kami menggambar di atas di XMind agar terlihat seperti:

Anda akan melihat bahwa saya hanya memberi kode warna apa itu keadaan dan apa itu tindakan. Saya juga menambahkan baris dari Tindakan Batal ke beranda untuk mewakili aliran itu secara akurat. Kami juga melihat dua kondisi ketika pengguna memilih "Login." Meski sama-sama masuk ke dashboard, kami tetap ingin menguji kedua kemungkinan kondisi tersebut.

Hal yang menyenangkan dengan XMind adalah jika kita bekerja pada aplikasi yang besar dan kompleks, kita dapat membuat level diagram yang berbeda, jadi jika Anda ingin memecah aliran menjadi beberapa aliran tetapi tetap menghubungkannya, itu sangat mudah dilakukan dengan menautkan topik untuk memisahkan lembar. Anda dapat memilih untuk menyisipkan hyperlink, dan dari jendela munculan wizard, Anda dapat memilih "Status" yang menjadi tujuan tindakan. Ini berarti jika Anda memilih "Login" di XMind dan hyperlink ke "Dashboard", kursor mouse Anda akan melompat ke "Dashboard", meskipun berada di lembar yang berbeda. Cukup keren.

Apa yang hilang dari aliran kami adalah label. Kami memberi produk label 0, karena itu adalah akar dari aliran. Kemudian, untuk setiap Status (biru), kami menambahkan label S#, untuk setiap Tindakan (hijau), kami menambahkan label A#, dan terakhir, untuk setiap Kondisi (cyan), kami menambahkan label C#. Setiap label harus unik. Kami berakhir dengan yang di bawah ini:

Untuk melacak nomor mana yang terakhir Anda gunakan—karena seiring pertumbuhan produk, mencoba menemukan nomor tertinggi dapat menjadi tantangan—saya menyimpan ini di topik Akar alur, seperti di bawah ini:

Sekarang kita sampai pada bagian membuat kasus uji. Kami akan fokus pada Hasil yang Diharapkan, yang mungkin merupakan informasi terpenting dalam kasus uji dan bagian dari kriteria penerimaan fitur. Saya akan menambahkan judul untuk setiap bagian atau tes dan kemudian mencantumkan hasil yang diharapkan di bawahnya. Saya akan melakukan ini hanya untuk sebagian agar artikel ini tetap ringkas:

Kemudian, Jendela Masuk:

Kemudian, Tindakan Masuk:

Ini benar-benar mulai terbentuk. Perhatikan batas dan tes keamanan ditambahkan. Anda dapat memberi judul ini sesuka Anda, mana yang paling mudah untuk Anda beri tag. Saya terkadang menandai judul dengan jenis pengujian, seperti Keamanan – Injeksi JS – Bidang Email, lalu mencantumkan hasil yang diharapkan di bawah ini.

Di sebagian besar tim, kami menemukan perubahan persyaratan yang sulit untuk dipertahankan. Tidak lagi. Katakanlah kita baru mengetahui bahwa semua pengguna pertama kali harus disajikan dengan jendela Ts dan Cs dan harus menerima sebelum melanjutkan ke dasbor mereka—tidak masalah. Kita dapat menambahkan status dan tindakan dengan relatif mudah, seperti di bawah ini:

Sekarang kita melihat dampak penambahan status baru. Perhatikan bahwa penomoran mungkin aneh pada awalnya, tetapi selama kita ingat, angka-angka tersebut hanya untuk mengidentifikasi setiap aktor secara unik—seperti Primary Key pada database. Jangan lupa untuk memperbarui catatan "Terakhir Digunakan" untuk melacak nomor yang Anda gunakan.

Membuat Kasus Uji dari Aliran

Setelah semua kemajuan ini, sekarang kita sampai ke bagian yang lebih mudah: pembuatan test case. Biarkan saya menyoroti beberapa poin penting. Kami memiliki label untuk setiap aktor, kami memiliki judul untuk setiap tes, dan kami mengharapkan hasil untuk setiap tes, dengan kondisi yang disematkan sebagai bagian dari aliran kami. Ini kedengarannya seperti resep untuk kasus uji, tidakkah Anda setuju?

Yang kami lakukan sekarang adalah menyalin-menempelkan apa yang ada di aliran kami ke alat manajemen kasus uji, situs Confluence, atau dokumen Excel yang Anda inginkan. Saya masih menggunakan Excel lama yang terpercaya. Saya menyimpan catatan semua kasus pengujian saya dalam satu file yang disebut "Baseline" - sangat asli. Setelah saya selesai menyalin-menempel, saya berakhir dengan yang di bawah ini:

Jangan ragu untuk menambahkan kolom untuk jenis pengujian, status pengujian, dan konfigurasi pengujian sesuai kebutuhan. Kondisinya mungkin lebih baik ditempatkan sebelum tindakan "Masuk", namun, tidak ada cara yang benar atau salah untuk melakukannya, itu tergantung pada preferensi pribadi dan bagaimana Anda mengatur diri sendiri.

Ada beberapa hal yang menjadi sorotan. Salah satunya adalah saya telah menggabungkan sel yang berbagi informasi yang sama—tidak perlu menyalin-tempel berulang kali, ini membuang waktu dan lebih sulit untuk dipelihara. Item lainnya adalah Langkah. Anda akan melihat bahwa dua tes memiliki langkah-langkah yang menggabungkan nomor Status dan Tindakan. Ini dapat digunakan ketika Anda memiliki alur sebagai bagian dari SDLC di tim Anda. Semua pemangku kepentingan kemudian berkontribusi pada aliran dengan memberikan informasi, mock-up, meningkatkan risiko, dll. Ini berarti dengan menyatakan nomor aliran, siapa pun di tim akan tahu apa yang harus dilakukan, dan jika ada anggota tim baru, semudah itu sebagai "ikuti jejak, referensi catatan."

Ini juga membantu otomatisasi. Anda dapat memberikan setiap langkah atau tindakan referensi unik. Dengan membuat paket otomatisasi yang terstruktur seperti alur Anda, Anda akan menemukan bahwa kerangka kerja otomatisasi yang dapat Anda bangun berpotensi menjadi sangat kuat, modular, dan kompatibel di seluruh aplikasi. Ini akan menggunakan objek paging dalam skala yang lebih besar, yang akan mengurangi waktu pemeliharaan dan memungkinkan Anda untuk menukar fungsi pengujian dengan yang baru.

Alur dapat menjadi satu-satunya sumber kebenaran untuk semua dokumentasi produk, termasuk spesifikasi teknis, spesifikasi fungsional, kasus uji, transisi status, aliran data, dll.

Pendekatan Rencana Uji Efisien

Jadi bagaimana dengan rencana pengujian?, Anda pasti berpikir. Ini sederhana. Rencana Uji berisi bagian seperti:

1. Pendahuluan & ruang lingkup
2. Item tes
3. Fitur yang akan diuji
4. Fitur tidak untuk diuji
5. Asumsi
6. Kriteria masuk
7. Kriteria keluar
8. WBS
9. Resiko
10. Persyaratan lingkungan

Pengantar dan ruang lingkup akan menjadi cerita JIRA atau tugas atau cerita apa pun di alat lain. Item pengujian hanyalah versi perangkat lunak atau nomor komit yang saat ini digunakan di lingkungan Anda, yang dapat Anda tautkan ke tiket JIRA atau saat pengujian Anda baik di Confluence atau alat manajemen pengujian.

Fitur yang akan diuji dan Fitur yang tidak akan diuji sebenarnya adalah kasus pengujian Anda. Kasus uji yang dipilih untuk dieksekusi untuk cerita JIRA ini adalah "Fitur yang akan diuji," dan apa pun yang tidak terdaftar adalah "Fitur yang tidak akan diuji." Cukup sederhana, buat daftar Status dan Tindakan yang akan Anda uji di tiket cerita.

Asumsi, Risiko, dan bahkan persyaratan Lingkungan dapat dikompilasi dalam dokumen atau ditambahkan ke komentar di JIRA, terkadang bahkan ditempatkan di Confluence dan ditautkan ke cerita.

WBS adalah perkiraan yang Anda tetapkan untuk cerita dalam hal poin cerita atau jam, tergantung pada proyek Anda. Kriteria Masuk dan Keluar sudah akan menjadi bagian dari cerita.

Jika Anda ingin mendekati rencana pengujian "tradisional", Anda dapat meminta pengembang atau pemangku kepentingan lainnya untuk mengomentari cerita dengan Ya atau Tidak untuk melihat apakah mereka setuju dengan rencana QA atau tidak. Ini secara teknis berfungsi sebagai tanda tangan digital Anda. Semua ini dapat dimasukkan dalam proses QA Anda dengan lebih mudah dan membantu Anda merampingkan dokumentasi QA Anda.

Apa yang Telah Kita Pelajari?

Alur pengguna dengan pendekatan di atas dan rencana pengujian yang disederhanakan untuk menggunakan alat yang tersedia saat ini akan membantu kami mengurangi pekerjaan yang berulang dan membantu QA untuk mencapai waktu penyelesaian yang lebih cepat tanpa mengorbankan kualitas.

Pendekatan ini telah berperan dalam membimbing saya untuk tetap teratur, mencakup setiap dasar, dan membangun dokumentasi yang dipahami seluruh tim. Di Agile, ini akan sangat berguna, dan bagian terbaiknya adalah kami masih mematuhi salah satu pendekatan Agile: “Sederhanakan Dokumentasi.”

Saya sangat berharap informasinya bermanfaat. Semuanya terserah Anda sebagai pembaca. Ini bukan seperangkat aturan konkret untuk diikuti, ini hanya panduan untuk memberi Anda ide untuk tumbuh dan meningkatkan efisiensi Anda. Tidak ada teknik yang cocok untuk setiap proyek, tim, atau produk, tetapi mungkin membuka jalan bagi ide inovatif lainnya.