Dengan dan proyek perangkat lunak besar melanjutkan pembangunan sesuai struktur tim berikut
1) Tim Fitur Pemilik: Ini adalah sebuah tim tingkat atas dalam hirarki, yang secara langsung berinteraksi dengan pelanggan prospektif. Hal ini bertanggung jawab untuk teliti memahami kebutuhan pelanggan dan kelompok-kelompok mereka menjadi beberapa fitur. Berbagai anggota tim sedemikian mungkin menjadi pemilik beberapa fitur tersebut. Anggota tim mengambil inisiatif dan secara aktif karena berinteraksi dengan berbagai tim menjadi penting dalam memberikan arah yang diperlukan dalam mengembangkan fitur yang dimiliki oleh mereka.
2) Tim Antarmuka Pengguna: User Interface yang disebut UI pendek sangat signifikan bagi produk. Bahkan jika sebuah produk perangkat lunak memiliki serangkaian fitur yang sangat baik, namun Antarmuka Pengguna tidak efektif & mudah, produk ini ditakdirkan untuk gagal.
Oleh karena itu tim independen User Interface dibuat. Para anggota dari tim User Interface adalah spesialis dalam merancang User Interface untuk produk perangkat lunak dan memahami perbedaan antara User Interface yang baik dan yang satu miskin. Tujuan satu-satunya tim seperti User Interface adalah untuk melakukan riset ekstensif dalam User Interface.
Tim desain UI UI untuk produk atau fitur-fiturnya. Dalam langkah berikutnya tim UI berinteraksi dengan tim Pemilik Fitur untuk memberikan bentuk praktis untuk UI bersama-sama. hasil pertemuan tersebut dapat menjadi mungkin "Page desain" atau "maket" yang mengandung semua elemen dari UI seperti yang diharuskan dalam halaman. The maket sangat membantu dalam penyajian tampilan yang diinginkan atau penampilan halaman. navigasi Aktual antara berbagai halaman juga diperiksa selama pertemuan lintas fungsional tersebut.
3) Tim Pengembangan: Apakah dipercayakan tugas pengembangan Produk.
4) Tim Uji Perangkat Lunak: Apakah dipercayakan tugas pengujian produk.
ARUS PROSES ATAS:
1) Proyek Kick mulai: Para anggota tim fitur pemilik kick memulai proses dengan pengembangan dokumen desain di tingkat tinggi berlaku untuk semua fitur & sama dilepaskan untuk semua pihak.
2) Pelepasan Tingkat Tinggi Desain Dokumen: Selain dari dokumen desain tingkat tinggi yang disiapkan oleh pemilik fitur, desain dari halaman atau User Interface maket dilepaskan untuk semua pihak yang terkait untuk referensi oleh tim UI.
3) Pengembangan Perangkat Lunak: Coding fitur yang diinginkan dimulai oleh tim pengembangan sesuai dokumen dirilis.
4) Software Pengujian: pengujian yang menendang tim memulai kegiatan terkait pengujian dengan cara sebagai berikut:
($) Penyusunan Dokumen dengan Test Garis Besar: Dokumen ini menjelaskan rincian arus dari pengujian atau Skenario Multiple-Test diproyeksikan pada tingkat tinggi. Uji garis akan memiliki informasi singkat tentang apa yang perlu diperiksa pada titik selama arus.
Selain rincian arus, dokumen ini berisi garis besar uji matriks rinci menjelaskan semua persyaratan dari Dokumen Tingkat Tinggi Desain (HLD) ke arus uji. Dalam HLD sebuah ID yang unik khas dapat mengidentifikasi kebutuhan masing-masing. Tujuan dari matriks ini adalah untuk memastikan bahwa semua persyaratan telah diperiksa dengan teliti untuk kekurangan apapun.
($) Persiapan Uji Kasus: Setiap skenario pengujian lebih lanjut dikonversi menjadi kasus uji individu, yang berisi semua informasi yang rinci. Ini menentukan langkah-langkah yang tepat untuk navigasi, yang diinginkan data dan informasi rinci tentang apa yang perlu diperiksa. penjelasan rinci dalam Kasus Uji berguna terutama ketika orang-orang yang menulis kasus pengujian selain orang-orang akan mengeksekusi mereka.
($) Test Otomasi: Meskipun tidak wajib, otomatisasi tes adalah langkah opsional. Ini melibatkan otomatisasi uji kasus dirancang dengan bantuan beberapa alat otomatisasi, paling cocok dengan kebutuhan perusahaan.
($) Concurrent Kegiatan: Pengembangan & kerja pengujian dilakukan secara bersamaan. Tim pengembangan mendapatkan terlibat dalam tugas utama coding dari fitur yang diinginkan. Tim Pengembangan kadang-kadang melakukan semacam pengujian pada akhir mereka. Sementara itu, tim menyiapkan pengujian kasus uji untuk pengujian manual dan otomatisasi script untuk mengotomatisasi pelaksanaan uji dengan bantuan beberapa alat otomatisasi.
($) Produk Pengujian: Siklus pengujian dimulai ketika tim pengujian secara aktif memulai pengujian produk dan mulai penebangan bug dalam sistem repositori bug didefinisikan. Saat para pengembang yang terlibat dalam perbaikan dari bug.
Sebagai praktik terbaik, dua contoh aplikasi terpisah diselenggarakan. Satu contoh adalah diperuntukkan bagi tim pengujian dan yang kedua dimaksudkan untuk tim pengembang atau bug fixing tim. Namun kedua tim beroperasi pada tingkat kode yang sama.
($) Logging Bugs: Sebelum penebangan bug dalam sistem bug repositori, itu diverifikasi, apakah kita dapat mereproduksi dalam contoh dimaksudkan untuk para pengembang atau tidak. Jika bug tersebut direproduksi, itu diberikan kepada pengembang yang bersangkutan untuk memperbaiki diperlukan. Ketika bug tersebut tetap, maka kode memperbaiki diterapkan pada contoh pengembang, benar-benar diverifikasi dan kemudian diterapkan untuk contoh tim pengujian untuk pengujian regresi.
Namun jika bug tersebut tidak bisa direproduksi di contoh pengembang, itu dapat disimpulkan bahwa hal itu dapat menjadi masalah yang berhubungan dengan beberapa jenis aplikasi setup. Dalam kasus seperti pengembang berinteraksi dengan tim pengujian untuk memastikan apakah itu adalah bug asli yang memerlukan perubahan kode atau beberapa jenis aplikasi pengaturan masalah. masalah pengaturan aplikasi seperti ini cukup umum selama pengujian dari suite produk perangkat lunak erat terintegrasi.
($) Regresi Pengujian: Kode patch dilakukan & penguji mengulang pengujian dari awal. Dalam rangka untuk memperbaiki bug, sering menambal sistem dihindari. Sesuai dengan kebijakan terbaik untuk menambal bug, untuk putaran melibatkan beberapa pengujian, patch dari semua bug akumulasi antara dua putaran pengujian dilakukan sekali saja, itu bug yang tetap dan selalu siap untuk patch bersama. Ini juga tidak memiliki aturan keras & cepat. Pengecualian ada untuk bug, yang dianggap kritis & yang parah dapat menghambat pengujian dapat segera ditambal.
($) Sanity Pengujian: Setelah patch selesai, contoh aplikasi untuk menguji kewarasan dikenakan oleh tim pengembangan. Kemudian dilepaskan untuk putaran berikutnya melibatkan pengujian pelaksanaan semua kasus uji lagi. Ini mencakup pelaksanaan uji kasus yang terjadi untuk lulus di babak sebelumnya.
($) Menghentikan Operasi Pengujian: Dalam skenario pengujian beberapa ronde, sebuah keputusan penting harus diambil, apakah untuk melanjutkan ke babak berikutnya pengujian atau menghentikan ada itu sendiri. Keputusan penting untuk sebagian besar tergantung pada jumlah bug yang telah dicatat selama putaran sebelumnya dari pengujian. Dua faktor dapat membantu mengambil keputusan tersebut adalah:
1) pengujian perangkat lunak lebih lanjut dapat berhenti ketika tidak ada bug kritis segar yang terdeteksi & ketika tidak perlu merasa lebih lanjut untuk pengujian regresi.
2) pengujian lebih lanjut dapat berhenti ketika jumlah sangat kurang masalah kecil yang tersisa. Istilah "Kurang" sangat subjektif dan sangat tergantung pada aplikasi yang sedang diuji.
Ingat bahwa setelah kita mampu menunjukkan kemampuan kita untuk secara efektif memahami proses pengujian software, dunia akan terbuka untuk kami dengan banyak peluang pekerjaan pengujian Perangkat Lunak yang besar juga.
Tidak ada komentar:
Posting Komentar