Pada umumnya proyek pengembangan perangkat lunak berjalan sesuai struktur tim berikut
1) Tim Pemilik Fitur: Ini adalah tim tingkat atas dalam hierarki, yang berinteraksi langsung dengan calon pelanggan. Bertanggung jawab untuk memahami persyaratan pelanggan dengan cermat dan mengelompokkannya ke dalam beberapa fitur. Berbagai anggota dalam tim tersebut dapat menjadi pemilik beberapa fitur tersebut. Anggota tim yang berinisiatif dan aktif berinteraksi dengan berbagai tim berperan penting dalam memberikan arahan yang diperlukan dalam mengembangkan fitur-fitur yang dimiliki.
2) Tim Antarmuka Pengguna: Antarmuka Pengguna yang disebut UI singkatnya sangat penting untuk produk. Sekalipun produk perangkat lunak memiliki serangkaian fitur unggulan, tetapi Antarmuka Penggunanya tidak efektif & nyaman, produk tersebut ditakdirkan untuk gagal.
Oleh karena itu tim Antarmuka Pengguna independen dibuat. Anggota tim Antarmuka Pengguna adalah spesialis dalam merancang Antarmuka Pengguna untuk produk perangkat lunak dan memahami perbedaan antara Antarmuka Pengguna yang baik dan yang buruk. Satu-satunya tujuan dari tim Antarmuka Pengguna tersebut adalah untuk melakukan penelitian ekstensif di Antarmuka Pengguna.
Tim UI mendesain UI untuk produk atau fiturnya. Pada langkah selanjutnya tim UI berinteraksi dengan tim Feature Owners untuk memberikan bentuk praktis UI secara bersama-sama. Pertemuan tersebut dapat menghasilkan “Desain halaman” atau beberapa “Mockup” yang berisi semua elemen UI seperti yang diperlukan di halaman. Maket sangat membantu dalam menyajikan tampilan atau tampilan halaman yang diinginkan. Navigasi sebenarnya antara berbagai halaman juga diperiksa selama pertemuan lintas fungsi tersebut.
3) Tim Pengembang: Diberikan tugas pengembangan Produk.
4) Testing Team: Diberikan tugas untuk menguji produk.
ARUS PROSES:
1) Memulai Proyek: Anggota tim pemilik fitur memulai proses dengan pengembangan dokumen desain pada tingkat Tinggi yang berlaku untuk setiap fitur & hal yang sama dirilis ke semua pihak.
2) Rilis Dokumen Desain Tingkat Tinggi: Terlepas dari dokumen desain tingkat tinggi yang disiapkan oleh pemilik fitur, desain halaman atau Maket Antarmuka Pengguna dirilis ke semua pihak untuk referensi oleh tim UI.
3) Pengembangan Perangkat Lunak: Pengodean fitur yang diinginkan dimulai oleh tim pengembangan sesuai dengan dokumen yang dirilis.
4) Pengujian Perangkat Lunak: Tim penguji memulai aktivitas terkait pengujian dengan cara berikut:
($) Persiapan Dokumen dengan Test Outline: Dokumen ini menjelaskan detail alur pengujian atau Skenario Uji Ganda yang diproyeksikan pada tingkat tinggi. Kerangka uji harus memiliki informasi singkat tentang apa yang perlu diperiksa pada titik mana selama aliran.
Selain rincian alur, dokumen garis besar pengujian ini berisi matriks terperinci yang menjelaskan semua persyaratan dari Dokumen Desain Tingkat Tinggi (HLD) hingga alur pengujian. Di HLD, ID unik dapat mengidentifikasi setiap persyaratan dengan jelas. Tujuan dari matriks ini adalah untuk memastikan bahwa semua persyaratan telah diperiksa secara hati-hati untuk setiap kekurangan.
($) Persiapan Kasus Uji: Setiap skenario uji selanjutnya dikonversi menjadi kasus uji individual, yang berisi semua informasi mendetail. Ini menentukan langkah-langkah yang tepat untuk navigasi, data yang diinginkan dan informasi rinci tentang apa yang perlu diperiksa. Penjelasan terperinci dalam Test Case sangat membantu terutama ketika orang yang menulis test case bukan orang yang akan mengeksekusinya.
($) Otomatisasi Uji: Meskipun tidak wajib, otomatisasi uji adalah langkah opsional. Ini melibatkan otomatisasi kasus uji yang dirancang dengan bantuan beberapa alat otomatisasi, yang paling sesuai dengan kebutuhan perusahaan.
($) Aktivitas Bersamaan: Pekerjaan pengembangan & pengujian dilakukan secara bersamaan. Tim pengembangan terlibat dalam tugas utama pengkodean fitur yang diinginkan. Tim pengembangan terkadang juga melakukan semacam pengujian pada akhirnya. Sementara itu, tim pengujian menyiapkan kasus pengujian untuk pengujian manual dan skrip otomasi untuk mengotomatiskan eksekusi pengujian dengan bantuan beberapa alat otomasi.
($) Pengujian Produk: Siklus pengujian dimulai ketika tim pengujian secara aktif memulai pengujian produk dan mulai mencatat bug dalam sistem penyimpanan bug yang ditentukan. Secara bersamaan para pengembang terlibat dalam perbaikan bug.
Sebagai praktik terbaik, dua contoh terpisah dari aplikasi dipertahankan. Satu instance diperuntukkan bagi tim pengujian dan yang kedua dimaksudkan untuk tim pengembang atau tim perbaikan bug. Namun kedua tim beroperasi pada level kode yang sama.
($) Pencatatan Bug: Sebelum mencatat bug di sistem repositori bug, diverifikasi apakah kami dapat mereproduksinya dalam contoh yang dimaksudkan untuk pengembang atau tidak. Jika bug dapat direproduksi, itu ditugaskan ke pengembang terkait untuk perbaikan yang diperlukan. Ketika bug diperbaiki, maka perbaikan kode diterapkan pada contoh pengembang, diverifikasi secara menyeluruh dan kemudian diterapkan pada contoh tim pengujian untuk pengujian regresi.
Namun jika bug tidak dapat direproduksi pada instance pengembang, dapat disimpulkan bahwa itu dapat menjadi masalah yang terkait dengan beberapa jenis penyiapan aplikasi. Dalam kasus seperti itu pengembang berinteraksi dengan tim pengujian untuk memastikan apakah itu adalah bug asli yang memerlukan perubahan dalam kode atau semacam masalah pengaturan aplikasi. Masalah pengaturan aplikasi seperti itu cukup umum terjadi selama pengujian rangkaian perangkat lunak dari produk yang terintegrasi secara ketat.
($) Pengujian Regresi: Penambalan kode selesai & penguji mengulangi pengujian dari awal. Untuk memperbaiki bug, sering menambal sistem dihindari. Sesuai dengan kebijakan terbaik untuk menambal bug, melibatkan beberapa putaran pengujian, menambal semua bug yang terakumulasi antara dua putaran pengujian hanya dilakukan sekali, Bug diperbaiki dan disiapkan untuk ditambal bersama. Ini juga tidak memiliki aturan keras & cepat. Pengecualian ada untuk bug, yang dianggap kritis & yang dapat sangat menghambat pengujian dapat segera ditambal.
($) Sanity Testing: Setelah penambalan selesai, instance aplikasi akan menjalani uji kewarasan oleh tim pengembangan. Kemudian dirilis untuk putaran pengujian berikutnya yang melibatkan eksekusi semua kasus uji lagi. Ini termasuk pelaksanaan kasus uji yang kebetulan lolos di babak sebelumnya.
($) Menghentikan Operasi Pengujian: Dalam skenario beberapa putaran pengujian, keputusan penting perlu diambil, apakah akan melanjutkan ke putaran pengujian berikutnya atau berhenti di sana sendiri. Keputusan penting sebagian besar bergantung pada jumlah bug yang telah dicatat selama putaran pengujian sebelumnya. Dua faktor yang dapat membantu mengambil keputusan seperti itu adalah:
1) Pengujian lebih lanjut dapat dihentikan ketika tidak ada bug kritis baru yang terdeteksi & ketika pengujian regresi tidak lagi diperlukan.
2) Pengujian lebih lanjut dapat dihentikan ketika jumlah masalah kecil yang tersisa sangat sedikit. Istilah “Kurang” sangat subyektif dan sangat bergantung pada aplikasi yang diuji.