Haruskah kita berhenti berusaha gesit jika QA membutuhkan waktu 12 minggu?

24

Seseorang di perusahaan saya baru-baru ini mengusulkan perubahan pada produk inti kami yang menurut manajer kami harus memicu apa yang saya kira perusahaan saya anggap sebagai siklus QA penuh (yaitu menguji seluruh rangkaian produk dari bawah ke atas). Tampaknya QA kami membutuhkan waktu 12 minggu untuk melakukan siklus QA penuh untuk produk kami. Masalah saya dengan ini adalah bahwa kami mencoba untuk melakukan pengembangan Agile (walaupun sebagian besar berpegang pada pendapat saya). Kami akan melakukan seluruh set sprint dan kemudian melakukan rilis, yang QA akan memakan waktu lama untuk melewati kurasa. Pertanyaannya adalah, jika QA kita akan membutuhkan waktu 12 minggu untuk melakukan pekerjaan mereka, bukankah kita harus berhenti berusaha melakukan Agile? Apa gunanya mencoba melakukan Agile dalam situasi seperti ini?

agile qa David Hosier
sumber
36
Saya berani mengatakan bahwa jika QA membutuhkan waktu 12 minggu, maka Anda tidak "gesit."
SingleNegationElimination
9
Jika tim tidak bertanggung jawab atas kualitas kode yang mereka hasilkan, saya tidak akan menyebutnya tangkas, baik ..
merryprankster
1
@merryprankster Bisakah Anda menguraikan respons Anda? Apakah Anda bermaksud mengatakan bahwa tidak ada gunanya QA menjadi bagian dari tim dan memverifikasi kualitas sebagai bagian dari sprint? Atau maksud Anda bahwa tim harus memverifikasi kualitas sendiri ke titik di mana QA harus diberikan hampir tidak berguna? Atau mungkin makna lain? Saya tidak tahu jawaban yang benar di sini. Saya hanya mencari saran yang bisa saya dapatkan untuk memperbaiki situasi yang saya rasa rusak parah. Terima kasih.
David Hosier
2
Maksud saya tim harus memiliki proses kualitas. Mereka akan melakukan apa yang perlu dilakukan untuk memastikan kualitas yang cukup baik. Ini menjaga umpan balik sesingkat mungkin, dan membuatnya lebih pribadi. Kualitas bukan properti eksternal, itu inheren bagian dari pengembangan.
merryprankster
2
Ini menjadi obrolan, jadi ini akan menjadi komentar terakhir saya. Ya, saya setuju bahwa di dunia nyata, Anda dibatasi oleh lingkungan Anda. Selain itu, Anda harus dapat memilih & memilih cara kerja Anda. Namun, saya pikir itu bukan kelincahan obrolan sejati menjadi fleksibel dalam segala hal, justru sebaliknya: kelincahan membutuhkan disiplin . Salah satu aspek penting dari pengembangan tangkas adalah menjaga umpan balik pendek. Jika Anda memiliki fase QA di luar iterasi, umpan balik terlambat. Jika tim tidak membahas QA sebagai bagian dari iterasi, mereka tidak gesit. Tim dapat memutuskan bagaimana mereka melakukan QA - itu fleksibel - tetapi tim harus melakukannya.
merryprankster

Jawaban:

21

Yah, jawaban langsung untuk pertanyaan Anda adalah Mu, saya khawatir - tidak ada cukup detail untuk membuat tebakan apakah Anda harus berhenti atau tidak.

Satu-satunya hal yang saya cukup positif adalah bahwa tingkat kelincahan harus didorong oleh kebutuhan pelanggan / pasar (yang Anda tidak memberi info tentang).

  • Sebagai contoh, sebagai pengguna IDE saya sangat senang untuk meng-upgrade ke versi baru sekali atau mungkin dua kali setahun dan saya tidak pernah terburu-buru untuk melakukan itu. Yaitu jika siklus rilis mereka adalah 3 bulan ( 12 minggu ) maka saya sangat senang dengan itu.
     
    Di sisi lain, saya dapat dengan mudah membayangkan, katakanlah, perusahaan perdagangan keuangan bangkrut jika dibutuhkan lebih dari sebulan untuk perangkat lunak mereka beradaptasi dengan perubahan pasar - siklus uji 12 minggu dalam kasus ini akan menjadi jalan menuju neraka. Sekarang - apa kebutuhan produk Anda dalam hal ini?

Hal lain yang perlu dipertimbangkan adalah kualitas tingkat apa yang diperlukan untuk melayani kebutuhan pelanggan / pasar Anda?

  • Contoh kasus - di sebuah perusahaan yang pernah saya bekerja, kami menemukan bahwa kami memerlukan beberapa fitur baru dalam produk yang dilisensikan dari beberapa vendor perangkat lunak. Tanpa fitur ini kami sangat menderita, jadi ya, kami benar-benar ingin mereka gesit dan memberikan pembaruan dalam waktu sebulan.
     
    Dan ya, mereka tampak gesit dan ya mereka merilis pembaruan itu dalam sebulan (jika siklus QA mereka adalah 12 minggu maka mereka kemungkinan besar hanya melewatkannya). Dan fitur kami bekerja dengan sangat baik - kira kita seharusnya benar-benar bahagia? tidak! kami menemukan bug regresi showstopper di beberapa fungsi yang bekerja dengan baik sebelumnya - jadi kami harus tetap menggunakan versi yang lebih lama.
     
    Sebulan lagi berlalu - mereka merilis versi baru: fitur kamiada di sana tetapi bug regresi yang sama juga ada di sana: sekali lagi, kami tidak memutakhirkan. Dan satu bulan lagi.
     
    Pada akhirnya kami hanya dapat meningkatkan setengah tahun kemudian begitu banyak untuk kelincahan mereka.

Sekarang, mari kita lihat lebih dekat ke 12 minggu yang Anda sebutkan ini.

Opsi apa yang Anda pertimbangkan untuk mempersingkat siklus QA? seperti yang dapat Anda lihat dari contoh di atas, hanya melewatkannya mungkin tidak memberi Anda apa yang Anda harapkan sehingga Anda lebih baik, lebih gesit dan mempertimbangkan berbagai cara untuk mengatasinya.

Misalnya, apakah Anda mempertimbangkan cara untuk meningkatkan kemampuan uji produk Anda?

Atau, apakah Anda mempertimbangkan solusi brute-force untuk hanya menyewa lebih banyak QA? Betapapun sederhananya terlihat, dalam beberapa kasus ini memang cara untuk pergi. Saya telah melihat manajemen yang tidak berpengalaman mencoba untuk memperbaiki masalah kualitas produk dengan secara buta merekrut lebih banyak pengembang senior di mana hanya sepasang penguji profesional rata-rata yang akan mencukupi. Menyedihkan sekali.

Yang terakhir tetapi tidak sedikit - saya pikir seseorang harus gesit tentang penerapan prinsip-prinsip tangkas. Maksud saya, jika persyaratan proyek tidak gesit (stabil atau berubah perlahan), lalu mengapa repot? Saya pernah mengamati manajemen puncak memaksa Scrum dalam proyek-proyek yang berjalan dengan baik tanpa. Sayang sekali itu. Tidak hanya tidak ada peningkatan dalam pengiriman mereka tetapi lebih buruk, pengembang dan penguji semua menjadi tidak bahagia.

pembaruan berdasarkan klarifikasi yang diberikan dalam komentar

Bagi saya, salah satu bagian terpenting dari Agile adalah memiliki rilis yang dapat dikirim pada akhir setiap sprint. Itu menyiratkan beberapa hal. Pertama, tingkat pengujian harus dilakukan untuk memastikan tidak ada bug yang muncul jika Anda berpikir Anda bisa merilis build ke pelanggan ...

Rilis shippable saya lihat. Hm Hmmm. Pertimbangkan menambahkan satu atau dua suntikan Lean ke dalam koktail Agile Anda. Maksud saya, jika ini bukan kebutuhan pelanggan / pasar maka ini hanya akan berarti pemborosan sumber daya (pengujian).

Saya tidak melihat kriminal dalam memperlakukan Sprint-end-release hanya sebagai beberapa pos pemeriksaan yang memuaskan tim.

  • dev: yeah itu terlihat cukup bagus untuk dilewatkan ke penguji; TA: ya itu terlihat cukup bagus untuk kasus ini jika pengujian-shippable lebih lanjut diperlukan - hal-hal seperti itu. Team (dev + QA) puas, itu saja.

