Pola justifikasi tugas dan antipatterns

Isi

• 1. Antipatterns: rationale yang buruk
  
  • 1.1. Jelas sekali
  • 1.2. Aku bersumpah demi ibu!
  • 1.3. Kelinci tersinggung
• 2. Pola pembenaran yang baik
  
  • 2.1. Pruflink
    
    • Tautan ke persyaratan
    • Persyaratan sendiri
    • Tautan internet
    • Surat pelanggan
    • ROI
    • Statistik
  • 2.2. Keseragaman
  • 2.3. Masalah, atau sakit # hidup
• 3. Ketika alasannya tidak dibutuhkan
• 4. Ringkasan

Ketika Anda memulai tugas, itu perlu dibenarkan. Anda harus meyakinkan pengembang bahwa:

• ini benar-benar sebuah bug;
• itu perlu diperbaiki;
• itu harus diperbaiki persis seperti yang kami katakan.

Dan terkadang Anda membaca bug (terutama bug pemula) dan bertanya pada diri sendiri:

- Mengapa ini bug ??

Misalnya, dikatakan: “Unduh laporannya, kami mendapatkan 57,6. Dan itu seharusnya - 57.9 ".



Menuliskan alasannya akan menyelesaikan masalah:

• Rekan-rekan kerja mengalihkan perhatian dengan pertanyaan “Mengapa ini bug?”, Mengambilnya di luar konteks.
• Sebulan kemudian, Anda sendiri lupa, tetapi, pada kenyataannya, mengapa itu adalah bug ...

Lihat juga:
Mengapa pembenaran dalam sebuah bug diperlukan - lebih terinci tentang mengapa, secara umum, pembenaran.

Ratusan penguji pemula (siswa) melewati saya. Justru pada tugas mereka, saya mulai mengajukan pertanyaan, "Mengapa ini bug?" ... Anda bertanya kepada teman-teman, dan sebagai gantinya Anda mendapatkan "Ya, sudah jelas!". Yah, entah bagaimana tidak terlalu =))

Melalui banyak tugas dan pertanyaan, "Mengapa?" pola tanggapan mulai muncul. Saya menyoroti pola yang baik dan buruk. Saya ingin berbicara tentang mereka.

Artikel ini untuk:

• Penguji awal - pelajari cara menjelaskan sudut pandang Anda dengan benar;
• manajer uji - untuk memberikan tautan ke Padawans mereka dan kemudian merujuk ke antipatterns tanpa penjelasan lebih lanjut.

1. Antipatterns: rationale yang buruk

1.1. Jelas sekali

Mengapa penguji tidak menulis alasan dalam bug sama sekali? Ya, karena tampak jelas bagi mereka. Dan mereka memproyeksikan pikiran mereka pada semua orang. Jelas bagi saya = jelas bagi semua orang mengapa menulis sesuatu?

Tetapi kenyataannya tidak demikian, karena setiap orang berada dalam konteks tertentu. Dan apa yang jelas bagi Anda sama sekali bukan fakta yang jelas bagi orang lain.

Mari kita lihat contoh-contoh sederhana. Baca kata yang akan saya tulis di bawah ini - apa yang Anda pikirkan ketika Anda membacanya? Asosiasi apa yang muncul di benak saya?

KUNCI

Kunci pintu atau benteng batu besar?

MARRIAGE

Pernikahan atau iPhone yang rusak?
...

Ya, ini adalah homonim. Tapi mereka sangat jelas menunjukkan masalah "sudah jelas." Jelas bagimu bahwa kastil itu adalah kastil, dan bagiku itu adalah kastil.

Dan jika Anda menulis dalam bug:

Hasil
57.6

Hasil yang Diharapkan
Jelas, harus ada 57,9

Itu tidak menjawab pertanyaan saya "MENGAPA?" Apa artinya "jelas"? Tolong jelaskan kepada saya. Bagi saya tidak jelas, kalau tidak saya tidak akan bertanya lagi. Tapi pengarangnya sudah jelas dan dia pikir semua orang juga.



Jika kita berbicara tentang pengalaman pemula, maka salah satu siswa saya merumuskan ide ini yang terbaik:

“Saya tidak mengerti mengapa membenarkan bug sama sekali, sampai saya membaca bug dari siswa lain”

Anda dapat mengatakan untuk waktu yang sangat lama bahwa itu "jelas" untuk semua orang yang berbeda dan saya tidak dalam konteks Anda, dan banyak lagi ... Tapi penulis tugas akan mempertimbangkan bahwa mereka hanya menemukan kesalahan padanya, sisanya tidak mengerti, tetapi dia baik-baik saja!

Dan hanya membaca bug orang lain, Anda mulai berpikir, “Hmmm, mengapa dia berpikir begitu? Saya berpikir secara berbeda. " Saat itulah pengertian muncul bahwa "jelas" Anda tidak jelas bagi semua orang.

Setelah saya masuk ke pelacak bug dan melihat bug seperti itu dari seorang siswa: “Kami memasukkan nama Sharipat, itu didefinisikan sebagai maskulin. Dan itu harus seperti wanita! " Kenapa harus seperti wanita? Saya melihat nama ini - yah, Sharipat dan Sharipat, terlihat seperti pria. Saya bertanya:

"Mengapa kamu memutuskan itu?" Mengapa perempuan?
- Ya, karena istri saya dipanggil begitu!

Dan ini setidaknya sudah menjelaskan kepada saya mengapa dia memulai tugas. Saat kami menguji aplikasi, pertama-tama kami mencoba data sederhana, hal-hal yang kami ketahui. Kami mencoba nama kami, nama istri, saudara laki-laki, saudara perempuan kami ...

