Bagaimana mendorong klien untuk melakukan beberapa pengujian QA internal?


14

Pembaruan / Klarifikasi Klien saya memahami kebutuhan untuk pengujian in-house mereka dan dia selalu bersumpah mereka akan "berbuat lebih baik" (yaitu melakukan sesuatu) tetapi itu tidak terjadi. Mereka tidak memiliki anggaran untuk pengujian luar. Saya kira saya bertanya (samar-samar, saya tahu) tentang apa yang bisa menanamkan "tes awal, tes sering, tes pada etos mesin target?

Pertanyaan: bagaimana mendorong pengguna untuk meluangkan waktu untuk secara eksplisit menguji dan melaporkan masalah dengan rilis baru, bukan untuk "menguji-saat-mereka-pergi" dalam proyek-proyek produksi.

Latar Belakang: Saya memiliki klien kecil yang telah menulis serangkaian alat presentasi multimedia. Mereka adalah klien yang baik dan kami memiliki hubungan yang baik. Proyek ini sedang berjalan, menambah fitur seiring berjalannya waktu.

Ada dua masalah yang saya miliki:

  1. Definisi fitur dilakukan sambil jalan, sering melalui telepon, dapat berubah, revisi, pembalikan. (sedikit seperti Kennedy "Kami akan pergi ke bulan dan melakukan hal-hal lain" - Saya selalu terhibur oleh bagian "hal-hal lain" itu)

  2. Sebenarnya tidak ada pengujian QA yang dilakukan pada akhirnya.

Saya bisa berurusan dengan # 1, lebih atau kurang. Ini bukan klien yang bahkan akan membaca spec sebelum rapat, apalagi menulis satu. Saya sudah terbiasa dengan itu. Ini adalah item # 2 yang saya miliki masalah: mereka tidak atau tidak akan menguji rilis baru. Apa yang mereka lakukan adalah menggunakannya untuk produksi sehingga ketika bug muncul, mereka menemukan solusi dan tidak melaporkannya, atau mereka sangat terburu-buru untuk melanjutkan proyek, sehingga laporan bug tidak jelas.

Kami telah melakukan banyak diskusi tentang semua ini, tetapi saya hanya bisa sedikit mendorong mereka (misalnya kami menggunakan github untuk melacak masalah - meskipun sebagian besar saya menggunakannya). Alasan dasarnya ada dua: mereka adalah perusahaan konsultan kecil dan tidak memiliki (atau tidak berpikir mereka memiliki) sumber daya untuk pengujian (atau anggaran untuk melakukan outsourcing). Dan budaya: meskipun mereka menganggap diri mereka sebagai "pengembang" mereka benar-benar hanya pengguna paket perangkat lunak multimedia. (misalnya mereka tidak memiliki perhatian neurosis obsesif terhadap detail pengembang "nyata").

