Get best of the week

Buku "Cara menguji di Google" - versi elektronik gratis

gambarHalo, habrozhiteli!

Buku ini menjelaskan pengujian produk perangkat lunak di Google: bagaimana proses diatur, bagaimana tim diatur, teknik apa yang digunakan, siapa yang bertanggung jawab atas kualitas. Prinsip-prinsip yang menjadi dasar pengujian Google berlaku untuk proyek dan perusahaan dengan ukuran berapa pun. Penulis buku itu sendiri bekerja pada produk Google, membuat alat pengujian, menyesuaikan proses, dan melakukan pengujian secara langsung.

Buku ini ditujukan untuk para profesional dari industri pengembangan perangkat lunak: spesialis pengujian, programmer, manajer.

Kutipan. Pengurangan risiko


Jarang mungkin untuk sepenuhnya menghilangkan risiko. Kami mengendarai mobil, meskipun ini berbahaya, tetapi apakah kami harus mulai bekerja? Secara umum, kemungkinan kecelakaan tidak berarti itu akan terjadi, dan, kemungkinan besar, tidak ada hal buruk yang akan terjadi. Mengapa? Karena dengan tindakan kami, kami mengurangi risiko yang mungkin terjadi. Misalnya, kami tidak mengemudi saat mabuk dan tidak mengemudi dalam kondisi visibilitas yang tidak memadai. Dengan demikian, kami mengurangi risiko.

Dalam pengembangan produk perangkat lunak, hal paling sederhana adalah menghindari area berisiko: semakin sedikit kode, semakin sedikit risiko. Tetapi selain menggunakan "kapak dan kapak", kita dapat melakukan lebih banyak untuk mengurangi risiko:

  • , , .
  • -, , .
  • , .
  • .
  • , . , .

Solusi spesifik tergantung pada fitur aplikasi, pada harapan pengguna mengenai keamanan dan keandalannya. Sebagai penguji, kita, tentu saja, dapat terlibat dalam proses pengurangan risiko, tetapi kita tentu saja terlibat dalam proses mengidentifikasi mereka. Kami mulai dengan memprioritaskan fitur yang ditandai dengan warna merah di tabel. Kami ingin menguji untuk mengurangi risiko. Ini penting: jika Anda tidak dapat menguji semuanya, pertama-tama uji hal yang paling penting. Dan yang paling penting adalah bahwa hal itu paling terbuka pada risiko paling serius.

Dalam beberapa proyek, penguji yang bertanya tentang kesiapan produk untuk rilis. Cukup bagi penguji yang baik untuk melirik peta panas untuk menentukan apakah masih layak untuk menyimpan produk di dalam oven atau sudah waktunya untuk menyajikannya di atas meja. Jika kita berbicara tentang meluncurkan Google Labs eksperimental, maka keberadaan zona risiko merah tidak begitu signifikan, jika mereka tidak terkait dengan keamanan, tentu saja. Dan jika ini adalah rilis versi baru Gmail, maka bahkan zona kuning adalah bahaya serius. Gradasi warna yang sederhana ini jelas bagi semua orang, bahkan manajer puncak.

Kekhawatiran tentang risiko mereda dari waktu ke waktu, dan volume besar pengujian yang sukses adalah pertanda baik bahwa risiko berada pada tingkat yang dapat diterima. Di sini kita mendapat manfaat dari menghubungkan kasus uji dengan fitur produk individual, dan kemudian ke atribut dan komponen dalam tabel risiko. "Analisis ACC" sangat ideal untuk kasus ini, dan itulah sebabnya kami membuat alat ini begitu saja.

Rencana Tes Resep James Whittaker dalam Sepuluh Menit


, , . , , — ? , , . Google, , -. , , : «», « » — « » ( ). ’, , - , .

— . -, , — , , ( ), , , . : , ,
?

- , , , . , — . : ?

- , - . . : -.

, : - . - , .

, . : . , , .
-, .

. : « , - ». , , . , , , , .

, , , (Google Docs, App Engine, Talk Video . .), .

, ACC-. , . — , — . , . - — . , , .

’, - . . ,
- .

, . , . 80% . ? , , ? , (, , ) . , , .

. -!