Dia mencoba memasukkan nama istrinya dan menemukan bug. Dan jika dia bahkan menulis dalam hasil yang diharapkan: "Jenis kelamin adalah perempuan, ini adalah nama perempuan - nama saya adalah itu", maka setidaknya pertanyaan "Mengapa Anda memulai tugas ini?" Akan hilang.

Tentu saja, pembenaran seperti itu tidak cukup. Google "nama yang tidak biasa", karena tidak dilarang bagi kami untuk bahkan memberi nama meja samping tempat tidur putra kami, tetapi apakah ada baiknya mempertimbangkan kata ini sebagai nama pria yang benar?

Jadi di sini perlu untuk google, apa nama-nama secara umum, untuk melokalisasi masalah - masalah dengan nama-nama Rusia? Kazakh? Ukraina? Tetapi haruskah sistem dapat memprosesnya? Dan sebagainya. Mungkin bukan bug sama sekali ...
Namun, "nama istri saya begitu" setidaknya memungkinkan penulis untuk memperkenalkan kami ke dalam konteksnya dan menjelaskan mengapa ia memutuskan untuk memulai tugas.

Dan ingat, bukti bisa ditentukan oleh konteks. Anda telah mempelajari modul sistem dengan hati-hati, Anda tahu segalanya dengan saksama. Oleh karena itu, sangat jelas bagi Anda bahwa "chip ini seharusnya bekerja DI SINI BEGITU." Tetapi jika Anda kembali ke tugas dalam satu atau dua bulan, Anda sudah akan mengerjakan modul lain, dan mengingat mengapa itu akan jadi akan lebih sulit.

Bahkan pensil paling bodoh lebih tajam daripada memori Internet paling tajam

Ketika Anda memulai bug, dan hasil yang diharapkan tampak jelas bagi Anda, berhentilah dan pikirkan: "Mengapa saya berpikir begitu?". Dan tuliskan jawaban untuk pertanyaan ini.

1.2. Aku bersumpah demi ibu!

Ketika seorang siswa menyadari bahwa menulis sama sekali tidak ada, "karena sudah jelas", tidak gagal, ia melanjutkan ke tahap berikutnya dari kemarahan, penolakan, dan pembenaran bug, yang disebut "Aku bersumpah demi Ibu!" Inilah saatnya kami mengatakan bahwa itu benar, tanpa menjelaskan alasannya.



Artinya, alasannya terlihat seperti ini:

Hasil
57.6

Hasil yang Diharapkan
57.9 karena itu benar

Tapi alasan seperti itu lagi tidak menjawab pertanyaan saya "Tapi mengapa?". Mengapa Anda memutuskan itu benar? Saya masih bukan wang atau telepatis, dan saya tidak tahu mengapa Anda berpikir ini benar.

Bahkan, ini tidak jauh berbeda dengan situasi "tidak menulis apa pun, karena sudah jelas." Oleh karena itu, saya menyebut ini tahap kedua - justru dalam skenario inilah peristiwa biasanya berkembang, pertama "jelas", lalu "ya, jadi tepat sekali." Mari kita lihat contoh dari kehidupan siswa:

Peter dan orang-orang India

Sistem kami dapat mendeteksi nama berdasarkan kasus. Seorang siswa memeriksa nama Peter. Apakah Anda tahu bagaimana condong? Dalam kasus nominatif, ini ditulis melalui huruf E, dan dalam semua yang lain - melalui E. "Peter, tetapi Peter."

Dan jadi saya pergi ke pelacak bug dan membaca bug seperti itu: "Peter membungkuk kasus melalui huruf e, tetapi harus melalui e."

Saya bertanya:

"Kenapa menurutmu begitu?"
- Ya, jelas bahwa melalui E itu perlu (tahap pertama)
"Mengapa menurutmu ini jelas?"
- Tapi ini sangat sesuai dengan aturan bahasa Rusia!
- Dengan aturan apa?
- Nah, haruskah saya menjalankan dan google aturan bahasa Rusia? (Tahap kedua - begitu benar, percayalah)
- YA! Ya, itulah yang harus Anda lakukan. Karena ini akan menjadi alasan untuk bug. Karena mungkin pengembang Anda orang India dan Anda juga orang India. Dan Anda tidak tahu aturan bahasa Rusia! Jadi beri mereka tautan, dan semua pertanyaan akan segera hilang.

Tentu saja, tidak perlu terlalu ekstrem dan memberikan tautan ke kamus ketika Anda memasukkan bug pada kesalahan ketik atau koma yang terlewat. Namun demikian, Peter adalah contoh non-sepele, ini merupakan pengecualian terhadap aturan tersebut. Selalu berfungsi seperti itu, tetapi bagi Peter itu berbeda.

Karena itu, di sini tautannya akan bermanfaat. Apalagi jika pengembang bertanya, "Benarkah itu benar?" Anda bisa menuduhnya kebodohan dan buta huruf dan merusak hubungan. Dan Anda dapat memberikan tautan, dengan lembut mengonfirmasi sudut pandang Anda.

Tapi oke, mari kita ambil contoh lain, bukan tentang aturan bahasa Rusia, yang "sangat jelas."

Email.rf

Murid-murid saya sangat menyukai tugas ini (hampir setiap aliran membuatnya):

- Saya mencoba mendaftar dengan email.ru dan saya tidak bisa. Ini bug!
- Kenapa?
- Kenapa begitu? Kami tinggal di Rusia, semua orang memiliki email seperti itu!

Saya menceritakan kasus ini di konferensi DUMP, dan saya memiliki ruang audiensi penuh. Saya diminta untuk mengangkat tangan mereka yang memiliki email seperti itu. Dari 200 orang, tiga orang mengangkat tangan.

Fakta bahwa kita hidup di Rusia tidak berarti bahwa setiap orang memiliki email seperti itu. Ya, ya, ya ... Dan beruang jinak dan boneka bersarang ...

Tidak ada hubungan kausal di sini, cukup sulit untuk melepaskan ide Anda. Lagi pula, di sini, saya menemukan bug! Bagaimana ini bukan bug ?? Sangat keren. Rusia, tentu saja! Tidak, tidak jelas? Yah, sama saja, Rusia, Tentunya ada banyak.

Dasar pemikiran ini lebih seperti “Saya terlalu malas untuk pergi google, mencari fakta. Percayalah pada kata. " Ketika kita tidak memiliki fakta dan bukti, ada keinginan untuk menutupi pembenarannya dan menulis "Mungkin, mungkin, pasti ...".



Tapi ini adalah kata-kata BERHENTI! Jika Anda memiliki keinginan untuk menulisnya, maka Anda tidak memiliki fakta nyata. Jadi Anda hanya memikirkannya saja. Dan mengapa kita perlu melakukan tugas berdasarkan imajinasi seorang tester? Buktikan teorimu!

Dan jika tidak ada fakta? Maka tugas itu bahkan tidak layak untuk dimulai. Ya, sulit untuk menolak bug "asli Anda sendiri". Tapi ini juga harus bisa.

Email.ru - fakta

Apa yang bisa menjadi fakta?

Pertama, kami dapat membuat situs kami untuk beberapa pelanggan pemerintah yang diharuskan mendaftar di domain.rf. Standar perusahaan, mereka tidak punya pilihan.

Atau kami benar-benar memiliki banyak pelanggan seperti ini, ini ditunjukkan oleh statistik. Misalnya, ada banyak kesalahan dalam log “upaya untuk mendaftar melalui domain seperti itu”. Dan mungkin ada baiknya membuat fitur ini. Agar tidak kehilangan pelanggan potensial.

Berdasarkan fakta-fakta tersebut, PM (Manajer Proyek) membuat keputusan apakah kami akan melakukan tugas atau tidak. Dan jika kita mau, lalu kapan. Atau dia mungkin berkata, "Ya, ada kesalahan, dan ya, ada kurang dari 1% dari total pendaftaran, kami tidak akan melakukannya"

Alih-alih abstrak "ya, orang-orang seperti itu pasti ada!" berikan FAKTA.

Dan ketika mengatur tugas, gunakan prinsip 5 mengapa. Ketika Anda menuliskan hasil yang diharapkan, tanyakan pada diri sendiri, "Mengapa saya mengharapkan ini?" Jawaban pertama adalah "Ini jelas", tetapi sekali lagi tanyakan pertanyaan "Mengapa?". Dan jika Anda memperhatikan bahwa tidak ada data, sepertinya bagi Anda begitu - cari fakta atau diskusikan situasinya dengan rekan kerja.

1.3. Kelinci tersinggung

Jika tidak ada fakta, tetapi Anda tidak ingin menolak bug, siswa pergi ke tahap berikutnya dari kemarahan, penolakan dan pembenaran bug ... Tekanan pada emosi:

Saya mencoba mendaftar dengan nama Cthulhu, tetapi sistem tidak. Seharusnya memberi, kalau tidak ... Saya tersinggung dan pergi, dan ANDA! Kehilangan pelanggan!

Dan tentunya semua orang sama dengan saya, jadi Anda telah kehilangan SEMUA klien, dan mereka juga telah mengajukan tuntutan hukum untuk menghina dan mengambil semua uang!

Dan mobil lain ...

Tentu saja, ketika saya pribadi tidak suka sesuatu, sangat marah mengabaikan masalah saya. Apa artinya "Orang normal tidak mendaftar dengan nama itu?" Apakah saya gila? Seperti yang saya inginkan, ini disebut, bagaimana Anda bisa melarang saya sesuatu ?!

Dan kemudian proyeksi menyala - jika saya tidak menyukainya, maka pengguna lain tidak akan menyukainya! Jika tidak semua, maka setidaknya banyak. Oleh karena itu, ini jelas merupakan bug dan perlu diperbaiki. Ya, atau setidaknya berangkat dalam kerangka pelatihan, jika kita berbicara tentang siswa.

Namun, pengguna yang tersinggung adalah pembenaran terburuk yang pernah ada. Karena mereka dapat membenarkan segala omong kosong:

• Apakah tidak ada kucing yang utama? Yah, itu dia! Saya tersinggung dan PERGI! Dan ANDA! Kehilangan pelanggan !!
• Saya mendaftar dan saya tidak dibayar untuk itu ?? Saya tersinggung dan pergi ... DAN ANDA! Yah, kamu mengerti!

Apa pun bisa terjadi dan menyinggung perasaan saya. Tombolnya hijau, tapi saya ingin yang merah, sistem tidak menawarkan saya pizza sebagai hadiah ... Sebagai pengguna, saya bisa tersinggung apa pun. Tapi siapa yang peduli? Semua sama, Anda tidak akan menyenangkan, kebencian tidak bisa dihindari. Dan mengancam biasanya adalah hal terakhir.

Semuanya dimulai dengan salah satu siswa, yang baru saja mengucapkan kalimat rahasia ini:
- Ah, Anda tidak ingin mendaftar melalui domain Federasi Rusia? Dan sebagai pengguna saya mencoba mendaftar, saya melihat situasi yang mencolok ini, dan PERGI! Dan ANDA! Kehilangan pelanggan!

Kemudian teman saya mengatakan bahwa pidato seperti itu sangat mirip dengan "Kelinci tersinggung." Saya tidak tahu dari mana dia mendapatkan analogi ini, tetapi semua orang menyukainya.

Siswa itu menyadari bahwa dia semakin bersemangat. Pergi untuk mencari pembenaran tanpa emosi. Dan kami mendapat nama antipattern.

