Viabilitas Tim Pengembang tanpa peran penguji * berdedikasi * [ditutup]


9

Saya telah banyak berpikir akhir-akhir ini tentang bagaimana membangun tim pengembangan lean. Pada akhirnya, saya ingin membuka rumah perangkat lunak kecil saya sendiri dengan sejumlah kecil orang yang berpikiran sama. Tujuannya bukan untuk menjadi kaya, tetapi untuk memiliki lingkungan kerja yang sehat.

Sejauh ini, saya mendefinisikan tim lean sebagai berikut:

  • Kecil;
  • Mengorganisir diri;
  • Semua anggota harus memiliki QA dalam pikiran;
  • Anggota harus mampu melakukan banyak peran

Poin terakhir adalah di mana saya sedikit khawatir karena, seperti mantra ...

Pengembang membuat penguji buruk.

Sementara saya mengerti bahwa, seringkali, pengembang "terlalu dekat" dengan kode mereka atau kode rekan mereka untuk membuat penilaian kualitas tingkat yang lebih tinggi, saya tidak yakin mereka adalah penguji buruk de-facto . Sebaliknya, saya berpendapat bahwa kualitas pengembang yang baik tumpang tindih dengan kualitas tester yang baik.

Dengan asumsi ini benar, saya telah memikirkan berbagai cara untuk mengatasi masalah dev / tester dan saya percaya saya telah datang dengan model yang layak.

Model saya membutuhkan:

  • Rumah perangkat lunak kecil dengan 2+ proyek
  • Pendekatan Agile (iteratif) untuk pengembangan dan pengiriman
  • 1 tim per proyek
  • Semua anggota tim akan menjadi Pengembang Perangkat Lunak
    • Deskripsi pekerjaan mereka jelas akan menyatakan Pengembangan , Jaminan Kualitas , Pengujian , dan Pengiriman sebagai tanggung jawab

Jika semua prasyarat ini telah dipenuhi, maka proyek dapat diatur dengan cara berikut (contoh ini akan merujuk pada dua proyek, A dan B ):

  • Setiap anggota tim akan berganti-ganti antara peran Pengembang dan peran Penguji
  • Jika anggota tim adalah Pengembang di proyek A , mereka akan menjadi Penguji di proyek B
    • Anggota akan bekerja pada hanya 1 proyek pada suatu waktu, dan karena itu diharapkan akan bertindak sebagai salah satu Dev atau Tester.
  • Sebuah Siklus Peran terdiri dari 3 iterasi sebagai Dev dan 2 iterasi sebagai Tester (sekali lagi, pada dua proyek yang berbeda)
  • Tim proyek akan memiliki 3 Dev dan 2 Penguji setiap saat.
  • Siklus Peran Anggota harus keluar dari fase dengan 1 iterasi.
    • Ini meminimalkan perubahan tim yang mendadak. Untuk setiap iterasi, 2 Devs dan 1 Tester akan tetap sama dengan iterasi sebelumnya.

Mengingat hal di atas, saya melihat Pro dan Kontra berikut:

Pro

  • Mendistribusikan pengetahuan proyek di seluruh perusahaan.
  • Pastikan anggota tim tidak menguji kode yang mereka bantu tulis.
  • Siklus peran di luar fase berarti tidak ada proyek yang pernah memiliki anggota yang beralih 100%.
  • Pergantian peran mematahkan monoton proyek yang membosankan.

Cons

  • Iterasi kedua proyek sangat erat. Jika satu proyek membatalkan iterasi setengah jalan dan mulai lagi, maka kedua proyek akan tidak sinkron. Ini akan membuat siklus peran sulit untuk dikelola.
  • Bergantung pada mempekerjakan Pengembang terbuka bekerja sebagai Penguji juga.

Saya telah menerima tinjauan beragam ketika mendiskusikan pendekatan ini dengan teman dan kolega. Beberapa percaya bahwa beberapa pengembang akan ingin berganti peran seperti ini, sementara yang lain memberi tahu saya bahwa mereka secara pribadi akan senang untuk mencobanya.

Jadi pertanyaan saya adalah: Bisakah model seperti itu berhasil dalam praktik? Jika tidak, mungkinkah itu diubah menjadi model yang berfungsi?

Catatan: Demi singkatnya, saya hanya fokus pada peran Dev dan Tester. Saya akan memperluas peran lain jika diperlukan.



Meskipun ada tumpang tindih mengenai apakah Pengembang dapat atau harus menjadi penguji, saya pikir inti dari pertanyaan ini adalah tentang peran out-of-phase 2 pada model 2 proyek.
MetaFight

