Biaya penundaan lebih lama antara pengembangan dan QA

Pada posisi saya saat ini, QA telah menjadi hambatan. Kami telah mengalami kemalangan fitur yang ditahan dari bangunan saat ini sehingga QA dapat menyelesaikan pengujian. Ini berarti fitur yang sedang dikembangkan mungkin tidak diuji selama 2-3 minggu setelah pengembang pindah. Dengan dev bergerak lebih cepat dan QA, celah waktu ini hanya akan menjadi lebih besar.

Saya terus membolak-balik salinan Kode Lengkap, mencari cuplikan "Hard Data" yang menunjukkan biaya memperbaiki cacat yang tumbuh secara eksponensial semakin lama ia ada. Adakah yang bisa mengarahkan saya ke beberapa studi yang mendukung konsep ini? Saya mencoba meyakinkan kekuatan bahwa hambatan QA jauh lebih mahal daripada yang mereka pikirkan.

Anda tidak perlu referensi, IMHO. Inilah yang dapat Anda ( seharusnya ) lakukan:

Hitung Biaya Penundaan! Mari kita asumsikan bahwa diperlukan 1 minggu untuk menguji fitur. Penundaan 2-3 minggu menyiratkan bahwa fitur tidak akan tersedia hingga setidaknya minggu ke-4. Dan itu juga dengan asumsi 100% sukses. Tambahkan waktu perbaikan satu minggu lagi jadi itu sekitar 5 minggu keterlambatan.

Sekarang, jika mungkin, dapatkan akses ke tenggat waktu yang diharapkan dari proyek / fitur. Kapan klien mengharapkannya? Akankah itu tergelincir? Jika tidak, akankah orang lain tergelincir sebagai akibatnya? Jadi seberapa banyak 'rilis' akan ditunda?

Apa 'biaya untuk perusahaan' untuk rilis itu yaitu berapa yang diharapkan klien untuk untung dari rilis itu? Jika mereka mengharapkan $ 5.200 / tahun laba dari rilis itu maka setiap minggu tergelincir biaya $ 100 dalam pendapatan yang hilang. Itulah pandangan klien. Anda mungkin atau mungkin tidak memiliki akses ke data ini, tetapi ada baiknya mempertimbangkan dan menyatakan bagaimana keterlambatan dapat mempengaruhi hubungan.

Sekarang, apa ruginya pengembang? Setelah pengembang beralih ke fitur lain, Anda memintanya untuk memutus siklus mereka dan 'memperbaiki' fitur sebelumnya. Apa kerugian waktu / usaha? Konversikan ke biaya untuk perusahaan dengan menggunakan gaji sebagai kelipatan untuk setiap jam yang terbuang sebagai hasilnya. Anda dapat menggunakannya untuk mengatakan jumlah "laba / pendapatan" yang menjadi "sampah makan".

Apa yang telah Anda temukan dapat dengan mudah dikuantifikasi menggunakan "Cost of Delay" - didukung oleh Don Reinerstein dalam Prinsip-prinsip aliran Pengembangan Produk dan juga oleh Dean Leffingwell dalam Persyaratan Perangkat Lunak Agile. Anda harus dapat mendukung setiap klaim tersebut dengan faktor ekonomi untuk meyakinkan 'kekuatan yang lebih tinggi' yang bahasa utamanya adalah $$ - Anda harus berbicara bahasa mereka untuk meyakinkan mereka :)

Binatang keberuntungan! (pun intended :)

Saya tidak berpikir Kode Lengkap adalah sumber yang tepat untuk Anda di sini. Ini bukan masalah kode, ini masalah proses, dan mungkin masalah manajemen.

Jika bagian dari proses Anda sangat lemah, maka inilah saatnya untuk merobohkan Teori Kendala :