Ingat satu aturan sederhana - tidak boleh ada emosi dalam bug!

Emosi adalah fenomena yang berlalu. Sekarang Anda menjadi sangat marah dan ingin mengungkapkannya dalam komentar jahat seperti "hanya orang idiot yang bisa menulis kode seperti ini". Tapi ingat situasi apa pun ketika seorang anak di sebelah Anda berubah-ubah, mengatur kemarahan kepada ibu karena mainan atau es krim yang tidak dibeli. Apakah Anda, sebagai pengamat luar, menikmati menonton adegan ini? Tetapi histeria Anda dalam pelacak bug terlihat persis sama!

Karena itu, jika Anda benar-benar ingin, katakan semuanya secara lisan. Diskusikan dengan pengembang tugas di ruang merokok, mempertahankan posisi Anda dengan keras. Tapi begitu kami sampai di komputer - kami menghilangkan emosi, kami hanya menulis fakta. Tanpa "jika ya jika" dan tanpa "dan ANDA! Kehilangan pelanggan! "

Ingatlah bahwa mereka kembali ke tugas setelah satu atau dua atau tiga tahun. Dan bahkan Anda akan dengan mudah melihat kemarahan Anda sendiri. Lagi pula, tidak ada lagi emosi masa lalu, ini terlihat konyol. Jadi emosi maksimal secara verbal - di ruang merokok! Dan dalam bug entah bagaimana tanpa mereka.



Dan dalam pembenaran tidak menulis tentang kelinci mega-tersinggung. Terkadang pembelaan tugas semacam itu menjadi konyol:

Siswa menemukan kesalahan ketik dalam penawaran pengguna. Masukkan bug dengan prioritas kritis. Ketika diminta untuk mengklarifikasi prioritas, dia sangat marah:

- Sistem menipu saya, saya tidak bisa mempercayainya !!!

Dia mungkin khawatir pertanyaan itu akan berubah menjadi "ini bukan bug sama sekali," jadi dia mulai membela bug-nya. Tetapi tidak ada yang tidak keberatan bahwa ini adalah bug. Tapi mengapa ini penting? Siapa yang membaca tawaran itu?

- Saya baca! Oleh karena itu, saya melihat bahwa sistemnya buruk, jika ada kesalahan ketik di sana, lalu apa yang dapat dilakukannya? Dan bagaimana cara mempercayainya sekarang ?!

Tetapi "Saya membaca" ≠ "semua orang membaca." Dan kemudian siswa itu sendiri mengakui bahwa dia tidak membaca dengan cermat SETIAP perjanjian lisensi yang dimasukkan ke dalam kita ketika menginstal program. Maka dengan tawaran cerita yang sama. Meskipun semuanya baik-baik saja, mereka tidak membacanya. Jika ada sesuatu yang tidak menyenangkan, sudah alamat ke aturan.

Namun, "sistem menipu saya dan saya tidak bisa percaya sekarang" karena salah ketik pada halaman kesepuluh dari teks yang dibaca beberapa orang ... Ya ... Jangan tulis ini dalam bug, jangan beri tahu RM Anda.

Jadi, kami menghilangkan emosi dari bug. Dan apa yang bisa kita tinggalkan di sana? Tentu saja faktanya!

Alih-alih menulis tentang emosi "kelinci pasti akan tersinggung, mereka akan pergi, dan Anda akan kehilangan pelanggan":

- Mengumpulkan statistik;
- memperkirakan biaya tenaga kerja;
- hitung ROI;
- Pengguna wawancara;
- Bandingkan produk dengan pesaing;

Dan alih-alih menjadi tupai histeris, Anda akan menjadi penguji keren yang membuat bug yang bijaksana!

2. Pola pembenaran yang baik

Bagaimana cara membenarkan bug dengan benar? Apa yang perlu ditulis dalam hasil yang diharapkan sehingga bug Anda diperbaiki saat Anda menulis? Dan mereka tidak bertanya 10 kali "mengapa begitu benar"?

Tiga antipattern dibahas di atas, mari kita bahas tiga pola yang baik untuk membenarkan bug.

2.1. Pruflink

Itu bisa:

• Tautan ke persyaratan
• Persyaratannya sendiri (file word, present ...)
• Tautan internet
• Taksiran ROI
• Surat pelanggan
• Statistik

Tautan ke persyaratan

Bug paling sederhana adalah ketika ada TK dan sistem tidak berfungsi seperti yang dijelaskan di sana.

Jadi, kami menulis dalam hasil yang diharapkan: "57.9, karena demikian dalam pernyataan kerja." Hmm, hmm ... Tunggu sebentar. Kedengarannya seperti "Aku bersumpah kepada Ibu" ...

Ya, dalam kata-kata itu terdengar seperti itu. Karena itu, konfirmasikan kata-kata Anda dengan tautan. Kalau tidak, pengembang membaca bug, dan ia perlu:

• menyadari jenis TK apa yang terlibat;
• temukan TK itu sendiri;
• temukan tempat spesifik yang dimaksud;
• untuk memahami ...

Bukankah lebih mudah meninggalkan hanya barang terakhir? Bagaimanapun, pengembang dapat mengerjakan 10 proyek berbeda, yang dokumentasinya didistribusikan di 10 tempat berbeda. Butuh 5-10 menit untuk mencari TK, dan menambahkan tautan untuk Anda adalah soal sedetik. Anda sekarang menguji menurut TK, yang berarti terbuka dan di depan mata Anda. Salin tautan dan tempel!

Hormati waktu kolega, dan mereka akan berterima kasih kepada Anda.

Persyaratan sendiri

Jika persyaratan TIDAK disimpan dalam pertemuan atau sistem cloud lainnya, tetapi dalam Word biasa, lampirkan dokumen yang Anda uji.



