Kami menganalisis secara terperinci bagaimana melakukan pengujian manual ketika itu lebih baik daripada pengujian otomatis, apa yang perlu dilakukan oleh para penguji dan bagaimana mereka dapat membangun karier mereka dari junior untuk menguji timah. Panduan ini disiapkan bersama dengan kepala departemen pengujian Agima Darina Gordeeva.
Hai Nama saya Darina Gordeeva. Saya telah bekerja di perusahaan AGIMA sebagai kepala departemen selama hampir 3 tahun. Di bidang pengujian dan jaminan kualitas selama lebih dari 6 tahun. Selama waktu ini, ia beralih dari junior ke kepala departemen, menguji besi, serta aplikasi seluler dan web, mengotomatisasi dan mengonfigurasi proses QA. Hari ini saya akan memberi tahu Anda tentang fitur, kemampuan, dan masalah tersembunyi dari pengujian manual.
Ingatlah bahwa setiap pembaca yang menggunakan kata promo Habr bisa mendapatkan diskon 10.000 rubel untuk kursus favorit mereka, sementara yang paling rajin dan penuh perhatian dapat mengumpulkan diskon 25.000 rubel dengan memecahkan teka-teki dari bahan yang disiapkan bersama dengan agensi Agima:
Efisiensi, fleksibilitas, kemungkinan improvisasi dan keuntungan lainnya
Saat ini ada banyak kerangka pengujian yang mendukung hampir semua bahasa yang ada. Tampaknya - Anda dapat mengambil dan mengotomatisasi. Tetapi bahkan sekarang, tes manual adalah penting.
Salah satu penjelasan untuk keperluan mereka adalah bahwa dengan pengujian manual terhadap fungsional, kita dapat memperoleh informasi tentang keadaan produk yang kita analisis lebih cepat, tentang kualitas pengembangan. Selain itu, selama otomatisasi, kasing pra-desain sering kali harus diubah dan diperbarui, dan perlu waktu untuk menulis autotest.
Pada saat yang sama, selama proses pengembangan, umpan balik dari pelanggan mungkin datang ketika dia melihat beberapa fungsi dalam produk jadi yang dia putuskan untuk diubah sebelum rilis - dan jika Anda sudah menyiapkan tes perangkat lunak untuk itu, Anda harus menulis ulang. Memutakhirkan kasus, menguji otomatis, dan memeriksanya akan membutuhkan waktu yang berharga yang dapat digunakan untuk memperbarui fitur ini sendiri.
Semua ini berarti bahwa tujuan utama dari tes manual adalah pertama-tama memastikan bahwa fungsionalitas yang dideklarasikan adalah fungsional, tidak memiliki kesalahan dan memberikan hasil yang diharapkan dan direncanakan. Tanpa mereka, Anda tidak dapat yakin bahwa Anda dapat bekerja. Ini terutama berlaku untuk fungsi-fungsi untuk implementasi yang terikat pengembangan selanjutnya. Dalam hal ini, keributan dengan penciptaan autotest untuk fitur-fitur ini menjadi faktor pemblokiran untuk seluruh pengembangan produk, menggeser tenggat waktu dan mengganggu tenggat waktu. Saat ketika saatnya tiba untuk mengotomatiskan kasus akan datang cepat atau lambat - tetapi jangan mencoba membawanya secara artifisial dalam mengejar pengecualian total tenaga kerja manual.
Selain itu, pada tahap awal pengembangan aplikasi, otomatisasi bisa sangat mahal. Anda akan memerlukan spesialis dengan kualifikasi khusus (dan mungkin lebih dari satu). Terus-menerus menjaga pengujian tetap terbaru membutuhkan sumber daya yang sesuai dengan pelepasan fitur. Dan bulan-bulan tanpa aktivitas yang ditujukan untuk menjilat autotest akan memukul motivasi tim.
Jika Anda ingin menambahkan fungsionalitas baru secara teratur dan mengikuti tindakan pesaing, maka sebelum membuat pengujian otomatis selalu periksa kemampuan produk secara manual. Hanya karena pengujian manual mempercepat proses Anda.
Ini terutama berlaku untuk pengembangan ponsel. Sebagian besar proyek ini sekarang sedang dikembangkan dalam sprint pendek, yang berarti fitur sedang diimplementasikan pada kecepatan yang dipercepat. Dalam kondisi seperti itu, pengujian manual memungkinkan Anda untuk memberikan umpan balik kepada tim secepat mungkin: melaporkan keberadaan bug - atau menyenangkannya dengan fakta bahwa semuanya baik-baik saja dan Anda dapat melanjutkan. Anda dapat melakukan serangkaian autotest nanti, yang mencakup sejumlah besar kode dengan bantuan mereka. Pengujian manual akan membantu menyiapkan kasus untuk pengujian ini.
Autests tidak memungkinkan Anda untuk memeriksa apakah nyaman untuk menggunakan fitur-fitur baru dari aplikasi - pengujian kegunaan selalu dilakukan secara manual.
Skillbox merekomendasikan: Kursus online Fullstack adalah pengembang seluler .
Dalam tes manual, Anda dapat berimprovisasi, membuat kombinasi tindakan gila yang tidak pernah terjadi pada pengguna, tetapi dapat dilakukan olehnya secara tidak sengaja. Ini memungkinkan Anda membuat case baru.
Kasus-kasus baru juga muncul karena penguji terus-menerus mengajukan pertanyaan "bagaimana jika?" Jadi dia menemukan cara orisinal untuk berinteraksi dengan aplikasi - bahkan jika mereka tidak ada dalam skenario dasar.
Masalah pengujian manual dan solusinya
Kerugian terbesar dari pengujian manual adalah faktor manusia. Tentu saja, ini mempengaruhi semua yang terjadi di tim - baik pekerjaan para peserta dan peristiwa yang terjadi di sisi klien. Dalam kasus QA, alasan bahwa tester lemah tenggelam dalam proses dan merindukan kesalahan potensial bisa apa saja - kurangnya pengalaman, masalah keluarga atau sakit kepala.
Dua penguji dapat menguji skenario yang sama dengan cara yang berbeda. Apa yang harus dilakukan? Adalah penting bahwa setiap hasil yang tidak terduga atau berbeda diharapkan dicatat sebagai suatu kasus. Sehingga setiap tester dapat mengujinya dengan melakukan serangkaian tindakan yang sama. Tetapi ini mungkin tidak cukup - jika kasing tidak cukup detail, dan tester tidak memahami uraian. Tentu saja, tidak mungkin untuk menjamin pengecualian absolut dari faktor manusia - tetapi Anda dapat mencoba untuk meminimalkan kemungkinan masalah yang disebabkannya.
Ini juga secara negatif mempengaruhi ketentuan pengiriman fitur dalam biaya produksi dan tenaga kerja: setelah semua, sekarang "rumit" kasus ditemukan oleh penguji dalam proses ditambahkan ke kasus dasar yang dilakukan secara berkala dan regresi.
Situasi ini diperburuk oleh kemungkinan bahwa beberapa bug yang ditemui belum memiliki deskripsi yang ketat karena alasan terjadinya mereka belum jelas. Bagaimana cara menghadapi tes ulang seperti itu? Entah menemukan sumber kesalahan dan menghilangkannya, atau - masih mengotomatiskan jalannya kasus-kasus masalah - dalam hal ini, transisi ke tes perangkat lunak akan dibenarkan baik dari segi waktu dan finansial. (Tidak, ini tidak bertentangan dengan yang disebutkan sebelumnya - karena situasi seperti itu sudah muncul dalam proses pengembangan aktif dan pada saat ini Anda dalam hal apa pun akan menyebarkan proses pengujian otomatis).
Dalam kasus apa pun, kemunculan kasus pertama yang memerlukan uji regresi atau pelepasan versi kedua aplikasi dan penskalaan tim yang terkait dengan peristiwa ini adalah saat ketika otomatisasi menjadi relevan (tetapi tidak mengecualikan pengujian manual fitur baru). Pada tahap ini, otomatisasi sudah akan mulai menghemat waktu: pengembang sendiri, bahkan sebelum transfer ke departemen QA, dapat menjalankan uji regresi fitur baru untuk memastikan bahwa itu tidak merusak fungsi yang ada, dan tester tidak harus melalui casing dasar yang sudah bosan lagi. Keuntungan lain dari penerapan autotest pada tahap ini adalah Anda dapat menjalankannya sesuai dengan jadwal tertentu - setiap malam, pada hari-hari akhir sprint, atau ketika menerbitkan versi baru aplikasi.
Pada saat yang sama, seseorang tidak boleh melupakan beberapa hal:
- membuat case dan menulis autotests akan memakan waktu - taruh dalam sprint;
- pastikan bahwa kasus autotest ditulis dengan baik dan terperinci dan menjelaskan kemungkinan masalah atau skenario yang ada secara keseluruhan;
- periksa apakah autotest berfungsi dengan benar dan apakah benar-benar memeriksa apa yang diperlukan dan melakukannya secara kualitatif.
Kami meringkas: pengujian manual memberikan keuntungan besar dalam kecepatan dan biaya tenaga kerja pada tahap awal, dan ketika aplikasi tumbuh dan sejumlah besar tes regresi muncul, itu masuk ke dalam kategori "pengujian operasional" fitur baru dalam sprint terpisah. Ini akan relevan dan, jika perlu, segera memeriksa bagaimana aplikasi akan menanggapi perubahan dalam sistem operasi atau memperbarui lingkungan.
Tahap pengujian: apa, kapan dan bagaimana
Jika Anda melihat proses pengembangan secara keseluruhan dan pengujian sebagai salah satu bagiannya, maka dengan perencanaan yang tepat Anda akan selalu memahami apa dan kapan akan siap. Ini akan memungkinkan Anda untuk merencanakan waktu tindakan tertentu dengan lebih baik - karena beberapa peristiwa secara logis mengikuti yang lain dan Anda memiliki kesempatan untuk mengaturnya berantai berdasarkan harapan Anda.
Penguji muncul dalam proses membuat aplikasi pada tahap awal. Di sini klien memiliki ide tertentu, analis bisnis mengumpulkan dari persyaratan ini - dan penguji sudah pada saat ini mulai bekerja, memeriksa persyaratan ini.
Bagaimana kabarnya? Mereka mengajukan pertanyaan tentang fungsi yang dimaksud. Mereka mencoba membayangkan bagaimana aplikasi akan terlihat ketika diimplementasikan. Jika kita berbicara tentang fitur baru pada produk yang sudah ada - mereka mencari tahu bagaimana itu akan berinteraksi dengan fungsionalitas yang ada. Setelah pengembang menilai kompleksitas ide klien dan menentukan berapa banyak waktu yang diperlukan untuk implementasi mereka.
Setelah itu, fase desain dimulai. Di sini menjadi perlu untuk memahami bagaimana transisi antar layar akan dilakukan, bidang-bidang tertentu yang akan divalidasi, bagaimana aplikasi atau fungsinya yang terpisah umumnya akan berinteraksi dengan pengguna akhir. Dalam hal fitur, penting untuk memahami bagaimana mereka akan dimasukkan dalam arsitektur aplikasi yang ada.
Pada tahap desain , ketika peta transisi antar layar dibuat, tester mengklarifikasi perilaku elemen individu yang dikandungnya dan efek visual apa yang akan menyertai tindakan pengguna tertentu. Selain itu, tester memvalidasi tata letak untuk kelengkapan, mengonfirmasi bahwa mereka menampilkan semua yang diperlukan untuk mengimplementasikan fungsionalitas yang dimaksud. Juga bermanfaat untuk memeriksa tata letak secara independen untuk kepatuhan terhadap pedoman.
Rekomendasi Skillbox: Desain Aplikasi Seluler kursus online
Dengan awal pengembangan, spesialis QA segera mulai menulis kasus uji. Pada tahap pengembangan yang berbeda, mereka mungkin memiliki tingkat detail yang berbeda, tetapi pada akhirnya diinginkan untuk memastikan cakupan maksimum dari seluruh kasus produk, sehingga, setelah menerima perakitan, Anda dapat segera memulai pengujian.
Langkah pertama dari pengujian itu sendiri adalah tes asap: penilaian bahwa aplikasi atau bagian barunya umumnya siap untuk verifikasi. Tes asap adalah tes apakah aplikasi atau fungsi tertentu diluncurkan pada prinsipnya.
Tes asap adalah cara cepat untuk melihat apakah kita bahkan dapat memulai pengujian fungsional. Istilah ini berasal dari pencipta papan sirkuit dan sirkuit mikro, yang pertama-tama harus memastikan bahwa sirkuit baru tidak akan terbakar - karena itu namanya: merokok / tidak merokok.
Ini adalah cara cepat untuk memastikan bahwa kami benar-benar telah melewati tugas dan dapat mulai bekerja, dan tidak dikirim kembali ke programmer.
Dengan menggunakan formulir otorisasi sebagai contoh, asap adalah penilaian apakah Anda dapat masuk sama sekali, tanpa menentukan apakah data yang dimasukkan dalam bidang tersebut valid, apakah fitur tambahan seperti pengingat kata sandi dan hal-hal lain berfungsi. Jika kami dapat masuk pada prinsipnya, kami dapat melanjutkan ke verifikasi modul ini lebih lanjut: mengambil kasus negatif, nilai batas, menilai kepatuhan dengan aturan validasi yang ditetapkan.
Tahap selanjutnya adalah melakukan tes regresi. Dalam mode manual atau otomatis, serangkaian tes utama yang telah direncanakan dilakukan.
Pengujian regresi baik karena memungkinkan Anda untuk menemukan kesalahan bahkan di tempat-tempat di mana semuanya sudah beres sebelumnya. Hal ini disebabkan oleh fakta bahwa regresi adalah penilaian fungsionalitas pada serangkaian kasus standar selama implementasi setiap modul baru dan setiap perubahan aplikasi. Memang, ketika pengembang menambahkan fungsionalitas baru, versi saat ini mungkin rusak atau fitur baru mungkin bertentangan dengan yang sudah ada.
Misalnya, menambahkan layar baru, dan karena itu mengubah navigasi, dapat mengganggu fungsi menu, atau setidaknya menampilkannya. Di sisi lain, refactoring global kode aplikasi dapat membawa kejutan yang tidak menyenangkan - setelah itu, juga diperlukan untuk melakukan tes regresi.
Masalah dapat disebabkan oleh memperbarui perpustakaan yang digunakan oleh aplikasi dan mengubah lingkungan di mana ia bekerja. Semakin sering Anda memperbarui aplikasi, semakin penting pemeriksaan regresi. Jangan membatasi diri Anda untuk pemeriksaan satu kali, dilakukan ketika fitur sudah diterapkan - periksa semua perubahan. Otomatisasi pengujian regresi akan membantu Anda di sini - hanya karena pengujian regresi manual dari fitur baru yang dibuat hanya dalam waktu seminggu dapat memakan waktu dua, atau bahkan lebih, dan departemen pengujian hanya akan terjebak dalam hal ini.
Pemeriksaan penuh, tentu saja, dilakukan ketika kandidat rilis dengan satu atau lebih fitur siap untuk diluncurkan ke produksi, tetapi masih diperlukan untuk menerapkan kasus-kasus tertentu yang relevan pada tahap pengembangan tertentu.
Semuanya berakhir dengan pengujian perakitan akhir - kandidat rilis. Ini termasuk memeriksa versi beta oleh penguji internal, pengujian bisnis - mengevaluasi produk yang dihasilkan oleh klien dan menerima umpan balik darinya, serta mengundang sekelompok pengguna tertentu untuk berkenalan dengan versi alfa pra-rilis dari aplikasi atau fitur-fitur barunya. Setelah itu, aplikasi siap diluncurkan untuk diproduksi.
Tetapi pekerjaan spesialis QA tidak berakhir di sana - ia harus menguji pembaruan aplikasi dan kompatibilitasnya dengan versi sebelumnya, mengkompilasi kasus untuk memeriksa inovasi dan, jika perlu, mengotomatiskan jalannya skenario ini.
Secara paralel, penguji berpartisipasi dalam analisis statistik lanjutan yang dikumpulkan oleh analis, memantau perilaku aplikasi dan bagaimana pengguna berinteraksi dengannya. Hal ini memungkinkan tidak hanya untuk melihat penggunaan langsung hasil pekerjaan mereka, tetapi juga, kadang-kadang, untuk menemukan skenario baru dan bug yang tidak diketahui yang menyebabkan aplikasi mogok.
Waktu rebus: tebak dan diskon sepuluh persen untuk kursus Skillbox sedang menunggu Anda saat ini atau tunjukkan ketekunan dan kumpulkan jawaban untuk semua rebus - diskon ini saling menambah satu sama lain (tetapi tanpa diskon lain pada kursus Skillbox).
Namun, Anda tidak harus menunda terlalu banyak - promosi berjalan hingga 30 Agustus 2018. Ingat bahwa subjek teka-teki adalah ponsel, dan kata-kata bahasa Inggris dapat mengganggu bahasa Rusia di sini, jadi berhati-hatilah! Kirim aplikasi untuk kursus, dan ketika manajer menghubungi Anda, beri dia pesan, dienkripsi dalam rebus (atau beberapa!).
Formalisasi pengujian: rencana pengujian, format laporan bug, pelaporan
Untuk mempersiapkan pengujian fungsional, seorang insinyur QA menyusun rencana pengujian. Ini adalah dokumentasi yang akan dia perlukan saat menguji produk, daftar tindakan yang perlu dia lakukan. Rencana pengujian menunjukkan waktu pengujian, menjelaskan produk atau tugas tertentu - untuk menentukan dengan tepat apa yang perlu diperiksa. Semua kasus uji utama dijelaskan secara rinci. Daftar jenis-jenis pengujian yang diperlukan: fungsional dan, misalnya, stres. Prosedur untuk mengotomatisasi kasus-kasus tertentu dan tahapan di mana mereka akan diuraikan dijelaskan.
Rencana pengujian diakhiri dengan deskripsi format laporan: Anda perlu menjelaskan terlebih dahulu dalam bentuk apa hasil akan diberikan. Format laporan yang paling umum adalah daftar kasus uji dengan status bagian mereka. Mengetahui bagaimana kasus mencakup seluruh volume persyaratan dan setelah membaca laporan, kita dapat menyimpulkan keadaan pengembangan aplikasi saat ini. Untuk melakukan ini, cukuplah untuk melihat berapa banyak dari mereka yang berhasil diselesaikan dalam satu atau beberapa majelis lainnya.
Lampu hijau terakhir, menunjukkan bahwa produk siap, adalah status "semua persyaratan dicakup oleh kasus, semua kasus diselesaikan dengan sukses."
Selain itu, rencana pengujian memformalkan format laporan kesalahan. Ini mungkin daftar bug, daftar tugas di pelacak.
Tugas penguji adalah untuk memberikan informasi paling lengkap tentang kualitas produk kepada semua anggota tim.
Apa yang perlu Anda ketahui dan bisa menjadi tester
Pertama-tama, penguji harus mampu berpikir dan penuh perhatian serta tekun. Pengalaman itu penting - memungkinkan Anda mengumpulkan pencapaian tertentu dan mengkonsolidasikan pengetahuan tentang proses pengujian, mengubahnya menjadi keterampilan.
Seorang spesialis tes manual tidak harus dapat menulis kode dan memiliki pemahaman yang mendalam tentang arsitektur. Ini tidak mencegahnya untuk memeriksa fungsionalitas dan memahami prinsip-prinsip interaksi antara aplikasi dan server di tingkat aplikasi.
Seorang spesialis dalam pengujian otomatis adalah profesi yang terpisah, dengan serangkaian pengetahuan yang sangat berbeda.
Pengujian mandiri berkualitas tinggi tidak hanya skrip, tetapi juga pemahaman tentang bagaimana aplikasi dibangun dari dalam, dan keterampilan khusus, seperti mengetahui cara memparalelkan pengujian atau cara menjalankannya di cloud atau di beberapa server. Hanya sekumpulan keterampilan yang memungkinkan kita untuk dengan bangga menyebut diri kita "insinyur otomatisasi dengan huruf besar". Jadi tanpa pengetahuan bahasa, kerangka kerjanya, prinsip-prinsip OOP dan pemantauan yang cermat terhadap perkembangan teknologi, autotester ini tidak bisa dilakukan.
Jalur setiap penguji dimulai dengan menguasai dasar teoritis pengujian, memperoleh gagasan awal tentang bagaimana aplikasi berinteraksi dengan server dan dengan lingkungan. Jika pengetahuan ini ada, dan dengan itu orang tersebut memiliki niat yang sangat serius untuk belajar, ia sudah dapat dianggap sebagai penguji junior. Sekelompok pendatang baru dengan mata bersinar ditugaskan spesialis senior - baik penguji terkemuka, atau, jika perusahaan mampu membelinya, seorang pelatih yang sengaja memompa bangsal. Mereka menjelaskan momen-momen yang tidak bisa dipahami oleh para junior dan memberikan tugas-tugas yang menyakitkan seperti menjalankan fitur-fitur pada kasus uji. Dalam prosesnya, seseorang belajar membaca kasus uji dan menguasai dasar-dasar praktis pengujian fungsional. Pada tahap ini, para junior masih perlu memeriksa kualitas tes mereka, melewati mereka setelah mereka.Langkah selanjutnya adalah membuat rencana pengembangan individu (atau kolektif, tergantung pada ukuran perusahaan), yang menurutnya penguji pemula harus mengembangkan, menguasai pengetahuan baru dan mencapai hasil tertentu dalam waktu yang diberikan kepadanya untuk ini. Inilah cara untuk menjadi spesialis tingkat menengah.Penguji tengah adalah orang yang sudah mampu secara mandiri memenuhi tugas yang diberikan kepadanya, menemukan solusi dan umumnya melakukan pekerjaannya secara sadar, daripada mengikuti algoritma yang dibuat secara membabi buta.Dengan pengembangan keterampilan desain pengujian, pengetahuan di bidang fungsional dan terapan, serta pengembangan teknik pengujian baru - yang sekarang perlu dikembangkan secara mandiri - terjadi transformasi bertahap menjadi spesialis terkemuka. Sekarang mereka dapat mempercayakan kepadanya perawatan dan dukungan dari junior yang sama seperti dirinya sebelumnya.Level selanjutnya adalah test lead. Dia sudah dapat mengelola tim, yang mencakup perwakilan dari ketiga kategori sebelumnya, proses yang dia kontrol dan waktu yang dia kelola, termasuk dengan berpartisipasi dalam perencanaan proses pembangunan global, mengevaluasi biaya tenaga kerja dan penganggaran untuk timnya.Pertumbuhan timbal vertikal lebih lanjut adalah manajemen departemen atau transisi ke manajemen produk. Namun, jika seseorang berusaha untuk pengetahuan baru, dan bukan untuk posisi administrasi baru, maka ia dapat memilih pengembangan, analitik, atau arah seperti DevOps, menggabungkan tanggung jawab administrator sistem, penguji, dan pemrogram.Pengujian hanyalah salah satu dari banyak bidang pengembangan ponsel yang kami pertimbangkan sebagai bagian dari kursus “Pengembang Fullstack-Mobile”. Para profesional industri yang bekerja dengan kami akan berbagi pengalaman mereka dengan Anda dan memeriksa pekerjaan rumah Anda, dan hasil pelatihan dapat diterima untuk magang di perusahaan besar. Datanglah ke kami untuk belajar!Skillbox merekomendasikan: