Mengapa panduan Scrum mengatakan tidak ada penguji?

14

Saya telah membaca Panduan Scrum dari scrum.org dan tertulis:

Tim Pengembangan tidak mengandung sub-tim yang didedikasikan untuk domain tertentu seperti pengujian atau analisis bisnis.

Dalam terjemahan literalnya ini berarti bahwa tidak ada penguji yang membingungkan. Bagaimana mereka bisa menyarankan ini?

scrum

— Pete2k
sumber

4

Dalam terjemahan literalnya, ini berarti tidak ada programmer juga. Tidak ada analis bisnis. Analogi yang tepat adalah bahwa setiap orang adalah orang yang selamat, yang tugasnya adalah melakukan (dan belajar melakukan) segala yang dibutuhkan untuk membantu setiap orang bertahan hidup.

— rwong

3

Tidak, itu sama sekali bukan terjemahan harfiah. Dikatakan tidak ada sub-tim khusus, itu saja. Anda dapat membagi tim Anda menjadi beberapa sub tim untuk mengatasi masalah, tetapi tim-tim tersebut harus dapat mencampur dan mencocokkan dengan mudah. Ia tidak mengatakan apa-apa tentang tidak memiliki penguji.

— zzzzBov

25

Ini berarti bahwa:

Penguji terintegrasi ke dalam alat pengembangan tim pengembangan untuk membantu pengembang menguji serta menguji.

atau:
Tim mempraktikkan Test Driven Development - yaitu Mereka menulis tes otomatis yang melatih sistem.

Salah satu dari ini berarti bahwa tidak perlu untuk tim pengujian yang terpisah.

— ChrisF
sumber

TDD akan menjadi pendekatan yang lebih baik untuk tim startup. Saya sangat yakin bahwa ketika penguji dan pengembang bekerja sama dalam tim pemula, pengujian menjadi masalah. Apa yang kamu katakan?

— Maxood

4

@ Maxood: Saya akan mengatakan bahwa TDD pasti tidak membuat pengujian manual berlebihan. Jika sesuatu menjadi masalah, Anda menyelesaikannya; Anda tidak mulai menghindarinya.

— Michael Borgwardt

@MichaelBorgwardt Sangat benar! Tetapi bagaimana jika Anda menemukan tester Anda sibuk dalam pengujian unit yang terutama merupakan pekerjaan pengembang? Saya merasa opsi sebelumnya hanya akan tersedia ketika datang untuk optimisasi kode dan skalabilitas aplikasi, dll. Apa yang Anda katakan?

— Maxood

7

@ Maxood: Penguji harus, menurut pendapat saya, tidak menyentuh tes unit. Mereka harus mengerjakan tes penerimaan, bekerja sama dengan pengembang, dan memiliki tanggung jawab untuk pengujian manual / GUI. Pengujian unit berada pada level yang hanya menarik bagi pengembang. Piramida tes ( blogs.agilefaqs.com/2011/02/01/inverting-the-testing-pyramid ) juga memiliki responsebilities, pengujian unit = pengembang, pengujian penerimaan = dibagi, pengujian GUI = penguji.

— martiert

12

Dalam terjemahan literalnya ini berarti bahwa tidak ada penguji yang membingungkan ... Bagaimana mereka dapat menyarankan ini?

Ya, ini adalah persis apa yang mereka sarankan. Dengan kata lain - pengembang adalah penguji dan penguji adalah pengembang.

Idenya adalah untuk menumbuhkan kepemilikan dan kualitas kode .

Ini tidak berarti bahwa kode tidak diuji, tetapi bahwa orang-orang yang terlibat dalam penulisan itu adalah orang-orang yang terlibat dalam mengujinya - tidak ada pemisahan tanggung jawab.

Masalah yang coba diatasi oleh pendekatan ini adalah pemisahan yang terlalu umum antara pengembang dan penguji, di mana pengembang akan menulis kode dan "membuangnya ke dinding" ke tim lain dan kemudian bergerak bolak-balik, menunda proyek dan memproduksi perangkat lunak di bawah standar.

— Oded
sumber

2

Saya seorang advokat yang kuat untuk meminta orang A menguji apa yang dikembangkan orang B. Apa yang dimiliki scrum sebagai saran untuk menghindari jebakan "kebutaan kode sendiri" (di mana jika Anda berdua adalah pengembang dan penguji fitur X, Anda tidak menjalankan kode dalam semua hal karena Anda tahu bagaimana kode dikodekan dan menganggapnya harus bekerja, atau secara tidak sadar menghindari titik lemah)?