Mungkin saja Anda menguji persyaratan yang sudah usang. Dan jika Anda melampirkan file kata langsung yang Anda periksa, analis dapat melihatnya dan berkata, “Oh, tunggu, kami sudah mengubah semuanya 10 kali, saya lupa mengunggahnya. Tunggu sebentar! ”

Jika tidak, maka menghabiskan tiga jam pada pertikaian dengan pengembang, yang akan mengatakan "tapi saya punya yang berbeda!". Anda akan lari, perhatikan persyaratannya, lalu persyaratan Anda, lalu cari analis untuk menjelaskan siapa yang benar ...

Jadi Anda segera memasukkan persyaratan, pengembang tampak berkata "sesuatu adalah semacam sampah," dialihkan analitiknya. Analis menulisnya, dan ketika dia membuka kata-kata Anda, dia akan segera mengerti apakah dia ketinggalan zaman atau tidak. Itu menghemat waktu!

Tautan internet

Seperti yang kita ingat, persyaratan jauh dari biasanya. Dan bukannya mereka mungkin ... Tautan ke Internet! Ya kenapa tidak

Jika kita mengingat contoh kita "Peter, Peter", maka bahkan jika kita memiliki persyaratan dalam sistem, tidak mungkin mengatakan "Sistem bekerja sesuai dengan aturan bahasa Rusia" dan semua aturan bahasa Rusia terdaftar. Tentu saja, tidak ada yang menulis seperti itu. Dan ternyata, jika Anda ingin merujuk aturan bahasa Rusia, Anda harus pergi dan google mereka.

Atau jika Anda mengambil contoh dari Sharipat. Sekali lagi, dari mana Anda mendapatkan bahwa ini adalah nama wanita normal? Kami google semua jenis Kazakh dan nama lain, menemukan Sharipat, menemukan nama lain yang serupa dan memberikan tautan ke halaman ini.

Dan di sini sudah, bahkan jika pengembang tidak setuju dengan Anda, dia bisa datang dan berkata - "Lihat, Anda memberi tautan ke situs, tapi ini semacam pers kuning, mereka selalu menulis sampah." Tetapi jika Anda tidak memberikan tautannya, pengembang harus mencari sendiri google, mencari semua jenis situs sendiri dan hanya kemudian dia akan mengerti bahwa Anda mungkin telah menyerang beberapa informasi palsu.Hemat waktu, segera berikan tautan ke Internet.



Ya, di sini Anda perlu memahami bahwa tidak setiap tautan berguna dan dibenarkan, tetapi setidaknya akan menunjukkan mengapa Anda pikir ini adalah bug. Ini bukan "ibuku bersumpah" padamu, tapi dengan justifikasi!

Surat pelanggan

Alasannya mungkin mengirim ke surat pelanggan. Kami bahkan memiliki bidang terpisah, Pembenaran Bisnis, tempat kami menuliskan pelanggan mana yang meminta fitur ini. Dan kemudian, ketika kita membaca bug kita, maka kita segera melihat:

- Ya, kasus bisnis kosong. Ini berarti bahwa kita sendiri telah menemukan masalah ini dan percaya bahwa itu perlu diperbaiki.

Atau:

- Ya, pelanggan seperti itu mengeluhkan masalah pada 1 Agustus 2015

Dan jika kita perlu mengklarifikasi dengan Pelanggan ini apa yang sebenarnya tidak cocok untuknya, maka kita dapat dengan mudah menemukan surat ini, karena kita memiliki semua informasi (siapa, kapan, apa surat itu disebut). Mengetahui info ini, saya akan pergi dan menemukan surat dalam 5 detik di Outlook saya. Jika informasi ini tidak ada di sana, maka saya harus pergi ke Outlook dan mencari di antara 10 ayah yang berbeda - pelanggan mana yang meminta dan dalam surat apa?

Selain itu, jika kita melihat bahwa fitur ini diminta oleh beberapa pelanggan yang berbeda, maka segera meningkatkan prioritas. Karena kita mengerti:

- Ya, di sini adalah pelanggan 1 mengeluh kemudian, setelah beberapa minggu / bulan pelanggan mengeluh yang lain. Hmmmm, tapi pasti ada banyak pelanggan lain yang juga menderita, tetapi diam. Menangis, tusuk, tapi terus makan kaktus. Lagi pula, tidak semua orang akan menulis kepada kami dan melaporkan masalah ...



Jadi semakin banyak keluhan, semakin tinggi prioritas. Karena kami memahami bahwa ini adalah pengguna yang sebenarnya mengeluh, mereka benar-benar memiliki masalah seperti itu. Dan bahkan jika kita kembali ke bug enam bulan atau setahun kemudian, berkat surat terlampir atau setidaknya tautan ke bug itu, akan selalu mungkin untuk meningkatkan riwayat tugas.

ROI

Kita dapat mencoba menghitung ROI - payback ratio. Apakah kita benar-benar perlu membuat fitur ini atau memperbaiki bug ini? Apakah ini akan membawa efek yang tepat?

Melakukan pengeditan kecil selama setengah jam untuk pengembangan, yang akan membantu ratusan pengguna. Ini benar-benar berbeda - karena histeria satu pengguna, dua minggu untuk mengulang pekerjaan sistem, yang cocok untuk semua orang.

Jika kami menghitung ROI dan melihat bahwa game itu sepadan dengan lilin, kami memasukkan perhitungan ke dalam tugas. Namun terkadang setelah perhitungan ternyata Anda tidak perlu melakukan tugas. Dan ini normal! Jadi, kami menghemat waktu tim untuk membahas fitur yang tidak perlu.