1. Identifikasi kendala tersebut.

   Ini berarti menemukan bagian paling lambat atau paling tidak efisien dari keseluruhan proses. Dalam kasus Anda, ini sedang diuji. Tapi bagian mana dari pengujian? Apakah itu:

   • Mempersiapkan lingkungan pengujian?
   • Menentukan apa yang akan diuji?
   • Tes fungsional (penerimaan)?
   • Tes regresi?
   • Pengujian eksplorasi?
   • Melaporkan bug / cacat dari tes?
   • Menentukan langkah-langkah untuk mereproduksi bug?
   • Dapatkan klarifikasi dari pengembang atau manajer proyek?
   • Memperbaiki masalah yang ditemukan pada tahap QA?

   Ini semua adalah masalah yang sangat berbeda dan membutuhkan solusi yang berbeda. Anda perlu memutuskan mana yang paling mahal / penting. Membenarkannya kepada manajemen seharusnya tidak sulit, karena semua kegiatan di atas menghabiskan waktu (uang AKA) dan hanya beberapa dari mereka yang merupakan nilai tambah waktu.

2. Memanfaatkan kendala.

   Dengan kata lain, optimalkan sekitar proses pembatas. Jangan pernah biarkan penguji menganggur. Ini pada dasarnya berjumlah:

   • Menempatkan penguji di dalam tim pengembangan, jika belum, maka ada umpan balik berkelanjutan dengan pengembang.
   • Memiliki penyebaran pengujian yang sering, jadi selalu ada sesuatu yang baru / tetap untuk diuji.
   • Membuat komunikasi lebih cepat dan lebih sering. Misalnya, pilih pesan instan dari utas email.
   • Memastikan bahwa penguji memiliki alat terbaik yang tersedia (mesin cepat, banyak monitor, pelacakan bug yang disederhanakan, dll.)

   Tahap ini bukan tentang mengoptimalkan proses pengujian itu sendiri (namun), ini lebih tentang mengurangi overhead. Jangan buang waktu penguji. Menghilangkan waktu yang benar-benar terbuang juga harus mudah dijual kepada manajemen.

3. Subordinate kegiatan lain dengan batasan.

   Pada titik ini, penguji sama produktifnya dengan diri mereka sendiri, jadi kita perlu mulai meminjam produktivitas dari bidang lain:

   • Instruksikan pengembang dan staf operasi untuk memberikan prioritas pertama kepada penguji, apa pun yang sedang mereka kerjakan.
   • Jika Anda tidak memiliki tim lintas fungsi, pesan ruang pertemuan setiap hari pada waktu yang telah ditentukan sehingga penguji tidak perlu membuang waktu untuk memesannya.
   • Alihkan persentase pengembang yang lebih besar (dan mungkin operasi) dari pekerjaan fitur; misalnya, fokus pada perbaikan bug, utang teknologi / refactoring, review kode, dan pengujian unit.
   • Tes terus menerus dan bertahap - jangan berkembang selama 3 minggu dan kemudian menendang ke penguji. Biarkan pengembang bekerja membuat kode mereka segera diuji, misalnya dengan perancah atau prototipe UI.

4. Tinggikan kendala.

   Jika penguji bekerja pada kapasitas penuh - baik dalam hal produktivitas dan overhead minimal - dan itu masih belum cukup cepat, maka Anda perlu mulai berinvestasi lebih banyak dalam pengujian.

   • Jika Anda mengandalkan penyebaran uji manual, otomasi melalui penggunaan skrip manajemen konfigurasi dan integrasi berkelanjutan.
   • Jika rencana pengujian membutuhkan waktu lama untuk dibuat, berusahalah untuk mendapatkan kriteria penerimaan yang lebih baik (yaitu INVEST ). Sebagian besar organisasi pada awalnya sangat buruk dalam hal ini.
   • Jika tes penerimaan terlalu lama, mulailah mengotomatiskannya. Gunakan alat seperti Mentimun atau FitNesse, atau tulis tes tipe xUnit jika Anda harus. Ada juga Selenium, Watij, dan alat otomatisasi browser lainnya jika pengujian UI membutuhkan waktu lama.
   • Jika tes regresi terlalu lama, otomatiskan juga. Jika tidak dapat diotomatisasi, fokuslah pada peningkatan kualitas di luar gerbang, yaitu dengan penekanan lebih besar pada tinjauan kode, pengujian unit, alat analisis statis, dll. Pengembang harus cukup yakin bahwa ada sangat sedikit bug aktual sebelum melewatinya ke QA (cacat produk adalah cerita yang berbeda).
   • Jika pengujian eksplorasi adalah hambatan, Anda berpotensi menunda beberapa hal sampai setelah rilis, atau mengontrak perusahaan pengujian untuk melakukan hal-hal yang sangat paralel seperti menguji alur kerja yang sama di beberapa browser.
   • Jika penguji tidak dapat mereproduksi banyak bug, pertimbangkan untuk membangun lingkungan pengujian kapasitas untuk dapat mulai mereproduksi kesalahan intermiten. Atau, coba jalankan tes penerimaan otomatis Anda secara paralel dan terus menerus, sepanjang hari, dengan menyimpan catatan terperinci.
   • Jika terlalu lama untuk memperbaiki bug, maka mulailah mempartisi proyek-proyek Anda dan / atau secara serius mempertimbangkan untuk menyusun ulang solusi Anda. Atau, alternatif, jangan perbaiki beberapa di antaranya; tidak setiap bug sangat penting, Anda harus dapat memprioritaskannya di samping fitur kerja.
   • Jika semuanya gagal, pekerjakan lebih banyak penguji.