Ini memengaruhi saya seperti yang Anda harapkan: tanpa umpan balik saya tidak bisa memastikan apakah suatu fitur sudah lengkap (lihat # 1), atau jika ada konsekuensi lain. Itu juga membuat saya sedikit malas.



3
Jika bug sangat kecil sehingga pengguna sendiri tampaknya tidak peduli apakah itu diperbaiki atau tidak, mengapa Anda bersikeras?
kamilk

2
@ kamilk - jawaban singkatnya adalah saya berinvestasi pada klien saya dengan baik, produktif, dll. Jawaban panjangnya adalah sering kali bukan hanya masalah bug "kecil" - mungkin juga masalah kegunaan, implementasi fitur hilang, dll. Jika saya tidak mengetahuinya, saya tidak bisa memperbaikinya. Juga, "solusi" yang mereka buat seringkali merupakan pemborosan waktu yang sangat besar bagi mereka atau bahkan tetap dengan versi perangkat lunak sebelumnya.
No Grabbing

18
Jika Anda berinvestasi pada klien Anda dengan baik; Anda harus melihat pengujian yang sangat solid sebelum melepaskannya. Klien bukan penguji. Menyewa penguji, atau melakukan pengujian Anda sendiri, atau menulis tes berkode, tetapi jika Anda ingin merasa sangat yakin barang-barang Anda bekerja untuk klien Anda, tes sebelum Anda memberikannya kepada mereka.
Jimmy Hoffa

4
@djechlin - ini tentang pengujian (dan pelaporan) sama sekali. Dan pengembang hanya dapat menguji begitu banyak: Saya tidak menggunakannya seperti yang dilakukan pengguna.
No Grabbing

Jawaban:


18

mereka tidak memiliki perhatian neurosis obsesif terhadap detail pengembang "nyata"

Pendahuluan : Jenis bahasa yang Anda gunakan di sini biasanya merupakan bendera merah untuk saya. Ketika saya mendengar orang berbicara tentang pengembang "nyata" atau cara (satu-satunya) "benar" dalam melakukan sesuatu, saya mulai berpikir tentang pengembang kargo yang berorientasi pada terowongan .

Sekarang, saya tidak mengatakan bahwa Anda pasti salah satu dari pengembang ini (saya tidak memiliki cukup bukti untuk menyatakan hal itu), tetapi jika ya, maka Anda mungkin mendapat manfaat dari jawaban ini.

Menjawab

Sepertinya Anda dan klien Anda mengoptimalkan berbagai hal. Ini adalah fakta yang tidak menguntungkan dalam rekayasa perangkat lunak yang sering kali kebutuhan bisnis dan keinginan para pengembang tidak selalu sejalan.

Pengembang perangkat lunak sering kali adalah orang yang bersemangat dengan fokus pada peningkatan. Mereka suka meningkatkan kinerja perangkat lunak, proses pengembangan, proses bisnis, metode komunikasi, dll. Dan itu hebat. Berfokus pada hal-hal ini adalah apa yang memisahkan pengrajin dan wanita pengrajin dari para pencabut bulu mata yang tidak berpikir.

Tapi, klien Anda bukan pengrajin perangkat lunak. Klien Anda adalah bisnis dengan serangkaian prioritas yang sama sekali berbeda. Dan, kadang-kadang, prioritas itu terlihat konyol bagi kita pengrajin perangkat lunak ... tapi itu hanya karena kita mengoptimalkan berbagai hal.

Bisnis sering ingin mengoptimalkan untuk hal-hal seperti rilis awal ke pasar dan penghematan biaya jangka pendek. Dengan melakukan itu mereka mungkin perlu mengorbankan hal-hal seperti QA, Pengalaman Pengguna, penghematan biaya jangka panjang, dan hal-hal lain yang membuat pengembang tergerak.

Itu adalah hal yang buruk? Ya belum tentu. Saya tidak dapat berbicara untuk semua bisnis, tetapi dalam pengalaman saya, klien saya melakukan hal-hal ini untuk meningkatkan ROI mereka sendiri (laba atas investasi). Melakukan hal-hal seperti QA, penyempurnaan UX, dan perencanaan jangka panjang menawarkan ROI yang lebih rendah. Lebih buruk lagi, banyak bisnis memiliki struktur investasi yang hanya memberi imbalan kemenangan jangka pendek sebagai lawan dari pendekatan berkelanjutan dan kemenangan jangka panjang.

Jadi, sementara Anda bisa mencoba menjual ide QA kepada klien Anda, Anda mungkin membuang-buang waktu dan mempererat hubungan Anda dengan mereka. Dalam kasus terbaik Anda akan membuat seseorang bersemangat untuk mencoba ide-ide Anda (tidak mungkin). Dalam kasus terburuk Anda harus meyakinkan seluruh perusahaan untuk memperbaiki struktur insentifnya sehingga investasi jangka panjang seperti QA dihargai. Dalam kedua kasus itu, peluang keberhasilan Anda rendah.


4
+1, mencoba mengubah cara kerja internal dari seluruh bisnis yang berbeda karena sepertinya tidak tepat untuk Anda biasanya memotong hubungan. Seorang profesional harus memberi nasihat jika ia dapat meramalkan masalah serius, khususnya jika mereka juga dapat memberi nasihat tentang cara mengurangi masalah tersebut. Namun jika masalahnya sangat kecil sehingga perusahaan bahkan tidak repot-repot melaporkannya, hal terbaik yang dapat Anda lakukan adalah mengirim pengingat ramah sesekali bahwa mungkin ada waktu yang dihemat jika X atau Y tanpa memaksa.
Ordous

-1 karena, sementara ini adalah posting yang ditulis dengan baik, ini tidak benar-benar menjawab pertanyaan tentang bagaimana Anda akan melakukannya. Jawabannya adalah Anda melakukannya dengan cara yang hampir sama dengan meyakinkan pengembang reguler untuk menguji: menunjukkan bahwa pengujian membantu mengurangi risiko. Lebih sedikit risiko == lebih sedikit masalah produksi di tengah demo klien.
David mengatakan Reinstate Monica

Tidak - jauh dari markas tetapi terima kasih telah membalas.
No Grabbing

@ DavidGrinberg itu semua baik dan bagus kecuali mengurangi jumlah masalah produksi tidak sebanding dengan upaya / biaya / waktu untuk klien. Jika itu masalahnya, tidak ada jumlah logika pengembang yang akan meyakinkan mereka untuk mengorbankan ROI mereka hanya untuk memuaskan Anda. Dan itu sebabnya saya tidak menjawab bagaimana pertanyaannya dan malah berfokus pada potensi kesalahan dalam premisnya.
MetaFight

pengrajin :-)
Toni Leigh