2
FWIW pendapat pribadi saya adalah bahwa Anda mengambil risiko cukup banyak dengan pendekatan seperti itu. Saya seorang mantan tester (dan bukan yang terburuk) dan ketika saya pernah mendarat di sebuah proyek di mana saya bisa "menjalin" 2 peran, saya pertama kali berpikir wow, kesempatan untuk mencari cara melakukannya dengan benar. Setelah sekitar setengah tahun saya berubah pikiran dan tidak pernah ingin mencobanya lagi. Kedua peran (dev dan QA) membutuhkan fokus 100% untuk melakukannya dengan benar, tetapi ketika Anda jalin, Anda mengalihkan perhatian dan kehilangan baik dalam kualitas atau dalam produktivitas atau keduanya. BTW mendapatkan penguji khusus dalam proyek itu menghasilkan ROI paling mengesankan yang pernah saya saksikan
nyamuk

2
@gnat, tetapi Anda belum menjelaskan mengapa Pengembang tidak dapat memenuhi peran Penguji. Jika orang yang bersangkutan perlu menganggapnya serius sebagai peran penuh waktu, itulah sebabnya saya menyarankan mereka mengganti proyek dan hanya mengerjakan satu proyek pada satu waktu. Saya tidak berharap ada Pengembang yang bisa melakukan ini ... hanya mereka yang akan menjadi Penguji yang baik seandainya mereka memilih jalur itu.
MetaFight

2
Mengutip apa yang ingin Anda lakukan: "Saya ingin membuka operasi medis, daripada mempekerjakan beberapa ahli anestesi, saya akan mempekerjakan cukup ahli bedah dan memutar mereka dengan seksama peran itu". Proposal Anda menunjukkan kurangnya pemahaman tentang apa yang ditawarkan oleh penguji profesional kepada tim. Anda bisa melakukannya, banyak yang melakukannya, beberapa membuatnya bekerja. Apa yang Anda tidak akan pernah tahu adalah apa yang Anda lewatkan dan apa yang bisa Anda lakukan dengan lebih baik. Omong-omong - Pengujian bukan QA - hanya satu pelajaran yang akan diajarkan oleh penguji profesional kepada Anda.
mattnz

Jawaban:


8

Saya tidak setuju dengan itu

Pengembang membuat penguji buruk

Sebagian besar tim yang saya kerjakan dalam karier saya belum memiliki dukungan QA. Ini termasuk beberapa perusahaan besar dan global yang melibatkan produk seperti sistem masuk dan pendaftaran global mereka. Dalam kasus lain, saya memiliki 30% dari pendapatan perusahaan berjalan melalui kotak di meja saya. (Praktek-praktek ini tidak disarankan BTW;)) Perusahaan-perusahaan ini bergantung pada para insinyur untuk memastikan kode mereka bekerja dengan benar. Dan kami, yang berorientasi pada detail, sedikit kompulsif, dan bangga dengan pekerjaan kami, akan berusaha keras untuk memastikan perangkat lunak kami bekerja dengan benar.

Juga, sebagai pengembang saya melakukan lebih banyak pengujian daripada Penguji. Saya secara rutin menguji unit kode saya hingga 90%, atau 100% jika saya tidak bekerja dengan Java.

Saya suka bekerja dengan Penguji karena mereka datang dari perspektif yang berbeda, dan menangkap hal-hal yang saya tidak pikirkan. Tetapi saya benar-benar tidak mengandalkan mereka untuk menyediakan lebih dari sekitar 30-50% cakupan tes, sementara saya menganggap diri saya bertanggung jawab atas 100%. (BTW Itu bukan slam pada mereka - mereka biasanya menyebar tipis di seluruh proyek.)

Daripada bertanya kepada insinyur dalam wawancara jika mereka ingin melakukan QA, tanyakan: jika ada bug yang muncul dalam produksi, siapa yang bertanggung jawab? Jika saya memperkenalkan bug, dan pelanggan mengalaminya, saya merasa buruk dan bertanggung jawab. Saya tidak menyalahkan orang-orang QA. IMHO Itu jenis insinyur yang ingin Anda pekerjakan (dan bekerja dengan)

Metode saya untuk memastikan kualitas adalah a) pengujian unit super agresif (meskipun saya tidak bisa memaksa diri untuk melakukan Uji-Driven Devlopment penuh), b) proses peninjauan kode yang kuat sangat membantu, dan c) mengintegrasikan intoleransi dan ketidaksabaran dengan cacat ke dalam budaya tim.

Saya selalu tersadar bahwa orang-orang yang paling senior adalah mereka yang paling rajin dan perhatian bahkan terhadap masalah-masalah kecil, karena mereka dapat menunjukkan masalah yang lebih besar. Tetapi terutama mereka adalah orang-orang yang paling bersedia menghabiskan waktu untuk memperbaikinya.