5. Kembali ke Langkah 1.

Saya ingin mengatakan bahwa ini semua masuk akal, tetapi sayangnya tidak, paling tidak di sebagian besar organisasi. Jika Anda mendapat banyak perlawanan dari manajemen, teknik yang tak ternilai adalah Value Stream Mapping (teknik dari lean manufacturing), yang dapat Anda gunakan untuk menunjukkan berapa banyak waktu dan karena itu uang benar-benar terbuang setiap hari oleh kandidat pelepas yang tidak dapat untuk pindah ke tahap berikutnya. Biaya peluang sulit untuk dipahami tetapi ini adalah salah satu cara terbaik yang saya temukan untuk memvisualisasikan dan menunjukkannya.

Dan jika tidak ada yang berhasil ... maka mungkin Anda berada di perusahaan yang disfungsional, keluar sebelum terlambat!

Tetapi Anda tidak akan menyelesaikan masalah ini hanya dengan menjatuhkan beberapa lembar kertas di meja manajer dan meminta mereka untuk melemparkan uang ke masalah tersebut, karena mereka akan berasumsi (dengan benar) bahwa melemparkan uang kepadanya mungkin tidak benar-benar menyelesaikannya, dan bahkan mungkin menghasilkan lebih buruk. Anda perlu memberikan solusi , dan itulah jawabannya. Jika Anda memperkenalkan masalah ini sebagai "berikut daftar cara kami dapat mulai memecahkan masalah ini, dalam urutan biaya / manfaat" daripada "kami membutuhkan lebih banyak penguji", maka Anda akan lebih sukses.

Halaman 29 dan 30 mungkin memiliki data yang Anda cari, meskipun mungkin diperlukan tindak lanjut.

Saya akan melihat penelitian yang disebutkan dalam kalimat ini di halaman 30:

Lusinan perusahaan telah menemukan bahwa hanya berfokus pada memperbaiki cacat lebih awal daripada kemudian dalam suatu proyek dapat memangkas biaya dan jadwal pengembangan dengan faktor dua atau lebih (McConnell 2004).

BTW, itu pertanyaan Anda yang membuat saya mengambil buku itu lagi untuk menyegarkannya :-)

Apa yang Anda gambarkan adalah hambatan dalam suatu proses. Teori lean menyatakan bahwa akan selalu ada hambatan dalam suatu proses, tetapi tingkat keparahannya dapat sangat bervariasi. Jika QA menyewa satu ekstra, maka pengembangan mungkin menjadi hambatan.

Untuk memahami biayanya, bayangkan situasi berikut. Anda memilih salah satu pengembang. Karyanya tidak akan pernah Terjamin Kualitas, tetapi selalu antri tanpa batas. Bayangkan, ini akan berarti bahwa QA dapat Memastikan Kualitas pekerjaan para pengembang lainnya secara tepat waktu dan tidak akan ada biaya keterlambatan.

Dalam skenario itu, biaya keterlambatan adalah biaya gaji pengembang, karena pekerjaannya akan sia-sia.