Itulah mengapa kami memikirkan alasannya - karena kadang-kadang sepertinya "Ah, apa bug, apa bug!", Dan kemudian Anda mulai berpikir tentang alasannya ... Dan Anda mengerti bahwa sampah ini, bukan bug, tidak layak untuk memulai ...

Misalnya, kami mulai bekerja dengan aplikasi seluler, dan ada panel debug untuk penguji yang terlihat seperti ini:



Wow, wow! Ada sedikit biru, ada sedikit merah, teks tidak sepenuhnya terlihat, font tersebar ... Bug yang jelas! Bagaimana ini tidak diperhatikan sebelum saya? Izin mendesak, perlu refactoring!

Bagaimana cara membenarkan? "Apa maksudmu, jika pengguna MELIHAT INI, maka dia akan segera tersinggung dan akan pergi." Berhenti . -. , [2]. . , , !

… , ? . , , . ? !

, . . . ? ? , , .

— , !

Statistik

Mengumpulkan statistik dan berinvestasi dalam tugas:

- jumlah kesalahan dalam log;
- jumlah pengaduan dalam dukungan teknis;
- jumlah klik pada tombol;
- jumlah pengguna yang pergi pada tahap menempatkan pesanan (menutup tab);
- ...

Yaitu, jika Anda berpikir bahwa bentuk standar untuk menempatkan pesanan di toko online adalah "buruk" dan perlu diperbaiki, benarkan. Kenapa itu buruk? Sehingga untuk memasukkan alamat Anda perlu mengetahui indeks Anda dan mengisi 10 bidang yang diperlukan? Apakah ini benar-benar buruk atau hanya mengganggu Anda?

Perlu diingat bahwa pengembang mungkin tidak melihat "jelas" dalam perangkat lunak mereka. Bagaimanapun, mereka mengembangkannya, mengujinya ... Mereka melihatnya terus-menerus 100 kali sehari, mereka sudah terbiasa dengan antarmuka. Jadi, bahkan jika itu benar-benar ketinggalan zaman, Anda perlu fakta.

Dan faktanya mudah dikumpulkan - kami meminta Anda membuat statistik untuk melihat kapan pengguna meninggalkan halaman. Dan jika dia menambahkan pizza ke keranjang, dan kemudian mulai mengisi ladang dan setelah 5-7 meludah dan pergi, ini tidak terlalu keren. Dan jika setiap tindakan ketiga seperti itu - itu pasti layak untuk meningkatkan sesuatu!

Jika Anda mengingat email.rf, Anda dapat melihat log - apakah ada kesalahan seperti "Mencoba mendaftar untuk email semacam itu ditolak"? Mungkin mereka sama sekali tidak ada, tetapi kami telah datang dengan sekelompok pengguna yang tersinggung, karena itu situs tersebut benar-benar kehilangan jutaan.

Mengapa statistik lebih baik daripada emosi? Karena kita, profesional TI, dan pengguna biasa adalah dua dunia yang berbeda. Apa yang nyaman bagi kita tidak nyaman bagi mereka. Begitu juga sebaliknya.



Misalkan kita melakukan perangkat lunak akuntansi. Tampaknya bagi kita: "Fu, tidak ada yang bekerja dengan mouse, kita harus memastikan bahwa semuanya bekerja dari baris perintah, sehingga mouse tidak perlu disentuh!" Kami menghabiskan banyak waktu untuk fungsi ini, tetapi pengguna sungguhan tidak menggunakannya sama sekali. Karena mereka memerlukan mouse untuk memilih, menyodok pada tombol besar ... Tapi apa yang nyaman bagi programmer, mereka umumnya tidak peduli, karena mereka merasa nyaman dengan sesuatu yang sama sekali berbeda.

Dan jika Anda ingin memberi tahu semua orang apa yang dibutuhkan pengguna, pertama-tama pelajari pengujian kegunaan, lalu katakan apakah kelinci tersinggung atau tidak.

Dalam sistem kami, kami mengumpulkan statistik anonim, fungsi mana yang digunakan dan mana yang tidak. Ada begitu banyak filter di formulir web yang sulit dipertahankan. Apakah mereka dibutuhkan? Anda tidak bisa hanya mengambil dan menghapus, ada baiknya memeriksa.

Jadi statistik biasanya sangat mengejutkan. Kami pikir filter ini tidak digunakan sama sekali, tetapi ternyata berhasil setiap jam. Dan di sisi lain mereka memiliki harapan tinggi, tetapi tidak ada yang membutuhkannya ...

Hanya statistik yang dengan jujur ​​menceritakan tentang adanya masalah tersebut. Jika tidak ada statistik, itu hanya rasa saja. Dan setiap orang memiliki selera berbeda. Penguji menginginkan tombol merah, pengembang yang hijau, dan desainer yang biru. Jadi cari fakta dan beri mereka pruflink!

2.2. Keseragaman

Jika tidak ada pruflink, kita bisa merujuk keseragaman dalam sistem. Karena jika sistem selalu bekerja dengan cara ini, dan kemudian tiba-tiba bekerja secara berbeda - ini mungkin menjadi alasan untuk bug.

Misalnya, jika sistem kami berfungsi seperti puntoswitcher (ini adalah ketika saya mencetak dalam bahasa Rusia, lupa untuk mengganti tata letak, dan sistem mengubahnya sendiri). Saya bisa mengetik "Olga", atau saya bisa mengetik "Jkmuf", sistem akan mengubah opsi kedua menjadi yang pertama.

Ini terjadi pada semua jenis aplikasi pemerintah. Terkadang mereka sendiri bekerja dengan prinsip yang sama. Anda harus mendaftar dengan jelas seperti di paspor Anda. Karena kami tinggal di Rusia, pendaftaran dilakukan dalam bahasa Rusia, jadi kami akan memperbaiki huruf bahasa Inggris. Anda jelas lupa mengubah tata letak, man!