— Marjan Venema

1

@MarjanVenema - Orang apa yang ditulis A dapat diuji oleh orang B, atau tes otomatis ditulis sebelum kode apa pun ditulis.

— Oded

5

Semua pengembang memiliki kebutaan QA yang tidak pernah hilang. Apa yang terjadi di industri adalah orang-orang bertindak terlalu jauh dengan sistem "QA versus Devs" dan menciptakan sistem "throw over the wall", dan kemudian ada serangan balasan. Pengembang dan QA berhasil dan gagal sebagai tim tunggal, tetapi QA adalah peran dan keterampilan yang berbeda dari pengkodean. Coder perlu dev-test, dan unit testing adalah bagian dari QA, tapi itu bukan fungsi QA keseluruhan. Juga, peran QA sering melibatkan pembuatan dokumentasi di tempat-tempat yang belum begitu "gesit" sehingga mereka berhenti menulis dokumentasi teknis.

— Warren P

6

Menurut pengalaman saya, pemisahan peran itulah yang memungkinkan tester melihat perangkat lunak dari sudut pandang pengguna akhir dan menemukan lebih banyak bug daripada pengembang. Produk yang dihasilkan jelas bukan "sub-standar".

— Giorgio

2

QA dan pengembangan adalah dua peran yang berbeda dengan dua perangkat keterampilan yang berbeda (dan skala gaji). QA yang luar biasa membutuhkan tingkat fokus dan spesialisasi yang tidak akan terjadi jika seseorang melakukan tugas ganda sebagai pengembang dan QA.

— 17 dari 26

2

Bagian mendasar dari hal ini adalah bahwa tanggung jawab pembuat kode adalah menciptakan kode yang berfungsi dan memenuhi persyaratan. Ini membutuhkan pola pikir tertentu - "Kode yang saya tulis melakukan apa yang seharusnya dilakukan."

Mencampur tanggung jawab pembuat kode berarti bahwa pembuat kode sekarang diminta untuk memasuki pola pikir lain untuk kegiatan lain, namun, sebagai seorang pembuat kode, sulit bagi seseorang untuk sepenuhnya menceraikan diri sendiri dari pola pikir itu.

Tanggung jawab penguji adalah untuk menemukan bug dan tempat-tempat di mana fungsi mengalihkan dari fungsi yang diperlukan. Ini membutuhkan pola pikir "Kode rusak dan saya akan mencari tahu caranya."

Demikian juga, seorang analis bisnis sedang mencoba mengidentifikasi persyaratan yang sebenarnya diminta pelanggan. Ini membutuhkan pola pikir lain dari "aplikasi tidak bekerja seperti ini, tetapi seharusnya."

Bagi seorang pembuat kode untuk bekerja dalam kapasitas-kapasitas lain mana pun, ada kemungkinan yang masuk akal bahwa pola pikir akan bertentangan dan pembuat kode akan melakukan sub-par:

Coder / QA - "Kode ini bekerja dengan sempurna, dan saya sudah mengkodekan untuk menangani setiap cara yang mungkin saya pikirkan yang mungkin merusaknya."
Coder / BA - "Kode harus bekerja dengan cara yang saya inginkan dan ini akan menjadi hal-hal yang rapi untuk ditambahkan yang tidak dipikirkan oleh pelanggan.

Ini bukan untuk mengatakan bahwa setiap pembuat kode rentan terhadap masalah ini (saya telah memenuhi beberapa jenis pembuat kode / QA yang sangat berbakat ... meskipun tidak untuk kode yang mereka tulis).

Ini meluas hingga ke tim pengembangan juga. Mencampur tanggung jawab dan pola pikir yang terkait dari tanggung jawab tersebut untuk tim pengembangan kompromi produk akhir (kode).

— geocodezip
sumber

1

Dikatakan tidak ada sub- tim yang didedikasikan untuk pengujian. Itu tidak berarti tidak ada tes yang dilakukan sama sekali. Ini hanya berarti bahwa anggota tim akan melakukan pengujian mereka sendiri, dan sering menguji kode / fitur orang lain. Saya tidak begitu akrab dengan metodologi scrum, tapi saya akan mengambil risiko dan mengatakan bahwa klien juga mungkin terlibat dalam pengujian.

— marco-fiset
sumber

"Klien mungkin juga terlibat dalam pengujian" - ya, tepat sekali, jika tidak, Anda memiliki proyek air terjun di mana definisi yang dilakukan adalah "kami telah mencapai akhir proyek". Itu tidak gesit.