Tetapi sebagian besar tim yang saya kerjakan, terutama untuk perusahaan kecil, belum memiliki komponen QA formal.


6

Saya setuju dengan jawaban @Rob Y, dan ingin menambahkan beberapa poin:

  • Dalam tangkas, penguji yang berdedikasi dalam tim adalah anti-pola, karena mereka memaksa tim untuk bekerja pipa dan secara inheren tidak efisien. Anda terus-menerus berakhir dengan cerita-cerita yang "dev selesai" tetapi tidak diuji. Penguji khusus baik-baik saja jika mereka bekerja di luar tim (atau tim terpisah).

  • Dev membuat penguji buruk ... dan penguji membuat penguji buruk. QA sulit. Faktanya, ini sangat sulit. Masalah Anda mungkin bukan orang dan peran. Masalah Anda mungkin karena perangkat lunak Anda tergeser. Sekali lagi, dengan gesit, adalah tanggung jawab tim Anda untuk menguji sebelum produksi (apakah mereka telah mendedikasikan QA atau tidak).

  • QA adalah bagian dari pengembangan, seperti refactoring, arsitektur, dll. Merupakan tanggung jawab tim pengembangan untuk menghasilkan perangkat lunak dengan standar realistis tertentu yang disepakati. QA tidak akan meningkatkan standar itu. Pengembang yang lebih baik mungkin akan melakukannya.

  • Provokasi: Siapa bilang QA lebih baik daripada pengembang di QA-ing? Itu adalah sesuatu yang orang katakan tetapi ... [rujukan?] Mentalitas "peretas" yang dibutuhkan dari QA adalah mentalitas pengembang. Faktanya, pada dasarnya semua peretas adalah atau pengembang, bukan QA ...

  • Provokasi 2: 99% pekerjaan QA dapat (dan, berani saya katakan, harus ) diotomatisasi melalui skrip. Tim yang baik akan melakukan ini, dan untuk melakukan ini dengan benar, Anda perlu ... pengembang.


Mengomentari Provokasi 2: otomatisasi uji dapat dilakukan oleh pengembang, tetapi tidak harus. Penguji yang tahu cara kode (tetapi tidak pada tingkat pengembang pro) dapat menulis skrip yang cukup baik.
Mate Mrše

4

Pada pekerjaan sebelumnya, kami hanya memiliki pengembang dan tidak ada staf QA. Akibatnya, tidak ada orang lain yang bisa disalahkan jika masalah berhasil sampai ke produksi. Kami mengambil tanggung jawab QA kami dengan sangat serius, dan sangat bergantung pada suite pengujian otomatis. Karena menulis tes otomatis masih dikode, itu bukan masalah besar untuk membuat pengembang melakukannya.

Kuncinya adalah menjadikannya bagian dari budaya tim, dan bagian dari setiap proyek. Kami menulis rencana pengujian (hanya daftar tes singkat yang kami maksudkan untuk sebuah proyek), dan pengembang lain akan meninjau dan menyarankan kasus dan skenario yang kami lewatkan.

Jika Anda teliti tentang hal itu, itu bisa bekerja dengan sangat baik. Itu berhasil bagi kami - kami memiliki waktu kerja yang baik dan cacat rendah dalam layanan web e-commerce yang selalu aktif.


posting ini agak sulit dibaca (dinding teks). Maukah Anda mengeditnya menjadi bentuk yang lebih baik?
nyamuk

2
Maaf, otak-dump pagi. Saya sudah putus sekarang.
Rory Hunter

2

Pertama peringatan - Saya telah bekerja secara profesional sebagai insinyur QA dan insinyur perangkat lunak.

Bisakah model seperti itu berhasil dalam praktiknya?

Apa pun mungkin.

Sementara saya mengerti bahwa, seringkali, pengembang "terlalu dekat" dengan kode mereka atau kode rekan mereka untuk membuat penilaian kualitas tingkat yang lebih tinggi, saya tidak yakin mereka adalah penguji buruk de-facto. Sebaliknya, saya berpendapat bahwa kualitas pengembang yang baik tumpang tindih dengan kualitas tester yang baik.

Tergantung pada jenis pengujian yang Anda butuhkan. Jika Anda membutuhkan pengujian manual berulang-kali yang mematikan, monoton, berulang untuk memastikan bahwa setiap layar atau elemen benar-benar telah diterjemahkan ke Bahasa Elbon ... Anda akan mengalami masalah.

Dan dalam pengalaman saya, setiap proyek membutuhkan setidaknya sedikit pengujian semacam ini (bahkan jika tidak setiap proyek melakukan pengujian semacam itu). Masalahnya adalah Anda tidak mendapatkan pengujian semacam ini dari orang yang tidak terbiasa dengan praktik terbaik QA. Sial, Anda bahkan tidak mendapatkannya dari orang yang tahu praktik terbaik, tetapi "percaya" pada pengembangnya.