Jkmuf → Olga

Oke, tetapi bagaimana jika saya mencoba mengetik nama "Julia"? Ini dimulai dengan huruf U, dan surat ini tidak sesuai dengan huruf alfabet Rusia, tetapi dengan karakter khusus:

> → Yu

Dan ini adalah kelas kesetaraan yang sama sekali berbeda!

Artinya, jika kita memahami bahwa sistem bekerja seperti puntoswitcher, kita memiliki setidaknya 2 kelas ekuivalensi: ada huruf Rusia yang sesuai dengan huruf Latin, dan ada yang sesuai dengan karakter khusus.

Ini adalah kelas yang sangat berbeda, mereka harus diperiksa! Dan mungkin ketika kita mencetak karakter khusus, sistem tidak mengenalinya. Dan kemudian kita mulai bug - saya ketik simbol>, saya berharap bahwa sistem akan menerjemahkannya ke huruf U, tetapi tidak ada yang terjadi. Mengapa saya mengharapkan ini? Karena sistem SUDAH berfungsi seperti itu, karena jika saya memasuki Jkmuf, sistem akan mengerti bahwa itu adalah Olga.

Kami menunjukkan bahwa sistem sudah bekerja seperti ini, dan ini adalah pembenaran yang baik. Kami tidak mengatakan "Saya bersumpah dengan ibu saya, dia bekerja seperti itu", kami membuktikannya pada Olga.

2.3. Masalah, atau sakit # hidup

Beri tahu kami tentang beberapa masalah pengguna nyata.

Karena kita adalah penguji. Tugas kita adalah menghancurkan dan menghancurkan, masukkan "War and Peace" di bidang singkat, edit satu entri di dua tab browser dan lainnya, lainnya. Dan bahkan jika sesuatu tidak bekerja untuk kita, ini tidak berarti bahwa pengguna akan melakukan hal yang sama.

Dan terkadang bug tidak diperbaiki hanya karena "ya tidak ada yang melakukan itu!" Dan ini normal. Mengapa membuang energi dan sumber daya untuk masalah yang tidak pernah muncul?

Ini terutama berlaku untuk masalah dengan kegunaan. Seperti yang kita ingat, apa yang nyaman bagi spesialis TI tidak nyaman bagi pengguna yang sederhana. Dan sebaliknya! Dan ternyata jika kita hanya menulis "Ya, ini tidak nyaman ..." - ini adalah pembenaran yang buruk, Anda tidak pernah tahu apa yang tidak nyaman, semuanya sesuai dengan yang lainnya. Tetapi jika kami mengumpulkan umpan balik dari pengguna, melampirkan surat mereka di mana mereka mengeluh kepada kami, maka ini segera menunjukkan bahwa masalah seperti itu benar-benar ada. Dan ini sudah meningkatkan prioritasnya.

Masalah pelanggan nyata selalu lebih baik daripada hanya semacam tes negatif dari tester.



Ini tidak berarti bahwa penguji tidak pernah diperbaiki untuk masalah. Jika Anda memiliki masalah, komplain juga! Mungkin pengembang dapat membantu Anda hanya dalam 5 menit, dia hanya tidak tahu situasinya.

Saat menguji fitur baru, saya menutupinya dengan uji otomatis. Kerangka uji telah ada sejak lama, kita sudah terbiasa. Tes mirip satu sama lain, jadi salin-tempel - setelah semua, kami biasanya mengubah satu parameter, membiarkan sisanya tidak berubah. Ini adalah prinsip "1 tes = 1 tes", sehingga setetes dalam tes segera menunjukkan penyebabnya.

Dan sekarang saya perlu menyalin parameter dari autotest ke autotest. Dan saya harus menggali mereka dari tes pertama ke yang kedua, ketiga, keempat, kelima, kesepuluh ... Dan dalam copy-paste ini saya hanya perlu mengubah 1 nilai dalam satu baris, dan jika tidak, semuanya akan berantakan dengan mengerikan sebuah kesalahan.

Tentu saja, ketika saya melakukan copy-paste, saya keliru setidaknya di suatu tempat ... Akibatnya, saya menulis 30 tes, menjalankannya sekaligus, dan semuanya jatuh dengan NPE. Aku duduk, menggaruk kepalaku dan berpikir, "sial, di mana aku salah?"

Saya telah memilah sepanjang hari, mencari kesalahan, menjalankan tes otomatis ... Saya mencoba untuk menemukan bug atau tempat di mana saya mengacau. Akibatnya, saya menemukan dan kemudian pada rapat umum berikutnya saya mengeluh:

"Saya menulis tes otomatis ini sepanjang hari kemarin, karena saya membuat kesalahan pada tes kelima dan kemudian mencoba memahami untuk waktu yang lama apa alasan kejatuhan itu." Oh, salin-tempel ini!

Dan kemudian pengembang mengatakan:
"Ya, dia akan datang kepadaku; aku akan memperbaiki segalanya untukmu dalam setengah jam dan memperbaiki masalah ini."

Dan itu mungkin? !!!

Tolong jangan takut! Mungkin Anda menderita, dan pengembang bahkan tidak mengetahuinya. Dan mungkin dia dapat dengan cepat memperbaiki masalah Anda, di sini dan sekarang. Dan mungkin tidak memperbaikinya, tetapi menyarankan solusi.

Tentu saja, jika masalahnya adalah masalah satu kali, atau butuh waktu terlalu lama untuk memperbaikinya, maka tugas pengoptimalan akan beralih ke rilis berikutnya atau lebih lanjut. Tapi ada baiknya setidaknya membahas "bagaimana ini bisa ditingkatkan" dan menetapkan tugas. Lagi pula, jika tidak ada tugas, tidak ada yang akan melakukan apa pun.