10

Pertanyaan yang menarik adalah ketika Anda dibayar, bukan apakah klien Anda melakukan pengujian sendiri.

  • jika Anda dibayar berdasarkan waktu Anda, tidak masalah.
  • jika Anda dibayar di muka, tidak masalah.
  • jika Anda dibayar ketika klien menyatakan proyek "selesai", masalah besar.

Masalahnya adalah bagaimana Anda bisa tahu kapan klien menerima perangkat lunak dan akan membayar Anda. Ini jelas tidak berfungsi ketika klien terus mengubah proyek dengan permintaan baru yang tidak jelas. Jika ini berarti hari pembayaran selalu ditangguhkan - dan menjadi lebih tidak mungkin oleh setiap permintaan - ini menjadi tidak dapat dipertahankan untuk Anda.

Kontrak tetap yang dengan hati-hati menentukan semua fitur dan mendefinisikan di bawah kondisi mana klien akan menerima fitur-fitur ini jelas sangat tidak nyaman, tetapi memungkinkan Anda untuk merencanakan proyek terlebih dahulu (juga proyek berikutnya). Ini juga menjamin Anda akan mendapatkan uang Anda untuk perangkat lunak yang Anda kirim, jika sesuai dengan spesifikasi. Dalam skenario seperti itu, satu-satunya tanggung jawab klien adalah selama fase definisi kontrak, dan pada akhirnya untuk pengujian penerimaan .

Pengujian penerimaan yang dilakukan oleh klien terpisah dari bentuk pengujian lain:

  • tes unit
  • tes integrasi sistem
  • tes kegunaan
  • tes beban
  • tes pra-rilis

Sejauh mungkin, Anda akan mengantisipasi tes penerimaan dan melakukannya sendiri sebelum memberikan fungsionalitas untuk menghindari rasa malu. Selain dari tes penerimaan (yang hanya mengukur pemenuhan kontrak , bukan kualitas perangkat lunak ), semua Jaminan Kualitas adalah tanggung jawab Anda. Secara khusus, klien Anda tidak harus memiliki pola pikir QA, latar belakang teknis yang diperlukan, atau kewajiban kontrak untuk melakukan QA. Juga, saya menemukan outsourcing berburu bug ke klien sangat tidak profesional.

Itu bukan untuk mengatakan bahwa bug tidak akan terjadi. Dengan asumsi Anda memiliki hubungan berbasis proyek dengan klien Anda, Anda akan ingin melewati batas antara menjadi sopan dan cepat memberikan perbaikan, dan menjelaskan bahwa mereka telah menerima rilis saat ini sebagai cukup untuk kebutuhan mereka - perubahan besar memerlukan kontrak baru. Jika Anda memiliki kontrak dukungan yang berkelanjutan, tentu saja Anda harus tetap berpegang pada tingkat layanan yang Anda setujui.

Dalam situasi yang gesit, menanggapi kebutuhan klien lebih dihargai daripada berpegang teguh pada surat kontrak, tetapi Anda tetap ingin dibayar. Oleh karena itu, banyak metodologi proyek yang berorientasi gesit menghargai interaksi klien yang erat, hingga klien dapat menjadi bagian dari tim. Anda kemudian dapat selalu berbicara dengan "pemilik produk" ini untuk mengklarifikasi poin yang diperlukan. Karena PO memiliki wewenang untuk memberi Anda waktu untuk bekerja pada fitur apa pun yang mereka anggap berharga, ini dapat berfungsi bahkan ketika memulai dengan kebutuhan klien yang tidak jelas. Jika Anda tidak memiliki komunikasi yang begitu dekat, Anda harus mengikuti pendekatan yang lebih formal.

  • Ketika Anda mengetahui kebutuhan pelanggan baru, bekerja dengan pelanggan untuk menerjemahkannya ke persyaratan. Ini membantu klien untuk mendapatkan apa yang sebenarnya mereka inginkan.
  • Persyaratan dapat diukur secara obyektif - mereka dipenuhi atau tidak. Ini menyelamatkan klien dari setengah solusi yang hanya berfungsi.
  • Semua permintaan klien harus disediakan dalam bentuk tertulis sehingga Anda dapat menagihnya. Ini melindungi mereka agar tidak ditagih untuk hal-hal yang Anda baru saja ingin kerjakan - seperti menulis ulang seluruh antarmuka saat meminta tombol untuk disejajarkan secara berbeda.

    Banyak komunikasi dapat dilakukan secara langsung atau melalui telepon, tetapi pada akhirnya Anda akan menginginkan selembar kertas untuk mendokumentasikan bahwa klien ingin Anda mengerjakan persyaratan ini . Dalam kasus sederhana, mungkin cukup untuk merekap panggilan telepon dan mengirim mereka email untuk memverifikasi apa yang mereka minta Anda lakukan.

