2.10 Bisnis Pengujian dalam Proyek


Melibatkan Pengguna Estat sebagai Langkah Pengujian Penting 

Pengguna yang sebenarnya akan memberikan umpan balik yang sangat berharga.
Pernahkah Anda terlibat dengan sebuah proyek yang tidak memberikan apa yang diharapkan?
Proyek ini mungkin telah gagal untuk memenuhi harapan karena proses baru atau sistem tidak bekerja dengan baik. Mungkin pengguna tidak mengikuti prosedur baru dan masalah yang disebabkan bagi orang lain. Atau mungkin mereka tidak bisa memahami pelatihan atau dokumentasi mereka akan diterima.


Apakah Anda ingat orang yang mendengar mengatakan hal-hal sepeerti "Itu lebih baik cara kita yang sebelumnya telah melakukannya "?
Jadi, bagaimana Anda bisa menghindari masalah ini?
Efektif "Bisnis Pengujian" dapat membantu. Pengujian memiliki peran mendasar dalam memastikan bahwa proyek-proyek Anda 'produk akhir yang berhasil dikirim.

Bisnis pengujian (juga dikenal sebagai Pengujian Penerimaan Pengguna, atau
User Acceptance Testing-UAT) biasanya dilakukan oleh orang yang akan menggunakan produk dalam praktek. Hal ini memastikan bahwa perubahan yang diusulkan benar-benar bekerja - SEBELUM mereka dimasukkan ke dalam digunakan.

Pada artikel ini, kami akan menunjukkan Anda bagaimana menyiapkan tes bisnis yang sukses. Ini akan membantu Anda melibatkan pengguna bisnis dan stakeholder lainnya untuk memeriksa bahwa proyek Anda memberikan hasil yang diinginkan. Hal ini juga membantu Anda memastikan bahwa sistem dan prosedur Anda menerapkan bekerja secara efisien, efektif dan akurat.
 

Pengujian fase Model - V
  • Komponen pengujian
  • Antarmuka pengujian
  • Sistem pengujian
  • Pengguna pengujian penerimaan
  • Rilis pengujian
Fase-fase dalam siklus V-model yang tercantum di bawah, tetapi ada label lain dan jenis lainnya pengujian. Yang menyenangkan tentang model V-adalah bahwa setiap tingkat pengujian dapat didamaikan kembali ke tahap desain. Jadi, misalnya untuk pengujian penerimaan pengguna menjadi cara mengecek apakah persyaratan bisnis telah dipenuhi, seperti pengujian antarmuka dapat menguji apakah desain sistem mendapat hal yang benar. 
Siklus pengembangan perangkat lunak dapat direpresentasikan dalam sejumlah cara. Satu kerangka populer bagi orang-orang yang terlibat dalam kualitas dan pengujian adalah Model V.

Model V memetakan tahap utama dari perangkat lunak (atau produk) proses pengembangan dan sesuai tahapan masing-masing dengan jaminan kualitas tertentu atau kegiatan verifikasi. Ini berlaku umum bahwa semakin cepat Anda mengidentifikasi masalah dan berurusan dengan mereka, semakin rendah biaya koreksi atau perbaikan.

Untuk manajer proyek dan analis bisnis mengembangkan dan menjelaskan beberapa kegiatan manajemen mutu dengan cara yang jelas dan ringkas. Untuk penguji dan kualitas manajer itu mungkin merupakan bagian integral dari toolkit. Bagi saya itu diperluas apresiasi saya tentang peran kualitas dan pengujian dan memberitahu saya dari sebuah struktur yang tersedia untuk digunakan untuk proyek-proyek saya.

V-Model; Nilai kualitas dan pengujian 

Mengapa tes? Mengapa memvalidasi? 
Nilai dari pengujian juga dapat digambarkan sebagai biaya kualitas.

Banyak proses dan kualitas guru menulis tentang di situs ini menulis tentang topik ini tahun yang lalu dan ketika Anda melihat model di bawah itu harus, jika tidak akrab, setidaknya secara intuitif benar.

Semakin awal Anda mengatasi masalah yang lebih murah mereka untuk memperbaikinya.



Berikut adalah contoh konstruksi; Ketika membangun sebuah  pembangun rumah berhenti dan memeriksa plat beton sebelum  membangun sisa bangunan. Jika dia tidak, dan bergegas ke dinding dan atap gedung, mungkin dia menemukan ada masalah dengan pondasi dan harus membongkar bangunan bawah dan mulai lagi, membuang banyak pekerjaan dan bahan.

