QA best practices
1.0.0
Ini adalah ringkasan dari praktik QA yang digunakan dan merekomendasikan untuk digunakan. Ini tidak seharusnya menjadi deskripsi terperinci dan kadang -kadang tidak dapat sepenuhnya digunakan dari semua tugas tetapi sebagai ikhtisar dari proses QA paling penting dan daftar praktik baik yang harus digunakan.
Untuk tujuan kejelasan, dokumen ini tidak menggambarkan kesalahan atau proses insiden (yaitu bug baru ditemukan dari produksi).
Semua orang di tim Futurice memiliki tanggung jawab QA, bahkan jika ada manajer QA bernama atau spesialis QA. Untuk futurice qa berarti tiga hal.
Pada pekerjaan QA tingkat tinggi dan praktik dapat dibagi menjadi dua proses.
Selanjutnya ada tindakan QA lainnya.
Futurice menggunakan metode TDD dan ATDD (Pengembangan Tes Penerimaan) bila berlaku.
Metode memaksa implementasi untuk mengikuti arsitektur dan mempertimbangkan modul yang digunakan. Implementasi dimulai dengan menulis tes otomatis terlebih dahulu dan kemudian menerapkan fungsionalitas untuk lulus tes.
Futurice menggunakan metode pemrograman pasangan bila berlaku. Ini adalah cara yang sangat nyaman untuk berbagi pengetahuan dan pengalaman tentang proyek dan perangkat lunak yang sedang dikembangkan.
Meninjau kode membantu anggota tim lain untuk mendapatkan informasi dari fungsionalitas tertentu dan memberikan kemungkinan untuk memberikan umpan balik kepada orang yang bertanggung jawab dan juga memastikan berbagi pengetahuan antara anggota tim.
Pengujian manual sebagian besar dilakukan dengan menggunakan metodologi pengujian eksplorasi dan kesalahan ditemukan segera diperbaiki atau diprioritaskan dan direkam ke alat manajemen tugas/cerita/kesalahan. Menjelajahi aplikasi atau layanan dapat dimulai tepat setelah sesuatu yang fungsional "siap".
Pengujian eksplorasi adalah alat yang sangat kuat pada pengujian ujung ke ujung di mana seluruh sistem dicakup oleh pengujian. Dalam metode tester melampaui apa yang dapat didefinisikan dalam kasus uji, menerapkan pemikiran seperti pengguna serta mencoba untuk memecahkan sistem dengan berbagai skenario kesalahan dan tidak pernah "dilakukan" dengan pengujian.
Di sekitar persyaratan fungsional dan pengujian biasanya ada persyaratan non-fungsional yang dapat diuji menerapkan lokalisasi, kegunaan, kinerja, dan pengujian beban. Kebutuhan dan alat -alatnya adalah proyek yang spesifik. Untuk pengujian kegunaan, Futurice memiliki laboratorium kegunaan seluler untuk digunakan. Untuk tes kinerja, Futurice telah menggunakan layanan berbasis web seperti Browsermob untuk menyebutkannya. Untuk pengujian beban LoadUI dan J Meter secara aktif digunakan untuk memvalidasi kemampuan layanan dalam lalu lintas tinggi dan untuk menemukan kemungkinan hambatan layanan.
Masalah yang ditemukan dicatat ke alat atau papan tertentu dengan informasi seperti prioritas, lingkungan (perangkat lunak dan informasi perangkat), langkah -langkah untuk mereproduksi, hasil yang diharapkan, waktu dan tanggal dan tangkapan layar. Alat seperti Jira, Trello, PivotalTracker, Tracker permintaan secara aktif digunakan juga untuk pelacakan kesalahan.
Salah satu prinsip Agile adalah bahwa cabang Kode Master harus selalu berpotensi dapat disetujui. Itu berarti harus selalu kualitas produksi. Ini dicapai dengan cara berikut:
Setiap kisah pengguna (atau fitur) dikembangkan secara individual di cabang fitur mereka sendiri. Tujuan dari ini adalah untuk memastikan bahwa setiap pembaruan ke Master Branch pada saat yang sama 1) sekecil mungkin dan 2) berpotensi dapat disetor, cerita lengkap.
Sebelum cabang fitur dapat digabungkan ke cabang master, ia harus melewati daftar tindakan, persyaratan, dan praktik yang disebut Definisi Selesai (DoD). Ini didefinisikan bersama dengan PO Pelanggan dan tim pengembangan dan dapat dimodifikasi selama proyek jika proyek perlu berubah.
Item berikut dalam DoD yang diusulkan telah dicetak tebal karena
Proses penyebaran adalah proses bagaimana rilis baru (atau versi di Master Branch) digunakan untuk produksi. Untuk proses ini ada tiga lingkungan yang relevan.
Server integrasi kontinu (CI) digunakan untuk pengujian otomatis dan menggunakan kode ke lingkungan. Tes otomatis dijalankan selalu ketika salah satu dari lingkungan ini diperbarui.
Lingkungan uji diperbarui secara otomatis oleh CI, setiap kali Cabang Master telah diperbarui. Ini berarti bahwa kasus uji otomatis juga dijalankan secara otomatis ketika cabang master diperbarui.
Lingkungan uji adalah server pengujian utama untuk Futurice. Diharapkan bahwa setiap rilis yang telah diuji di sini siap untuk didorong ke QA atau produksi (ini tergantung terminologi dan integrasi yang digunakan dalam proyek).
Tidak perlu menjalankan kasus uji regresi manual, saat memperbarui tes. Cukup sering waktu yang dihabiskan untuk pengujian eksplorasi lebih bermanfaat. Namun, ini adalah praktik yang baik untuk menjalankan tes ini setidaknya sekali per sprint.
Lingkungan QA harus digunakan sebagai lingkungan untuk tes penerimaan, demo atau pengujian atau audit pihak ke -3 (keamanan, lokalisasi, beban, kegunaan dll.). Ini bukan server pengujian utama Futurice (tes adalah). Pembaruan untuk QA selalu disepakati antara PM pelanggan dan Futurice.
Alasan utama untuk memiliki dua lingkungan pengujian (Tes dan QA) adalah untuk mematuhi persyaratan keamanan dan integrasi. Tes memungkinkan Futurice untuk mengembangkan layanan menggunakan prinsip Agile. QA memungkinkan waktu dan kontrol bagi pelanggan untuk menjalankan proses QA mereka saat ini.
QA tidak boleh diperbarui kecuali rilis telah lulus pengujian di lingkungan pengujian.
Lingkungan Prod adalah lingkungan untuk situs langsung (produksi).
Praktik yang baik adalah menggunakan dan menjalankan tes otomatis setidaknya dalam QA, sebelum mendorong pembaruan ke Prod. Namun pada fungsi utama Prod perlu diperiksa setelah setiap penyebaran.
Dianjurkan agar PO juga memiliki hak untuk mendorong pembaruan untuk Prod, tanpa pengujian di QA (jika versi dilewatkan dalam pengujian). Ini relevan di mana pembaruan sangat kecil atau sederhana.
Pada akhirnya dalam pengembangan Agile, ketika layanan ini dalam pengembangan berkelanjutan, tujuannya adalah untuk memiliki banyak pembaruan kecil juga untuk didorong. Yaitu lebih penting bahwa proses penyebarannya ramping dan cepat daripada anti peluru. Dianggap lebih penting untuk dapat melakukan perbaikan dengan cepat daripada memiliki layanan bebas bug (jelas dengan DOD dan pengujian otomatis kualitas juga harus tinggi). Futurice tidak merekomendasikan memulai dengan pendekatan ini segera. Namun, ini harus menjadi arah di mana kedua organisasi ingin pergi.
Setiap platform seluler memiliki SDK spesifik, set alat, dan praktik terbaik Futurice.
Untuk android https://github.com/futurice/android-best-practices
Untuk ios https://github.com/futurice/ios-good-practices
Untuk Windows Phone https://github.com/futurice/windows-app-development-best-pactices
Platform seluler menyediakan emulator dalam SDK mereka.
Selama fase implementasi, pengembang dapat menggunakan perangkat yang disimulasikan / ditiru untuk memvalidasi perubahan tetapi tidak ada yang dapat mengalahkan pengujian perangkat nyata di mana seluruh sistem dari layar sentuh dan memori terintegrasi ke prosesor seluler dipertimbangkan.
Browser seluler juga dapat diuji dengan layanan berbasis cloud seperti BrowserStack.
Futurice memiliki variasi perangkat yang berbeda dan versi sistem operasi di perpustakaan perangkat, mulai dari ponsel dasar hingga tablet canggih.
Untuk pengujian aplikasi lalu lintas data yang padat dan validasi kinerja Futurice telah menggunakan Lab ELISA Test (ELISA adalah penyedia layanan seluler Finlandia). Di dalam lingkungan laboratorium, beban dan kecepatan yang berbeda dapat diuji di lingkungan yang terkontrol / terisolasi tanpa perlu mengatur sesi pengujian lapangan yang mahal dan bukan yang efektif.
Biasanya aplikasi seluler terhubung ke layanan backend melalui jaringan seluler. Untuk mendapatkan hasil maksimal dari pengujian, tester perlu memiliki kontrol penuh dari backend di mana aplikasi seluler terhubung untuk mempersiapkan dan menjalankan skenario uji ujung ke ujung yang berbeda.
Di perangkat seluler, instalasi Test Build dapat dilakukan: secara lokal dengan kabel menggunakan pengembangan alat SDK yang dikendalikan secara nirkabel melalui alat distribusi build seperti testflight atau hockeyApp. Kerangka kerja pelepasan biasanya mendukung pengumpulan log crash dan data versi. Rilis Dev, Alpha dan Beta juga dapat disediakan untuk mengumpulkan umpan balik sebelum merilis aplikasi ke toko. Google Play Store memiliki opsi untuk mengatur grup uji alpha dan beta di mana aplikasi spesifik hanya tersedia untuk anggota grup
Dalam aplikasi seluler modern analitik dan pengumpulan data mewakili fungsi kritis yang juga perlu diuji. Futurice menganggap ini sebagai bagian penting dari pengujian fungsional.
Karena fakta bahwa proses pembaruan aplikasi seluler berbeda dari satu aplikasi web, pengaturan analitik perlu mendapatkan langsung dari percobaan pertama atau kemudian data berharga terlewatkan. Proses pembaruan dilakukan melalui prosedur toko aplikasi, tetapi apakah pembaruan akan dilakukan atau tidak tergantung pada pengaturan dan aktivitas pengguna. Jadi jika versi pertama melewatkan beberapa fungsionalitas analitik kritis dan beberapa pengguna tidak pernah memperbarui aplikasi, data itu kemudian akan dilewatkan. Solusinya dapat dipaksa ditingkatkan, di mana aplikasi menjadi tidak dapat digunakan sampai pengguna memperbarui versi terbaru yang tersedia tetapi itu mungkin sudah terlambat.