... Poin paling penting yang Anda buat adalah di akhir respons Anda dalam hal tidak menerapkan gesit jika persyaratannya tidak gesit. Saya pikir ini tepat. Ketika kami mulai lincah, kami melakukannya, dan situasinya masuk akal. Tetapi sejak itu, banyak hal telah berubah secara dramatis, dan kami berpegang teguh pada proses di mana hal itu mungkin tidak masuk akal lagi.

Anda benar sekali. Juga dari apa yang Anda gambarkan sepertinya Anda sampai pada kondisi (kematangan tim / manajemen dan hubungan pelanggan) yang memungkinkan Anda untuk menggunakan pengembangan model iteratif reguler alih-alih Scrum. Jika demikian maka Anda mungkin juga tertarik untuk mengetahui bahwa menurut pengalaman saya dalam kasus seperti iteratif reguler terasa lebih produktif daripada Scrum. Jauh lebih produktif - ada hanya begitu banyak overhead kurang, itu hanya jauh lebih mudah untuk fokus pada pengembangan (untuk QA untuk masing-masing fokus pada pengujian).

  • Saya biasanya memikirkannya dalam hal Ferrari (seperti iteratif reguler) vs Landrover (sebagai Scrum).
     
    Saat mengemudi di jalan raya (dan proyek Anda tampaknya telah mencapai jalan raya itu ) Ferrari mengalahkan Landrover.
     
    Ini adalah off-road di mana seseorang membutuhkan jip bukan mobil sport - Maksud saya jika persyaratan Anda tidak teratur dan / atau jika pengalaman kerja tim dan manajemen tidak begitu baik, Anda harus memilih Scrum - hanya karena mencoba go regular akan membuat Anda macet - seperti Ferrari akan macet di luar jalan.

Produk lengkap kami benar-benar terdiri dari banyak bagian yang lebih kecil yang semuanya dapat ditingkatkan secara mandiri. Saya pikir pelanggan kami sangat ingin meningkatkan komponen yang lebih kecil lebih sering. Tampak bagi saya bahwa kita mungkin harus fokus pada rilis dan QA'ing komponen yang lebih kecil di akhir sprint sebagai gantinya ...

Di atas terdengar seperti rencana yang bagus. Saya pernah bekerja di proyek semacam itu. Kami mengirimkan rilis bulanan dengan pembaruan yang dilokalkan dalam komponen kecil berisiko rendah dan QA sign-off untuk ini semudah mendapatkannya.

  • Satu hal yang perlu diingat untuk strategi ini adalah memiliki verifikasi yang dapat diuji bahwa perubahan dilokalkan di tempat yang diharapkan. Bahkan jika ini sejauh perbandingan file bit-demi-bit untuk komponen yang tidak berubah, lakukan atau Anda tidak akan mendapatkannya dikirim. Masalahnya, itu QA yang bertanggung jawab untuk kualitas rilis, bukan kami pengembang.
     
    Adalah sakit kepala penguji untuk memastikan bahwa perubahan tak terduga tidak lolos - karena terus terang sebagai pengembang saya punya cukup hal lain yang perlu dikhawatirkan yang lebih penting bagi saya. Dan karena itu mereka (penguji) benar-benar sangat membutuhkan bukti kuat bahwa segala sesuatu berada di bawah kendali dengan rilis yang mereka uji coba.