Hal yang sama dapat diterapkan untuk semua jenis hampir semua proyek, dan terutama besar proyek perangkat lunak yang kompleks.



Ada juga ide mengelola kualitas dalam, daripada mengelola cacat keluar.

Menarik cacat keluar dari jalur produksi adalah salah satu cara meningkatkan kualitas bagi pelanggan, tetapi hari-hari itu diterima secara umum bahwa Anda ingin mencabut cacat dari proses produksi itu sendiri, sehingga tidak membuat cacat dan sehingga Anda bisa mendapatkan tertinggi hasil keluar dari jalur produksi Anda.
Dalam pengembangan perangkat lunak ini dilakukan oleh dua aliran kegiatan; validasi persyaratan dan desain solusi, biasanya dengan review dokumen, dan juga dengan memastikan bahwa sistem fungsional, kuat dan memenuhi persyaratan pelanggan sebelum melepaskannya ke dalam produksi.
Dengan cara itu, setelah pengguna telah login untuk pertama kalinya pada sistem yang memungkinkan melakukan seperti yang diharapkan, dan workarounds proses tidak akan diminta untuk melakukan smoke and mirror tricks sehingga pelanggan mengalami pengalaman berkualitas.

V-Model: Proses Pembangunan

Model V seperti yang dirancang dibangun untuk proses pembangunan air terjun proyek tradisional.

Proses validasi ini sejalan dengan pemerintahan dan perencanaan artefak seperti dokumen persyaratan dan desain solusi.

Proses pengujian juga sejalan tapi kurang erat dengan proses pembangunan air terjun dan dapat diterapkan apapun kerangka pembangunan yang digunakan. Sebagai contoh, jika Anda menggunakan Agile Anda bisa menerapkan model V-tes untuk setiap iterasi dari perkembangan Anda.


Tahapan khas dari SLDC air terjun adalah:
  • Kasus Bisnis
  • Bisnis Persyaratan
  • Solusi Arsitektur atau Spesifikasi Sistem
  • Desain Sistem
  • Komponen Desain
  • Komponen Konstruksi
Untuk masing-masing tahap ada latihan validasi yang dapat dilakukan pada jalan melalui proses pembangunan, dan aktivitas pengujian daripada yang dapat dilakukan pada jalan keluar dari pengembangan pada cara untuk produksi.

Untuk sekarang di sini adalah model sebagai diagram. Anda dapat klik gambar untuk mendapatkan tampilan yang lebih besar.


V-Model: Verifikasi dalam perjalanan ke pengembangan

Ini mungkin memperluas model V di luar desain aslinya itu, tapi saya pikir itu sebuah konsep yang bermanfaat. Selama fase perencanaan, analisis dan desain proyek ada kesempatan untuk memvalidasi desain poin sepanjang jalan.

Metode yang paling umum adalah untuk persetujuan formal dari milestone dokumen seperti spesifikasi persyaratan, dokumen solusi desain dan sebagainya. Karena setiap dokumen-dokumen yang dihasilkan mereka beredar, disosialisasikan dan dinilai oleh para ahli subjek yang relevan.

Analis bisnis memiliki banyak berkontribusi pada fase ini karena mereka mempertahankan sejumlah besar keahlian subyek di sekitar kebutuhan bisnis dan proses bisnis lebih lanjut. Dengan demikian mereka secara unik mampu berpartisipasi dalam review dan pekerjaan penilaian di sepanjang siklus hidup proyek.

Para analis bisnis dapat bekerja sama dengan stakeholder dan menawarkan rekomendasi untuk persetujuan atau penolakan atas dokumen desain, dan membantu mengidentifikasi atau mengembangkan non-teknis solusi kesenjangan dalam desain solusi.


Manajer proyek  juga harus  berencana untuk memiliki diskusi penuh dan jujur
​​dengan analis bisnis tentang kesesuaian solusi. Apakah ada cara yang lebih murah non teknis atau lebih baik memecahkan masalah? Setelah semua teknologi akan fokus pada penyediaan solusi berbasis teknologi, tetapi mereka tidak selalu yang terbaik. Misalnya suatu kegiatan dapat outsourcing untuk laba atas investasi.
 
Pada akhir fase menganalisis dan merancang persyaratan dan solusi harus telah divalidasi oleh manajer proyek analis, bisnis dan sponsor.