Sebagai penguji, Anda tidak bisa mempercayai pengembang. Saya telah kehilangan hitungan bug yang saya temukan bahwa "tidak mungkin disebabkan oleh perubahan itu" atau "bekerja dengan baik di kotak dev saya".

Bahkan jika Anda dapat menemukan pengembang yang dapat mentolerir tidak melakukan apa yang mereka sukai 2 minggu dari 5 Anda juga akan mengalami kontradiksi inti ini. Lebih buruk lagi, Anda menghabiskan waktu dan energi untuk melatih orang untuk menjadi baik di dua pekerjaan daripada satu. Perusahaan memiliki waktu yang cukup sulit untuk menemukan dan melatih orang-orang hebat dalam satu pekerjaan, apalagi dua.

Mungkin Anda luar biasa dalam beberapa hal yang belum saya temui - tapi saya ragu.


Mungkin model saya membutuhkan peran QA Sr untuk meninjau pendekatan yang diusulkan dari penguji dev saya dan untuk merekomendasikan pendekatan praktik terbaik. Oh, dan kebanyakan orang tidak menganggapku keren, tapi ibuku suka :) dan itu cukup baik untukku!
MetaFight

Saya mentransisikan beberapa peran QA kami menjadi Pemilik Produk. Sepertinya Anda tidak memiliki persetujuan pemilik produk akan cerita pengguna atau ulasan sprint. Kedua hal ini akan menangkap banyak masalah yang mungkin terlewatkan oleh tim pengembangan. Namun sebelum itu, jika Anda tidak dapat mempercayai pengembang untuk menghasilkan kualitas, Anda perlu menemukan pengembang yang berbeda. Itulah kesimpulan saya - dalam pengalaman saya - Anda tidak dapat melatih kualitas buruk dari pengembang yang buruk. Saya telah bekerja dengan banyak pengembang "selesaikan pekerjaan", dan ini adalah output yang Anda dapatkan dari mereka. Tim scrum yang baik membutuhkan pengembang yang baik.
David Anderson

0

Saya pikir itu bisa berhasil, tetapi ada beberapa hal yang saya pastikan Anda lakukan.

  1. Menjadi sangat terbuka tentang peran ganda kepada kandidat. Ini bukan untuk semua orang karena berbagai alasan. Jika Anda memiliki terlalu banyak orang yang tidak menyukainya, Anda akan mengalami kegagalan dan pergantian.
  2. Buat rencana di mana Anda dapat mengevaluasi cara terbaik untuk menggabungkan ini dengan tim. Walaupun saya suka fokus pada satu tugas / proyek pada satu waktu, saya tidak yakin saya ingin tidak pemrograman untuk jangka waktu yang sangat lama. Mungkin pengujian adalah liburan yang menyenangkan jauh dari pemrograman. Bukannya lebih mudah, hanya menggunakan beberapa sel otak yang berbeda untuk suatu perubahan. Bersiaplah untuk mencobanya dengan cara yang berbeda sebelum Anda memutuskan apa yang terbaik.

Proyek sinkronisasi sepertinya bukan solusi praktis. Jika seseorang adalah penguji pada suatu proyek, mereka mungkin menjadi kandidat terbaik untuk menggantikan seorang programmer dan sebaliknya.

Rencana ini tidak membiarkan tim cukup mengatur diri sendiri. Satu strategi mungkin tidak cocok untuk semua tim dan semua proyek.


Peran Tester dalam kasus ini mungkin akan melibatkan pengujian manual dan otomatis. Saya berharap pengembang akan menulis tes unit dan integrasi, tetapi Penguji juga akan melakukan hal yang sama. Pembagian yang tepat dari penulisan tes berkode diharapkan akan menjadi keseimbangan alami yang dicapai setelah beberapa iterasi.
MetaFight

Bahkan seharusnya tidak menjadi masalah apakah kandidat bersedia untuk memainkan peran ganda atau tidak. Jika Anda ingin menjalankan perusahaan yang sukses, Anda harus menempatkan orang di mana mereka unggul. Mengapa menempatkan orang pada pengujian yang dapat merancang dan kode 2 sistem yang dapat diandalkan sendiri di mana dibutuhkan tim 4 atau 5 untuk melakukan satu sistem dalam waktu yang sama? Demikian juga, pengujian memiliki keterampilan sendiri untuk dapat melakukannya dengan baik. Kemajuan terbesar dalam peradaban manusia terjadi ketika manusia mulai berspesialisasi. Mengapa menjalankan perusahaan perangkat lunak berbeda dari alam sudah terbukti bekerja dengan baik?
Dunk
Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.