Alasan mengapa saya berdebat dalam hal biaya dan bukan nilai yang diciptakan oleh proses, adalah hanya karena lebih sulit untuk mendokumentasikan nilai suatu proses, meskipun itu jauh lebih baik.

Saya terus membolak-balik salinan Kode Lengkap, mencari cuplikan "Hard Data" yang menunjukkan biaya memperbaiki cacat yang tumbuh secara eksponensial semakin lama ia ada. Adakah yang bisa mengarahkan saya ke beberapa studi yang mendukung konsep ini?

Biaya eksponensial untuk menemukan bug tampaknya didasarkan pada studi NIST . Penelitian ini adalah survei mengasumsikan tahapan air terjun yang berbeda:

Software Development Stage         | Cost
-----------------------------------+------
Requirements and Design            | 1X
Code and Unit Testing              | 5X
Integration and System Testing     | 10X
Beta Testing                       | 15X
Post Release                       | 30X

( meja di sini dari sini )

Salah satu tujuan dari metodologi pengembangan perangkat lunak Agile adalah untuk menghapus tahapan yang berbeda ini dan mengurangi biaya ini. Angka-angka tidak berlaku ketika menggunakan metodologi lain untuk air terjun.

Masalah Anda tidak dengan QA, pada kenyataannya, jika QA Anda melakukan Pengujian, keterlambatan adalah yang paling sedikit dari kekhawatiran Anda. Tolong izinkan saya expalin (sekali lagi, karena itu kesalahpahaman umum dalam industri Pemrograman) ... QA Menjamin kualitas produk dengan mengawasi seluruh SDLC, dari Persyaratan (mungkin sebelumnya), melalui pengembangan, verifikasi, rilis, dan dukungan. Pengujian memastikan bahwa tidak ada cacat yang jelas dalam kode. Ada perbedaan yang sangat besar dan penting. Jika Anda memiliki QA yang benar, mereka akan berada di seluruh bagian Uji / V&V yang menanyakan mengapa mereka menghabiskan waktu bisnis (dan karena itu uang) menunda rilis, atau seluruh manajemen proyek memastikan mereka mengelola penjadwalan proyek dengan benar, atau seluruh pembuatan manajemen yakin ada cukup penguji untuk kode yang diproduksi dll ...

Jadi anggaplah dengan QA maksud Anda benar-benar Uji, kembali ke pertanyaan awal. Kode Lengkap sudah benar - biaya cacat adalah waktu yang dibutuhkan dari penyisipan ke koreksi. Deteksi dini hanya berguna jika Anda juga memperbaikinya sejak dini, tetapi sebagian besar interpretasi orang salah.

(Catatan: Saya bermain sebagai pendukung Iblis di sini, jangan anggap ini benar-benar terjadi karena saya tidak tahu apa-apa mengenai situasi Anda). Penyebab keterlambatan oleh departemen Tes Anda adalah biaya, benar-benar, bagaimanapun, saya harus bertanya, jika Anda menunggu mereka untuk menemukan cacat Anda, apa yang Anda lakukan - jika Anda tidak menemukan cacat Anda sendiri? Mungkin jika mereka memiliki lebih sedikit pekerjaan (melalui input berkualitas lebih tinggi dengan lebih sedikit cacat dari Anda), penundaan tidak akan sepenting dan biaya lebih rendah - sebagai manajer saya akan bertanya kepada Anda bagaimana Anda berencana untuk mengurangi cacat dalam kode yang Anda kirim ke tes, karena (berdasarkan argumen Anda) cacat tersebut lebih mahal jika ditemukan dengan tes sendiri.

Juga sebagai manajer Anda, saya mungkin menyatakan bahwa bukan pekerjaan Tes menemukan cacat Anda, Tugas mereka adalah untuk menemukan tidak ada cacat - jika Anda mengharapkan mereka menemukan cacat, mungkin Anda belum melakukan pekerjaan Anda dengan cukup baik.

Hati-hati bagaimana Anda mendekati ini. Jika Anda tidak memiliki solusi untuk masalah tersebut, Anda kemungkinan akan menjadi yang terbaik kedua.