Komunikasi Tester-Pengembang

Sementara banyak yang ditulis tentang pengembang-pengembang, pengembang-klien, pengembang-tim manajer komunikasi, saya tidak dapat menemukan teks yang memberikan pedoman tentang komunikasi dan hubungan pengembang-tester.

Apakah penguji dan pengembang adalah tim yang terpisah atau dalam tim yang sama (dalam kasus saya, saya seorang penguji tunggal dalam proyek pengembangan tangkas), saya memiliki keyakinan bahwa bagaimana penguji dirasakan sangat penting agar pengujian diterima dengan baik. , dan untuk melayani tujuannya dalam meningkatkan kualitas proyek (misalnya, mereka tidak boleh dipandang sebagai pasukan polisi).

Adakah saran, atau studi tentang bagaimana penguji harus berkomunikasi dengan pengembang?

Pembaruan : Terima kasih atas jawaban Anda. Mereka semua membenarkan apa yang ada dalam pikiran saya. Adapun saat ini, tim saya sangat menerima peran saya dan kami akhirnya membuat kemajuan nyata. Saya bisa memilih lebih dari satu sebagai jawaban tetapi saya harus membuat keputusan.

Cara termudah untuk meningkatkan komunikasi adalah bekerja sama dengan pengembang Anda (dan desainer dan arsitek dll) dan perlahan-lahan memecah peran konyol itu dan akhirnya menyadari bahwa kita semua adalah penguji, kecuali bahwa sebagian dari kita memiliki lebih banyak pengalaman daripada yang lain.

Untuk gesit, lakukan saja "dengan buku". Penguji adalah bagian dari tim dan bukan hanya entitas eksternal yang Anda serahkan ketika sudah selesai. Keahlian Anda yang berharga digunakan selama pengembangan keseluruhan . Pertama saat membuat cerita pengguna, Anda membantu menurunkan tes penerimaan dan membuatnya otomatis. Tes-tes ini kemudian digunakan oleh para pengembang dalam pekerjaan mereka. Anda juga menghabiskan waktu setiap hari untuk melakukan uji eksplorasi pekerjaan parsial dan selesai, dan berbicara dengan PO untuk mengklarifikasi dan meningkatkan tes Anda terus menerus.

Itulah yang saya maksud ketika saya berbicara tentang "bekerja bersama". Saya sepenuhnya yakin ini adalah bagaimana komunikasi dalam tim harus bekerja. Artikel ini menjelaskannya dengan sangat baik.

Berseberangan dengan ini, banyak organisasi suka menangani pengembangan dengan menempatkan semua penguji (dan DBA, dan desainer dan programmer) di departemen yang terpisah. Ini bekerja melawan komunikasi dan hanya berfungsi untuk memperkuat ide pengembangan bertahap. Mencoba meningkatkan komunikasi dalam situasi seperti itu adalah mungkin, tetapi perbaikan kecil yang dapat Anda harapkan tidak sepadan dengan usaha. Setidaknya tidak dibandingkan dengan benar-benar menempatkan orang di ruangan yang sama dan membuat tim lintas fungsi.

Saya sangat percaya pada komunikasi APAPUN antara dev dan tes.

Terlalu sering saya melihat pertarungan roti antara masing-masing tim, bolak-balik kecil ("ditutup oleh desain", diikuti oleh "dibuka kembali" dll).

Saya selalu memberi tahu penguji tempat saya bekerja untuk datang dan berbicara kepada saya jika mereka memiliki keraguan sama sekali.

Satu hal yang saya benar-benar BENCI, adalah pengembang yang menjadi sombong tentang pengujian dan membicarakannya, sehingga apa pun yang dapat saya lakukan untuk membina hubungan baik dengan tim pengujian, saya coba lakukan.

Penguji harus sangat jelas dan tepat dengan pengembang saat berkomunikasi tentang kesalahan dan pengujian. Daftar terperinci langkah-langkah untuk mereproduksi kesalahan, tangkapan layar jika perlu ... Deskripsi yang salah tentang kesalahan yang tidak dapat direproduksi atau memiliki langkah-langkah yang tidak jelas untuk mereproduksi akan sangat merusak hubungan pengembang-penguji.

Saya tidak pernah percaya bahwa selalu ada tingkat ketidaksepakatan antara pengembang dan penguji, tetapi saya harus menghadapi situasi ini ketika salah satu sahabat saya mendapat peran penguji di perusahaan tempat saya bekerja dan yang mengejutkan saya dia diberi modul yang sama untuk diuji. bahwa saya sedang berkembang dan itu adalah FUNbekerja nyata dengannya dan saya harus mengatakan bahwa sangat penting untuk memahami pendapat orang lain dalam situasi seperti itu dan memiliki kendali atas egonya sendiri, ini banyak membantu saya dan kita semua berhubungan baik dengan profesional kita komitmen serta tingkat persahabatan pribadi.

Karena Anda menyatakan bahwa Anda adalah satu-satunya penguji dalam lingkungan Agile (dengan asumsi Scrum) mungkin memanfaatkan pertemuan retrospektif sebagai forum terbuka untuk menentukan proses komunikasi yang mungkin dilakukan.