Laporan bug selalu sulit. Jika klien Anda adalah devs sendiri yang seharusnya membantu karena mereka dapat memahami kebutuhan Anda: memiliki langkah-langkah yang jelas untuk mereproduksi. Cara sederhana untuk mendapatkan wawasan yang kuat adalah dengan mengaktifkan pencatatan di perangkat lunak yang digunakan. Asalkan masalah privasi data dapat diselesaikan, mengharuskan setiap laporan bug untuk memiliki log saat ini terpasang tidak hanya menjamin beberapa komunikasi tertulis, tetapi juga memberi tahu Anda apa yang sebenarnya dilakukan pengguna (berbeda dengan apa yang mereka pikir mereka coba lakukan) .


1
Uang bukan masalah (Saya menerima pembayaran bulanan - saya dibayar apakah saya kode atau tidak). Ini cara menyenggol budaya kantor mereka ... atau sesuatu yang tidak saya dapatkan.
No Grabbing

2

Cara untuk mendorong komunikasi bug adalah dengan mendorong komunikasi fitur yang sering dan terperinci. Jika Anda melatih perusahaan yang mereka dapat meminta apa pun dengan upacara nol, mereka juga akan menggunakan fitur itu untuk bug minor. Menyerah pada perubahan alur kerja klien Anda kecuali perubahan ini membuat hidup mereka lebih mudah.

Membuat klien Anda untuk melakukan pengujian di rumah itu sulit, tetapi meminta mereka untuk melaporkan bug sebenarnya tidak sesulit kedengarannya. Cara untuk mendapatkan lebih banyak umpan balik adalah mengurangi gesekan pengguna ... bahkan jika itu berarti mentransfer sebagian dari gesekan itu kepada Anda sendiri.

  1. Gunakan alat yang lebih sederhana, bahkan jika alat tersebut tidak memadai dan tidak sesuai. Misalnya, BaseCamp adalah pelacak bug yang cukup mengerikan (karena ditujukan untuk manajemen proyek), tetapi orang-orang sebenarnya bersedia menggunakannya.

  2. Karena pelacak bug yang kami gunakan tidak mendukung copy-paste gambar, saya benar-benar menulis program sepele yang menyalin gambar clipboard saat ini ke disk (sebagai Guid), kemudian menyalin Guid ke clipboard. Setelah pelatihan minimal, pengguna dapat melampirkan gambar clipboard ke masalah hanya dengan menekan layar cetak, mengklik tombol, dan kemudian menempelkan ke dalam dialog pemilih file dari alat pengiriman bug.

Tangkapan layar (mungkin diedit dalam MS Paint dengan anotasi) dan 1-2 kalimat sudah cukup untuk menunjukkan sebagian besar fitur / bug.

Kedua saran ini menargetkan titik friksi yang saya alami, dan kedua saran ini meningkatkan pelaporan dengan faktor lebih dari 10. Namun, Anda harus menargetkan titik friksi Anda sendiri.


Jawaban ini sampai pada intinya. Anda ingin mereka menerapkan protokol pengujian yang ketat: itu sangat tidak mungkin terjadi, terutama jika itu berasal dari luar organisasi (misalnya Anda). Hal terbaik yang harus dilakukan dalam kasus ini, karena Anda dibayar bagaimanapun, adalah membuatnya tanpa rasa sakit untuk melaporkan bug kembali kepada Anda. Jika Anda benar - benar siap untuk pengujian menyeluruh, lakukan sendiri, dan pelajari lebih lanjut tentang proses bisnis jika Anda perlu ... Ini adalah kenyataan yang disayangkan bahwa banyak perusahaan tidak akan pernah memprioritaskan pengujian.
DrewJordan

1

