Latar belakang
Baru-baru ini, salah satu kenalan saya QA Engineer, yang bekerja lama di sebuah proyek yang lamban, di mana tanggung jawabnya dijabarkan dengan ketat, mengubah pekerjaannya dan masuk ke proyek yang baru diluncurkan. Setelah menghabiskan beberapa hari tanpa tugas yang ditunjukkan di atas, dan terus terang bosan, dia pergi ke manajemen dengan pertanyaan "Apa yang harus saya lakukan?" di mana dia menerima respons yang bermakna, "Atur pekerjaan Anda." Dan kemudian dia jatuh pingsan, "Dan bagaimana ini?" Dan sungguh, bagaimana?
Beberapa bulan yang lalu, saya mengubah pekerjaan saya sendiri dan masuk ke proyek bahasa Inggris yang tidak pernah memiliki QA sebelumnya. Proyek itu sendiri sudah ada sejak lama. Seperti yang sering terjadi, sebuah perusahaan di mana ada banyak uang telah membeli perusahaan di mana ada sedikit uang, tetapi ada pelanggan. Akibatnya, sebuah perusahaan besar menerima pelanggan baru dan minus satu pesaing di pasar. Proyek saya menerima perubahan prinsip manajemen dan manajemen.
Pada hari-hari pertama bertemu dengan tim baru, saya mendengar pertanyaan membingungkan yang jujur dari salah satu pengembang kantor London, "Apa yang akan Anda lakukan di sini?"
Sebenarnya, setelah datang ke proyek ini dan melihat-lihat selama beberapa hari, saya, seperti rekan saya, pada awalnya jatuh pingsan. Bukan karena saya tidak tahu harus berbuat apa. Sebaliknya, saya tidak tahu bagaimana cara memasukkan diri ke dalam fondasi yang telah dikembangkan di sini dengan benar. Tim pengembangan memiliki keberadaan yang luar biasa tanpa penguji. Mereka menggunakan kanban, prinsip-prinsip pengiriman berkelanjutan, tanpa rasa takut, dengan tenang dan penuh percaya diri digunakan untuk produksi hampir setiap hari, bahkan pada hari Jumat. Dan semuanya karena mereka memiliki cakupan yang sangat baik dengan autotest. Mungkin yang terbaik yang pernah saya temui. Saat meninjau permintaan satu sama lain, mereka tidak ragu untuk saling memberi tahu satu sama lain tentang apa yang ditambahkan autotest. Penulis perubahan saat ini sendiri menyebarkan karyanya ke produksi, yang berarti ia bertanggung jawab penuh atas karyanya. Dan dia membawanya, terlepas dari kenyataan bahwa saya muncul di proyek ... dan sebelum penempatan, alangkah baiknya mendengar pendapat saya.
Namun demikian, tentu saja, prosesnya tidak sempurna: kebetulan pengembang tidak memahami persyaratan, melewatkan bug, dan cukup sering di sisi pelanggan ada beberapa masalah yang memerlukan tindakan.
Menghadapi kebutuhan untuk menentukan posisi saya di tim, saya juga pergi ke kepemimpinan. Hanya dialog kami yang dibangun sangat berbeda, tidak seperti teman saya.
Organisasi kerja Insinyur QA
Ajukan pertanyaan yang tepat.
Jadi Untuk dialog, saya mengumpulkan para pemimpin dan pengembang proyek yang terkemuka. Ada satu aturan manajemen yang luar biasa, yang tentu saja tidak bisa saya lupakan: menyuarakan masalah, menyuarakan opsi untuk menyelesaikannya, setidaknya satu.
Meskipun demikian, saya memiliki dua pertanyaan, jawaban yang tidak dapat saya ketahui. Cara termudah untuk memulai dengan mereka.
Pertanyaan pertama. Apa struktur organisasi, yaitu, siapa yang berdiri di atas siapa dan siapa yang bertanggung jawab atas apa?Idealnya, perusahaan harus memiliki skema yang disajikan secara hierarkis yang menggambarkan struktur perusahaan. Tapi saya tidak ideal, jadi penting untuk mencari tahu kepada siapa dengan pertanyaan dan saran apa Anda bisa pergi.
Pertanyaan kedua. Perusahaan memperkenalkan QA Engineer ke dalam proyek, apa harapan mereka bagi saya, apa tujuan mereka dalam membuka posisi ini?Ketika jawabannya sangat spesifik, sebagian besar menentukan bagian depan pekerjaan. Dalam kasus saya, jawabannya berisi banyak frasa umum yang kabur, yang saya anggap sebagai "lakukan apa yang Anda inginkan, tetapi agar semuanya baik-baik saja dengan kami."
Tentang ini, bagian pertama dari diskusi berakhir.
Kami membahas rencana aksi
Bagian kedua dari diskusi, dan mungkin yang paling penting, adalah presentasi rencana kerja saya dan alasannya. Saya perlu menerima restu dari atasan saya untuk pengenalan tanpa hambatan dari diri saya dan kegiatan saya ke dalam proyek.
Sangat jelas bahwa buku-buku pintar dan teori tidak ada dari awal, jadi saya mempersenjatai diri dengan pengetahuan yang diperoleh dalam persiapan untuk sertifikasi ISTQB, sekali karena penasaran saya membaca buku-buku tentang teori pengujian dan Scrum, saya memberikannya semua melalui pengalaman sepuluh tahun dan menyusun pilot. proyek untuk Strategi QA.
Bernegosiasi dengan manajemen dan didukung penuh olehnya, ia kemudian memperoleh format dokumen resmi perusahaan. Selanjutnya, saya ingin berbagi ide tentang cara menyusun dokumen seperti itu. Mereka membentuk intisari dari pengalaman sebelumnya dan jalan yang ditempuh pada proyek saat ini.
Dan, mungkin, dalam bentuk kutipan saya akan mencetak ulang di sini beberapa fragmen dalam bentuk asli saya: dalam bahasa Inggris. Saya yakin bahwa untuk setiap QA Engineer, persiapan rencana seperti itu akan menjadi jawaban kunci untuk pertanyaan "Bagaimana mengatur pekerjaan Anda"
Kami membentuk Strategi QA
1. Pengantar Jaminan Kualitas
Ingatkan / perkenalkan istilah Jaminan Kualitas untuk pertama kalinya. Percayalah, tim Anda penuh dengan orang-orang yang sangat samar membayangkan apa itu. Definisi umum yang cukup dapat dipinjam
dari Wikipedia . Taktik menunjukkan bahwa kehadiran tim QA pada proyek tidak berarti bahwa semua tanggung jawab untuk kualitas pekerjaan sekarang ditransfer hanya kepada mereka:
Pengujian adalah bagian dari QA. Ini memungkinkan kami untuk menentukan tingkat kualitas fitur yang kami nilai.
Ini bukan tanggung jawab penguji untuk melakukan QA. Seluruh tim dapat dan harus berkontribusi untuk memastikan tingkat tinggi kualitas produk dan layanan yang disampaikan.
2. Pengantar Strategi QA
Persiapkan untuk apa yang akan dibaca lebih banyak orang.
Strategi Pengujian adalah dokumen yang berkembang yang merinci proses dan cara kita akan memastikan kualitas produk kita ke depan.
Suara kontennya. Ini bisa berupa daftar isi atau kalimat yang lebih abstrak. Di sini, sebutkan keberadaan Pendekatan Tes, Proses Tes, Strategi Otomasi Tes, dan kebutuhan akan Rencana Tes.
Itu penting. Tunjukkan interval waktu untuk merevisi dokumen ini. Dan proyek dan proses di perusahaan sedang berkembang, dokumen ini seharusnya tidak berubah menjadi dinosaurus. Karena itu, rencanakan tanggal ketika strategi Anda akan ditinjau dan diubah. Menurut saya, enam bulan sudah cukup untuk kembali dengan pemikiran baru.
3. Pendekatan Tes
Apa itu pendekatan pengujian? Beranjak sedikit dari kata-kata resmi yang banyak tentang definisi ini, saya membiarkan diri saya menyederhanakannya dengan tesis bahwa ini adalah "pemikiran dasar yang dengannya kita mulai bekerja setiap hari." Tulis di sini: apa mesin kemajuan Anda?
Klasik genre dan pendekatan yang berfungsi dengan baik adalah "proaktif" dan "berbasis risiko".
Kami akan mengadopsi pendekatan pengujian proaktif dan berbasis risiko.
Proaktif - Ini berarti bahwa proses desain pengujian dimulai sedini mungkin untuk menemukan dan memperbaiki cacat sebelum pembuatan dibuat.
Berbasis risiko - Ini berarti bahwa kami akan mengatur upaya pengujian kami dengan cara yang mengurangi tingkat risiko produk ketika sistem dikirimkan. Menurut silabus ISTQB “Pengujian berbasis risiko adalah gagasan bahwa kami dapat mengatur upaya pengujian kami dengan cara yang mengurangi tingkat residu risiko produk ketika sistem dikirimkan. Pengujian berbasis risiko menggunakan risiko untuk memprioritaskan dan menekankan pengujian yang sesuai selama pelaksanaan pengujian, tetapi ini lebih dari itu. Pengujian berbasis risiko dimulai pada awal proyek, mengidentifikasi risiko terhadap kualitas sistem dan menggunakan pengetahuan risiko tersebut untuk memandu perencanaan, spesifikasi, persiapan, dan pelaksanaan pengujian. Pengujian berbasis risiko melibatkan kedua mitigasi - pengujian untuk memberikan peluang untuk mengurangi kemungkinan cacat, terutama cacat berdampak tinggi - dan pengujian kontingensi - untuk mengidentifikasi solusi untuk membuat cacat yang melewati kita tidak begitu menyakitkan. Pengujian berbasis risiko juga melibatkan pengukuran seberapa baik yang kami lakukan dalam menemukan dan menghilangkan cacat di area kritis »
Ketika kita berbicara tentang menjadi proaktif, pertama-tama dan terutama kita harus berbicara tentang spesifikasi persyaratan kontrol kualitas. Para manajer yang menyusun spesifikasi elemen-elemen dari siklus pengembangan berikutnya, sebagian besar, berpikir sebagai pengguna biasa sistem, sementara logika pemikiran para pengembang ada di dimensi lain. Pertama, lebih dari sekali saya melihat bahwa seorang pengembang, membaca spesifikasi, tidak dapat menerjemahkannya ke dalam bahasa pemrograman. Misalnya, tidak dapat mencocokkan pengguna yang disebutkan dalam spesifikasi dengan peran / hak akses yang ada dalam sistem. Akibatnya, ia dapat memilih peran yang paling cocok, menurut pendapat pribadinya, yang ternyata salah dan harus mengembalikan fungsionalitas untuk bekerja kemudian dan kehilangan waktu; atau mengajukan pertanyaan kepada manajer, yang, mungkin, pergi berlibur dan sekali lagi kehilangan waktu untuk mengantisipasi. QA Engineer adalah lapisan luar biasa antara manajer yang berfokus pada pengguna dan pengembang yang berpikiran teknis, terutama jika QA Engineer tidak mengabaikan pengujian kotak putih. Kitalah yang mampu memahami manajer dan menerjemahkan pikiran mereka ke pengembang. Tepat waktu.
Pengujian berbasis risiko memiliki metode formal yang menarik untuk menilai risiko proyek dan risiko produk. Sangat bagus bisa mempraktikkannya. Tetapi secara pribadi, saya tidak pernah punya cukup waktu untuk melukiskan probabilitas kejadian, beratnya konsekuensi mereka, dll. dan menghitung risiko sesuai dengan semua aturan. Di sini saya lebih mengandalkan insting dan akal sehat saya. Saat menguji atau menutupi autotest dengan zona risiko (apa yang harus diberi perhatian pertama dan utama) untuk sebagian besar:
- fungsi yang dirancang langsung
- daerah yang berdekatan dan berinteraksi
- fungsionalitas yang penting secara komersial
- apa yang paling sering rusak
- kompatibilitas ke belakang (jika, misalnya, format metadata diubah, apakah fungsi data yang ada akan berhasil)
4. Proses Tes
Beri tahu kami urutan pekerjaan metodologis apa yang Anda rencanakan untuk patuhi. Saya tidak menemukan sesuatu yang rumit, tetapi saya mengambil
ide dari ISTQB dan menggunakannya.
Jika Anda mengikuti cara saya, berkenalanlah dengan urutan pekerjaan yang direkomendasikan oleh penulis ISTQB, perhatikan langkah-langkah apa yang akan Anda ambil dan bagaimana caranya. Kita mulai dengan perencanaan dan kontrol. Keduanya hidup bersama karena Berdasarkan pemantauan kegiatan mereka sendiri, rencana dapat digambar ulang secara teratur. Selanjutnya, bekerja dengan dokumentasi dan menulis uji kasus, menempatkan mereka ke dalam operasi (menggunakan data uji yang direncanakan dan lingkungan yang sesuai), menyelesaikan pengujian dan pembersihan setelah diri sendiri (menghapus file sementara, dll.)
Kami akan menggunakan proses pengujian yang diuraikan dalam silabus ISTQB tingkat Foundation: Perencanaan dan Kontrol Tes, Analisis dan Desain Uji, Implementasi dan Eksekusi Uji, Mengevaluasi Kriteria dan Pelaporan Keluar, dan Kegiatan Penutupan Tes.
5. Tanggung jawab
Identifikasi tanggung jawab Anda dan orang lain di bidang peningkatan kualitas produk. Laporkan misi Anda.
Pertama, tekankan lagi bahwa
setiap anggota tim adalah penguji dalam dirinya sendiri , semua orang menguji apa yang mereka hubungkan. Menulis kode - mengujinya.
Kedua, klarifikasi dan pahami arah pengembangan berkelanjutan Anda.
QA Engineer adalah ahli utama pada fungsionalitas produk : dia tahu bagaimana dan apa yang berhasil, mampu menjelaskan bagaimana dan apa yang perlu diuji. Dia adalah orang yang memprediksi perilaku operasional pelanggan, yang berarti bahwa dia tidak akan membiarkan masalah serius berkembang.
Ketiga, tunjukkan
bagaimana Anda berinteraksi dengan manajer dan pengembang . Misalnya, berhenti di
pendekatan Tiga amigos tangkasKolaborasi antara Bisnis, Pengembangan dan QA
a. Bisnis - Masalah apa yang kita coba selesaikan?
b. Pengembangan - Bagaimana kita membangun solusi untuk menyelesaikan masalah itu?
c. Pengujian - Bagaimana dengan ini, apa yang mungkin terjadi
6. Tingkat Pengujian dan Strategi Otomasi QA
Hari ini, bagian ini telah menjadi dokumen mandiri mandiri bagi saya. Tetapi pada tingkat organisasi dari proses QA yang baru lahir dalam tim, tunjukkan jenis pengujian apa yang akan dilakukan oleh siapa. Apa yang akan dilakukan secara manual, apa yang akan diotomatisasi, dan dengan prinsip apa. Siapa yang bertanggung jawab atas autotest.
Sebagai contoh, pada proyek saat ini, saya hanya menulis tes end-to-end, operasi yang lancar yang secara strategis penting dari sudut pandang bisnis. Pada saat yang sama, saya melihat permintaan tarik pengembang dan, jika perlu, memberikan rekomendasi tentang cakupan pengujian. Semua yang lain (unit, integrasi, memuat, dll.) Adalah karya pengembang. Pada proyek sebelumnya, pengujian beban ada pada saya, dan saya menulis tes integrasi bersama dengan para pengembang.
7. Fitur alur kerja
Hari ini, proyek saya bekerja di Scrum menggunakan sprint dua minggu. Oleh karena itu, saya memiliki dokumen siklus hidup tertulis selangkah demi selangkah untuk setiap Kisah.
Apapun metodologi yang dipatuhi proyek, jelaskan bagaimana melakukan pekerjaan sehari-hari selangkah demi selangkah. Jika di atas kita berbicara lebih banyak tentang taktik aksi, maka harus ada indikasi yang jelas tentang apa yang terjadi terlebih dahulu, lalu apa.
Misalnya, versi saya adalah
Alur kerja di bawah merinci proses yang akan kami adopsi secara internal.
1. Dapatkan cerita sebelum sesi perencanaan
2. Buat daftar periksa sesuai dengan kriteria penerimaan dan deskripsi
3. Catat detail / pertanyaan yang tidak jelas
4. Perjelas pertanyaan tentang perencanaan
5. Perbarui daftar periksa
6. Sorot semua dependensi dan bagaimana Anda akan mengatasinya
7. Ketika cerita dalam Review memeriksa apakah kriteria penerimaan dicakup oleh autotest
8. Dorong pengembang untuk mencakup semua kriteria penerimaan dengan autotest atau lakukan sendiri
9. Ketika cerita siap untuk pengujian, lakukan pengujian manual menggunakan daftar periksa
10. Buat bug untuk cerita jika ada dan kembalikan item ke pengembangan
11. Ketika bug diperbaiki lakukan pengujian manual menggunakan daftar periksa lagi
12. Periksa apakah semua autotest dilewatkan
13. Buat tugas untuk mengimplementasikan autopsi integrasi tambahan jika diperlukan
14. Memindahkan cerita dalam status QA Passed
8. Rencana Uji
Pilih jenis Rencana Tes, platform tempat Anda akan menyimpannya dan tujuan keberadaannya. Berikan cara bagi siapa saja untuk mencari di sana.
Pada proyek ini, Rencana Tes saya adalah satu set daftar periksa untuk setiap Story. Dengan tingkat otomatisasi saat ini, ini sudah cukup untuk saat ini.
Pada proyek sebelumnya, Rencana Uji digunakan untuk pengujian manual menyeluruh dan sebagai dasar ideologis untuk autotest di masa mendatang.
Jika Anda memiliki banyak tes manual, tuliskan test case secara detail, sehingga setiap insinyur QA baru, setelah datang ke proyek, dapat melakukannya secara mandiri.
Cara bekerja dengan dokumen
Menulis seluruh rencana ini dan kata-kata efektif sangat keren. Pihak berwenang akan menghargai, saya tidak ragu. Namun ada satu poin penting dalam keberadaan dokumen ini. Ini adalah jawaban jujur untuk pertanyaan untuk siapa dan mengapa semua ini ditulis?
Saat menuliskan setiap kalimat, alangkah baiknya memikirkan pertanyaan:
"Apakah saya benar-benar ingin bekerja seperti ini?" ,
"Apakah saya benar-benar akan menghidupkan proyek ini?"Jika kedua jawaban positif, cetaklah dengan percaya diri.
Jika salah satu jawabannya adalah "Tidak", menurut pendapat saya, ini adalah tanda pasti untuk tidak menggantungkan tugas yang tidak perlu.
Jika salah satu jawabannya berasal dari seri "Saya belum tahu", biarkan langsung di halaman Anda untuk saat ini.
Saya memiliki saat-saat seperti itu tetap dalam daftar apa yang akan ditinjau pertama dalam beberapa bulan.
Pertama-tama, saya menulis dokumen saya sendiri. Saya memiliki saat-saat ketika saya mundur dari proses yang dijelaskan dan bahkan sedikit menentangnya. Menyesuaikan diri dengan situasi agar dapat menggunakan sumber daya secara efisien di sini dan saat ini adalah normal. Tetapi mayoritas, dengan pekerjaan rutin yang biasa, dokumen saya adalah buku panduan saya. Lebih dari sekali saya yakin bahwa rencana / strategi yang ada di bidang apa pun selalu membawa hasil yang diinginkan lebih cepat lebih cepat dan lebih sedikit rasa sakit daripada kekurangannya. Saya berharap Anda membangun pekerjaan Anda dengan mudah dan efisien!
Sebelum publikasi itu sendiri, artikelnya sangat berkurang, besar sekali rasanya bagi saya untuk Sandbox. Saya akan senang untuk melanjutkan topik ini nanti. Meskipun demikian, saya selalu senang untuk berkembang, jika ada sesuatu yang saya benar-benar lupa, tolong tuliskan saya komentar.
Terima kasih