agas
sumber
1
Saya pikir ini mungkin respons terbaik mengingat situasi kita saat ini. Bagi saya, salah satu bagian terpenting dari Agile adalah memiliki rilis yang dapat dikirim pada akhir setiap sprint. Itu menyiratkan beberapa hal. Pertama, tingkat pengujian harus dilakukan untuk memastikan tidak ada bug yang muncul jika Anda pikir Anda bisa merilis build ke pelanggan. Kedua, anggap pernyataan pertama itu benar, mungkinkah QA menduplikasi banyak pekerjaan yang seharusnya sudah dilakukan selama pengembangan? Saya pikir mungkin ada sesuatu untuk diatasi di sana, baik di QA kami dan tim pengembangan kami (saya seorang dev).
David Hosier
Namun, saya tidak ingat kami pernah merilis build ke pelanggan setelah sprint. Selain itu, seperti halnya basis pelanggan kami, mereka tidak ingin sering merilis produk lengkap. Pelanggan kami lambat untuk ditingkatkan. Poin paling penting yang Anda buat adalah pada akhir respons Anda dalam hal tidak menerapkan gesit jika persyaratannya tidak gesit. Saya pikir ini tepat. Ketika kami mulai gesit, kami melakukannya, dan situasinya masuk akal. Tetapi sejak itu, banyak hal telah berubah secara dramatis, dan kami berpegang teguh pada proses di mana hal itu mungkin tidak masuk akal lagi.
David Hosier
3
Produk lengkap kami benar-benar terdiri dari banyak bagian yang lebih kecil yang semuanya dapat ditingkatkan secara mandiri. Saya pikir pelanggan kami sangat ingin meningkatkan komponen yang lebih kecil lebih sering. Tampak bagi saya bahwa kita mungkin harus fokus pada melepaskan dan QA komponen-komponen kecil di akhir sprint sebagai gantinya. Kami dapat mempersingkat putaran umpan balik karena pendekatan yang lebih fokus dan memberikan nilai kepada pelanggan lebih cepat. Kemudian kita bisa melakukan rilis produk lengkap di beberapa titik yang merangkum semua bit yang lebih kecil. Maka QA memiliki sedikit hal untuk dilakukan karena sebagian besar telah divalidasi dalam sprint sebelumnya.
David Hosier
1
+1 Saya suka contoh Anda tentang kebutuhan pasar yang berbeda. Seseorang dapat memberikan contoh yang lebih ekstrim. Misalnya perangkat lunak pengontrol untuk mengelola peluncuran roket ruang angkasa. Pelanggan mungkin senang dengan peningkatan setiap lima tahun (hukum fisika tidak banyak berubah), tetapi hanya satu bug regresi tunggal dapat menelan biaya ratusan juta dolar .
MarkJ
14

Oh, aku merasakan sakitmu. Ada beberapa perubahan serius yang perlu Anda lakukan pada tim QA agar ini bisa berfungsi.

Saran saya adalah membagi tim menjadi tiga tim:

Pengujian fitur - Perputaran cepat untuk menguji perkembangan baru.

Pengujian regresi - Pengujian penuh produk sebelum keluar dari pintu. Ini seharusnya tidak memakan waktu 3 bulan, bahkan setelah mengurangi ukuran tim karena sebagian besar bug akan ditemukan oleh tim pertama.

Pengujian otomatis - Menulis rangkaian uji regresi lengkap untuk mempercepat pekerjaan tim pengujian regresi.

Tim ketiga adalah bonus, tetapi jika Anda tidak dapat memiliki dua tim pertama maka Anda juga bisa menjadi air terjun.

pdr
sumber
+1 Pengujian Otomatis - Tes regresi adalah kandidat utama.
Joshua Davis
Saya pikir ini adalah respons yang sangat baik. Saya tidak begitu sadar tentang bagaimana tim QA diatur atau bagaimana mereka melanjutkan pengujian mereka. Tim QA kami ada di India, yang menurut saya bukan bagian dari masalah. Dari apa yang saya mengerti, rencana pengujian mereka tidak dipublikasikan sehingga siapa pun dapat meninjau dan memvalidasinya. Selain itu, karena perbedaan waktu, waktu berbalik dan mundur antara pengembang dan QA sangat buruk. Apa yang harus dilakukan selama satu jam percakapan di meja seseorang berubah menjadi hari-hari email atau komentar JIRA.
David Hosier
13

Sebagai ilustrasi:

masukkan deskripsi gambar di sini

Perhatikan bahwa tim QA Anda mungkin bekerja di luar lingkaran (ATDD), dan Anda sedang bekerja di dalam.

Saya pikir tidak apa-apa untuk bekerja seperti itu; jika Anda dapat membuktikan dalam pengujian otomatis Anda bahwa Anda memenuhi persyaratan pelanggan pada setiap sprint, Anda dapat mengizinkan QA untuk melakukan tes pada waktu luang mereka, dan mendatangi Anda dengan cacat, yang kemudian dapat Anda lakukan dalam sprint berikutnya.