— Robin Green

1

Saya pikir ini sebagian berarti Anda diharapkan untuk menulis tes untuk kode Anda sendiri sehingga Anda tahu itu berfungsi (jika tidak, Anda belum benar-benar menyelesaikannya) dan sebagian bahwa Anda mungkin diharapkan menjadi penguji untuk kode orang lain kadang-kadang .

Daripada membiarkan orang untuk menurunkan pekerjaan kualitas perangkat lunak ke orang lain dan mengabaikannya, ini memaksa semua orang untuk memikirkan kode yang mereka tulis dari perspektif kualitas sepanjang waktu, jadi itu ide yang bagus.

— Matt Gibson
sumber

1

Pernyataan ini pada dasarnya berusaha untuk menghindari kerja diam. Salah satu bagian dari solusi untuk ini adalah praktik-praktik seperti - Pengembangan Berbasis Tes - Pemrograman Pair - Permintaan Tarik - Tes otomasi dan sejenisnya yang semuanya menjadikan pengujian sebagai bagian intrinsik dari proses pengembangan daripada sesuatu yang dilakukan secara terpisah baik di samping maupun di samping. 'setelah'.

Selain itu, ada pembicaraan yang sangat terbatas tentang peran dalam Panduan Scrum. Bahkan, mereka berbicara tentang Tim Pengembangan. Maksudnya adalah Anda menginginkan tim lintas fungsi yang kuat. Ini berarti bahwa tergantung pada apa yang dibutuhkan proyek Anda, Anda memerlukan berbagai keterampilan, seperti UX, BA, QA / Tester, Ops, Coder, dll. Tetapi apakah ini satu atau banyak individu yang meliput ini, tidak masalah.

Tim saya bekerja dengan pasti memiliki QA sebagai peran, karena kami memiliki orang-orang DevOps. Tetapi mereka semua juga Dev, hanya dengan spesialisasi di bidang ini. Triknya adalah tidak jatuh ke silo dan bekerja dalam isolasi.

— pengguna334514
sumber

1

Itu tidak selalu berarti tidak ada penguji. Mungkin saja tim Scrum memiliki penguji yang berdedikasi atau tidak.

Bagi saya, apa arti pernyataan tentang Scrum ini adalah Anda harus memikirkan seluruh jalur pengiriman sebagai satu tim. Menjadi bagian dari tim yang sama menyarankan beberapa hal:

Ada satu perkiraan pada cerita / bug / tugas. Tidak ada estimasi dev dan estimasi pengujian.
Tim tidak memperkirakan cerita dan berkomitmen untuk itu tanpa penguji hadir.
Jika ada yang salah, itu tidak lebih dari kesalahan penguji daripada kesalahan pengembang. Itu adalah kesalahan tim .
Tim tidak perlu meminjam, meminta, atau meminta penguji.
Pengujian adalah bagian dari definisi yang dilakukan. Pekerjaan yang tidak diuji adalah pekerjaan yang tidak lengkap.
Pengembang harus mempertimbangkan testabilitas saat mereka merancang kode mereka.

Jika mereka bekerja bersama satu tim, maka tim berhasil bersama dan gagal bersama. Saya telah berada di tim Scrum yang sangat sukses yang memiliki beberapa penguji. Penguji hadir selama semua standup, sesi perawatan, perencanaan, dll. Jika tidak jelas bagaimana menguji sebuah cerita, tim tidak akan berkomitmen untuk itu. Kami selalu berbicara dengan penguji saat memperkirakan.

Tanda-tanda potensial Anda mungkin tidak benar-benar memperlakukan penguji sebagai bagian dari tim pengiriman, bahkan jika Anda berpikir Anda melakukannya:

Penguji memiliki "QA standup" (ya, saya pernah melihatnya).
Penguji memiliki struktur manajemen yang terpisah.
Anda memiliki petunjuk QA.
Anda sangat bergantung pada tes ujung ke ujung.
Tes ditulis sprint berikut.
Sebagian besar pengujian terjadi pada hari terakhir sprint.

Ini subjektif dan tidak selalu salah. Mereka adalah bendera merah, menurut saya.

Semua ini mengatakan, sangat mungkin untuk memiliki tim Scrum tanpa siapa pun yang memiliki peran sebagai penguji. Itu bisa bekerja dengan baik juga. Terutama jika Anda mengotomatisasi pengujian. TDD juga membantu.

— Brandon
sumber