Stakeholder views seharusnya mendengar dan mengerti dalam konteks tujuan proyek dan tim proyek harus merasa bahwa ada kesempatan yang baik dari proyek yang bel untuk menyampaikan apa yang berkomitmen untuk.


V-Model: Test dan Verifikasi di jalan keluar


Setelah perkembangan yang sebenarnya telah dilakukan Anda ingin menguji untuk memastikan memenuhi spesifikasi. Sekali lagi matematika memungut cacat awal berlaku. Semakin awal Anda menemukan kesalahan mudah untuk memperbaikinya.

Sepertinya ini adalah salah satu kekuatan dari sebuah pendekatan pengembangan tangkas, Anda menempatkan komponen fungsional ke dalam produksi atau setidaknya sebuah ruang tes sedini Anda sehingga dapat Anda dapat mengambil masalah. Terlepas dari metode prinsip masih berlaku.

Fase-fase dalam siklus V-model yang tercantum di bawah, tetapi ada label lain dan jenis lainnya pengujian. Yang menyenangkan tentang model V-adalah bahwa setiap tingkat pengujian dapat didamaikan kembali ke tahap desain. Jadi, misalnya untuk pengujian penerimaan pengguna menjadi cara mengecek apakah persyaratan bisnis telah dipenuhi, seperti pengujian antarmuka dapat menguji apakah desain sistem mendapat hal yang benar.

V-Model Pengujian fase
  • Komponen pengujian
  • Antarmuka pengujian
  • Sistem pengujian
  • Pengguna pengujian penerimaan
  • Rilis pengujian

Peran analis bisnis dalam tahap siklus pengembangan adalah untuk bertindak sebagai penilai dan komunikator. Peran Anda adalah untuk memahami apa yang penguji lakukan, apa hasil yang mereka dapatkan dan dapat dengan jelas menjelaskan apa yang berarti bagi para pemangku kepentingan bisnis.

Hal yang perlu dipertimbangkan meliputi; 

  • Bila Anda tidak mengerti apa yang ada dalam rencana uji; meminta manajer pengujian atau pengembang untuk menjelaskannya.
  • Bila Anda berpikir Anda melihat kesenjangan dalam perencanaan, mengangkat isu tersebut sampai Anda puas, ini adalah persyaratan Anda yang sedang dilayani setelah semua.
  • Bila ada bug atau masalah, memahami mereka dalam konteks solusi penuh sebelum menaikkan alarm, tetapi jika hal-hal yang benar-benar tidak bekerja, biarkan orang tahu.
Anda dapat mengatur kesalahan atau kerusakan seperti Anda mengelola isu-isu proyek dan risiko, mereka harus secara jelas diartikulasikan dan memiliki pemilik, rencana aksi dan tenggang waktu. Jika Anda tidak menetapkan waktu masalah itu dapat memiliki dampak jadwal keseluruhan proyek. Jika masalah tidak diselesaikan dengan tenggang waktu  yang mengendor akan meningkatkan masalah ke tingkat yang baru.

Banyak analis bisnis juga sangat terlibat dalam pengujian penerimaan pengguna (UAT). Bisnis analis (dan jenis lain dari manajer persyaratan) harus terlibat dalam UAT sehingga mereka memiliki pemahaman yang rinci dan menyeluruh dari kedua proses validasi dan useability sistem baru dan proses. Dengan berpartisipasi penuh dalam kegiatan ini Anda dapat mengidentifikasi aspek-aspek buruk dibangun dari sistem dan daerah di mana proses bisnis perlu ditingkatkan.

Anda juga memperdalam keahlian pokok Anda dalam larutan, yang berguna untuk pekerjaan manajemen perubahan yang datang pada tahap pelaksanaan proyek.

Memperluas V-Model; Centang keberhasilan proyek

Bayangkan memperluas model V menjadi bentuk centang.

Pikirkan tentang model V-seperti: miring ke bawah selama fase perencanaan dan pengembangan, sisi kanan V naik selama melakukan latihan pengujian nd validasi, dan kemudian, kaki manajemen organisasi dan perubahan proyek memperluas dan luar teknis pekerjaan.

Hal-hal di sebelah kanan harus, sesuai dengan kerangka kerja, akan menguji memvalidasi kegiatan.

Mereka bisa kegiatan seperti perjanjian transisi bisnis, atau serah terima dari tim proyek untuk operasi atau pelaksanaan indikator kinerja baru dalam modus baru operasi. Ini mengakui langkah-langkah yang membantu bermigrasi kiriman proyek ke negara masa depan bisnis '. 





0 comments:

AddThis