Google Test Analytics mengambil sebagai dasar kriteria penilaian risiko yang dijelaskan di atas ("sangat jarang", "jarang", "kadang-kadang", "sering"). Kami secara khusus tidak ingin mengubah analisis risiko menjadi tugas yang sulit, jika tidak maka tidak akan selesai. Kami tidak tertarik pada detail matematika yang tepat, karena angkanya kecil. Cukup mengetahui bahwa "A" lebih berisiko daripada "B", tidak memperhatikan signifikansi risiko yang sebenarnya. Pengetahuan sederhana tentang peluang mana yang lebih berisiko daripada yang lain akan memungkinkan manajer pengujian untuk mendistribusikan pekerjaan penguji secara lebih efisien. Dan orang-orang seperti Patrick Copeland dapat dengan mudah memutuskan berapa banyak penguji untuk ditugaskan ke setiap tim pengembangan. Memahami risiko menguntungkan seluruh perusahaan.

Analisis risiko adalah bidang ilmiah independen yang dihormati di banyak industri. Kami menggunakan versi metodologi yang disederhanakan, tetapi ini tidak menghalangi kami untuk tertarik pada penelitian baru untuk meningkatkan pendekatan kami dalam pengujian. Jika Anda ingin mempelajari lebih lanjut tentang analisis risiko, mulailah dengan artikel "Manajemen Risiko" di Wikipedia.

GTA membantu mengidentifikasi risiko, dan pengujian membantu menguranginya. Penguji berfungsi sebagai perantara dalam proses ini. Dia dapat melakukan tes internal di beberapa area yang paling berisiko atau pengembang tugas dan pengembang dalam pengujian sehingga mereka menambahkan tes regresi. Ada alat lain dalam gudang senjata: pengujian penelitian, menarik pengguna internal dan beta dan kekuatan komunitas eksternal.

Penguji bertanggung jawab untuk mengetahui semua bidang yang berisiko. Dia harus mencoba mengurangi risiko dengan cara apa pun yang dikenakan padanya. Berikut adalah beberapa rekomendasi yang kami temukan berguna dalam menghadapi risiko.

  1. Untuk fitur yang paling berisiko dan pasangan atribut / komponen yang ditandai dengan warna merah, tulis satu set cerita pengguna, kasus penggunaan, atau panduan tes. Di Google, tanggung jawab untuk peluang paling berisiko terletak pada penguji. Dia dapat mengoordinasikan pekerjaannya dengan kolega, menggunakan alat yang berbeda, tetapi tanggung jawab pribadi masih ada padanya.
  2. , . , GTA? ? ? . , , .
  3. , / , , . .
  4. — . , . , . , : «!», . , .
  5. , . , , . , « ?» « ?». Google , , .
  6. 6 , , , . ! .




, . , , , .

, , - . - , , , . , , . , , .

, , . -, - — !

— . - . — . Google , . -: Google Documents — , .

, , , . — .

Kami tidak akan terlalu salah dengan peluang berisiko rendah. Kami dapat memutuskan bahwa menulis kasus uji untuk area ini terlalu mahal. Sebaliknya, kita dapat membatasi diri pada pengujian penelitian atau pengujian crowdsource. Untuk mengelola pekerjaan penguji dari komunitas eksternal, kami sering menggunakan konsep wisata - ini adalah instruksi tingkat tinggi untuk pengujian penelitian. Sederhananya, pendekatan ini memberikan permintaan Anda spesifik yang Anda butuhkan. Misalnya, bertanya kepada komunitas: "Habiskan tur FedEx untuk serangkaian fitur" - kami akan mendapatkan hasil yang jauh lebih baik daripada hanya memberikan aplikasi dan berharap yang terbaik. Kami segera menentukan fitur yang perlu diuji, dan memberikan instruksi tentang cara melakukan ini.

Crowdsourcing




— . , , - ! , . . ?

, , . , , — , , -. , Chromium, . , , . , .

( ) — . , , . , , ? — .

, , , . , : -1000 , : Chrome, : 1 = 1000 20 = 50 . .

, , , . , , . Chrome, , , ( « Chrome»). . , . « , » , .

- — Google: , , . , . , , , (, uTest). .

Jadi, kekuatan analisis ACC adalah bahwa kita mendapatkan daftar fitur produk yang dapat diurutkan berdasarkan risiko dan ditugaskan untuk pemain yang berbeda. Penguji yang mengerjakan proyek yang sama dapat menerima serangkaian kemampuan uji yang berbeda. Pengguna internal, peserta “dua puluh persen”, penguji, penguji komunitas, pengembang, pengembang dalam pengujian semua akan menerima daftar fitur mereka, dan, bagi penguji, area-area penting akan ditutupi dengan lebih sedikit tumpang tindih daripada jika kami hanya menyerahkan aplikasi untuk menguji untuk semua orang.

Pekerjaan penguji, berbeda dengan pekerjaan pengembang dalam pengujian, tidak berakhir dengan masuknya produk.

» Unduh epub dan pdf

More articles:


All Articles