Satu , ditambah dengan yang
lain , artikel saya ternyata menjadi panduan untuk bertindak bagi mereka yang belum menemukan "gaya mereka sendiri" dan tidak yakin harus mulai dari mana.
Beberapa menjawab bahwa saya menulis tentang "kebenaran umum," tetapi saya menerima respons yang baik dalam komentar dan pesan pribadi dari kategori "itu berguna," "apa yang saya butuhkan sekarang," dll. Tapi ada beberapa pertanyaan. Pertanyaan-pertanyaan, sebagian besar, bermuara pada "rasa sakit" yang belum melewati QA tunggal dalam karirnya:
- Bagaimana cara berinteraksi secara efektif dengan pengembang?
- bagaimana mengatur kerja dengan mereka sehingga mereka menerima: apakah ada pendapat lain tentang proyek, pendapat QA, dan apakah itu juga penting?
- bagaimana mendorong mereka untuk berinteraksi, misalnya, ketika membangun otomatisasi uji bersama ketika mereka tidak dikonfigurasi untuk bekerja bersama?
- bagaimana bertindak dalam kasus ketika keterampilan teknis Anda dalam tumpukan teknologi yang digunakan tidak cukup?
Segera buat reservasi bahwa topiknya sangat sensitif, membicarakannya Anda selalu harus menyeimbangkan di ambang tidak menyakiti kebanggaan kedua pengembang dan QA itu sendiri. Oleh karena itu, saya mohon Anda membaca dengan hati dingin dan hanya mencoba menyoroti beberapa poin berguna dan mencobanya dalam latihan.
Pendahuluan
Pertama, seperti yang ditunjukkan oleh praktik, sering kali QA yang tidak berhasil menerobos pengembangan seperti yang dipersyaratkan oleh profesi
- sama sekali tidak percaya diri. Mereka tidak dapat mencapai apa yang mereka dengar, karena mereka berbicara dengan tidak terdengar, tidak secara wajar, mengungkapkan keraguan yang terus-menerus;
- mereka takut melakukan kesalahan dan memikul tanggung jawab ekstra;
- kompleks karena pengetahuan teknis yang tidak sempurna.
Kedua, pengembang dalam tim menganggap QA sebagai pelengkap yang hanya menekan tombol sebelum memberikan produk kepada klien, atau tidak membayangkan bagaimana berinteraksi dengan mereka. Ini mungkin karena fakta bahwa
- mereka masih menganggap QA sebagai penguji 10-20 tahun yang lalu, ketika mereka sebenarnya;
- semua QA sebelumnya dengan mana mereka bekerja dengan cara dan perilaku yang persis sama, dan mereka tidak tahu apa yang terjadi sebaliknya;
- pada prinsipnya, mereka tidak tahu apa esensi dari pekerjaan Insinyur QA pada intinya, karena mereka tidak membutuhkannya - mereka mengembangkan keterampilan mereka;
- pengembangan kode sudah mapan dan mengubah sesuatu di dalamnya hanya kemalasan.
Mari kita mulai dengan masalah pertama.
Insinyur QA! Lakukan pembersihan pegas di kepala Anda
Berusahalah memahami profesi Anda
Jika Anda ingin mengubah dunia, mulailah dengan diri Anda sendiri. Kebenaran yang terkenal dan sangat relevan dalam topik kita.
Sebagai seorang Insinyur QA, sungguh tidak ada salahnya Anda mencari tahu untuk posisi apa Anda bekerja. Jika proyek Anda masih hidup dengan prinsip arsitektur air terjun, dan Anda disewa hanya oleh penguji manual, yang, seperti OTC di perusahaan, memeriksa kesiapan produk akhir, maka ini adalah satu hal, dan di sini semuanya cukup transparan.
Dan jika Anda berada dalam posisi QA Engineer yang lengkap, yang hampir universal sekarang, itu berarti bahwa tanggung jawab Anda, ditetapkan oleh kanon profesi ini dalam [1], tidak hanya menguji produk jadi, tetapi juga berpartisipasi langsung dalam mengatur proses penciptaan dan interaksi peserta. seluruh proyek. Harap diingat bahwa tanpa proses dan organisasi tim yang jelas hampir tidak mungkin untuk mendapatkan produk yang berkualitas, oleh karena itu, di bidang ini, suara QA harus terdengar percaya diri dan jelas. Untuk mencegah munculnya bug, dan tidak memperbaiki setelah fakta - ini adalah banyak tim yang terorganisir dengan baik. Dan melakukan upaya untuk meminimalkan jumlah bug adalah banyak tim QA. (Lingkaran ditutup.)
Karena itu, yang pertama, ingatlah semua hal mendasar tentang prinsip, jenis, tingkat pengujian, dan kata-kata dari definisi profesi QA Engineer. Memahami yang terkenal "Siapa aku?" dan "Mengapa saya di sini?"
Temukan jawaban untuk pertanyaan
Ketika penggalian sendiri secara profesional selesai, buat garis besar rencana untuk diri sendiri, apa yang akan Anda lakukan, Anda dapat mengambil ide dari artikel saya, atau menyusun rencana Anda sendiri yang sesuai dengan keadaan Anda. Setiap poin aktivitas Anda harus jelas bagi Anda sendiri - mengapa, bagaimana menerapkannya, apa untungnya.
Hanya dalam hal ini Anda akan dapat berbicara dengan percaya diri tentang proyek tersebut. Sekalipun Anda sejauh ini hanya tahu jawaban atas pertanyaan "mengapa" dan "apa manfaatnya", tetapi Anda tidak tahu "bagaimana". Sudah merasa percaya diri dari kenyataan bahwa Anda melihat bagian depan pekerjaan, perumusan tugas yang benar adalah keberhasilan 80%.
Langkah selanjutnya adalah menuliskan pertanyaan yang perlu Anda pecahkan untuk menjawab pertanyaan "bagaimana". Dan pergi ke orang-orang dengan ini, yaitu, berdiskusi dengan tim - dalam pertemuan yang diselenggarakan khusus, mengobrol di antara bisnis atau secara informal di dapur sambil minum kopi, tidak masalah. Adalah penting bahwa proyek Anda penuh dengan orang-orang yang memiliki pengalaman berbeda, pengetahuan lain, menggunakan gudang informasi yang berguna ini, berkomunikasi, bertanya dan semuanya akan diklarifikasi.
Jatuhkan pengalaman bahwa Anda tidak sempurna
Jika Anda sangat pemalu atau dalam hidup seorang maksimalis yang selalu berusaha untuk menjadi seorang pemimpin, maka akan sulit untuk memainkan peran QA. Karena QA Engineer adalah seorang insinyur, ia adalah orang yang terlibat dalam pengembangan, tetapi pada saat yang sama kami menemukan diri kami pada proyek-proyek dengan tumpukan teknologi dan arsitektur yang berbeda, sementara pengembang memiliki spesialisasi mereka sendiri. Mengakui bahwa Anda "di luar topik" bagi sebagian orang berarti menulis diri Anda sendiri ke dalam "tautan lemah". Dan ini adalah masalah saya, yang saya perjuangkan untuk waktu yang sangat lama. "Apakah itu yang perlu saya katakan bahwa saya tidak tahu, bahwa saya tidak tahu apa, saya tidak mengerti?!" - Lebih dari sekali saya jatuh pingsan dalam diskusi aspek teknis penuh.
Tetapi hanya pada titik tertentu saya akhirnya menyadari bahwa tidak mengetahui bukanlah hal yang memalukan. Saya malu untuk terus "bersembunyi di shell" dan tidak mencoba mencari tahu. Dan untuk tetap diam, untuk tampak serba mengerti, lebih baik bagi diri sendiri.
Anda dipekerjakan, mereka membaca resume Anda (Anda akan yakin dengan kemampuan Anda;)), Anda berbicara dengan Anda di wawancara, dan Anda dipekerjakan. Jadi setumpuk keterampilan teknis Anda baik-baik saja dengan semua orang dan mereka yang mempekerjakan Anda telah menebak apa yang diharapkan. Oleh karena itu, melompat di atas kepala Anda sekarang tidak masuk akal. Dan ketika Anda mengatakan "Saya belum pernah bekerja dengan ini, tetapi saya ingin mengetahuinya, bantu saya memahami ini dan ini" - ini adalah situasi yang benar-benar normal, sehat dan benar (jangan hanya membawa yang paling utama ke titik absurditas) pengetahuan - definisi dan formulasi - belajar dari Internet). Dan ketika Anda menunjukkan kepada orang lain bahwa Anda tidak memahami latar belakang teknis ini, pertama, mereka sudah merasa perlu berkomunikasi lebih sederhana, dan kedua, Anda dapat mengajukan pertanyaan klarifikasi dengan hati nurani yang jelas. Jika Anda menulis kode sekali atau dua kali dan sepenuhnya memahami arsitektur internal proyek, maka Anda mungkin akan terlibat langsung dalam pengembangan, bukan?
Dan trik kecil favorit saya adalah selalu membantu orang lain, ketika saya bisa - dengan perbuatan, saran, kata-kata baik, ini kembali dengan keinginan bersama orang lain untuk membantu saya.
Jangan takut melakukan kesalahan
Anggap saja bahwa alur kerja melibatkan diskusi tentang semua opsi yang mungkin. Kebenaran lahir dalam perselisihan. Tugas Anda bukan untuk menjadi benar, tetapi untuk menemukan solusi terbaik. Dan jika Anda ingin menawarkan sesuatu, tetapi takut itu akan terdengar konyol, percayalah pada saya berapa banyak tim yang saya lihat, kolega pendiam yang paling acuh tak acuh yang terlihat kalah. Mengenali beberapa kesalahan kami, mendukung ide-ide terbaik dan secara antusias berkontribusi dalam implementasinya adalah alur kerja yang sehat.
Ingat, tokoh utama Muravyeva dalam film "Moscow Don't Believe in Tears" mengatur dirinya sebelum pergi ke perpustakaan: "jika Anda berseru, berkata dengan percaya diri - maka ini disebut sudut pandang". Ini benar-benar berfungsi.
Jangan takut untuk memanggil diri sendiri tugas yang tidak bisa Anda tangani. Ingat, Anda bekerja dalam tim dan mengatakan bahwa ada sesuatu yang tidak berhasil dan meminta bantuan tim adalah hal yang normal.
Dan bahkan jika dalam pekerjaan Anda, Anda sampai pada kesimpulan "Anda tidak perlu melakukan ini", itu akan menjadi kemajuan, karena langkah selanjutnya adalah menemukan solusi terbaik.
Lepaskan standar usang, lihat ke masa depan
Fondasi-fondasi ini bahwa QA adalah posisi rendah, tidak begitu penting dan tidak begitu signifikan ditemukan dalam tim. Dan sementara Anda sendiri berpikir begitu, Anda meremehkan kecenderungan ini, sayangnya, memberi makan.
Anda bekerja setiap hari, Anda melakukan upaya setiap hari, membuat produk dan tim lebih baik, Anda menghabiskan waktu dan energi, posisi Anda diletakkan dalam kerangka proyek - ini berarti itu penting dan perlu. Itu saja. Jangan meninggalkan ruang untuk melukai diri sendiri, dan jangan meninggalkan ruang di kepala Anda untuk "mengejek" dari mereka yang menganggap bahwa Anda memiliki status yang lebih rendah darinya. Saat-saat ini, ketika ada penguji tangan monyet-penguji yang sederhana, telah dilupakan, di masa depan, QA Engineers adalah "detasemen pasukan khusus elit yang keberhasilannya tergantung pada taktik yang sangat baik dan senjata modern" [2].
Ingatlah bahwa hari ini di perusahaan-perusahaan terkemuka seperti, misalnya, Microsoft dan Google, “pengembang bertanggung jawab atas kualitas. Jika produk rusak setelah rilis, maka kerucut akan terbang ke pengembang yang menciptakan masalah, dan bukan ke penguji yang tidak menemukannya ”[2]. Oleh karena itu, di perusahaan seperti itu, memiliki tim QA yang akan membantu menciptakan produk yang berkualitas adalah hak istimewa bagi pengembang.
Dan itu ada di tangan Anda untuk memperkenalkan prinsip-prinsip canggih di perusahaan Anda, alih-alih melihat kembali stereotip sebelumnya.
Tetapi sekali lagi, saya kembali pada kenyataan bahwa Anda perlu terus tumbuh dalam proyek Anda. Jika Anda datang ke proyek, enam bulan telah berlalu, dan Anda masih belum menemukan otomatisasi pengujian yang efektif, jangan mencoba untuk mencari tahu apa yang dilakukan tim, jangan menganalisis autotest yang ada, maka Anda tidak cukup elit yang dituliskan oleh buku.
Ada tim yang hidup tanpa posisi QA Engineer sama sekali, saya tahu itu. Dan jika Anda sudah hari ini berusaha untuk membenamkan diri dalam proyek dan belajar cara menulis autotest dengan pengembang, suatu hari Anda dapat menjual kompetensi Anda bahkan di sana dan menjadi insinyur perangkat lunak dalam pengujian di sana.
Insinyur QA! Sempurnakan kerja tim
Ketika pekerjaan untuk diri Anda sendiri selesai, saatnya untuk bekerja membangun kolaborasi dengan pengembang.
Yang paling penting
- Tindakan Anda harus jelas dan transparan kepada tim. Yang paling sederhana dan paling efektif adalah untuk menyampaikan misi mereka kepada mereka. Jika, tanpa alasan, Anda mulai memanjat ke kolam mereka dengan permintaan yang menanyakan "tes seperti apa yang Anda miliki di sini?", "Tetapi Anda harus menulis tes seperti itu", reaksi pertama (protektif) adalah " kemana kamu pergi ?! "," siapa kamu / seperti itu untuk mengkritik pekerjaanku?! ". Dia mungkin telah memasak brunch ini selama seminggu, akhirnya dihembuskan, dan kemudian QA mendapatkannya. Karena itu, beri tahu mereka sebelumnya apa yang akan Anda lakukan, mengapa dan apa manfaatnya bagi proyek dan tim. Siapkan tanahnya.
- Partisipasi Anda dalam pengembangan apriori harus dianggap sebagai berkah, sebagai sesuatu yang secara kualitatif meningkatkan pekerjaan pengembang. Menjadi pasangannya. Misalnya, mengedukasi - memberi tahu bagaimana pelanggan cenderung menggunakan fungsionalitas, bug apa yang telah terjadi dan mana yang harus dihindari, yang secara bersama-sama memikirkan tentang tes mana dan mengapa penting. Jangan berkomunikasi dalam suasana hati yang imperatif. Anda bahkan dapat menggunakan trik psikologis - untuk mencatat mereka yang meningkatkan cakupan tes mandiri dalam beberapa laporan akhir dalam format "apa yang kita semua lakukan!" Itu selalu menyenangkan ketika pekerjaan Anda dihargai. Dan tinjauan QA tradisional dengan cakupan uji otomatis juga merupakan motivasi untuk bekerja bersama.
Biarkan perubahan pada proyek menjadi lancar. Jika Anda datang ke kantor suatu pagi dan berkata, “Saya sudah membaca sebuah artikel tentang Habré, dan Anda akan mulai menampar sepatu Anda di platform bersyarat, mengocok udara, kata mereka, sekarang saya akan menunjukkan kepada Anda ibu Kuzkin!”, Mereka akan melihat Anda sebagai aneh, ini fakta. Ya, dan akan sulit bagi Anda - dihadapkan dengan masalah di semua lini - akan ada keinginan yang tak tertahankan untuk melepaskan seluruh gagasan untuk meningkatkan pekerjaan QA.
Lebih baik mengatur tugas-tugas kecil yang dapat dimengerti untuk semua orang, mencapainya dan mengambil yang berikut ini. Dengan hati-hati bergerak maju, waktu berlalu dengan cepat, suatu hari akan menyenangkan untuk kembali.
Jawaban untuk pertanyaan spesifik
Setelah
artikel kedua saya , yang menawarkan kerja QA dan pengembangan yang erat, audiens kedaluwarsa dari kategori "kami mencoba, tetapi pemimpin tim pengembang tidak benar-benar ingin bertemu." Dari tingkat pengembangan profesional saya saat ini, saya hanya dapat menyarankan yang berikut ini.
Bersikap ramah dan perlakukan dengan tenang menenangkan mereka yang tidak menerima pekerjaan Anda seperti yang Anda harapkan. Dalam praktik saya, saya bertemu banyak pengembang yang berbeda dan semua yang benar-benar matang secara profesional selalu datang menemui saya, selalu membantu, dan kami mencapai hasil gabungan yang sangat baik, mereka semua puas. Mereka yang "mendengus" dan "menjauh darimu", sayangnya, berasal dari kategori "remaja profesional". Mereka belum belajar untuk mengatasi perasaan mereka, menganggap diri mereka yang paling sayap kanan (dan usia fisik tidak berperan di sini). Mereka sama sekali tidak tahu cara bekerja dalam tim, dan Anda adalah bagian integralnya. Anda bisa membantu mereka tumbuh, tetapi, sayangnya, beberapa tidak pernah tumbuh. Dan di sini Anda hanya dapat memengaruhi mereka melalui dukungan kepemimpinan dan otoritas kolektif dari seluruh tim yang akan mendukung Anda. Jika Anda tahu cara terbaik, bagikan!
Ada juga pertanyaan menarik tentang bagaimana menjadi jika Anda hanya belum tahu cara membaca kode pengembang, Anda tidak dapat mengetahui autotest mereka.
Saya akan meninggalkan jawaban saya di sini, agar tidak hilang, mungkin seseorang akan berguna. Jika Anda tidak dapat membacanya, saya berkeras menyertakan daftar autotest yang dikembangkan dalam deskripsi PR dan fokus pada itu. Saya percaya ini adalah hak dan kewajiban penuh dari tim QA untuk mewaspadai mungkin tentang cakupan produk dengan autotest, jika tidak seluruh gagasan jaminan Kualitas hilang ... Jika kita mempertimbangkan situasi keterbatasan waktu yang berat dari seluruh tim, termasuk pengembang, maka saya akan meminta peninjauan kembali. Cakupan skenario kritis / strategis oleh autotests integrasi. Dan untuk semua skenario lain, saya mendokumentasikan tugas terpisah untuk membuatnya nanti. Dalam proyek apa pun, ada periode tenang ketika tidak ada tenggat waktu - maka ada baiknya memfokuskan Manajer Produk / Ketua Tim / Scrum Masters tentang cara memasukkan tugas-tugas ini: itu lebih rumit - biarkan pengembang melakukannya, pelajari sendiri yang paling sederhana.
Kesimpulan
Saya tidak bisa mengatakan bahwa segala sesuatu yang tertulis di atas pasti akan membantu Anda, setelah semua, saya merasa bahwa suara dan gaya profesional saya sendiri datang dengan pengalaman dan melalui benjolan boneka. Tidak mungkin untuk mengambil dan bagaimana menerapkan skrip kerja orang lain ke proyek Anda melalui stensil. Tetapi jika coretan saya meminta Anda untuk tidak memasang momen yang tidak Anda sukai, dan Anda punya ide di benak Anda bahwa Anda dapat melakukan yang baik untuk diri sendiri, untuk tim, untuk produk, maka saya telah menghabiskan waktu tidak sia-sia. Dan ya, jangan berpikir saya menggambarkan QA Shark, yang tahu segalanya, tahu segalanya. Saya belajar dan berubah terus-menerus. Saya sadar betul bahwa dalam setahun prinsip-prinsip kerja saya dapat berubah. Selalu sangat senang dengan umpan balik dan saya akan dengan senang hati belajar dari pengalaman Anda, menulis;)
Dan jika Anda ingin membaca sesuatu untuk memperkuat motivasi Anda sendiri, mulailah dengan dua buku yang bagus, referensi yang saya berikan dalam teks:
1. Yayasan Pengujian Perangkat Lunak: Sertifikasi ISTQB
oleh Dorothy Graham, Rex Black, Erik van Veenendaal, Isabel Evans
2. Cara menguji di Google
James Whittaker, Jason Arbon, Jeff Carollo
Terima kasih atas perhatian Anda!