Ada berbagai kasus masalah:

- masalah pelanggan;
- masalah pengguna nyata;
- masalah penguji;
- masalah di dalam tim;

Beberapa lebih diprioritaskan, yang lain kurang. Namun, jika kita menggambarkan kasus nyata dan masalah nyata, maka tugas seperti itu memiliki lebih banyak peluang untuk koreksi daripada "jelas, sehingga semua orang akan lebih baik."

Ya, Anda perlu memahami bahwa meskipun kami menggambarkan betapa buruknya bagi pengguna nyata, itu masih tidak menjamin bahwa kami akan memperbaiki bug, tetapi ini adalah kehidupan. Bagaimanapun, jika kita setidaknya menggambarkan masalahnya, setidaknya akan jelas mengapa kita mengatur tugas ini. Bahkan jika kita kembali kepadanya dalam sebulan, dua atau tiga. Kami akan selalu melihat mengapa kami berpikir bahwa pengguna buruk dan tidak nyaman bekerja dengannya.

3. Ketika alasannya tidak dibutuhkan

Tiba-tiba, bukan? =)

Namun demikian, antipattern "jelas" memiliki pengecualian. Kami benar-benar TIDAK perlu menulis alasan jika sistem:

• menutup telepon;
• jatuh dengan kesalahan tidak tertangani;

Apalagi jika ini terjadi pada produksi. Jika situs kami ada, tidak ada alasan untuk membenarkannya, Anda harus mengalahkan gong dan lari ke pengembang "segera perbaiki!" Itu mungkin tanpa bug sama sekali. Dan Anda bisa dengan singkat "Kesalahan 500 pada utama", ini sudah cukup.

Jangan menghisap dasar pemikiran dari jari, karena "itu selalu perlu." Untuk menulis "sistem tidak boleh jatuh" adalah teks demi teks.

Tapi! Anda pasti perlu menulis hasil yang diharapkan. Bahkan jika itu tampak jelas bagimu, tulislah, itu tidak akan menghapusmu.

Langkah-langkah
Buka situs web example.com

Hasil
Kesalahan 500

Hasil yang Diharapkan
Halaman utama telah dibuka

Segalanya tampak sederhana di sini - yang utama tidak terbuka, tetapi seharusnya demikian. Tetapi ada contoh yang lebih rumit.

Misalnya, pengembang membuat formula dari TK dan pembagian di suatu tempat dengan nol terjadi. Jika Anda hanya menulis "Seharusnya tidak ada kesalahan, laporan dimuat", maka pengembang akan tetap mendatangi Anda dengan pertanyaan "Bagaimana seharusnya dibuka? Ada pembagian dengan nol! "

Anda perlu memikirkannya dan menulis "Saya berharap laporan akan terbuka dengan nilai ini dan itu sesuai dengan rumus " - selagi Anda berpikir apa yang harus ada di sana, Anda sendiri dapat menemukan sambungannya di dalam TOR. Dan kemudian periksa dengan analis bagaimana cara yang benar.



Jadi, bahkan jika tidak ada pembenaran, setidaknya ada hasil yang diharapkan. Dan ingat bahwa ini merupakan pengecualian terhadap aturan tersebut. Sistem seharusnya tidak jatuh dan membeku. Namun, bug seperti itu jarang terjadi, dan dalam kasus lain harus ada pembenaran.

4. Ringkasan

Kami membahas 3 antipattern. Tiga tahap kemarahan, penolakan dan pembenaran bug:

1. Jelas - Jelas bagi kami bahwa kami tidak membenarkannya. Dan kemudian kita mendapatkan "oh, saya lupa mengapa saya ingin" ... Ini jelas hanya untuk Anda, hanya di sini dan hanya sekarang. Setelah enam bulan, Anda sendiri akan melupakan alasannya. Jelaskan betapa bodohnya, bukti seperti apa yang ada di sana.
2. Aku bersumpah demi ibuku, itu benar! - Kenapa bersumpah? Untuk beberapa alasan, Anda pikir itu benar, jadi beri tahu saya alasannya. Berikan tautan ke persyaratan, misalnya.
3. Kelinci tersinggung - "Oh, Anda tidak menambahkan kucing ke halaman utama? Yah, itu dia! Saya tersinggung ... DAN PERGI! Dan kamu! Kehilangan pelanggan !! ” Tetapi apa yang tidak nyaman bagi Anda mungkin nyaman bagi orang lain. Jadi singkirkan emosi dan berikan fakta.

Sebaliknya, mereka harus menggunakan alasan yang benar:

1. Pruflink - TK, Internet, surat klien tempat ia meminta fungsi ini ...
2. Keseragaman - Jika sistem selalu bekerja seperti ini, dan di satu tempat berbeda, ada baiknya memperbaikinya!
3. Masalah - gambarkan masalah yang muncul untuk Anda atau pengguna (jika Anda berkomunikasi dengan pelanggan). Masalah sebenarnya selalu lebih baik daripada hanya tes negatif.

Pastikan untuk menulis mengapa kami memutuskan bahwa ini benar-benar bug dan mengapa kami ingin memperbaikinya persis seperti yang kami tulis di sini. Kami bertanya pada diri sendiri pertanyaan dari seri "5 mengapa"

- mengapa saya pikir ini jelas?
- mengapa saya pikir itu benar?
- mengapa saya pikir pengguna kesal?

Kami menyediakan tautan ke persyaratan di Internet, menunjukkan keseragaman, atau berbicara tentang masalah nyata pengguna.

Dan ketika setelah satu tahun Anda akan membaca kembali tugas yang dilaksanakan secara kompeten, Anda masih akan berkata kepada saya "Terima kasih!" ツ