Jadikan pengujian untuk klien Anda mudah, tetapi buatlah sangat sulit bagi klien Anda untuk menggunakan fitur baru apa pun dalam versi yang belum diuji dalam produksi. Ini dapat dicapai sebagai berikut:

Setiap kali Anda memberikan fitur baru, Anda menerapkan ini pertama kali dalam "versi beta", ditandai dengan tanda "tidak untuk produksi". Anda membuat versi beta ini tersedia untuk klien untuk pengujian. Anda juga memberikan "versi produksi" terbaru yang akan ia gunakan untuk produksi nyata (tanpa fitur baru, tetapi dengan perbaikan bug terbaru), dan Anda menolak untuk mentransfer fitur beta baru ke dalam versi produksi hingga Anda mendapat umpan balik dari seseorang di pihak klien setidaknya sudah mencobanya terlebih dahulu.

Jika klien mulai menggunakan versi beta pada data produksi sebenarnya meskipun selalu menunjukkan pesan besar "Tidak untuk penggunaan produksi" setiap kali ia memulai program, maka Anda tidak dapat membantunya, tetapi setidaknya Anda menjelaskan bahwa setiap kali ia kehilangan produksi bekerja karena ia menggunakan beta untuk tujuan yang salah sehingga jelas kesalahannya. Jika klien tidak belajar dari itu, Anda dapat mempertimbangkan untuk menonaktifkan kemampuan klien Anda untuk menggunakan "beta" dalam produksi dengan menonaktifkan beberapa fungsi penting seperti menyimpan hasil ke disk dalam "beta", jika itu perlu.

Menyediakan "beta" yang terpisah akan memaksa Anda untuk membuat kontrol versi / manajemen konfigurasi yang tepat, sehingga Anda dapat mengelola cabang produksi dan cabang pengujian beta berdampingan tanpa kesulitan. Tetapi karena Anda bekerja dengan Github, saya kira Anda sudah menggunakan sesuatu seperti GIT, yang membuat manajemen seperti ini sangat sederhana.


Saya tidak terlalu setuju dengan paragraf pertama. Seringkali orang benar-benar menyadari bahwa sesuatu itu penting tetapi gagal melakukannya (berhenti merokok misalnya). Pengujian adalah contoh klasik dari sesuatu seperti ini: bahkan jika Anda menyadari itu benar-benar penting, diperlukan banyak disiplin untuk tidak mengambil jalan pintas ketika dihadapkan dengan tenggat waktu, dll. Namun, gagasan beta baik, mengingat keinginan pelanggan untuk menjadi lebih baik dalam pengujian.

Saya juga akan menggunakan ini sebagai kesempatan untuk membahas poin # 1. Usulkan seluruh proses kepada pelanggan di mana persyaratan baru ditulis, disepakati, diuji dalam lingkungan non-produksi, kemudian dirilis.

Saya menandai rilis baru sebagai "alfa" atau "pra-rilis - bukan untuk produksi", plus mengerjakan semua hal "tonggak" github dengan masalah (bug, fitur baru untuk diuji, dll.) Tetapi belum membuat perbedaan. Seluruh situasi agak membingungkan saya. Saya telah mengusulkan hal-hal seperti hal "hari pizza" pengujian bug bulanan untuk memfokuskan pengujian tim mereka (2-3 orang), hal "suara untuk masalah favorit / paling menjengkelkan Anda". Agak aneh - namun mereka menggunakan perangkat lunak saya untuk presentasi besar sepanjang waktu jadi saya tidak mengerti mengapa tidak ada lagi pushback. Saya kira itu jatuh ke dalam "hal lain untuk melakukan / bukan pekerjaan saya"
No Grabbing

@TOMATO: apakah Anda benar-benar menolak untuk mentransfer fitur dari versi pra-rilis ke versi produksi, sampai pelanggan memberi tahu Anda bahwa ia telah menguji fitur tersebut? Apakah pelanggan Anda mencoba menghindari penolakan itu?
Doc Brown

2
+1 untuk versi beta yang ditandai dengan jelas: jika Anda membagikan versi uji dalam ungu ungu, dengan spanduk berkedip hijau besar di bagian atas layar utama berteriak "VERSI UJI - BUKAN UNTUK PENGGUNAAN PRODUKSI - TIDAK AMAN - AAARGH! ", mereka tidak akan menggunakannya untuk presentasi atau bahkan di mana saja di mana klien mungkin melihatnya. Anda dapat menahan versi produksi bersih (anggap sebagai sandera, jika Anda mau) sampai mereka memberikan semacam umpan balik yang berguna.
Christian Severin
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.