Robert Harvey
sumber
2
Masalahnya adalah Anda mendapatkan laporan cacat dari pekerjaan yang dilakukan 4-6 sprint yang lalu (dengan asumsi sprint 2-3 minggu). Bergantung pada kebijakan dan prosedur QA perusahaan, mereka mungkin benar-benar harus menandatangani sprint sebelum dapat dirilis ke pelanggan. Jadi, ya, Anda memiliki produk yang berpotensi dikirim setelah setiap sprint, tetapi kurang dari 25% dari mereka akan mencapai QA (dengan asumsi bahwa ketika mereka selesai menguji satu kandidat, mereka mulai menguji kandidat yang paling baru) sehingga Anda dapat menunjukkan kepada pelanggan suatu produk setiap beberapa minggu, tetapi mereka hanya bisa mendapatkan satu setiap 12 minggu dan itu akan lebih tua dari apa yang baru saja mereka lihat.
Thomas Owens
Kanan. Saya hanya mendiskusikan ini dengan seorang rekan. Saya katakan kita bahkan belum benar-benar melakukan rilis yang tepat di akhir setiap sprint. Kami membuat build di akhir setiap sprint karena itulah yang Agile katakan harus Anda lakukan, tapi kami tidak punya niat siapa pun pernah melihat build itu. Saya tidak tahu apakah QA mendapatkan bangunan itu atau tidak, tetapi saya dapat memastikan bahwa Anda tidak akan melihat pelanggan di mana pun di akhir sprint. Hanya satu bangunan yang berpotensi resmi, dan itu satu dari sprint terakhir. Dalam pikiranku, itu sama sekali tidak Agile sama sekali. Dengan alur kerja itu, Agile hanya cara untuk mengatur pekerjaan.
David Hosier
Selain itu, saya tidak ingat pernah mendapatkan umpan balik dari QA sampai setelah membangun dari sprint terakhir seperti yang saya sebutkan di atas. Ini memvalidasi poin Anda. Apa yang saya pikir bisa mengarah pada situasi di mana keputusan yang dibuat dalam sprint 1 berubah menjadi keputusan yang salah, tetapi keputusan yang salah itu tidak sepenuhnya terwujud sampai semua pekerjaan selanjutnya dilakukan di atas keputusan yang salah itu. Ini tentu saja dapat menyebabkan sejumlah besar pengerjaan ulang.
David Hosier
8

Sepertinya Anda memiliki masalah "Definisi Selesai".

Mengingat bahwa grup QA Anda bersifat eksternal, dan hanya terlibat pada rilis pelanggan, Anda tidak dapat mengandalkan mereka untuk mendapatkan umpan balik yang tepat waktu tentang masalah. Itu berarti jika Anda ingin umpan balik yang cepat, Anda harus membawa beberapa tingkat pengujian "di rumah" untuk tim.

Perlakukan Grup QA seolah tidak ada. Bertindak adalah jika rilis Anda pada akhir sprint akan digunakan untuk lingkungan Anda yang paling penting pada hari berikutnya. Perangkat lunak tidak selesai sampai siap untuk pergi ke pelanggan.

QA seharusnya tidak menemukan apa pun.

Ini akan lebih sulit untuk dicapai. Anda mungkin akan memiliki beberapa hal yang menyelinap melalui beberapa kali pertama. Tes penerimaan otomatis dan tes "regresi" adalah teman terbaik Anda di sini. TDD akan membantu Anda membangun sebagian besar suite tersebut. Anda harus bisa tahu - dengan cepat - jika Anda telah merusak sesuatu.

Sean McMillan
sumber
3

Apakah Anda memiliki perwakilan pelanggan / pemilik produk yang dapat melihat rilis yang diberikan sebelum QA selesai dengan itu dan memberi Anda umpan balik otoritatif di atasnya? Jika demikian, Anda dapat melakukannya, dan mendapatkan sebagian besar manfaat dari, metode tangkas sambil memperlakukan QA sebagai sumber umpan balik sekunder yang agak lambat. Rilis hanya akan "resmi siap" setelah QA selesai, tetapi Anda tidak perlu menunggu mereka sebelum memulai berikutnya.

Tetapi jika aturan perusahaan mengatakan bahwa pelanggan tidak boleh melihat rilis sebelum QA selesai dengan itu, maka Anda bisa lupa tentang menjadi gesit, sampai Anda berhasil mengubah aturan itu.

Michael Borgwardt
sumber
3

Proses yang Anda uraikan bukanlah proses yang gesit. Tim yang memiliki tingkat kelincahan tinggi mampu memberikan bangunan yang andal dan berpotensi dirilis setiap sprint. Dalam sebagian besar implementasi tangkas, fungsi QA dibangun dalam tim tangkas membantu untuk mencapai tujuan ini.

