Dalam edisi baru podcast Dry Oars, pengembang Android mengundang orang-orang QA untuk mengunjungi. Kami membahas disiplin apa ini, bagaimana itu berguna untuk bisnis dan bagaimana menguji roket tanpa meminta Ilon Mask.
Pengembang Redmadrobot
merekam podcast penuh perasaan yang membahas pengembangan, analitik, pengujian, dan aspek lain dalam menciptakan produk TI. Kali ini, detasemen QA dari Redmadrobot mengintip ke dalam cahaya: rekan setimnya Alex dan Gleb, dan pemimpin mereka Sasha. Kami mendapat percakapan jujur tentang kehidupan QA di dunia di mana ada penguji dan pengembang. Di bawah ini adalah tautan ke entri lengkap dan jawaban untuk pertanyaan terpanas.
Apa itu QA?
QA atau Quality Assurance adalah disiplin yang bertanggung jawab atas kualitas produk. Misalnya, untuk kualitas aplikasi seluler. Biasanya ini diintegrasikan ke dalam semua tahap proyek. Spesialis QA menyiapkan dan menerapkan standar pengembangan, melakukan pemeriksaan kualitas, mencegah kesalahan, dan terus meningkatkan proses internal. QA digunakan tidak hanya dalam pengembangan ponsel, tetapi juga di web, di industri dan di banyak bidang lainnya.
Apa perbedaan dari tester?
QC global (Kontrol Kualitas) atau penguji adalah bagian dari QA.
Penguji mempelajari produk, melakukan penelitian, menyusun skenario yang mungkin dan menangkap bug. Ini memberikan tim dengan gambaran keseluruhan produk. QC tidak meningkatkan kualitas, tetapi memberikan gambaran tentang apa yang terjadi dalam pengembangan.
QA juga membantu tim untuk menetapkan proses yang berkaitan dengan kualitas. Dia melihat seluruh gambar dan membuatnya sehingga ada lebih sedikit kesalahan.
QC tentang hasilnya: temukan bug. QA tentang proses: proses pengembangan debug sehingga tidak ada bug.
Haruskah penguji mengetahui bahasa pemrograman tempat program ditulis?
Penguji tidak harus tahu bahasa dan teknologi, tetapi ini bisa menjadi nilai tambah dalam pekerjaan.
Saya benar-benar ingin menyelidiki bug dan kadang-kadang itu membawa saya ke bawah: Saya mencapai baris kode di mana bug itu direproduksi. Sangat menarik ketika Anda dapat memberikan sedikit lebih banyak informasi kepada pengembang di "laporan bug". Tapi ini sepenuhnya opsional.
"Kode ini ditulis h̶o̶r̶o̶sh̶o̶": pengembang menulis kode, dan tester mencari bug. Bagaimana tidak bertengkar?
Pengembang sedang memikirkan bagaimana melakukannya dengan baik. Penguji berpikir bagaimana menguji untuk menemukan mengapa ini buruk. Ada konflik kepentingan tertentu.
Kami memiliki hipotesis bahwa itu semua tergantung pada seberapa jauh QA dari pengembang. Ketika mereka duduk di dekatnya, mereka beralasan dan merenungkan tugas bersama. Ini bekerja lebih baik karena tingkat kepercayaannya lebih tinggi. Berada di departemen atau perusahaan yang berbeda sulit untuk mencapai saling pengertian seperti itu. Tetap marah pada laporan dari orang yang tidak dikenal.
Ini juga terjadi pada spesialis di awal perjalanan. QA dan pengembang muda memiliki sedikit pengalaman dalam kerja tim, sehingga kesulitan muncul. Seiring waktu, ada kesadaran bahwa Anda adalah mitra, mengerjakan satu produk dan melakukannya lebih baik bersama.
QA go programmer gagal?
Itu terjadi dengan cara yang berbeda, beberapa pergi untuk menguji cinta. Sebagai contoh, Kepala QA Sasha kami meninggalkan pemrograman karena ia lebih suka merusak segalanya. Apakah mungkin untuk "bermigrasi" dari satu jenis pengujian ke yang lain?
Singkatnya, ya. Penguji adalah penguji di mana-mana: ia harus dapat membuat bug, memahami bagaimana tes ditulis dan sebagainya. Jika mau, Anda bisa mengetahui arah baru dalam beberapa minggu.
Tapi bagaimana cara menguji roket?
Kami sedang menguji perangkat lunak dan tidak terkait dengan ruang. Tapi kita bisa berasumsi bagaimana ini bisa terjadi.
Seperti dalam tes lain, di sini kita berurusan dengan daftar karakteristik objek. Materialnya, ketahanan aus, suhu pemanasan atau pendinginan, jumlah bahan bakar per penerbangan, dan ratusan poin lainnya. Jika penguji ingin menguji roket, maka ia akan melakukan apa pun dengan roket itu: ia akan memanaskan, mendinginkan, mengirimkannya ke jarak yang tidak dirancang untuknya, dan seterusnya. Pengembangan skenario seperti itu, mulai dari dokumentasi untuk objek atau dari pengetahuan empiris, mampu mengidentifikasi cacat, koreksi yang menentukan kualitas produk apa pun.
Tautan yang bermanfaat
Paket perdana untuk siapa saja yang ingin masuk ke dunia QA hari ini:
→
Menguji Dot Kom, atau Buku Pegangan tentang Kekejaman terhadap Bug di Startup Internet→
Pengujian Perangkat Lunak. Kursus dasar→
sertifikasi ISTQB→
Harus Memiliki untuk setiap testerJika Anda memiliki pertanyaan - tulis di komentar, kami akan mengerti :)
Dengarkan kami di platform yang nyaman
SoundCloud Apple Google Podcasts . Ayo bahas masalah ini di
obrolan Telegram .