Untuk mulai dengan, di antara orang-orang, semua insinyur jaminan kualitas ("dengan cara kita sendiri", insinyur dari departemen kualitas) disebut penguji. Ini tidak sepenuhnya benar, pada kenyataannya pengujian hanyalah bagian dari tugas QA, tetapi siapa yang akan peduli. Oleh karena itu, mari kita masuk dalam tren umum dan kami akan menggunakan drive biasa untuk semua.
Jadi apa yang menentukan penguji yang baik? Kami tidak akan tunduk pada kata-kata hampa dan berkata: perhatian, ketekunan, kesabaran, keingintahuan, bakat, semua istirahat dan omong kosong lainnya. Ini semua, tentu saja, penting, tetapi bukan yang utama. Pertama-tama, seseorang harus memiliki akal sehat dan tanggung jawab.
Misalnya, kata mereka, yang utama adalah memiliki bakat untuk menghancurkan segalanya. Seringkali Anda dapat mendengar, mereka mengatakan bahwa dia tidak akan mengambil, akan merusak segalanya. Ini, tentu saja, patut dipuji, tetapi pekerjaan penguji bukanlah hal utama untuk memecahkan sesuatu. Di sini, definisi akan muncul untuk bantuan kami, yang tidak sulit ditemukan di Wikipedia.
Pengujian perangkat lunak adalah proses meneliti, menguji produk perangkat lunak, yang bertujuan untuk memeriksa korespondensi antara perilaku nyata program dan perilaku yang diharapkan pada serangkaian tes terbatas yang dipilih dengan cara tertentu.
Ini menunjukkan bahwa ada persyaratan khusus untuk perangkat lunak, dan perlu dipenuhi. Jika penguji merusak program alih-alih memeriksa apakah ia menjalankan fungsi yang ditetapkan untuk itu sama sekali, sebagai hasilnya, itu bisa menjadi stabil, tetapi tidak perlu, sampah bagi pelanggan.
Saya mengerti bahwa semua orang menyukai cerita, bagaimana seseorang mengacau, saya memilikinya. Saya bekerja di tempat yang berbeda dan pada proyek yang berbeda untuk pekerjaan saya, jadi saya sendiri adalah saksi atau mendengar banyak cerita dari rekan-rekan saya. Beberapa dari mereka siap bercerita. Baiklah dan ya, mantra yang diperlukan: semua kebetulan adalah acak, dan nama diciptakan.
Menguji dan banyak lagi
Mari kita mulai. Seperti yang saya katakan di awal, tester tidak hanya pengujian. Bagaimana Anda menyukai permainan kata-kata seperti itu? Di perusahaan besar dan terkemuka, mereka mencoba menghubungkan tim penguji dengan proyek pada tahap awal, yaitu. pada tahap pengumpulan persyaratan, tetapi ini tidak dilakukan di mana-mana dan tidak selalu.
Setelah selama pengujian penerimaan, pengguna memulai bug kritis, karena salah satu persyaratan tidak terpenuhi. Inti dari klaim tersebut adalah bahwa pengguna di layar tidak menemukan atribut yang dibutuhkannya (bagi mereka yang ada di tangki - bidang dengan nilai). Penguji, tentu saja, masuk ke dalam spesifikasi, memeriksa apakah atribut ini ada dalam aplikasi, dan dengan gembira berlari memberi tahu pengguna bahwa semuanya baik-baik saja.
Anda sudah mengerti bahwa sejarah tidak berakhir di situ.
Penguji mencoba menjelaskan kepada pengguna apa kesalahannya, setelah mengalami bagian negatif dan kemarahan. Pengguna mendudukkannya dan menemukan persyaratan berdasarkan spesifikasi tertulis. Salah satu persyaratan ini hampir secara harfiah dibaca sebagai berikut: "Atribut harus ditampilkan di setiap layar." Satu kalimat, tapi betapa masuk akal! Kemudian dia membuka aplikasi dan mulai menavigasi secara acak ke layar yang berbeda, mengatakan: "Dan di mana atribut ini?" Jelas bahwa pengguna secara terbuka diejek, tetapi secara resmi ia memiliki hak untuk melakukannya. Masalahnya adalah bahwa eskalasi terus berlangsung, dan semakin banyak orang terlibat dalam diskusi tentang masalah tersebut. Pada akhir pengguna, selain penguji sendiri, beberapa PM dan kerumunan analis meyakinkannya, dan dia bersikeras dan menuntut hal yang mustahil.
Akibatnya, sebuah kompromi ditemukan, dan dalam permintaan tersebut daftar layar yang diperlukan muncul di mana atribut harus ditempatkan, tetapi ini membutuhkan perubahan besar dalam kode program, karenanya, seluruh siklus pengembangan harus dijalankan kembali, tetapi dengan kecepatan yang dipercepat. Perusahaan mengeluarkan uang ekstra, belum lagi biaya reputasi, untuk stres dan pemrosesan karyawan. Semua ini bisa dihindari jika tester terhubung pada awal proyek dan dia bisa melihat persyaratan untuk ambiguitas - setidaknya, atau lambat, untuk memeriksa spesifikasi untuk kepatuhan dengan persyaratan. Dan ya, penguji sering bekerja dengan pengguna nyata secara langsung, yang mengharuskan mereka untuk menangani pengurangan stres, psikoanalisis dan persepsi ekstrasensor.
Tidak ada fanatisme
Kami melangkah lebih jauh, sangat ironisnya, proses pengujian itu sendiri ditandai dengan anekdot berjanggut:
Setelah tester memasuki bar.
Berlari ke bar.
Merayap ke bar.
Menari, menembus bar.
Menyelinap ke bar.
Masuk ke bar.
Melompat ke bar.
Pesanan:
secangkir bir
2 gelas bir
0 gelas bir
999999999 gelas bir,
kadal dalam gelas
-1 gelas bir
mug bir qwerty.
Pelanggan nyata pertama datang ke bar dan bertanya di mana toiletnya. Bilah terbakar, semua orang mati.
Tidak semua orang mengerti bahwa Anda dapat menguji tanpa henti. Yang ideal tidak dapat dicapai, dan proyek memiliki tenggat waktu yang sangat spesifik untuk menyesuaikan. Jadi, ada satu penguji yang, ketika lulus ujian, selalu gagal. Waktu berlalu, proyek sudah mulai berakhir, dan pengembang mengatasi semua masalah yang ditemukan. Dan di sini penguji menyatakan bahwa fungsi dasar yang diperlukan tidak bekerja. Semua orang mengerti: itu tidak akan berhasil memperbaikinya tepat waktu.
Dalam proses persidangan, ternyata: selama pengujian, skrip tidak pernah selesai sepenuhnya sampai saat naas. Penguji menemukan cacat pada awal proses, yang diuji, memulai tiket dan melemparkan setengah. Pada saat yang sama, itu mungkin untuk melanjutkan pengujian, karena Semua kesalahan yang ditemukan tidak memblokirnya. Selanjutnya, seluruh tim memiliki tekanan dan pemrosesan tradisional.
Ngomong-ngomong, beberapa pengguna melakukan ini pada pengujian penerimaan, menyatakan bug kritis dan berhenti bekerja. Ini sangat menyulitkan pekerjaan, karena dalam aliran masalah umum, yang secara umum mungkin tidak menjadi masalah, bug yang sangat kritis hilang.
Moralnya adalah ini: seorang penguji yang baik tidak akan pernah berhenti menemukan bug pertama yang ditemukan. Itu akan melewati seluruh skrip dari awal hingga akhir, secara bersamaan merekam semua bug yang ditemukan, dan jika itu mengalami kesalahan saat memblokir bagian tersebut, ia akan mencari solusinya, mis. solusi. Dan ketika dia yakin bahwa tidak ada solusi, dia akan berhenti.
Ada satu peringatan. Paling sering, proyek dilakukan di bawah tenggat waktu yang ketat, atau tidak terlalu ketat, tetapi cukup spesifik. Kebetulan bahwa seseorang disemprotkan pada pengujian tanpa henti dari satu bidang, memperkenalkan semua varian nilai yang mungkin dan tidak mungkin. Selain itu, sesuai dengan kebutuhan pelanggan, perlu untuk memeriksa fungsi yang dilakukan oleh aplikasi, meskipun menggunakan nilai dari bidang ini. Akibatnya, ia berisiko membuang-buang waktu dan tidak memeriksa hal utama. Penguji harus dapat menilai dengan benar kekuatan dan tempat kritis aplikasi mereka. Tidak perlu menguji tempat-tempat yang tidak memerlukan pengujian. Yang utama adalah bahwa aplikasi harus memenuhi fungsi yang ditugaskan padanya. Pertama, Anda perlu mencapai eksekusi skenario langsung, dan kemudian meningkatkan kualitas eksekusi ke level yang diinginkan.
Lidah saya adalah musuh saya
Selanjutnya ... Masalah dengan dokumentasi tidak hanya untuk analis, tetapi juga untuk penguji. Berulang kali dicatat bahwa tidak hanya para pengembang tidak dapat dengan jelas menggambarkan isi tiket di bidang yang sesuai, tetapi penguji sendiri tidak dapat dengan benar menuliskan urutan tindakan yang menyebabkan kesalahan. Ini masalah besar. Seseorang sama sekali tidak mengerti mengapa kesalahan terjadi, dan tidak repot-repot mencari tahu langkah-langkahnya. Seseorang memiliki masalah literasi sama sekali.
Apa artinya semua ini? Di sini jawabannya dan landak bisa dimengerti, tetapi dengan contoh-contohnya, tentu saja lebih menarik.
Ada sekelompok penguji yang, melihat kesalahan di depan mereka sendiri, cukup mencatat jutaan langkah itu, termasuk sampah yang menyebabkan bug. Mereka tidak mereproduksi kesalahan dan tidak mencari tahu apa sebenarnya yang menyebabkannya. Pada saat yang sama, mereka dapat menuliskan serangkaian langkah yang tidak terkait dengan kesalahan ini sama sekali. Pengembang akan mencoba mereproduksi, pada titik tertentu kepalanya akan mendidih, dan ia akan pergi untuk menangani tester secara pribadi. Mereka akan mengerti bersama dan keduanya akan menghabiskan banyak waktu untuk komunikasi yang tidak perlu. Untungnya, semua ini dengan cepat ditangani oleh waktu dan pengalaman, walaupun ada beberapa kasus klinis.
Literasi semakin sulit. Dalam praktik saya, ada kasus ketika pemimpin QA perlu memperbaiki deskripsi beberapa lusin tiket, karena mereka seharusnya dikirim ke pelanggan dalam laporan kemajuan. Ini terjadi karena sebagian besar tim tidak dapat merumuskan pikiran mereka dengan benar dalam bahasa Inggris.
Tetapi ada juga masalah dengan Rusia, terima kasih Tuhan, lebih jarang. Semuanya sama di sini, deskripsi yang ditulis dengan buruk menyebabkan fakta bahwa tiket, seperti bola sepak, mulai berderap di antara orang-orang tanpa masuk ke gawang. Baik jika tim semua berada di ruangan yang sama dan dapat berbicara tanpa bangun dari monitor. Lebih sulit - jika tim didistribusikan. Sangat buruk, jika multibahasa. Hal terburuk yang dapat terjadi pada akhirnya adalah bahwa tiket akan dilakukan secara tidak benar karena kesalahpahaman dan akan dibuka kembali seribu kali. Dan bahkan kepada pelanggan akan terbang dalam salah satu rilis dengan logika terbalik.
Ruang pribadi
Masalah lain adalah bangku tes dan data tes. Di perusahaan yang berbeda, ini terjadi dengan cara yang berbeda, tetapi sering terjadi bahwa seorang karyawan diberikan hak ke server kerja pelanggan atau diberikan databasenya untuk pengujian. Tampaknya apa yang salah?
Tapi apa yang ... Jika seseorang memiliki akses ke server pelanggan, di satu sisi itu nyaman, Anda dapat melihat masalah dari peringkat pertama dan tidak membuat kesalahan tentang foto. Tetapi ada risiko merusak data pelanggan, yang dapat menyebabkan konsekuensi serius. Saya sudah diam tentang kasus-kasus ketika akses seperti itu umumnya dilarang oleh hukum.
Ada kasus ketika seorang pelanggan jatuh dari server selama 3 hari. Pengembang selama ini tidak dapat memahami mengapa ini terjadi, dan dengan panik mencari kesalahan, dan bisnisnya mengalami kerugian. Akibatnya, ternyata: perusahaan mempekerjakan orang India untuk melakukan outsourcing, di mana orang-orang, tanpa basa-basi lagi, memberikan semua hak admin. Untuk semua orang - ini berarti bahkan gadis itu yang telah bekerja selama 3 hari di perusahaan, dan tidak ada komputer di desanya, sehingga mereka memiliki periode kencan yang lebih pendek. Tetapi gadis itu ternyata sangat berbakat, dia berhasil menemukan esensi dasar di panel admin dan mengubah tipenya, setelah itu semuanya secara alami jatuh dan berhenti bekerja. Mudah untuk menebak bagaimana dia melepas karier setelah itu.
Omong kosong yang sama dan dengan data dari pelanggan. Sekali lagi, saya tidak berbicara tentang kasus-kasus yang dilarang oleh hukum. Jika mungkin untuk bekerja pada data nyata, ini bagus, tetapi orang harus berhati-hati dengan ini. Semua orang mungkin mendengar cerita tentang pengiriman surat atau pesan acak dari server uji ke pengguna sungguhan. Jadi, ini bukan lelucon. Ini benar-benar terjadi, dan cukup sering. Nah, jika pesan-pesan ini berhak sebagai pesan uji dan memiliki konten yang waras, tetapi kebetulan orang-orang engah dan menulis apa yang disesali seluruh tim pengembangan aplikasi.
Momen organisasi
Saya sudah mulai bosan dengan banyak teks, jadi yang terakhir. Penguji harus selalu memberikan informasi terbaru tentang pekerjaannya kepada bosnya. Menurut laporan tersebut, jika dilakukan dengan benar, kepala membuat kesimpulan tentang keadaan proyek secara keseluruhan. Tidak hanya tentang pekerjaan satu penguji atau seluruh tim pengujian, tetapi juga tentang pekerjaan tim pengembangan dan tahap di mana proyek berada. Selain itu, laporan tersebut memungkinkan analisis direncanakan untuk rilis di masa mendatang, dll., Dll.
Ada banyak contoh ketika pekerjaan ini tidak dilakukan atau dilakukan dengan cara yang tidak pantas, dari mana pihak berwenang memiliki perasaan ketidakpastian dengan semua konsekuensi yang terjadi. Aku akan memberitahumu yang paling cerdas.
Setelah tester dimasukkan pada proyek baru. Karena dia tidak mengenalnya dengan baik, dia diberi tugas memilah dan merekam pengamatan. Karena itu adalah sesuatu yang informal, kami sepakat bahwa kami akan menulis di Googledock. Pria itu mulai melakukan tugas, seminggu kemudian tugas ini diperiksa, penguji ditepuk pundak dan dia terus bekerja. Berbulan-bulan berlalu, pihak berwenang mulai khawatir mengapa tidak ada tiket di bugtracker dan tidak ada yang dilakukan pada proyek tersebut. Kami mulai mencari tahu, ternyata seseorang terus menulis di Googledock itu. Tidak ada yang mengatakan "Potty, jangan memasak" dan tidak menghentikan tester, dan dia secara teratur terus memahami dan mencatat pengamatan, sementara tidak membiarkan dirinya tahu. Ada bug, dan dia menemukan mereka, tetapi tidak memberi tahu siapa pun, tetapi hanya mencatatnya dalam file, yang semua orang lupa seminggu kemudian.
Bahkan, harapannya adalah bahwa seseorang akan terus bekerja secara formal, yaitu di pelacak bug, memberikan tiket kepada pengembang dengan tiket mereka, tetapi ini tidak terjadi. Tampaknya pria itu tidak melakukan apa-apa, meskipun dia bekerja. Jelas bahwa masalahnya bukan hanya pada pihak penguji, tetapi jika dia melakukan laporan rutin tentang kegiatannya, maka kesalahpahaman dapat dihindari.
Seringkali kurangnya informasi menciptakan perasaan pengujian produk yang buruk, bahwa ini atau itu bagian dari fungsi belum diuji. Untuk mencegah hal ini terjadi, Anda perlu membuat laporan terperinci, ini sangat penting untuk proyek-proyek besar.
Kesimpulan
Anda perlu memahami bahwa QA sebenarnya adalah pengacara pengguna. Dalam situasi yang tidak dapat dipahami terkait dengan aplikasi, penguji harus menempatkan dirinya di tempatnya. Jika, melalui manipulasi kesadaran sederhana ini, ternyata aplikasi tersebut tidak senang dengan sesuatu, maka Anda perlu memulai tiket. Dan ini mungkin sebuah tombol di tempat yang salah atau hal sepele lain dari sudut pandang pengembang, tetapi sering terjadi bahwa bagi pengguna hal sepele ini bisa berubah menjadi neraka dan titik iritasi. Sebagai contoh, Anda dapat mengambil pop-up dalam aplikasi. Ya, program menjalankan fungsinya, tetapi sulit untuk menggunakannya, karena pelaksanaan fungsi ini membutuhkan banyak waktu dan upaya pengguna yang terpaksa menekan banyak jendela tambahan dengan unduhan dan lebih banyak, daripada melakukan semua pekerjaan pada satu layar.
Dan jika seseorang secara bertanggung jawab dan dengan akal sehat mendekati pekerjaannya, maka dia akan dapat menghindari sebagian besar masalah di jalannya, tidak hanya dalam profesi QA.