(dari Tester Story Cycle )Halo semuanya. Seperti yang mungkin Anda perhatikan, intensitas peluncuran kursus di OTUS meningkat setiap bulan, dan pada bulan Maret ada banyak dari mereka. Hari ini kami ingin bertepatan dengan peluncuran kursus
"Otomasi pengujian web" , yang dimulai pada pertengahan Maret. Selamat membaca.
Saya masih melihat banyak penguji yang berbicara tentang jumlah bug dan kerentanan yang ditemukan, sebagai ukuran keberhasilan pengujian. Baru-baru ini, saya melihat sudut pandang yang berbeda, yang menyatakan bahwa esensi sebenarnya dalam kualitas kesalahan, tetapi tidak dalam kuantitasnya. Namun, dengan ukuran ini juga perlu diperhatikan. Sekarang kita akan membicarakan ini.
Gagasan utamanya adalah bahwa metode pengujian ditentukan oleh jenis kesalahan yang perlu Anda temukan.
Saya sudah berbicara tentang beberapa aspek dari topik hari ini sebelumnya dalam
percakapan tentang perburuan serangga . Saya tidak ingin mengulang sendiri, jadi saya akan mencoba untuk singkat. Saya akan memformalkan tesis pemikiran saya dan dalam kaitannya dengan tim tempat saya bekerja.
Yang penting bagi saya dalam pengujian adalah dampak pada pengguna sehingga mereka membuat keputusan yang tepat lebih cepat. Untuk melakukan ini, Anda harus menggunakan loop umpan balik yang ketat untuk mempersingkat waktu antara pengembang membuat kesalahan dan kemudian memperbaikinya. Kesalahan ini adalah area di mana berbagai kualitas - perilaku, kinerja, keamanan, kegunaan, dll. - tidak ada atau memburuk.
Ini jelas tidak diukur dengan jumlah kesalahan yang ditemukan, tetapi sifat kesalahan memainkan peran. Tugas saya adalah menemukan kesalahan yang paling mengancam integritas dan kualitas pengembangan. Ini mungkin dapat dikaitkan dengan "kualitas" kesalahan, yaitu, kesalahan ini semakin penting semakin mereka mengancam integritas.
Kunci untuk koreksi kesalahan yang efektif, menurut saya, adalah menemukan kesalahan ini secepat mungkin, idealnya segera setelah muncul. Meskipun dari sudut pandang saya, bahkan "kualitas kesalahan" jauh dari ukuran tertinggi.
Kami sangat mementingkan kualitas kesalahan, tetapi apakah benar-benar jumlah mereka pada umumnya tidak signifikan?
Bahkan, jumlah kesalahan penting jika Anda sangat terpaku pada pengurangan jumlah waktu untuk mencarinya. Katakanlah sistem memiliki 10 bug kritis. Dan saya sangat cepat menemukan dua dari mereka, dan itu sangat keren! Dua kesalahan kritis ditemukan sebelum produk diperkenalkan. Tetapi saya tidak menemukan orang lain sebelum ditempatkan. Ini berarti bahwa 8 kesalahan kritis tidak ditemukan. Dalam hal ini, jumlah kesalahan adalah ukuran kunci, bahkan jika kita tidak memahaminya saat itu.
Penting untuk berpikir dengan cara yang sedikit berbeda. Jumlah kesalahan atau kualitasnya tidak begitu penting sebagai mekanisme yang dengannya mereka terjadi dan, karenanya, mekanisme untuk pencarian mereka. Ada banyak opsi yang tersedia:
- Mekanisme yang bagus dalam menemukan bug, tetapi itu bekerja terlalu lama;
- Mekanisme yang menemukan bug buruk, tetapi bekerja sangat cepat;
- Mekanisme yang “cenderung” memperhatikan bug dari jenis tertentu, tetapi pada saat yang sama tidak melihat yang lain;
- Mekanisme yang tidak terlalu populer dengan penguji, tetapi benar-benar bekerja dan tidak menggunakannya, karena tidak ada yang tahu tentang mereka dalam tim, itulah sebabnya apa yang dapat ditemukan tetap dapat ditemukan;
- Mekanisme yang dapat bekerja dengan baik dan cepat, mampu menemukan banyak kesalahan, tetapi respon dari mereka sangat kabur sehingga orang tidak dapat membuat keputusan berdasarkan output mereka.
Berfokus pada aspek-aspek ini, tidak kurang dari yang diketahui, adalah penting karena membantu untuk menghindari beberapa masalah yang timbul secara tradisional. Misalnya, saat Anda menjalankan seratus tes, tetapi tidak menemukan satu bug pun. Dan ini mungkin bagus, tetapi hanya jika benar-benar tidak ada kesalahan. Tetapi jika mereka ada, maka ini buruk jika metode pengujian yang diterapkan tidak dapat mengidentifikasi mereka. Atau situasi ketika saya menjalankan banyak tes, saya menemukan kesalahan kecil, sambil melewatkan yang lebih sulit.
Saya dan tim saya harus membuat keputusan berdasarkan tes yang dilakukan. Ini berarti bahwa kita harus memercayai apa yang dikatakan oleh hasil tes yang kita sampaikan kepada kita, oleh karena itu, pada awalnya kita harus mempercayai metode deteksi yang diterapkan dalam tes ini.
Beberapa metode deteksi berasal dari tes itu sendiri, secara kasar, dari apa yang mereka cari dan bagaimana mereka mencari. Metode deteksi lain harus melekat pada lingkungan itu sendiri dan kemampuan pengujian, yang kami tentukan untuk menentukan seberapa mungkin dan mungkin, pada prinsipnya, bahwa pengujian akan menyebabkan kesalahan, jika ada.
Di akhir pemikiran singkat saya, saya ingin menyampaikan fakta bahwa saya tidak menentukan keberhasilan pengujian oleh faktor spesifik apa pun. Tetapi jika Anda masih ingin entah bagaimana menentukan ini untuk diri Anda sendiri, maka Anda harus menentukan bukan dengan jumlah kesalahan dan kerentanan yang ditemukan dan bukan oleh kualitas kesalahan ini, tetapi oleh kemampuan spesifik mekanisme pengujian untuk mendeteksi mereka.
Saya menemukan bahwa penguji yang tidak berpengalaman, setelah membaca catatan ini, tidak akan melihat perbedaan yang signifikan antara gagasan mendeteksi kemampuan dan hasil yang diperoleh setelah menyoroti fitur-fitur ini. Adapun para spesialis, mereka harus sangat membedakan mereka.
Mampu memahami dan merumuskan perbedaan ini, penguji dapat melampaui perbedaan yang tidak berguna (hanya pendapat penulis) antara "verifikasi" dan "pengujian" dan alih-alih membangun pemahaman konstruktif tentang metode deteksi, baik manusia maupun otomatis, yang memungkinkan pengujian untuk membantu orang membuat keputusan yang lebih baik lebih cepat.
Berikut ini bahan yang tampaknya sederhana, tetapi cukup bermanfaat. Menurut tradisi yang ada, kami menunggu komentar Anda dan kami mengundang Anda ke
webinar terbuka , yang akan diadakan pada 11 Maret oleh
Mikhail Samoilov , alat otomatisasi pengujian terkemuka di Group-IB.