Haruskah QA menjadi bagian dari departemen pengembangan?

Saya bekerja untuk perusahaan kecil yang telah memiliki departemen pengembangan produk selama beberapa waktu. Namun, yang belum kami miliki adalah grup QA / pengujian.

Kami mencari untuk menambah grup pengujian, tetapi berjuang untuk menentukan di mana yang terbaik untuk menempatkan mereka dalam struktur organisasi perusahaan. Secara khusus, kami akan menyewa posisi "penguji memimpin". Haruskah mereka dimasukkan sebagai bagian dari departemen pengembangan produk, atau haruskah mereka menjadi departemen baru? Haruskah mereka berada di tempat lain?

Perusahaan kami kira-kira terstruktur sebagai berikut:

• CEO
  • CTO
    • Direktur Pengembangan Produk
    • Direktur Layanan Pelanggan
      • Pengembang
    • Operasi VP
      • Insinyur jaringan
  • Insinyur penjualan / penjualan
  • Presiden
    • Pengendali

Ya dan tidak :)

Baik pengembang dan orang-orang QA harus memiliki tujuan yang sama (dan kinerja mereka diukur terhadap itu): memberikan produk yang berkualitas tepat waktu dan sesuai anggaran. Anda dapat mendefinisikan "produk berkualitas", tetapi harus sama untuk kedua kelompok. Mengapa? Karena jika tidak sama, Anda akan mendapatkan dua kelompok dengan agenda yang berbeda dan yang dapat dengan cepat memburuk menjadi situasi yang merugikan produk / perusahaan.

QA harus bekerja (sangat) erat bersama dengan pengembang dan sebaliknya, tetapi keduanya harus benar-benar independen dari yang lain dalam pengambilan keputusan. Bagaimanapun, mereka bertanggung jawab atas aspek-aspek pengembangan produk yang sama sekali berbeda

Cara kami mengaturnya adalah bahwa "Pengembangan Produk" adalah departemen "virtual" yang direalisasikan oleh dua departemen konkret: QA dan Pengembangan. Keduanya melapor kepada anggota tim manajemen yang sama: CTO. Ini memastikan bahwa ada satu orang yang bertanggung jawab atas produk (CTO kami) dan bahwa QA dan Pengembangan keduanya independen satu sama lain.

Itu benar-benar tergantung pada seberapa serius perusahaan Anda tentang QA. Misalnya apakah Anda akan melakukan pengembangan yang digerakkan oleh tes?

Anda menyebutkan "grup pengujian", ini akan menyarankan banyak orang. Jika itu sebenarnya sekelompok orang, mungkin harus departemen terpisah. Namun, teka-teki apa yang saya miliki saat ini, setidaknya memiliki satu orang yang berdedikasi untuk QA dan pengujian? Jika tidak, apakah Anda berencana untuk berdiri dengan grup baru dengan cepat? Jika demikian, ini akan menjadi transformasi organisasi yang substansial dan dapat menyebabkan gesekan besar dengan pengembang Anda saat ini yang perlu mengubah cara mereka bekerja juga.

Jika apa yang Anda rencanakan mempekerjakan satu orang QA sekarang dan mungkin perlahan-lahan menumbuhkan fungsi QA, maka mungkin lebih baik meminta orang itu melapor langsung ke direktur pengembangan produk. Bagian terberat dari pekerjaannya, dan yang paling penting, adalah mentransformasikan budaya organisasi Anda untuk mengintegrasikan QA ke semua langkah proses daripada sesuatu yang dilakukan setelah fakta.

Apa yang belum kita miliki, adalah QA ...

Telah ada yang melakukannya - belasungkawa tulus saya. Baik diberikan di atas saya akan mengatakan mendapatkan tester akan jauh lebih baik daripada apa yang Anda miliki sekarang, tidak peduli di departemen mana mereka akan mendarat.

Selain itu saya merasa aman merekomendasikan departemen terpisah untuk QA.

Saya berpartisipasi dalam dua rilis yang tidak ada henti dari perspektif QA - sekali sebagai tester, yang lain sebagai pengembang. Dalam kedua kasus saya pikir memiliki departemen QA yang terpisah cukup membantu.

Sejauh yang saya tahu ketika penguji berada di departemen terpisah menjadi lebih sulit untuk menyembunyikan masalah kualitas produk di balik "penyelarasan tim" palsu . Ini membantu semua orang untuk memahami dengan jelas apa yang kami lepaskan dan mengapa. Ini pada gilirannya membantu mengelola harapan dan rencana pelanggan untuk pengembangan lebih lanjut.

Dalam hampir semua kasus, QA harus terpisah dari Pembangunan. Sementara tujuan antara kedua departemen adalah sama (melepaskan produk / solusi berkualitas), QA perlu merasa mereka memiliki otorisasi untuk memperbaiki dan membuat saran tentang produk dengan pengembangan, dan berada pada posisi yang sama. Jika kepala QA melapor langsung kepada kepala pengembangan, ini dapat menyebabkan QA mundur selangkah dan berada di bawah kendali pembangunan (dan akibatnya kode / produk yang lebih sembrono didorong ke produksi).

Bergantung pada metodologi pengembangan yang Anda gunakan: jika Anda melakukan agile / lean maka Agile Testing bisa menjadi jalan yang harus ditempuh dan karenanya harus dekat dengan pengembang.

Dari apa yang Anda katakan, Anda memiliki perusahaan yang cukup kecil. Masuk akal bagi saya untuk memanfaatkan ukuran dan kemampuan itu untuk berkomunikasi selagi Anda bisa, sebelum Anda menjadi lebih besar. Ini berarti menjaga mereka dengan perkembangan.

Di perusahaan yang lebih besar ketika Anda memiliki tim Dev dan QA berukuran layak, mungkin masuk akal untuk memisahkan mereka saat itu, dan meminta mereka mempertahankan tujuan tim mereka sendiri, terpisah, dll.

Sekarang, saya juga pasti akan memiliki beberapa posisi QA pertama menjadi posisi SDET ... yaitu. penguji dengan coding chops. Tingkatkan otomatisasi Anda, berjalan dan stabil sejak awal.