Seperti yang Anda ketahui, pertemuan restrospektif adalah untuk mengatasi kerutan dalam proses Scrum. Ini bisa menjadi item seperti memungkinkan pengembang berjam-jam XY waktu tanpa gangguan, hanya email komunikasi pada hari Senin dan verbal sisa minggu ini, apa pun yang sesuai dengan tim ANDA ; karena komunikasi tidak pernah satu ukuran cocok untuk semua pendekatan.

Sebagai pengembang, saya menghargai tester yang menunjukkan inisiatif. Mereka tidak menarik garis ... mereka ingin cacat diselesaikan; terlepas dari akar penyebabnya. Pengembang dan penguji harus memisahkan perasaan dari bisnis. Cacat adalah bagian dari bisnis karena manusia terlibat. Pendekatan terbaik untuk resolusi cacat adalah tim yang disejajarkan diatur untuk menyelesaikan cacat secara holistik. Ketika garis-garis mulai muncul dan batas-batas diletakkan; komunikasi akan terputus.

Manfaatkan rapat harian Anda. Terlibat sebanyak mungkin; tidak hanya dengan pengujian tetapi dengan produk secara keseluruhan. Pada akhirnya seorang pengembang dan penguji sedang mengerjakan satu tujuan dan harus selalu fokus pada hal itu.

Saya lebih suka melihat penguji sebagai bagian dari tim yang sama. Dalam hal itu tidak ada masalah komunikasi.

Setiap kali seorang tester harus berbicara dengan pengembang atau sebaliknya hanya datang dan mari kita ngobrol. Hanya rutinitas sehari-hari.

Namun, kedua belah pihak harus saling menghormati dan melakukan pekerjaan mereka dengan benar.

Penguji perlu memberikan perincian menyeluruh tentang kondisi bug dan tidak melaporkan sesuatu sebagai bug saat sedang dirancang. Terutama ketika hanya perlu bertanya pada pria di sana tentang sesuatu yang mencurigakan seperti fitur.

Pengembang harus menganggap serius laporan bug dan menyelidiki secara mendalam, bukan hanya menutup masalah jika Anda tidak mereproduksi bug dalam lima klik.

Sikap profesionallah yang dibutuhkan.

Alat nomor 1 yang saya temukan bahwa saya, sebagai tester (SDET), dapat memanfaatkan untuk meningkatkan hubungan dev-test adalah pujian yang jujur, terutama dalam bentuk mencari bimbingan dari para dev.

Mudah-mudahan, pengembang yang bekerja dengan saya adalah pengembang atasan daripada saya. Mereka tidak sempurna, atau saya tidak akan memiliki pekerjaan, tetapi ada banyak hal yang mereka tahu lebih baik daripada saya. Mereka adalah pengembangan murni, sementara perhatian saya sebagian difokuskan pada pengujian. Saya mencatat hal-hal yang mereka lakukan lebih baik, dan saya sering menyebutkannya. Ketika saya membaca kode mereka, saya perhatikan detail elegan atau penggunaan pola desain yang rapi dan membawa mereka dalam percakapan. Saya meniru pengembang, menggunakan konvensi pengkodean yang serupa bila mungkin, dan mengintegrasikan komponen dari produksi ke alat pengujian saya bila perlu (misalnya, logging). Saya mengenali keahlian mereka, dan sebagai hasilnya mereka senang mengakui keahlian saya. Pikiran Anda, jika saya pikir ada cara yang lebih baik untuk melakukan hal-hal maka saya benar-benar berbicara - tetapi saya bertujuan untuk memberikan umpan balik yang lebih positif daripada yang negatif, secara keseluruhan. Secara umum, saya mencoba membuat umpan balik negatif lebih formal dan impersonal (misalnya, laporan bug) dan umpan balik positif kurang formal dan lebih pribadi (misalnya, percakapan langsung).

Memberikan umpan balik positif tentang kualitas serta umpan balik negatif dan meminta saran mengubah hubungan dari menjadi kontroversial menjadi tentang kerja tim dan pembelajaran timbal balik dan menurunkan pertahanan diri. Para pengembang tahu bahwa mereka dapat mempercayai saya untuk selalu mengatakan hal-hal yang lebih baik daripada yang buruk, sehingga mereka merasa nyaman mendengarkan saya. Juga, mengajukan pertanyaan berwawasan tentang pembangunan meningkatkan pendapat mereka tentang saya dan menerobos stereotip "SDET gagal," (di mana ia masih ada).

Saya sangat percaya bahwa komunikasi yang baik antara pengembang dan penguji sangat penting. Adapun cara terbaik untuk melakukan saya yakin bahwa ada banyak pendekatan yang baik tetapi di sini adalah apa yang paling berhasil bagi saya.

Komunikasi langsung / pribadi! Saya telah menemukan bahwa komunikasi pribadi, bukan email, selalu bekerja paling baik. Ini memungkinkan pengembang dan tester untuk membentuk hubungan pribadi. Setelah Anda memiliki hal-hal yang tampaknya berfungsi lebih baik dan cenderung mengalir. Mereka tidak pernah memiliki masalah menjalankan tes khusus atau berusaha keras untuk Anda. Hal yang sama berlaku untuk pengembang dan saya selalu meluangkan waktu ekstra untuk melihat hal-hal yang mereka perlukan atau sedang mengalami masalah. Dalam pengalaman saya itu membuat menyelesaikan masalah lebih cepat, ada lebih sedikit waktu yang terbuang.