Jika Anda, pimpinan proyek Anda, pemilik produk Anda dan pengembang tidak bekerja bersama dan Anda tidak memiliki rencana perbaikan (retrospektif) maka beri nama proses Anda sesuatu yang lain dan lanjutkan. Tampaknya masalah tim Anda bukan kesalahan manajer atau QA. Mereka tampaknya bereaksi terhadap beberapa masalah sistemik yang keluar dari organisasi pembangunan. Semua tidak hilang jika tim mau mengambil tanggung jawab dan mulai bekerja dengan pemangku kepentingan.

Anda bisa mencoba tiga hal. Pertama, pastikan setiap pemangku kepentingan memiliki peran yang didefinisikan secara ringkas dan bahwa setiap orang memahami tanggung jawab mereka. Dua, stabilkan build dan dapatkan signoff dari QA tanpa memasukkan lebih banyak perubahan. Tiga, otomatisasi uji institut. Tim QA akan mencintaimu karenanya.

GuyR
sumber
Anda 100% benar. Tiga item Anda adalah saran yang bagus. Saya hanya dapat memengaruhi banyak perubahan sebagai pengembang tunggal, tetapi saya dapat mencoba memimpin dengan memberi contoh dan melihat apakah beberapa orang QA ingin ikut dalam perjalanan. Frustrasi terbesar saya adalah bahwa tidak ada orang lain yang benar-benar peduli, yang jelas merupakan penghalang besar bagi keberhasilan pergantian yang diperlukan. Kebanyakan orang di tim senang untuk melanjutkan dengan status quo; setidaknya itulah kesan saya.
David Hosier
2

Sayang sekali umpan baliknya memakan waktu begitu lama, tapi saya pikir tidak ada gunanya berhenti dengan gesit. Pada akhir sprint (atau pasangan) Anda merilis produk yang Anda yakini dapat dijual di pasaran. Untuk tim Anda gesit membawa kemampuan untuk fokus pada pekerjaan yang harus dilakukan dan menjaga produk yang dapat dilepas. Ketika QA menemukan masalah, saya sarankan untuk membuat laporan bug untuk masalah ini dan mengatasinya dalam sprint berikutnya (jika mereka memiliki prioritas yang cukup tinggi).

Tes lapangan produk kami memakan waktu 8 minggu penuh ditambah bahwa kami bergantung pada petani luar. Masih dengan melakukan lincah kami dapat tetap fokus pada pekerjaan yang ada dan menghasilkan versi baru dengan sangat cepat ketika dibutuhkan.

Masalahnya terletak (di mata Anda) dengan departemen QA dapatkah masalahnya diselesaikan di sana? Sudahkah Anda mendiskusikannya?

refro
sumber
Respons Anda membawa beberapa percakapan yang bagus antara seorang kolega dan saya. Poin utama dalam respons Anda yang membuat saya marah adalah, "Di akhir sprint (atau pasangan) Anda merilis produk yang Anda yakini dapat diluncurkan di pasar." Saya tidak pernah ingat merilis produk pada akhir sprint sampai setelah kami menyelesaikan serangkaian sprint, ia melewati QA, dan kami telah menjalani beberapa putaran perbaikan bug lanjutan. Dalam hal itu, saya pikir kami menggunakan Agile hanya sebagai cara untuk memecah dan mengatur beban kerja kami dan tidak ada yang lain. Kami benar-benar tidak mendapatkan manfaat Agile.
David Hosier
@ David: Saya setuju dengan Anda.
Christopher Mahan
1

12 minggu panjang, tapi semoga QA dapat memberi Anda umpan balik dan laporan bug selama waktu itu (bukan setelah tiga bulan).

Maka Anda masih bisa menanggapi masalah yang paling penting dengan cara yang gesit dan dapat memperbaiki banyak jika tidak semua bahkan sebelum mereka selesai!

Hugo
sumber
-2

Apa yang dilakukan orang-orang QA saat Anda menjalankan beberapa sprint? Kedengarannya mereka merasa perlu menguji segalanya setelah setiap perubahan (Itulah sebabnya mereka menunggu sejumlah besar perubahan.).

Tim pengembang gesit, tetapi perusahaan lain tidak.

Siapa pun yang bertanggung jawab atas QA juga tidak tahu apa yang ia lakukan atau mereka telah melakukan Jedi Mind Trick pada manajemen tingkat atas dan diizinkan untuk mengambil waktu manis mereka. Bagaimana QA bisa lebih lama dari pengembangan?

JeffO
sumber