Apa yang bisa diajarkan tentara oleh tester? Apa dua ekstrem dalam pendekatan pengujian? Bagaimana menjelaskan bahwa utang teknis berwarna merah karena pembayaran? Apa kesamaan pertanyaan sebelumnya?
Secara umum adalah bahwa untuk semua perbedaan mereka, mereka semua dekat dengan satu orang.
Jim Holmes memiliki di belakangnya beberapa dekade pengalaman TI, yang dimulai pada tahun 80-an di Angkatan Udara AS - tidak mengherankan bahwa ia siap untuk banyak bercerita. Konsep "budaya pengujian" penting baginya, dan kami menanyakan kepadanya pertanyaan yang dapat sangat bervariasi, tetapi pada akhirnya entah bagaimana terkait dengan budaya pengujian.
- Pertanyaan pengantar: ceritakan tentang diri Anda.- Nama saya Jim Holmes, saya seorang konsultan independen dan pemilik perusahaan saya sendiri, Guidepost Systems. Saya berspesialisasi dalam kualitas pengiriman perangkat lunak dan telah pemrograman selama total sekitar 20 tahun, sebelum itu saya bertugas di ketentaraan untuk waktu yang lama. Saya menjadi sangat tertarik pada kualitas sekitar 15 tahun yang lalu, ketika mengerjakan beberapa proyek yang tidak terlalu sukses. Secara umum, saya melakukan banyak otomatisasi pengujian, pengujian unit, pengujian integrasi, dan terutama pengujian fungsional, pengujian UI. Secara khusus, saya bekerja untuk sebuah perusahaan yang menulis alat Telerik Test Studio yang luar biasa. Dan dalam 5-8 tahun terakhir, saya mulai berurusan tidak hanya dengan aspek teknis semata, tetapi juga dengan kualitas pasokan secara keseluruhan - yaitu, seberapa baik hubungan antara tim pemasok dan bisnis. Tetapi pada saat yang sama, saya masih men-debug skrip WebDriver untuk waktu yang lama dan menyelesaikan masalah seperti kegagalan berkala karena tindakan asinkron yang salah. Saya tinggal di kota Ashland di Oregon - ingatkan Anda, bukan di Portland (ketika di AS Anda mengatakan "Oregon", biasanya semua orang berpikir "Portland").
- Mungkin, untuk penguji, bagian paling tidak biasa dari biografi Anda adalah dinas militer. Apa yang sebenarnya kamu lakukan di sana?- Saya bertugas di Angkatan Udara AS karena saya selalu terinspirasi oleh pesawat terbang dan ayah saya seorang pilot. Dia membawa saya pada penerbangan pertama saya ketika saya baru berusia 4 tahun. Di Angkatan Udara, saya sangat beruntung, saya bertugas di tim E-3 - ini adalah pesawat besar dengan cakram besar di atasnya, di mana saya bertanggung jawab atas pengoperasian radar dan beberapa sistem komunikasi. Selama sebelas tahun saya telah mengelola dan men-debug sistem elektronik besar ini. Dan selama waktu bebas dari penerbangan, saya mengelola komputer skuadron kami. Sekitar saat itu, menjadi mungkin untuk membuat jaringan di tempat kerja. Selain itu, karena saya seorang tentara, saya dibayar untuk pendidikan, jadi saya pergi ke sekolah malam untuk mengembangkan perangkat lunak.
Adapun pertanyaan Anda, pengalaman dinas militer tidak biasa tidak hanya untuk penguji, tetapi juga untuk banyak bidang lainnya. Saya dapat mengatakan bahwa setidaknya saya diajar disiplin di sana.
- Ya, dalam hal tentara, hal pertama yang terlintas dalam pikiran adalah disiplin. Dan dengan ini, banyak penguji dan pengembang mengalami masalah. Apakah Anda pikir mereka memiliki sesuatu untuk dipelajari dari militer?- Ini pertanyaan yang sangat menarik. Faktanya adalah bahwa disiplin yang diajarkan kepada saya agak berbeda dari, katakanlah, pasukan terjun payung, yaitu, tidak ada tangisan dan hukuman yang konstan. Saya diajari pendekatan disiplin untuk pengujian dan, secara umum, untuk pemecahan masalah. Disiplin tempat kerja juga penting - memahami apa itu hierarki; untuk mempelajari cara bekerja di dalamnya, seseorang harus dapat berkomunikasi dengan atasan. Disiplin semacam ini banyak membantu saya.
Saya meninggalkan tentara 25 tahun yang lalu - ya, saya sudah tua - dan pekerjaan di sektor sipil sangat kontras dengan pengalaman saya sebelumnya karena prioritas di sana. Di tentara, saya bertugas di pesawat terbang, yang seharusnya memantau musuh di wilayah yang luas dan memastikan keamanan wilayah saya sendiri. Kesalahan apa pun berarti risiko bagi kehidupan prajurit kita. Saya tidak ingin melebih-lebihkan, tetapi itu benar-benar terjadi. Jadi ketika seseorang di TI mulai panik dan menuntut agar suatu tugas segera diselesaikan, berkat disiplin dan pengalaman saya, saya selalu dapat meyakinkan orang - kami tidak terancam bahwa seseorang akan mati, dan kami tidak akan kehilangan ratusan ribu dolar per menit (dan saya telah berada dalam situasi seperti itu). Kami sangat sering panik dan membiarkan bisnis atau pemegang saham tidak perlu mengintimidasi kami dan menciptakan ketegangan yang tidak masuk akal yang tidak ada gunanya bagi siapa pun. Mungkin hal terbaik yang tentara ajarkan kepada saya adalah kemampuan untuk meminta ketenangan, menilai situasi dengan baik dan merencanakan tindakan kami sebelumnya, dan tidak terburu-buru melakukan tugas tanpa berpikir karena kepanikan yang diciptakan secara artifisial.
- Artinya, Anda perlu meluangkan waktu untuk memikirkan strategi.- Ya, dan di TI masalah ini sudah lama: persyaratan konstan untuk mengirimkan proyek ini detik ini. Hal utama adalah melakukan dengan cepat, dan apa yang sebenarnya dilakukan adalah kepentingan sekunder. Paling sering, tekanan ini dapat dikendalikan jika dialog dilakukan dengan benar. Tetapi untuk ini penting untuk dapat mengatakan bahwa kita akan menciptakan nilai lebih jika kita menghabiskan lebih banyak waktu dan secara rasional mendekati masalahnya.
- Mari beralih ke aktivitas Anda saat ini. Di tempat kerja, Anda terbiasa dengan cara mereka melakukan pengujian di berbagai perusahaan dengan cara yang berbeda. Jelas bahwa pendekatannya mungkin tergantung, misalnya, pada ukuran perusahaan. Tetapi mungkin ada banyak perbedaan yang kurang jelas - dapatkah Anda membicarakannya?- Ini pertanyaan yang bagus. Selain pekerjaan independen saya, saya juga bekerja dengan Teknologi Pilar dari Columbus, Ohio. Saya sudah kenal banyak orang dari perusahaan ini sejak lama. Sekarang sekitar 250 orang bekerja di sana, dan hampir semuanya bekerja dengan prinsip pemrograman ekstrem (XP): mereka memiliki banyak unit test, dan pengembangannya dipikirkan dengan sangat baik. Ketika saya dipekerjakan di sana tiga tahun lalu, saya adalah satu-satunya penguji, dan mereka menciptakan produk yang sangat berkualitas tinggi. Mereka mendekati pengujian secara eksklusif dari posisi XP, dari posisi pengembangan yang digerakkan oleh pengujian. Ini adalah pendekatan yang hebat, dan mereka telah berhasil menerapkannya, dan saya, bersama beberapa karyawan lainnya, berhasil mengubah beberapa aspek pengiriman perangkat lunak.
Dan Anda dapat membandingkan pengalaman ini dengan perusahaan lain di mana saya telah berkonsultasi selama tiga tahun terakhir. Ini adalah perusahaan industri, masuk dalam daftar sepuluh besar Fortune, dan mempekerjakan sekitar 200 ribu orang di seluruh dunia. Mereka memiliki departemen IT yang sangat besar untuk kebutuhan internal perusahaan. Ada banyak orang baik di sana, tetapi pengujian mereka macet pada praktik tahun 1980-an atau 1990-an. Perusahaan memproduksi sejumlah besar produk yang persis sama, dan banyak yang terbiasa dengan kenyataan bahwa dalam produksi, katakanlah, bantalan bola, sangat mungkin untuk memperkirakan jumlah cacat yang diharapkan. Tetapi masalahnya adalah mereka mentransfer pemikiran seperti ini ke IT.
Saya melakukan percakapan dengan empat, secara umum, karyawan yang sangat cerdas yang terlibat dalam mengumpulkan laporan cacat dari beberapa proyek dan mencoba memprediksi jumlah kemungkinan cacat di masa depan. Saya mengatakan kepada mereka bahwa ini cukup masuk akal untuk dilakukan di industri, tetapi bagaimana mereka membedakan indikator yang dihitung untuk aplikasi seluler dari indikator, katakanlah, layanan web? Mereka menjawab bahwa tidak ada perbedaan. Jadi saya beruntung melihat titik yang sepenuhnya berlawanan pada spektrum berbagai pendekatan pengujian dan budaya.
Selain itu, saya bekerja dengan beberapa perusahaan yang tidak berhasil keluar dari tahap startup, ketika mereka bekerja sepanjang waktu tanpa melihat ke belakang, tidak berusaha untuk menutupi seluruh situasi. Dan kemudian, setelah beberapa tahun, dalam proyek yang kompleks, masalah yang muncul pada tahap ini mulai terasa tajam, dan saya harus meyakinkan orang bahwa pendekatan ini salah dan bahwa sekarang saya harus berhenti dan memikirkan tindakan saya dengan benar. Secara umum, jawaban saya agak luas, saya harap saya belum sepenuhnya kehilangan kontak dengan pertanyaan Anda.
- Dan dalam praktik konseling Anda, ada kalanya, setelah menyelesaikan pekerjaan dengan perusahaan, mereka memberi tahu Anda "tidak ada yang lebih baik"?- Saya akan memberi tahu Anda rahasia bahwa sulit bagi orang-orang, kami adalah makhluk yang sangat sulit. Ini adalah salah satu alasan mengapa saya memiliki banyak uban (yang kedua adalah putri saya). Mengubah satu orang itu sulit, mengubah orang dalam suatu organisasi bahkan lebih sulit. Jadi ya, saya sering mengalami situasi ini.
Tentang beberapa konsultan, kami bahkan mengatakan bahwa ia "kelelahan". Hal ini disebabkan oleh kenyataan bahwa kami melakukan banyak upaya untuk mengubah budaya yang telah berkembang dalam organisasi, dan kami harus banyak bekerja dengan masalah di tingkat pribadi - orang takut akan perubahan, mereka terus-menerus harus meyakinkan diri sendiri bahwa ini perlu , dan cari jalan yang cocok untuk mereka. Tidak peduli seberapa kuat dan kerasnya aku, aku tidak bisa hanya datang dan berkata: lakukan ini dan itu. Perlu mencapai konsensus. Pekerjaan ini perlu dilakukan selama bertahun-tahun untuk mencapai sesuatu, dan ketika tampaknya Anda telah menyelesaikan masalah dan Anda pergi untuk berkonsultasi dengan organisasi lain, Anda akan menghadapi masalah yang sama persis seperti di tempat sebelumnya. Sekali lagi Anda menghabiskan banyak waktu dan usaha, dan ternyata di perusahaan pertama itu semuanya telah kembali ke keadaan sebelumnya.
Orang-orang sangat teratur, sulit bagi kami, kami sering kembali ke kebiasaan lama kami. Namun terlepas dari ini, ada contoh pekerjaan yang benar-benar sukses. Ada organisasi yang mengelola untuk mengkonsolidasikan hasil yang dicapai dengan Anda. Secara umum, saya akan mengatakan bahwa yang satu menyeimbangkan yang lain. Saya terus melakukan pekerjaan ini karena kasus-kasus sukses ini sangat memuaskan.
- Di blog Anda, Anda menulis tentang prinsip-prinsip profesional Anda, dan di sana Anda berbicara tentang perlunya bersikap terbuka, selalu belajar hal-hal baru, lebih banyak mendengarkan daripada berbicara, beradaptasi dan bersikap baik kepada orang-orang. Saya bertanya-tanya apakah itu benar-benar membantu sikap yang baik terhadap orang lain?- Ya, ini membantu. Saya mengatakan bahwa saya bertugas di ketentaraan, di mana kami memiliki disiplin yang ketat - tetapi kami harus memahami bahwa disiplin dan struktur itu sama sekali tidak mengganggu hubungan baik dan empati dengan orang lain. Apakah Anda kenal koki Skotlandia Gordon Ramsay? Dia memimpin pertunjukan Hell's Kitchen. Saya menyebutkan dia karena koki di restoran mahal sangat sering berperilaku menjijikkan dengan karyawan - mereka berteriak dan menghina. Saya benci sikap ini terhadap orang-orang. Bagi saya, sikap yang baik terhadap satu sama lain adalah penting. Jika Anda ingin mencapai perubahan, maka Anda perlu memahami mengapa orang menolaknya, yaitu, Anda perlu empati. Dan itu akan memungkinkan Anda untuk membuat orang itu sendiri ingin berubah. Pendekatan semacam itu jauh lebih efektif daripada meneriaki orang dan menuntut agar mereka patuh dan tidak bertanya. Setiap orang memiliki pikirannya sendiri, jiwanya sendiri, pengalamannya sendiri. Saya tidak ingin masuk jauh ke dalam filsafat, tetapi saya percaya bahwa dalam jangka panjang, sikap dan empati yang baik akan memungkinkan Anda untuk mencapai hasil yang bagus. Jadi ya, mereka membantu.
- Anda melakukan seminar, dan di salah satu dari mereka mengajar orang-orang pemrograman yang tidak tahu cara memprogram. Saya punya dua pertanyaan. Pertama, masalah apa yang paling sering mencegah orang dari pemrograman sendiri? Kedua - apakah Anda berpikir bahwa selama tahun berikutnya pengujian otomatis akan menang atas pengujian manual?- Dalam pengalaman saya, orang sering diganggu bukan oleh kesulitan teknis, tetapi oleh rasa takut. Saya dapat memberikan contoh dari pengalaman saya di sebuah perusahaan dari Fortune 10, yang sudah saya bicarakan. Saya bekerja dengan tim penguji yang melakukan pengujian manual, dan kami perlu melakukan otomatisasi menggunakan WebDriver. Dari jumlah tersebut, sebagian besar bahkan tidak dapat membuka Eclipse untuk mulai menulis kode. Mereka takut menulis skrip untuk otomatisasi, karena dalam pemahaman mereka ini tidak jauh berbeda dengan menulis layanan web yang skalabel atau database dengan multithreading, yaitu hal-hal yang telah dipelajari para pengembang selama bertahun-tahun. Ketakutan ini menghalangi mereka untuk melakukan hal-hal sederhana pada umumnya.
Saat ini saya sedang mengembangkan kursus untuk Kementerian Pengujian berdasarkan pada lokakarya di mana saya menjelaskan bahwa Anda tidak perlu berlatih selama bertahun-tahun untuk sekadar membuka skrip Java, C # atau Ruby, membacanya dan memahami struktur umum, atau menulis tes sederhana di WebDriver. Selain itu, bahkan jika Anda tidak sepenuhnya memahami segala sesuatu yang terjadi dalam kode, Anda dapat memberikan penilaian umum untuk itu, karena Anda tahu, misalnya, bahwa satu metode tidak boleh menempati tiga layar, seharusnya tidak ada empat bersarang jika pernyataan - mereka akan sulit untuk menguji, Anda tidak dapat memberikan variabel nama satu huruf dan sebagainya. Menurut pendapat saya, pada tahap awal, kesulitan utama adalah untuk mengatasi rasa takut bahwa Anda harus menyelesaikan tugas yang sangat kompleks. Dan saya selalu tertarik untuk melihat seberapa cepat klien saya menghilangkan rasa takut ini - Anda hanya perlu memberikan orang itu tes unit sederhana dan memintanya untuk menulis mengatur, bertindak dan menegaskan. Saya pikir komponen manusia ini sangat penting.
Sebagian besar teknologi yang kami gunakan tidak terlalu rumit, hanya sedikit yang terlibat dalam hal-hal seperti kendaraan tak berawak. Saya pernah mengadakan seminar untuk satu klien di India, dan ada satu manajer tanpa pengalaman pemrograman. Manajer ini pada awalnya sangat marah, dan alasannya justru karena ketakutan yang baru saja saya bicarakan, dan ketakutan ini ditumpangkan pada keengganan untuk tampak bodoh. Tetapi pada akhir pelajaran pertama, ia terjun ke dalam tes menulis begitu banyak sehingga saya harus mengeluarkannya dari penonton satu jam setelah pelajaran selesai - ia duduk, mengubur dirinya di monitor, berpasangan dengan peserta lain dalam seminar dan menulis tes sederhana untuk algoritma gaji papan. Dan intinya di sini tidak sama sekali dalam keterampilan mengajar saya - itu hanya menunjukkan betapa pentingnya rasa takut ini atau ketidakhadirannya bermain. Di sini kita berbicara tentang hal-hal yang melekat dalam sifat manusia.
Pertanyaan kedua Anda terkait dengan transisi dari pengujian manual ke pengujian otomatis. Saya punya pengalaman di sini, saya bekerja selama tiga tahun di sebuah perusahaan yang bergerak di bidang otomatisasi uji. Saya percaya bahwa pertanyaan harus diajukan secara berbeda dan berusaha bukan untuk pengujian otomasi, tetapi untuk pengembangan penguji dan perolehan banyak keterampilan teknis, salah satunya harus pengujian otomatis. Saya ingin melihat penguji seperti itu, yang memiliki cerita pengguna, spesifikasi dan persyaratan, dapat dengan bebas melakukan dialog dengan pengembang tentang hal-hal yang cukup khusus dan bersama-sama mencari solusi yang kemudian akan diwujudkan dalam kode. Ini agak berbeda dari pendekatan di mana tester mengajarkan pemrograman, hanya untuk dapat menulis skrip WebDriver. Keterampilan ini, tentu saja, juga penting, tetapi, menurut saya, itu bukan yang paling penting. Supertask, menurut pendapat saya, adalah kemampuan untuk melakukan dialog dengan pengembang dan untuk memastikan bahwa ia memikirkan proses pengujian ketika ia menulis kode. Bahkan TDD sudah akan menjadi hasil yang signifikan - saya percaya bahwa semua organisasi harus dapat menulis seperti itu.
Intinya adalah bahwa pengujian yang disampaikan dengan benar masih jauh dari berkurang menjadi tes unit atau tes integrasi. Sangat sering orang puas dengan pengujian jalur eksekusi kode yang khas - semua tes dilewati, kotak centang ada di mana-mana, cakupan kode 100% tercapai. Tapi semua ini tidak menjamin kualitas kode, bukan? Meskipun ini juga merupakan prosedur yang perlu, tentu saja. Jadi dalam pemahaman saya, penguji seharusnya tidak hanya menulis beberapa tes fungsional atau tes di WebDriver, tetapi pikirkan tentang bagaimana ia dapat menjalin kerja sama yang lebih erat dengan pengembang dan analis bisnis. Anda dapat, misalnya, mencoba
pemrograman massa . Secara umum, saya percaya bahwa otomatisasi adalah alat, bukan tujuan.
- Kata-kata “kerja sama erat dengan pengembang” sangat dekat dengan kami sebagai penyelenggara Heisenbug - bahkan slogan konferensi adalah “tentang pengujian, tetapi tidak hanya untuk penguji”. Dan sehubungan dengan kerja sama ini, saya ingin mengajukan pertanyaan berikut: apa, sebagai orang dengan pengalaman pengujian yang luas, yang ingin Anda sampaikan kepada pembaca dan programmer kami?"Bahwa kita tidak semua jahat!" Penguji telah mendapatkan ketenaran mereka dengan tindakan mereka sendiri. Mereka menemukan kesalahan dengan detail terkecil di rapat, sering berkomunikasi dengan laporan bug, bukan kata-kata. Pengembang datang untuk bekerja di pagi hari dan melihat 50 laporan bug yang menceritakan tentang kesalahan tata bahasa dan halaman yang tidak selaras. Saya telah berada di kedua peran, dan saya tahu bagaimana para programmer bereaksi terhadap hal ini. Ini adalah bagian dari sekolah lama pengujian, dan saya sendiri pernah berlaku seperti ini juga. Tetapi para penguji, yang lebih terbiasa dengan pendekatan modern, memahami bahwa lebih mudah dan lebih baik berbicara dengannya daripada membombardir seorang programmer dengan laporan bug.
Menurut pendapat saya, penting bagi pengembang untuk memahami bahwa tester yang baik bisa sangat berharga, dan jika Anda berbicara dengannya sebelumnya, Anda dapat menghemat banyak waktu dan saraf. Inilah yang dikatakan teori kendala. Misalkan saya seorang pengembang, dan saya melihat bahwa tester telah mendeteksi beberapa masalah. Jika alih-alih menulisnya di TFS atau di tempat lain, saya hanya mendatanginya dan berbicara langsung, maka percakapan ini akan membantu saya mengurangi jumlah cacat dalam kode yang saya tulis. Selain itu, dalam komunikasi pribadi, sebagian besar penguji, pada umumnya, jauh dari menakutkan. , , , , — , , , .
, . , , , , — , . , .
, , : Heisenbug , Fortune 10. , ? 6-7 Heisenbug , .
— . «The leadership journey» . , : , , — . ?— , , IT: , , , , . , , , , . , , , . , , .
, . , , , . , : , , . , , , . , , , . . , , . , , - , . , , . , — .
— , . : , , , . — ?— 18 , , 13 14. . , — , , . , , . , .
, . , , . DevOps. , , . , . , Skype - , Skype for Business Google Hangouts, . . , . , , , Xbox — , .
, — . , . hangout Slack — . , , .
20 , , — . . , , , . , , , . . , — , . , , .
— «Technical debt: payment plan». « » , « » , . , , , , ?— . , , IT - , . (Trish Khoo), Twitter hogfish. — , . , , «Technical debt: payment plan». , , , , -, .
, , , , - . -, , , . , , . - X , Y , . , - . , , 30 - , . , -, . , , : - .
, 10 3 . 3 . , . . , , , , . , , , - , . , . , , IT, , . , . , . . , , - , , , .
, , . , , . , , , . , .
— , , , . , , , .— . , . , , , . , , — , . , , - . .
, . , , , , . , , , , , , . , , , .
— , — . , .— Fortune 10, , . , . , , , . , , , , , Acceptance Testing.
, , . , (, Sonar Cube), , . , , . , « », , , , . , , . , , - .
— . .— , . , : , .